Как стать автором
Обновить

Комментарии 43

что такое зарегистрированный адрес?

Судя из теста, автор имеет ввиду "белый" ip адрес он же "чистый" ip адрес он же внешний ip адрес.

Верно)
Каждый кличет как хочет, так что нужно,наверное, ориентироваться на "частный" и на "публичный" в дальнейшем
---
ps в последующем учту :)

Строго говоря, NAT не всегда строится между частной сетью и публичной, бывает и так, что делается NAT из частной в частную сеть, например, филиальный VPN может работать не в режиме маршрутизации, а в режиме трансляции адресов, и получится, что локальная сеть скажем 192.168.10.0/24 транслируется в локальный, но на другой стороне, адрес 10.10.10.187. (Дисклеймер про совпадения.jpg)

Спасибо за статью! Все четко и понятно. А команды вынесены на скриншоты чтобы не загружать текст как большинство это делает, путая читателей. Далеко не всем интересно разбираться в командах конкретного синтаксиса, который может быть разный при одном смысле. Сразу нашел в статье ясный и простой ответ на вопрос, который сам себе поднял и искал на него ответ довольно долго в свое время: как сервер понимает кому в локальной сети отправлять пакеты из интернета в режиме PAT.

Вот не вижу ответа на этот вопрос в этой статье. Ответом является NAT-таблица динамических сопоставлений internalIP:internalPort в externalIP:externalPort, которую NAT-роутер строит и поддерживает по мере поступления запросов на соединение изнутри наружу, и когда приходит ответный пакет на externalIP:externalPort из этой таблицы выбирается internalIP:internalPort, на чей запрос изначально должен был этот ответ прийти.

"Перегруженный NAT - форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта."

Слегка неграмотно. "Компьютер транслируется" в порт. Транслируется тут соединение, точнее, адрес сокета на стороне инициатора. Ну и из текста следует, что каждому компьютеру (читай IP-адресу локальной сети) соответствует ОДИН порт. Ну и вопрос, открыл ты в двух браузерах на таком компе один сайт, как роутер поймет, в какой сокет отдавать пакет, пришедший на тот самый единственный порт?

Я думаю отдаст пакет в один и тот же сокет как на компьютере с прямым внешним ip происходит. А там уже так как пакеты из разных TCP сессий они дойдут до разных браузеров.

А вот на компе с прямым IP сокетов несколько, по одному на соединение. В этом весь нюанс. NAT (PAT) создает по одному псевдосокету с внешним IP-адресом на каждое соединение изнутри наружу, и занимается подменой TCP/UDP-заголовков при форвардинге пакетов. Снаружи ходят только пакеты с внешним(и) IP сервера NAT, внутри уже с внутренними IP клиентов, которые лезут в интернет. Поэтому в случае трансляции IP->порт не получится определить, в какой сокет клиента направить ответный пакет, если соединяться клиент будет с одним и тем же IP:port в Интернете, так как все 4 параметра пакета после NAT окажутся одинаковыми, а именно на них основывается механизм трансляции. Если транслировать в один порт соединения с разными dst ip:port, то можно определить правильный сокет на стороне клиента по источнику пакета, если это TCP- или UDP-соединение и если протокол гоняет все данные по одному и тому же соединению (например, FTP так не делает, у него одно соединение под команды, другое под данные, и для работы FTP поверх NAT нужна доп.обработка пакетов на уровне приложения, она же ALG. Туда же SIP/RTP, и ещё найдется наверняка что-либо). Оттого я в качестве примера неработающего варианта и привел ситуацию «1 ПК два браузера один и тот же сайт».

Понятно. Но тогда определение что Пара адрес и порт образует сокет является не совсем точным. На одном порту и адресе может быть несколько сокетов

Два, я так понимаю — TCP и UDP. Т.е. сюда надо добавить протокол. И да, для UDP таблица NAT-трансляций тоже есть. А вот если можно больше сокетов, или больше одного на протокол — хотел бы знать как, я тоже могу тупить :(

Как же тогда компьютер работающий с одним сайтом, но из 2х браузеров при прямом выходе в интернет с внешним ip имеет разные сокеты, протокол то у обоих TCP). Видимо сокет это программная сущность, с которой все не так просто....

