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-