Pull to refresh

Comments 31

Да, жизнь будет всё сложнее, если мир пойдёт по пути NAT'изации всего трафика.
Хуже если для выхода в интернет нужно будет использовать прокси сервер.
Прям вспомнились нулевые.
А что нулевые? В организациях такое до сих пор часто встречается.
одно дело «злые админы\руководители\нормы\порядки» в организации, другое дело поголовное использование. Когда вообще не будет возможности прямого коннекта между двумя ПК через публичные сети.
Чиновники просто плясать будут от счастья. Они давно мечтают запретить интернет. Разделить интернет на «серверный» с белыми IP, и регуляцией вусмерть, и «клиентский» — без IP и возможности хостить сайты — просто подарок.

И без того дело к этому идёт, если смотреть со стороны законодательных инициатив. А если им ещё и технические ограничения помогут, совсем счастье будет.
Зато нат частично выполняет функции фаервола — клиент не смотрит в мир всеми своими открытыми портами
нат частично выполняет функции фаервола
опаснейшее заблуждение
Т.е извне можно через достучаться до открытых портов компа? Если в большинстве случаев нельзя, то, что это не как частичное выполнение функций фаервола?
Т.е извне можно через достучаться до открытых портов компа?
Из одного broadcast-сегмента с внешним интерфейсом натящего роутера («локалка провайдера») — элементарно. Malware, распространяющее себя по локалке — далеко не самый экзотичный сценарий.
Если по пути есть другие маршрутизаторы, то сложнее и не всегда (на самом деле — редко когда) возможно, но рассчитывать на то, что админы маршрутизаторов по пути о вашей безопасности позаботились больше, чем вы — не совсем правильно.
Безопасность сети вполне волнует админов ибо, скажем, из-за мусорного трафика некоторые сервисы в нете спокойно могут забанить ip провайдера. Да и изоляция компов абонентов между собой вполне реальный кейс — ну… например, чтобы минимизировать риск перепродажи трафика. Сейчас это не так актуально, а всего несколько лет назад еще было. Изоляция может быть на физическом уровне (виланами) или программном (пппое). В целом это немного улучшает безопасность сети. Немного, да, но я и не говорил, что полностью.
Функции фаерволла должен выполнять грёбанный фаерволл (хотя бы на пограничном оборудовании), а никак не NAT.
Это бонус. Я не говорю, что он должен заменять фаервол, я говорю по факту, что есть и польза от ната — скажем, домашний комп не смотрит в мир «голой задницей»
Если вы выходите с домашнего компа в инет, воткнув кабель от провайдера напрямую в машину — у меня для вас плохие новости. Достаточно вспомнить изкоробочный Teredo в последних Windows.
В Windows по умолчанию запрещены все входящие подключения через Teredo. Роутер, к слову, ситуацию с Teredo никак не изменяет и не изменил бы.
Максимальное число возможных портов составляет 65 тыс., поэтому, в теории, такое же количество локальных адресов может быть отображено на один внешний адрес.
Не могу согласиться с этим утверждением.
Если локальные адреса будут обращаться к разным адресам во внешней сети (как оно обычно и бывает), то это ограничение не сработает. Проблема случится только когда будет установлено 65 тыс. соединений с внутренних хостов на один порт внешнего ip-адреса. Вот тогда — да, портов не хватит, т.к. удаленный хост может различить соединения только по порту.
P.S. Тут я не учитываю возможные ограничения конкретных реализаций NAT-а.
Подумалось… Возможно, при использовании протоколов, не использующих UDP или TCP, проблемы могут начаться и раньше, т.к. не во всех протоколах есть понятие порта или его аналог.

Например: GRE не использует порты.

Вот объясните вообще зелёному новичку в сетях:
OFFTOP
Есть 2 питон-скрипта. Один — UDP сокет-сервер, второй — то же самое, только клиент.
Клиент шлёт серверу некоторые данные (допустим, содержимое файла, разбитое на пакеты).
Внутри локальной сети всё работает.
Усложним задачу. Теперь сеть выглядит так:
[сервер] -> [usb модем] -> [провайдер 3g] -> [ИНТЕРНЕТ] -> [провайдер проводной] -> [роутер] -> [клиент]
или даже так:
[сервер] -> [Android tethering] -> [провайдер 3g] -> [ИНТЕРНЕТ] -> [провайдер проводной] -> [роутер] -> [клиент]
т.е. у каждого получается по 2 nat'a. (роутер+провайдер)
Что должны делать стороны, чтобы сервер продолжил получать данные в такой сети?
Причём, объясните «для чайников».
Пробовал:
Сервер открывает сокет, и отправляет пакет «третьей стороне» с белым ip.
Третья сторона передаёт ip и порт сервера клиенту.
Клиент шлёт данные на эти ip и порт.
Если я правильно понял, то так работает udp hole punching, но в моём случае данные не доходят.
PS:
Про то, что можно заставить 3-ю сторону быть ретранслятором я знаю, но интересно именно прямое подключение. 3-я сторона может передавать данные для подключения, например, ip и порты.
Клиент и сервер (в моём случае) могут влиять на свои роутеры, но вот как открыть порт в случае андроид-тетеринга я не знаю.