Сокет=IP+протокол+порт. Если затеете собирать с такого ПК трафик, то увидите, что пакеты от одного браузера (разделять можно по активности) идут с одной пары IP:port, а в некоторых случаях теперь (TLS1.3+QUIC) ещё и по UDP, а от второго через другую, мало того, если сайт работает на HTTP/1.1, то и сокетов браузер откроет не один, а с десяток. curl/wget работают в один поток и один сокет, можно эмулировать два браузера запустив два curl — тоже увидите два сокета на клиенте.


В сущности с сокетом всё достаточно просто — клиент просит у ОС сокет на IP: протокол, она отдает "эфемерный" порт, клиент с него отправляет данные в сторону куда хочет, прилетать они будут в него же. Возможно, с тех пор, как я про сокеты читал, появилась возможность использовать оин клиентский сокет для работы с несколькими серверами и разделять потоки между собой, но в сущности можно считать каждый такой поток идущим к своему сокету. Для целей NAT'а такой клиентский сокет будет един, так как NAT-сервер разделять потоки данных не умеет, и запись в NAT-таблице будет одна.

Да, надо будет как-нибудь попробовать снять дамп трафика с компьютера при прямом доступе в интернет и двумя запущенными браузерами с одним сайтом.

Cогласно документу RFC 1918, IANA зарезервировала 3 блока адресов для частных IP (серых) (рис 1), остальные же IP адреса носят название публичных адресов (белых).

Вообще-то поболе (емнип, их аж 11). Ярчайший пример немаршрутизируемой подсети за пределами указанных - APIPA.

Для решения этой проблемы было придумано несколько способов:
...

И третий способ - использование технологии трансляции сетевых адресов - NAT.

Вот мне как-то кажется, что NAT был придуман задолго до того, как в воздухе запахло недостатком адресов. Так что корректнее сказать не "было придумано", а что-нибудь типа "может использоваться".

Вот мне как-то кажется, что NAT был придуман задолго до того, как в воздухе запахло недостатком адресов

Проект по созданию технологии, сохраняющей ip адреса, начали разрабатывать после появления резкого спроса на адреса, а массово внедрили позже...

RFC 1631 "The IP Network Address Translator (NAT)" датирован маем 1994 года, когда мы не то что про недостаток IP-адресов, а ещё даже про проблему 2000 года не задумывались.

Что же до использования NAT именно как средства борьбы с исчерпанием адресов - так это, как по мне, сказки. По-моему, всё ограничилось двумя мерами - изъятие подсетей и поднятие цен. И те, кто раньше шиковал, беря целую /24 подсеть и раздавая белые адреса рабочим станциям (сам видел, на практике!), быстренько ограничивались /29-30, а то и вообще одним адресом, и прятали всех за NAT (впрочем, там ещё свою роль сыграло появление толп малолетних хацкеров со скачанными где-то эксплойтами наперевес, в этих условиях компьютер с XP на борту голым задом в Инете - не лучшее решение).

Технологии создают тогда, когда возникает потребность в чем-либо.

Проблему нехватки могли рассматривать практически сразу после введения в эксплуатацию адресов.
NAT способен сохранить ip, разбив их на "частный" и "публичный". Под 1 публичным номером может сидеть n-ое число устройств. Маршрутизатору необходимо только изменять ip-dest пакета на ходу и занести source/dest пакета в таблицу маршрутизации.
+ сохраняется конфиденциальность узлов. ПК извне не пропингует пк в определенной локальной сети, защищенной NAT'ом на граничном маршрутизаторе.

На сколько я помню в XP SP2 (а может даже и в SP1) был вполне таки годный файрвол. Всё настраивалось, лишнее закрывалось и работало годами на белом ИП, даже без всяких обнов, патчей и антивирусов. Без файрвола - да - жило от силы сутки со всеми патчами и антивирусами, что в принципе ожидаемо - дырявая SMBv1 - это было файспалмом еще в 2000-е. Переход на /29-30 сети до сих пор не укладывается у меня в голове - это же огромный оверхед ИП-адресов. Считай у каждого клиента 3 ИП адреса - коту под хвост (подсеть, шлюз, бродкаст). Что мешало раздавать клиентам не мелко-нарезанные подсети, а ИП поштучно, используя один шлюз сразу на несколько клиентов?

Не знаю насчет клиентов, но в корпоративных сетях активно используют /31 для p2p линков между маршрутизаторами. Хотя можно и еще строже подойти и вообще не использовать IP адреса на p2p линках между маршрутизаторами, т.н. "ip unnumbered" :)

в p2p - бесспорно /31 и правильнее и секьюрнее, но это совсем другой случай.

Из nat rfc:

Abstract

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.

