Они открыли для себя DHCP ? или там PPPoE ? какое новаторское прозрение! они ДОРОСЛИ!!! 2010/5/26 Vladimir Litovka :

http://www.triolan.ua/item.aspx?id=112

-- /doka

/*-- http://doka-ua.blogspot.com/ --*/

Приветствую, Всё статиками, вручную, с привязкой IP-MAC-port ... если о триолан. Вы писали 26 мая 2010 г., 12:11:19:

Они открыли для себя DHCP ? или там PPPoE ? какое новаторское прозрение! они ДОРОСЛИ!!!

2010/5/26 Vladimir Litovka :

...

http://www.triolan.ua/item.aspx?id=112

-- /doka

/*-- http://doka-ua.blogspot.com/ --*/

-- Sergey Galat

У меня DHCP с реальным адресом. Что я делаю не так ? :-) 2010/5/26 Sergey Galat :

Приветствую,

Всё статиками, вручную, с привязкой IP-MAC-port ... если о триолан.

Вы писали 26 мая 2010 г., 12:11:19:

...

Они открыли для себя DHCP ? или там PPPoE ? какое новаторское прозрение! они ДОРОСЛИ!!!

...

2010/5/26 Vladimir Litovka :

...

http://www.triolan.ua/item.aspx?id=112

-- /doka

/*-- http://doka-ua.blogspot.com/ --*/

-- Sergey Galat

-- Alexey Radetsky Phone: +380-44-5949641 Net Style: VAS and IT solutions www.netstyle.com.ua

Ты молодой абонент. Не застал, видать, Тех Времен (ТМ) гггггг :) :) :) 2010/5/26 Alex Radetsky :

У меня DHCP  с реальным адресом. Что я делаю не так ? :-)

Дык, с 2006 или 2007 года, примерно. Да ладно, фигня все это. :) 2010/5/26 Andrew Stesin :

Ты молодой абонент. Не застал, видать, Тех Времен (ТМ) гггггг :) :) :)

2010/5/26 Alex Radetsky :

...

У меня DHCP  с реальным адресом. Что я делаю не так ? :-)

-- Alexey Radetsky Phone: +380-44-5949641 Net Style: VAS and IT solutions www.netstyle.com.ua

Мля, а мене оце порадувало (той самий УРЛ): *Акция TrioLOVE is...* ПРАЗДНИЧНОЕ ТРИО КОТОРОЕ ОБЪЕДИНЯЕТ СЕРДЦА! Лямур-де-труа - це так еротично. Нема на них нац.комісії по моралі, сцуко... :))))) Нє, чуваки - креативщики конкретні! :)) 2010/5/26 Vladimir Zagaychuk

26 мая 2010 г. 12:04 пользователь Vladimir Litovka написал:

...

http://www.triolan.ua/item.aspx?id=112

-- /doka

/*-- http://doka-ua.blogspot.com/ --*/

http://www.triolan.ua/action.aspx "с 3 по 33 декабря подключись к Кабельному ТВ или локальной сети Triolan и пользуйся услугой бесплатно до 03.03" *Акция действует с 3.12.2009 по 02 января 2010 г.

33 декабря - это очень ок.

"Основное правило, которым руководствуется Triolan(R) - услуга должна быть доступной и понятной. Именно поэтому мы не продаем <<цифры>> - мегабиты, кол-во каналов... Мы предлагаем конкретный объем услуг."

Шо не ясно? (с)

-- Vladimir Zagaychuk (VZ485-RIPE)

Hello! Wed, May 26, 2010 at 04:38:32PM +0300, gul wrote:

On Wed, May 26, 2010 at 12:04:19PM +0300, Vladimir Litovka writes:

...

http://www.triolan.ua/item.aspx?id=112

А если серьёзно, то я не понимаю, какие есть причины выдавать всем абонентам белые ip (а не только тем, кто явно захотел статический за отдельную плату), кроме отсутствия технической возможности их занатить.

RIPE нормально смотрит на выдачу абонентам белых IP?

RIPE не имеет права отказать даже если ты на все возможные железки у абонента захочешь выделять "белые" IP. :)