А нельзя просто развернуть схему, и поставть сервер за проводной интернет с белым адресом, а клиента — за 3g?
Можно, но у проводного интернета адрес ни разу не белый. Белый у 3-й стороны, которую трогать нежелательно.

В общем случае — проковырять дырку нельзя.
Могу порекомендовать посмотреть в сторону:


Попробуйте залочить номер исходящего порта так чтоб он был таким же как и входящий. Когда udp-пакет проходит через нат, последний запоминает связку «src-ip, dst-ip, src-port, dst-port» и временно разрешает «обратные» пакеты. По идее вы можете даже обойтись без 3й стороны. Я такой эффект наблюдал, когда был админом сети — валил (вероятно вирусный) udp трафик на клиента, при этом клиент довольно долго запросы не делал
Можно поподробнее, что значит «залочить»?
Когда система создает соединение, она в качестве src-port выбирает рандомный не занятый в данный момент порт. Ответ приходит именно на этот порт. Допустим вы создаете 2 соединения (что не совсем корректно звучит в рамках udp, но все же) на один и тот же хост. Как удаленный хост будет различать пакеты с вашего ip? Правильно, по src-port. Это так, для понимания процесса рассказал. Залочить порт — это сделать чтоб src-port был фиксированным. Я не знаю есть ли либы для питона, которые могут такое делать. Хотя сам в основном программирую на питоне, но для таких вещей использую перл)
Уверен, что либ, позволяющих 'зафиксировать' src порт на NAT'е не существует ни для питона, ни для перла.
А от фиксированности и известности src-порта на хосте за натом в общем случае толку мало.
Знаете, перл может кем-то и считается некрасивым языком, но говорить, что он чего-то не может — это опасно:

use IO::Socket::INET;
$| = 1;
$socket = new IO::Socket::INET (
PeerHost => '127.0.0.1',
PeerPort => '5000',
LocalPort => '5000',
Proto => 'udp',
);
print $socket "test\n";


Тисипидамплю:

sudo tcpdump -ilo0 -p -n udp
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
01:41:10.327757 IP 127.0.0.1.5000 > 127.0.0.1.5000: UDP, length 5
P.S. Я увидел, что вы имеете ввиду фиксацию порта на нате, я как раз об этом и не говорил

Если ваши религиозные чувства задеты упоминанием перла, то возможно утешением будет отсутствие подобных библиотек не толька для перла с питоном, а и для си, явы, эрланга и всех остальных: ну не можете вы на локальной машине влиять, во что будут транслированы нат'ом ваш адрес и (src) порт.
Код же, приведенный вами задает src порт на локальной машине (и подозреваю, что нет яп, имеющего средства для работы с сокетами, при этом не умеющего такого "функционала"). Но вот огорчение: снаружи от ната от (номера) этого порта никакой пользы нет, от слова совсем.

Честно говоря, я подумал, что вы меня тролите в том, что я не могу создать сокет с заданным src портом и я просто на нем забиндил адрес. А на счет того, что на выходе нат-а будет иной порт — признаю, я почему-то подумал, что речь идет не о симметричном нате и порт не будет подменен. В случае симметричного нат-а, конечно смысла в фиксации порта на клиенте нет смысла. Просто иначе организовать соединения через 2 ната — это уже хакерские фишки со спуфингом ip — видимо из-за этого подумал, что у человека проще условия
Скорей всего на той стороне стоит фаервол который следит за состоянием соединений и просто не может пропустить входящий пакет если на этот адрес/порт не было исходящего — т.е. соединение небыло инициировано изнутри сети. Иногда, эта проблема решается технологией UPNP, когда клиент специальным способом сообщает NAT что он ожидает входящее соединение. По крайней мере, последний uTorrent-клиент каким-то образом это делает. Современные роутеры в режиме NAT поддерживают UPNP, а дальше провайдер и дело за ним…
Что бы работал ваш велосипедный stun необходимо, чтобы src ip и порт в которые нат транслирует внутренний адрес и порт стороны А были одинаковыми как для пакетов к стороне Б, так и для пакетов к третьей стороне. В общем случае это не так.
В частном — практически наверняка это не так у 3g провайдера. Поэтому совет поменять местами клиента с сервером некоторого смысла не лишен.
А в будущем нас ждет следующий уровень развития NAT — Carrier Grade NAT (CGN/CGNAT).
Да, вроде как, все постепенно двигаются в сторону 464XLAT и аналогов, чтобы в сети были только IPv6-адреса, а IPv4-трансляции совершались только на NAT64-устройствах. В отличие от DS-Lite, 464XLAT — транслятор, а не туннель, что создает меньшую нагрузку на оборудование, и позволяет передавать большее количество данных в одном пакете.
Это не панацея, т.к. 464XLAT поддерживается только на мобильных устройствах, да и не на всех, но, например, T-Mobile USA и Orange Poland уже несколько лет используют его для некоторых устройств.
Only those users with full accounts are able to leave comments. Log in, please.