Thu, May 27, 2010 at 09:49:56, gul wrote about "Re: [uanog] скромность и красота - наши главные достоинства :-)":
Btw, а торренты не используют что-то типа STUN? Не пытаются соединиться по UDP напрямую, когда оба за натом (при помощи сервера на этапе установки соединения)? Понятно, что это не всегда возможно, но во многих случаях должно получиться.
Для этого лучше SOCKS. По крайней мере при этом адрес одной из сторон становится публичным и устойчивым. AS>> Безопасность, собственно, выполняет не столько NAT, сколько встроенный AS>> в него stateful firewall.
Да, вопрос можно переформулировать: нужны ли пользователю входящие соединения?
К сожалению, во многих случаях протоколы ориентированы на возможность установления соединения в обе стороны. Классический уже пример - SIP. Даже при работе с ближайшим прокси SIP клиент получает запросы входящих звонков/сообщений отдельными пакетами или соединениями. С другой стороны, видим IAX2, который рассчитан на держание одного соединения на всё, и он задачу выхода из-за NAT решает прямолинейно и равномерно:) Да, есть недостатки - слабое масштабирование, жёстко заданный набор кодеков, негибкая авторизация, наконец, TCP для голоса - редкое извращение. Но - просто, понятно, дёшево и в относительно локальных сетях хорошо работает.
Я считаю, что в подавляющем большинстве случаев не нужны и, наоборот, вредны. Когда нужны входящие, SMTP на внешние релеи, vpn и т.п. - это уже не совсем домашнее абонентское включение, оно должно по отдельному тарифному плану проходить, и такой пользователь будет осознавать, что его компьютер открыт для всех вирусов, хакеров и DoS-атак снаружи.
Твоё описание слабо разделяет как минимум три ситуации: 1) входящие, явно разрешённые клиентом в каждом отдельном случае 2) ограниченные входящие по какому-то правилу (например, только 25/tcp) 3) неограниченные входящие и твоё описание ужасов относится к третьему случаю, хотя для первого они некорректны. Первый случай принципиально ничем не отличается от исходящего, кроме направления инициации. Я не вижу причин порождать какой-то отдельный "тарифный план" только ради возможности принять, например, VPN на свою машину. Это практически базовая функциональность.
А если входящие закрыты - тогда и смысл в белых IP теряется, всё равно два таких пользователя не смогут передать файл или поговорить голосом без помощи внешнего релея.
Смысл в белых IP в том, что даже в первом случае - разрешаемые по случаю отдельные входящие - резко упрощается (до тривиальности) определение адреса, куда должно поступить это соединение, а также управление им. NAT - это шлюз адресных пространств, со всеми последствиями этого - нужна трансляция, результаты которой будут известны клиенту и без тяжёлого напряга. Именно поэтому подход на расширение адресного пространства по принципу "нехер экономить два байта" возобладал над "посадим всех за шлюз и будем мучаться с особенностями реализации у очередного говновендора, считающего себя самым умным на планете и не прочитавшего даже две страницы базового RFC, потому что многабукв ниасилил". К величайшему сожалению.
Если давать пользователям белые IP, не закрывать им входящие, следующие шаги в этом направлении - оставлять им SMTP куда угодно, не изолировать пользователей друг от друга, не ограничивать source mac/ip на пользовательском порту, не закрывать dhcp response от пользователей... Бывает и такое, конечно, но IMHO это не повод для гордости.
Почему это вдруг выдача белого IP автоматически означает не только устранение всех фильтраций, но и наплевательство на идентификацию пользователей? Не вижу никаких причин для такого перехода...
С другой стороны, тоже понятно: пользователю даётся свобода; фильтрация его трафика - дополнительная услуга, которая требует дополнительных ресурсов; вирусы и ботнеты - проблема пользователей; исчерпание IPv4 - проблема RIR-ов; при NAT вычислить пользователя по IP крайне проблематично (для этого нужно вести лог всех соединений всех пользователей, и всё равно возможна ошибка из-за рассинхронизации часов) - всё это приводит к тому, что NAT постепенно остаётся только в корпоративных сетках, а что будем делать, когда закончатся IP-адреса, будем думать потом. :)
Ну при грамотном подходе v6 не закончатся, и вообще-то тотальное избавление от NAT предполагает именно v6. Для v4, достаточно динамического адреса (подобрать размер пула для жизни адреса минимум сутки). -netch-