О проблеме исчерпания адресов задумались задолго до того как это стало проблемой. Потому, что изначально вообще существовали классы сетей A, B и C и при таком распределении не могло быть и речи о том, что адресов хватит каждому сетевому устройству в мире. Ведь уже тогда существовали факсы и сетевые принтеры. А компьютеры начали становиться доступными каждому бизнесу и любому человеку среднего класса. Академикам было очевидно, что для всего бизнеса в мире адресов не хватит, ведь IPv4 разрабатывался лишь для нужд армии США и их подрядчиков. А так же казалось, что умный дом, в каждом доме это неизбежное будущее, которое наступит в ближайшем XXI веке и всем этим умным устройствам будет нужен способ коммуникации. Но в нашем прекрасном настоящем все они коммуницируют через сервера корпораций и умирают при их отключении.

Cогласно документу RFC 1918, IANA зарезервировала 3 блока адресов для частных IP (серых) 

на самом деле 4. Все забывают про несчастный 100.64.0.0/10

А еще провайдеры любят раздавать эти адреса под видом "белых" - мало кто знает про этот диапазон.

Ну, справедливости ради, это диапазон для CGN (Carrier Grade NAT), он был описан в RFC 6598. И предназначался как раз для провайдеров, позволяя экономить уже столь дефицитные белые адреса. Что, впрочем, никоим образом не препятствует использованию как ещё одной частной сети.

А как на счет 127.0.0.1. -? Разве он не зарезервирован ?

Построить сеть на 127/8 может только самый опытный админ

Выше говорили об 3 частных IP, потом уже о 4. Я же спрашиваю об еще одном - 127. Если он также зарезервирован, то их уже 5. По поводу опытного админа, что такого тяжелого в этом айпи?

что такого тяжелого в этом айпи

Адреса 127.0.0.0/8 не рутятся никуда. Это всё - предустановленная локальная сеть масштаба одного компьютера,в которой компьютеру принадлежит сразу 16 миллионов адресов. Пакеты с айпишниками из этого блока в принципе не должны попадать в физический интерфейс. Скорее всего это правило зашито на уровне кода операционной системы.

Выше говорили об 3 частных IP, потом уже о 4. Я же спрашиваю об еще одном - 127. Если он также зарезервирован, то их уже 5.

Зарезервированные блоки и частные блоки это разные вещи. Множество частных блоков входит в множество зарезервированных. Зарезервированных вообще достаточно много .

Правильно ли я понимаю, что самы "ходовой" это Перегруженный NAT? Например раздача инета с айфона "по воздуху" посредством включения мобильной точки доступа.

+

Правильно. В iptables это называется маскарад. А static/dynamic nat в soho роутерах может быть вообще не представлен.

Полный хаос в звучании одной и той-же технологии в зависимости от вендора - весьмадоставляет )))

Так и есть. Хотя лично меня от названия "перегруженный нат" как-то коробит... PAT вполне нейтральное название отражающее механизм работы. А вот это "перегруженный" идет от аргумента "overload" команды "ip nat" в Cisco, что является их личной проблемой и другими вендорами не используется. В реальности у динамического НАТа есть два режима - NO-PAT и PAT. Если домашний интернет с одний айпишником от провайдера или с айфончика тетеринг, тогда это всегда PAT, без вариантов.

А что такое "денежная стоимость"?

А если UDP как NAT узнаёт кому пакет принадлежит?

Не имеет значения какой протокол, TCP, UDP, ICMP и т.д. NAT работает с любым из них одинаково.

Строго говоря нет никакого "и т.д.", PAT работает только с TCP, UDP и ICMP:

Port Address Translation (also called NAT overload) only supports protocols whose port numbers are known; these protocols are Internet Control Message Protocol (ICMP), TCP, and UDP. Other protocols do not work with PAT because they consume the entire address in an address pool. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/xe-16/nat-xe-16-book/iadnat-addr-consv.html

Также многие протоколы работающие поверх TCP и UDP нуждаются в NAT ALG для корректной работы. Это тоже нужно учитывать.

Для UDP тоже порт указывается, разве нет?

Строго судить не буду, но Packet Tracer как-то контрастируют с фразой "не только" в заголовке ;-) Статья уж совсем для новичков, скорее похожа на запись в бложике студента курса CCNA. И очень странно, что говоря о NAT вы не рассмотрели таблицу трансляций адресов "show ip nat translation", мне кажется это необходимо для понимания "магии" NAT'a :-)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории