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. Но в домонетах на динамическом пуле много не сэкономишь, а возни с ним больше. -- Паша.