-- Паша.

-- Best regards, Igor Kremez Internet Data Center "ColoCALL"

Pavel Gulchouck wrote:

On Wed, May 26, 2010 at 12:04:19PM +0300, Vladimir Litovka writes:

...

http://www.triolan.ua/item.aspx?id=112

А если серьёзно, то я не понимаю, какие есть причины выдавать всем абонентам белые ip (а не только тем, кто явно захотел статический за отдельную плату), кроме отсутствия технической возможности их занатить.

Во-первых, часть сервисов из-за ната работает криво или не работает вообще, а те, что работают - работают медленно. Во-вторых, по нашим подсчетам на сети уже с 1000 пользователей стоимость натящей железки ощутимо больше прихода денег "за реальный адрес".

RIPE нормально смотрит на выдачу абонентам белых IP?

Отлично смотрит. Даже статических юзер=айпи. Чуть кривится, но выдает. P.S. Не прячьте далеко наты. Еще год-два - и по-другому будет совсем никак ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Mike Petrusha wrote:

...

Во-первых, часть сервисов из-за ната работает криво или не работает вообще, а те, что работают - работают медленно. Во-вторых, по нашим

Такими сервисами я лично не пользовался, но вполне могу себе представить чаты/файл-сервера и т.п., на к-рых банят по IP. И если за этим IP - тысяча пользователей, то наверное это сложно поддерживать.

VoIP P2P удаленный заход домой с работы Это так, сходу, и это немало.

...

Отлично смотрит. Даже статических юзер=айпи. Чуть кривится, но выдает.

А на GPRS? :)

С ГПРС сложнее, но не безнадежно. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

Pavel Gulchouck wrote:

On Wed, May 26, 2010 at 04:47:26PM +0200, Mike Petrusha writes:

...

...

Во-первых, часть сервисов из-за ната работает криво или не работает вообще, а те, что работают - работают медленно.

Сижу за натом и никаких неудобств не испытываю. Конечно, если кто хочет поднимать vpn или прочие туннели - тому нужна статика. Но таких ведь очень немного. Всякие skype, torrent, sip, онлайновые игрушки и пр. нормально работают через нат. Откуда могут взяться тормоза, если натящая железка справляется?

Какая железка и сколько еще юзеров сидит за ней одновременно?

Ну что ж, IPv6 - наше будущее...

Та забей, не будет никакого IPv6 в реальном мире! ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

On Wed, May 26, 2010 at 06:12:30PM +0300, Pavel Gulchouck wrote:

On Wed, May 26, 2010 at 04:47:26PM +0200, Mike Petrusha writes:

...

...

Во-первых, часть сервисов из-за ната работает криво или не работает вообще, а те, что работают - работают медленно.

Сижу за натом и никаких неудобств не испытываю. Конечно, если кто хочет поднимать vpn или прочие туннели - тому нужна статика. Но таких ведь очень немного. Всякие skype, torrent, sip, онлайновые игрушки и пр. нормально работают через нат. Откуда могут взяться тормоза, если натящая железка справляется?

Классический пример с torrent'ами: ты сидишь за nat'ом и раздаешь какой-нибудь MPLS_Traffic_Engineering.pdf. Я тоже сижу за nat'ом и хочу с тебя этот файл скачать. Вопрос: у меня это получится ? Ответ: пока этот же файл не потребуется какому-нибудь пользователю с белым ip - не получится. А ждать такого пользователя можно очень долго - это вам не порнуха ;) Плюс, даже если такой пользователь находится, но при этом у тебя 10Mbit, у меня 10Mbit, а у него всего 128kbit да и то через спутник - файло через него будет ехать о-о-о-чень долго, несмотря на то что оба NAT'а вполне справляются. То же самое с sip'ом - без какого-нибудь media-relay с белым адресом мы с тобой поговорить не сможем.

NAT выполняет две основных функции: экономия белых IP и безопасность. Обе мне кажутся достаточно важными.

Безопасность, собственно, выполняет не столько NAT, сколько встроенный в него stateful firewall.

MP> Такими сервисами я лично не пользовался, но вполне могу себе представить MP> чаты/файл-сервера и т.п., на к-рых банят по IP. И если за этим IP - тысяча MP> пользователей, то наверное это сложно поддерживать.

О, наконец-то понял. Однозначная идентификация пользователя по ip-адресу! Да, эта причина становится всё более актуальной со временем. И тут, действительно, нужен не просто белый, а статический IP каждому. Чтобы никакой анонимности.

Ну что ж, IPv6 - наше будущее...

IPv6 stateful firewall'ов не отменяет.

Hi! On Wed, May 26, 2010 at 07:23:14PM +0300, Pavel Gulchouck writes:

То есть, конечно, бывают странные железки, которые не понимают, как серый адрес может быть внешним, и считают это ошибкой конфигурации, но таких, всё-таки, немного.

Не так и мало. Как оказалось, Apple AirPort - а их не мало. Хотя, возможно, уже и пофиксили это бок. -- WBR, Yuriy B. Borysov YOKO-UANIC | YOKO-RIPE

On Wed, May 26, 2010 at 07:36:57PM +0400, Alexandre Snarskii writes: AS> On Wed, May 26, 2010 at 06:12:30PM +0300, Pavel Gulchouck wrote:

...

On Wed, May 26, 2010 at 04:47:26PM +0200, Mike Petrusha writes:

...

...

Во-первых, часть сервисов из-за ната работает криво или не работает вообще, а те, что работают - работают медленно.

Сижу за натом и никаких неудобств не испытываю. Конечно, если кто хочет поднимать vpn или прочие туннели - тому нужна статика. Но таких ведь очень немного. Всякие skype, torrent, sip, онлайновые игрушки и пр. нормально работают через нат. Откуда могут взяться тормоза, если натящая железка справляется?

AS> Классический пример с torrent'ами: ты сидишь за nat'ом и AS> раздаешь какой-нибудь MPLS_Traffic_Engineering.pdf. Я тоже сижу AS> за nat'ом и хочу с тебя этот файл скачать. Вопрос: у меня это AS> получится ? Ответ: пока этот же файл не потребуется какому-нибудь AS> пользователю с белым ip - не получится. А ждать такого пользователя AS> можно очень долго - это вам не порнуха ;) Плюс, даже если такой AS> пользователь находится, но при этом у тебя 10Mbit, у меня 10Mbit, а AS> у него всего 128kbit да и то через спутник - файло через него будет AS> ехать о-о-о-чень долго, несмотря на то что оба NAT'а вполне справляются. Да, это понятно, но быстрая раздача непопулярных торрентов со своего открытого IP пользователям нужна редко. Btw, а торренты не используют что-то типа STUN? Не пытаются соединиться по UDP напрямую, когда оба за натом (при помощи сервера на этапе установки соединения)? Понятно, что это не всегда возможно, но во многих случаях должно получиться.

...

NAT выполняет две основных функции: экономия белых IP и безопасность. Обе мне кажутся достаточно важными.

AS> Безопасность, собственно, выполняет не столько NAT, сколько встроенный AS> в него stateful firewall. Да, вопрос можно переформулировать: нужны ли пользователю входящие соединения? Я считаю, что в подавляющем большинстве случаев не нужны и, наоборот, вредны. Когда нужны входящие, SMTP на внешние релеи, vpn и т.п. - это уже не совсем домашнее абонентское включение, оно должно по отдельному тарифному плану проходить, и такой пользователь будет осознавать, что его компьютер открыт для всех вирусов, хакеров и DoS-атак снаружи. А если входящие закрыты - тогда и смысл в белых IP теряется, всё равно два таких пользователя не смогут передать файл или поговорить голосом без помощи внешнего релея. Если давать пользователям белые IP, не закрывать им входящие, следующие шаги в этом направлении - оставлять им SMTP куда угодно, не изолировать пользователей друг от друга, не ограничивать source mac/ip на пользовательском порту, не закрывать dhcp response от пользователей... Бывает и такое, конечно, но IMHO это не повод для гордости. С другой стороны, тоже понятно: пользователю даётся свобода; фильтрация его трафика - дополнительная услуга, которая требует дополнительных ресурсов; вирусы и ботнеты - проблема пользователей; исчерпание IPv4 - проблема RIR-ов; при NAT вычислить пользователя по IP крайне проблематично (для этого нужно вести лог всех соединений всех пользователей, и всё равно возможна ошибка из-за рассинхронизации часов) - всё это приводит к тому, что NAT постепенно остаётся только в корпоративных сетках, а что будем делать, когда закончатся IP-адреса, будем думать потом. :) -- Паша.

Hi Pavel,

Да, вопрос можно переформулировать: нужны ли пользователю входящие соединения? Я считаю, что в подавляющем большинстве случаев не нужны и, наоборот, вредны. Когда нужны входящие, SMTP на внешние релеи, vpn и т.п. - это уже не совсем домашнее абонентское включение, оно должно по отдельному тарифному плану проходить, и такой пользователь будет осознавать, что его компьютер открыт для всех вирусов, хакеров и DoS-атак снаружи.

А если входящие закрыты - тогда и смысл в белых IP теряется, всё равно два таких пользователя не смогут передать файл или поговорить голосом без помощи внешнего релея.

Полностью согласен. Было бы гораздо лучше, если бы моей маме на dial-up'е давали private IP.

Если давать пользователям белые IP, не закрывать им входящие, следующие шаги в этом направлении - оставлять им SMTP куда угодно,

Sorry, что значит "оставлять им SMTP куда угодно"? Не блокировать исходящий SMTP?

С другой стороны, тоже понятно: пользователю даётся свобода;

С другой стороны, все меньше комп-ров подключены напрямую, на любой DSL/Cable ставится "домашний router" и дальше там все равно NAT, даже если всего один компьютер. (И включен WiFi.) В этом случае преимуществ с private IP не видно, зато легко предсказать проблемы с двойным NAT'ом. Соотв-но возвращаюсь у уже сказанному: хочу private IP на dial-up'е. А на "broadband", скорее, не хочу. Но опять же, боюсь, выдача private IP клиентам выливаются в дополнительные затраты на support, куда звонят невинно забаненые. (Не так?) Кстати, не так уж редко операторы делают 1-to-1 NAT. (1 private IP мапится в 1 public) Не знаю, зачем. -- Mike

...

С другой стороны, тоже понятно: пользователю даётся свобода;

С другой стороны, все меньше комп-ров подключены напрямую, на любой DSL/Cable ставится "домашний router" и дальше там все равно NAT, даже если всего один компьютер. (И включен WiFi.) В этом случае преимуществ с private IP не видно, зато легко предсказать проблемы с двойным NAT'ом.

Universal PNP потом порты пробрасывает в обе стороны по запросу с компа. Если ПО поддерживает - uTorrent тот же умеет с upnp работать. -- Sergey Smitienko

On Thu, May 27, 2010 at 10:34:50AM +0300, Valentin Nechayev writes:

Thu, May 27, 2010 at 09:49:56, gul wrote about "Re: [uanog] скромность и красота - наши главные достоинства :-)":

...

Btw, а торренты не используют что-то типа STUN? Не пытаются соединиться по UDP напрямую, когда оба за натом (при помощи сервера на этапе установки соединения)? Понятно, что это не всегда возможно, но во многих случаях должно получиться.

Для этого лучше SOCKS. По крайней мере при этом адрес одной из сторон становится публичным и устойчивым.

Для Socks нужно содействие провайдера, весь трафик будет ходить через этот socks, а stun можно поднимать при помощи любого сервера где-либо на просторах Интернета, и трафик пойдёт напрямую, а не через этот сервер. Для torrent, skype, jabber, sip такие сервера есть - с их помощью и можно пробовать соединиться директом, когда оба за натом. Только вот не уверен, что где-то такое делается.

...

...

Безопасность, собственно, выполняет не столько NAT, сколько встроенный в него stateful firewall.

Да, вопрос можно переформулировать: нужны ли пользователю входящие соединения?

К сожалению, во многих случаях протоколы ориентированы на возможность установления соединения в обе стороны. Классический уже пример - SIP. Даже при работе с ближайшим прокси SIP клиент получает запросы входящих звонков/сообщений отдельными пакетами или соединениями.

У меня на компе sip-клиент - нормально работает через нат, и входящие принимает. Я не знаю, каким образом он это делает, но работает.

...

Я считаю, что в подавляющем большинстве случаев не нужны и, наоборот, вредны. Когда нужны входящие, SMTP на внешние релеи, vpn и т.п. - это уже не совсем домашнее абонентское включение, оно должно по отдельному тарифному плану проходить, и такой пользователь будет осознавать, что его компьютер открыт для всех вирусов, хакеров и DoS-атак снаружи.

Твоё описание слабо разделяет как минимум три ситуации: 1) входящие, явно разрешённые клиентом в каждом отдельном случае 2) ограниченные входящие по какому-то правилу (например, только 25/tcp) 3) неограниченные входящие

и твоё описание ужасов относится к третьему случаю, хотя для первого они некорректны. Первый случай принципиально ничем не отличается от исходящего, кроме направления инициации.

Первый случай - технически это socks или есть другие варианты? Есть ли реальные прецеденты применения такой политики каким-то из современных провайдеров?

...

А если входящие закрыты - тогда и смысл в белых IP теряется, всё равно два таких пользователя не смогут передать файл или поговорить голосом без помощи внешнего релея.

Смысл в белых IP в том, что даже в первом случае - разрешаемые по случаю отдельные входящие - резко упрощается (до тривиальности) определение адреса, куда должно поступить это соединение, а также управление им. NAT - это шлюз адресных пространств, со всеми последствиями этого - нужна трансляция, результаты которой будут известны клиенту и без тяжёлого напряга.

Это теоретические рассуждения (об управлении входящими) или реальная практика провайдеров? Я встречал только варианты "всё открыто" и "пользователи за натом". В первом варианте получаются ужасы с вирусами, во втором - никаких входящих вообще. Вот эти два встречающихся в реальности варианта я и сравниваю.

...

Если давать пользователям белые IP, не закрывать им входящие, следующие шаги в этом направлении - оставлять им SMTP куда угодно, не изолировать пользователей друг от друга, не ограничивать source mac/ip на пользовательском порту, не закрывать dhcp response от пользователей... Бывает и такое, конечно, но IMHO это не повод для гордости.

Почему это вдруг выдача белого IP автоматически означает не только устранение всех фильтраций, но и наплевательство на идентификацию пользователей? Не вижу никаких причин для такого перехода...

Устранение всех фильтраций - потому что цена решений nat и stateful firewall практически одинакова. Предоставлять пользователям белые IP, но защищать их трафик stateful firewall - странное решение, я не верю, что где-то такое есть. Прикрыть acl-ем можно, но, опять же, в реальности видел разве что transparent proxy для http и smtp. Наплевательство на идентификацию пользователей - потому что, если провайдер считает nat или stateful firewall слишком дорогим решением, которое не окупится, то и свичи у него, скорее всего, не сумеют защитить пользователей друг от друга. Это нормально и естественно - свичи, висящие в подвалах домов, и не должны уметь 802.1x, dhcp, switchport protected и т.п., но вызывает удивление, когда отсутствие какого-то функционала объясняется не экономической целесообразностью, а тем, что мы такие умные и догадались.

...

С другой стороны, тоже понятно: пользователю даётся свобода; фильтрация его трафика - дополнительная услуга, которая требует дополнительных ресурсов; вирусы и ботнеты - проблема пользователей; исчерпание IPv4 - проблема RIR-ов; при NAT вычислить пользователя по IP крайне проблематично (для этого нужно вести лог всех соединений всех пользователей, и всё равно возможна ошибка из-за рассинхронизации часов) - всё это приводит к тому, что NAT постепенно остаётся только в корпоративных сетках, а что будем делать, когда закончатся IP-адреса, будем думать потом. :)

Ну при грамотном подходе v6 не закончатся, и вообще-то тотальное избавление от NAT предполагает именно v6. Для v4, достаточно динамического адреса (подобрать размер пула для жизни адреса минимум сутки).

Динамический пул был актуален на диалапе. Сейчас - на gprs. Но в домонетах на динамическом пуле много не сэкономишь, а возни с ним больше. -- Паша.

OMG, есть такие операторы, которые считают траффик абонентов ШПД с помощью нетфлоу ? Можно подробностей про величину абонентской базы ну и success story ? 27 мая 2010 г. 11:16 пользователь Sergey Galat написал:

Приветствую,

Вы писали 27 мая 2010 г., 11:01:28:

...

Hi Valentin,

 >> Ну при грамотном подходе v6 не закончатся, и вообще-то тотальное избавление  >> от NAT предполагает именно v6. Для v4, достаточно динамического адреса  >> (подобрать размер пула для жизни адреса минимум сутки).

...

Не знаю, что ты имел в виду. На DSL и т.п. обычно около 80% клиентов не отключаются и разницы между статикой/динамикой особой нет.

Дело даже не всегда в отключаются/не отключаются, очень многие операторы имеют тарифные планы с подсчетом трафика. И в случае с netflow и адресами за NAT возникают проблемы с подсчетом. Потому на ШПД как правило не используют динамические IP.

-- Sergey Galat

-- Yours, Max Telecommunication/HPC consulting

Thu, May 27, 2010 at 11:38:23, gul wrote about "Re: [uanog] скромность и красота - наши главные достоинства :-)":

...

Для этого лучше SOCKS. По крайней мере при этом адрес одной из сторон становится публичным и устойчивым. Для Socks нужно содействие провайдера, весь трафик будет ходить через этот socks, а stun можно поднимать при помощи любого сервера где-либо на просторах Интернета, и трафик пойдёт напрямую, а не через этот сервер. Для torrent, skype, jabber, sip такие сервера есть - с их помощью и можно пробовать соединиться директом, когда оба за натом. Только вот не уверен, что где-то такое делается.

Крупные сети можно занатить только в symmetric, иначе будет слишком много конфликтов в пуле. А это значит, что STUN не сможет получить внятный результат ни в одну сторону, и в наиболее значимом случае он бесполезен.

...

К сожалению, во многих случаях протоколы ориентированы на возможность установления соединения в обе стороны. Классический уже пример - SIP. Даже при работе с ближайшим прокси SIP клиент получает запросы входящих звонков/сообщений отдельными пакетами или соединениями. У меня на компе sip-клиент - нормально работает через нат, и входящие принимает. Я не знаю, каким образом он это делает, но работает.

Я знаю, как это сделать.:) Но в сложных случаях всё равно дофига проблем.

...

1) входящие, явно разрешённые клиентом в каждом отдельном случае 2) ограниченные входящие по какому-то правилу (например, только 25/tcp) 3) неограниченные входящие

...

и твоё описание ужасов относится к третьему случаю, хотя для первого они некорректны. Первый случай принципиально ничем не отличается от исходящего, кроме направления инициации.

Первый случай - технически это socks или есть другие варианты?

Нет, можно и просто stateful firewall, если есть метод приказать. Таким приказом может быть исходящее соединение или пакет.

Есть ли реальные прецеденты применения такой политики каким-то из современных провайдеров?

См. выше. Для UDP достаточно послать пакет наружу. Для TCP - открыть соединение; напоминаю, что на TCP встречный взаимный коннект является штатным режимом (в отличие от SCTP, где это убили).

...

...

А если входящие закрыты - тогда и смысл в белых IP теряется, всё равно два таких пользователя не смогут передать файл или поговорить голосом без помощи внешнего релея.

...

Смысл в белых IP в том, что даже в первом случае - разрешаемые по случаю отдельные входящие - резко упрощается (до тривиальности) определение адреса, куда должно поступить это соединение, а также управление им. NAT - это шлюз адресных пространств, со всеми последствиями этого - нужна трансляция, результаты которой будут известны клиенту и без тяжёлого напряга.

Это теоретические рассуждения (об управлении входящими) или реальная практика провайдеров? Я встречал только варианты "всё открыто" и "пользователи за натом". В первом варианте получаются ужасы с вирусами, во втором - никаких входящих вообще. Вот эти два встречающихся в реальности варианта я и сравниваю.

