VASExperts Dec 13 2016 at 13:02

«Эхо прошлых лет»: Как решается вопрос недостатка адресов IPv4

4 min

27K

VAS Experts corporate blogIT Standards*Development for e-commerce*Development of communication systems*

+18

Comments 31

ifaustrue Dec 13 2016 at 13:15

Да, жизнь будет всё сложнее, если мир пойдёт по пути NAT'изации всего трафика.
Хуже если для выхода в интернет нужно будет использовать прокси сервер.
Прям вспомнились нулевые.

bodqhrohro Dec 13 2016 at 20:13

А что нулевые? В организациях такое до сих пор часто встречается.

ifaustrue Dec 13 2016 at 21:02

одно дело «злые админы\руководители\нормы\порядки» в организации, другое дело поголовное использование. Когда вообще не будет возможности прямого коннекта между двумя ПК через публичные сети.

Saffron Dec 15 2016 at 19:55

Чиновники просто плясать будут от счастья. Они давно мечтают запретить интернет. Разделить интернет на «серверный» с белыми IP, и регуляцией вусмерть, и «клиентский» — без IP и возможности хостить сайты — просто подарок.

И без того дело к этому идёт, если смотреть со стороны законодательных инициатив. А если им ещё и технические ограничения помогут, совсем счастье будет.

ef_end_y Dec 13 2016 at 14:08

Зато нат частично выполняет функции фаервола — клиент не смотрит в мир всеми своими открытыми портами

Zolg Dec 13 2016 at 14:38

нат частично выполняет функции фаервола

опаснейшее заблуждение

ef_end_y Dec 13 2016 at 15:36

Т.е извне можно через достучаться до открытых портов компа? Если в большинстве случаев нельзя, то, что это не как частичное выполнение функций фаервола?

Zolg Dec 13 2016 at 17:47

Т.е извне можно через достучаться до открытых портов компа?

Из одного broadcast-сегмента с внешним интерфейсом натящего роутера («локалка провайдера») — элементарно. Malware, распространяющее себя по локалке — далеко не самый экзотичный сценарий.
Если по пути есть другие маршрутизаторы, то сложнее и не всегда (на самом деле — редко когда) возможно, но рассчитывать на то, что админы маршрутизаторов по пути о вашей безопасности позаботились больше, чем вы — не совсем правильно.

ef_end_y Dec 13 2016 at 19:58

Безопасность сети вполне волнует админов ибо, скажем, из-за мусорного трафика некоторые сервисы в нете спокойно могут забанить ip провайдера. Да и изоляция компов абонентов между собой вполне реальный кейс — ну… например, чтобы минимизировать риск перепродажи трафика. Сейчас это не так актуально, а всего несколько лет назад еще было. Изоляция может быть на физическом уровне (виланами) или программном (пппое). В целом это немного улучшает безопасность сети. Немного, да, но я и не говорил, что полностью.

Prototik Dec 13 2016 at 14:39

Функции фаерволла должен выполнять грёбанный фаерволл (хотя бы на пограничном оборудовании), а никак не NAT.

ef_end_y Dec 13 2016 at 15:33

Это бонус. Я не говорю, что он должен заменять фаервол, я говорю по факту, что есть и польза от ната — скажем, домашний комп не смотрит в мир «голой задницей»

ksenobayt Dec 13 2016 at 19:07

Если вы выходите с домашнего компа в инет, воткнув кабель от провайдера напрямую в машину — у меня для вас плохие новости. Достаточно вспомнить изкоробочный Teredo в последних Windows.

ValdikSS Dec 13 2016 at 20:48

В Windows по умолчанию запрещены все входящие подключения через Teredo. Роутер, к слову, ситуацию с Teredo никак не изменяет и не изменил бы.

miksoft Dec 13 2016 at 14:22

Максимальное число возможных портов составляет 65 тыс., поэтому, в теории, такое же количество локальных адресов может быть отображено на один внешний адрес.

Не могу согласиться с этим утверждением.
Если локальные адреса будут обращаться к разным адресам во внешней сети (как оно обычно и бывает), то это ограничение не сработает. Проблема случится только когда будет установлено 65 тыс. соединений с внутренних хостов на один порт внешнего ip-адреса. Вот тогда — да, портов не хватит, т.к. удаленный хост может различить соединения только по порту.
P.S. Тут я не учитываю возможные ограничения конкретных реализаций NAT-а.

