On Thu, May 27, 2010 at 11:38:23AM +0300, Pavel Gulchouck wrote:
Btw, а торренты не используют что-то типа STUN? Не пытаются соединиться по UDP напрямую, когда оба за натом (при помощи сервера на этапе установки соединения)? Понятно, что это не всегда возможно, но во многих случаях должно получиться.
Для этого лучше SOCKS. По крайней мере при этом адрес одной из сторон становится публичным и устойчивым.
Для Socks нужно содействие провайдера, весь трафик будет ходить через этот socks, а stun можно поднимать при помощи любого сервера где-либо на просторах Интернета, и трафик пойдёт напрямую, а не через этот сервер. Для torrent, skype, jabber, sip такие сервера есть - с их помощью и можно пробовать соединиться директом, когда оба за натом. Только вот не уверен, что где-то такое делается.
stun вообще-то это не более чем определение типа твоего nat'а. Да, если хотя-бы у одного из заначенных пользователей nat не symmetric а *cone - это помогает. Другой вопрос, что я в реальной жизни cone nat'ов не видел...
Безопасность, собственно, выполняет не столько NAT, сколько встроенный в него stateful firewall.
Да, вопрос можно переформулировать: нужны ли пользователю входящие соединения?
К сожалению, во многих случаях протоколы ориентированы на возможность установления соединения в обе стороны. Классический уже пример - SIP. Даже при работе с ближайшим прокси SIP клиент получает запросы входящих звонков/сообщений отдельными пакетами или соединениями.
У меня на компе sip-клиент - нормально работает через нат, и входящие принимает. Я не знаю, каким образом он это делает, но работает.
Потому что "та сторона" media-потока - белый адрес. Дальше - man symmetric rtp.
Я считаю, что в подавляющем большинстве случаев не нужны и, наоборот, вредны. Когда нужны входящие, SMTP на внешние релеи, vpn и т.п. - это уже не совсем домашнее абонентское включение, оно должно по отдельному тарифному плану проходить, и такой пользователь будет осознавать, что его компьютер открыт для всех вирусов, хакеров и DoS-атак снаружи.
Твоё описание слабо разделяет как минимум три ситуации: 1) входящие, явно разрешённые клиентом в каждом отдельном случае 2) ограниченные входящие по какому-то правилу (например, только 25/tcp) 3) неограниченные входящие
и твоё описание ужасов относится к третьему случаю, хотя для первого они некорректны. Первый случай принципиально ничем не отличается от исходящего, кроме направления инициации.
Первый случай - технически это socks или есть другие варианты? Есть ли реальные прецеденты применения такой политики каким-то из современных провайдеров?
Моя предыдущая работа: - в обе стороны нафик зафильтрованы стандартные виндовые порты (135,137-139,445). - от пользователей с динамическими адресами tcp/25 открыт только на локальный релей. От пользователей с статическими адресами - открыт полностью. - все остальное - полностью открыто, в обе стороны.
Ну при грамотном подходе v6 не закончатся, и вообще-то тотальное избавление от NAT предполагает именно v6. Для v4, достаточно динамического адреса (подобрать размер пула для жизни адреса минимум сутки).
Динамический пул был актуален на диалапе. Сейчас - на gprs. Но в домонетах на динамическом пуле много не сэкономишь, а возни с ним больше.
Домонет, pppoe. До сих пор актуально.