Я сейчас не могу отвечать именно за _провайдеров_, но реальные сети с политикой "IP честные, но входящие только инициированные изнутри" мне известны.

...

...

Если давать пользователям белые IP, не закрывать им входящие, следующие шаги в этом направлении - оставлять им SMTP куда угодно, не изолировать пользователей друг от друга, не ограничивать source mac/ip на пользовательском порту, не закрывать dhcp response от пользователей... Бывает и такое, конечно, но IMHO это не повод для гордости.

...

Почему это вдруг выдача белого IP автоматически означает не только устранение всех фильтраций, но и наплевательство на идентификацию пользователей? Не вижу никаких причин для такого перехода...

Устранение всех фильтраций - потому что цена решений nat и stateful firewall практически одинакова.

NAT существенно дороже: модификация пакетов, которая часто ещё и требует их реассемблирования после дефрагментации, прокси протоколов (начиная с FTP), учёт занятых внешних адресов (хэш IP с портами).

Предоставлять пользователям белые IP, но защищать их трафик stateful firewall - странное решение, я не верю, что где-то такое есть. Прикрыть acl-ем можно, но, опять же, в реальности видел разве что transparent proxy для http и smtp.

У тебя очень странная реальность. Не далее чем в LN ещё с 1999 входящие на 137-139 на диалап были закрыты, потом сюда добавился 445. Так что не только transparent proxy - у тебя на глазах возникло:) Во, вспомнил: в том же LN мы таким stateful прикрывали пользователей в соседних зданиях и собственный terminal server. Народ был доволен.

Наплевательство на идентификацию пользователей - потому что, если провайдер считает nat или stateful firewall слишком дорогим решением, которое не окупится, то и свичи у него, скорее всего, не сумеют защитить пользователей друг от друга. Это нормально и естественно - свичи, висящие в подвалах домов, и не должны уметь 802.1x, dhcp, switchport protected и т.п., но вызывает удивление, когда отсутствие какого-то функционала объясняется не экономической целесообразностью, а тем, что мы такие умные и догадались.

Вообще-то единственный нормальный стиль для "свичей, висящих в домах" - это DOCSIS-like стиль, то есть: * один порт выделен как аплинк * с аплинка - раздаётся согласно макам * с остальных портов - сливается на аплинк и таки минимальный port security. Связи между дороговизной NAT и качеством свичей не вижу по-прежнему. NAT дорог не самой по себе реализацией, а разбором последствий. Например, когда NATовый адрес попадает в слабовменяемый чёрный список. Отсутствие возможности писать логи для всех видов взаимодействий (не будешь же каждый пакет писать, пусть даже в виде netflow) тоже "помогает".

...

Ну при грамотном подходе v6 не закончатся, и вообще-то тотальное избавление от NAT предполагает именно v6. Для v4, достаточно динамического адреса (подобрать размер пула для жизни адреса минимум сутки). Динамический пул был актуален на диалапе. Сейчас - на gprs. Но в домонетах на динамическом пуле много не сэкономишь, а возни с ним больше.

Вполне верю. -netch-

27 мая 2010, в 13:05, Max Speransky написал(а):

OMG, есть такие операторы, которые считают траффик абонентов ШПД с помощью нетфлоу ? Можно подробностей про величину абонентской базы ну и success story ?

Воля. Киев. >> 200K абонентов. Только не говорите, что это не ШПД :) --- Regards, Vadim Garbooze VOLIA NIC: VEG5, VEG1-RIPE

ШПД - это 100Mbps ;-) остальное - narrowband :) 2010/5/27 Гарбуз Вадим

27 мая 2010, в 13:05, Max Speransky написал(а):

...

OMG, есть такие операторы, которые считают траффик абонентов ШПД с помощью нетфлоу ? Можно подробностей про величину абонентской базы ну и success story ?

Воля. Киев. >> 200K абонентов. Только не говорите, что это не ШПД :)

--- Regards, Vadim Garbooze VOLIA NIC: VEG5, VEG1-RIPE

-- /doka /*-- http://doka-ua.blogspot.com/ --*/