miksoft Dec 13 2016 at 14:53

Подумалось… Возможно, при использовании протоколов, не использующих UDP или TCP, проблемы могут начаться и раньше, т.к. не во всех протоколах есть понятие порта или его аналог.

Bozaro Dec 13 2016 at 15:12

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

Kop3t3 Dec 13 2016 at 15:14

Вот объясните вообще зелёному новичку в сетях:

OFFTOP

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

Prototik Dec 13 2016 at 15:31

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

Kop3t3 Dec 13 2016 at 21:11

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

Bozaro Dec 13 2016 at 15:49

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

https://habrahabr.ru/post/279969/ — проброс портов через подконтрольный домашний NAT;
https://ru.wikipedia.org/wiki/STUN — STUN сервера используются для получения информации о внешнем адресе.

ef_end_y Dec 13 2016 at 15:50

Попробуйте залочить номер исходящего порта так чтоб он был таким же как и входящий. Когда udp-пакет проходит через нат, последний запоминает связку «src-ip, dst-ip, src-port, dst-port» и временно разрешает «обратные» пакеты. По идее вы можете даже обойтись без 3й стороны. Я такой эффект наблюдал, когда был админом сети — валил (вероятно вирусный) udp трафик на клиента, при этом клиент довольно долго запросы не делал

Kop3t3 Dec 13 2016 at 21:13

Можно поподробнее, что значит «залочить»?

ef_end_y Dec 14 2016 at 01:13

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

Zolg Dec 14 2016 at 01:50

Уверен, что либ, позволяющих 'зафиксировать' src порт на NAT'е не существует ни для питона, ни для перла.
А от фиксированности и известности src-порта на хосте за натом в общем случае толку мало.

ef_end_y Dec 14 2016 at 02:44

Знаете, перл может кем-то и считается некрасивым языком, но говорить, что он чего-то не может — это опасно:

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

-1

ef_end_y Dec 14 2016 at 02:50

P.S. Я увидел, что вы имеете ввиду фиксацию порта на нате, я как раз об этом и не говорил

Zolg Dec 14 2016 at 09:24

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

ef_end_y Dec 14 2016 at 09:59

Честно говоря, я подумал, что вы меня тролите в том, что я не могу создать сокет с заданным src портом и я просто на нем забиндил адрес. А на счет того, что на выходе нат-а будет иной порт — признаю, я почему-то подумал, что речь идет не о симметричном нате и порт не будет подменен. В случае симметричного нат-а, конечно смысла в фиксации порта на клиенте нет смысла. Просто иначе организовать соединения через 2 ната — это уже хакерские фишки со спуфингом ip — видимо из-за этого подумал, что у человека проще условия

Alexeyslav Dec 13 2016 at 17:19

Скорей всего на той стороне стоит фаервол который следит за состоянием соединений и просто не может пропустить входящий пакет если на этот адрес/порт не было исходящего — т.е. соединение небыло инициировано изнутри сети. Иногда, эта проблема решается технологией UPNP, когда клиент специальным способом сообщает NAT что он ожидает входящее соединение. По крайней мере, последний uTorrent-клиент каким-то образом это делает. Современные роутеры в режиме NAT поддерживают UPNP, а дальше провайдер и дело за ним…

Zolg Dec 14 2016 at 02:00

Что бы работал ваш велосипедный stun необходимо, чтобы src ip и порт в которые нат транслирует внутренний адрес и порт стороны А были одинаковыми как для пакетов к стороне Б, так и для пакетов к третьей стороне. В общем случае это не так.
В частном — практически наверняка это не так у 3g провайдера. Поэтому совет поменять местами клиента с сервером некоторого смысла не лишен.

ValdikSS Dec 13 2016 at 16:30

А в будущем нас ждет следующий уровень развития NAT — Carrier Grade NAT (CGN/CGNAT).

Да, вроде как, все постепенно двигаются в сторону 464XLAT и аналогов, чтобы в сети были только IPv6-адреса, а IPv4-трансляции совершались только на NAT64-устройствах. В отличие от DS-Lite, 464XLAT — транслятор, а не туннель, что создает меньшую нагрузку на оборудование, и позволяет передавать большее количество данных в одном пакете.
Это не панацея, т.к. 464XLAT поддерживается только на мобильных устройствах, да и не на всех, но, например, T-Mobile USA и Orange Poland уже несколько лет используют его для некоторых устройств.