Комментарии 43
что такое зарегистрированный адрес?
Судя из теста, автор имеет ввиду "белый" ip адрес он же "чистый" ip адрес он же внешний ip адрес.
Верно)
Каждый кличет как хочет, так что нужно,наверное, ориентироваться на "частный" и на "публичный" в дальнейшем
---
ps в последующем учту :)
Спасибо за статью! Все четко и понятно. А команды вынесены на скриншоты чтобы не загружать текст как большинство это делает, путая читателей. Далеко не всем интересно разбираться в командах конкретного синтаксиса, который может быть разный при одном смысле. Сразу нашел в статье ясный и простой ответ на вопрос, который сам себе поднял и искал на него ответ довольно долго в свое время: как сервер понимает кому в локальной сети отправлять пакеты из интернета в режиме PAT.
Вот не вижу ответа на этот вопрос в этой статье. Ответом является NAT-таблица динамических сопоставлений internalIP:internalPort в externalIP:externalPort, которую NAT-роутер строит и поддерживает по мере поступления запросов на соединение изнутри наружу, и когда приходит ответный пакет на externalIP:externalPort из этой таблицы выбирается internalIP:internalPort, на чей запрос изначально должен был этот ответ прийти.
"Перегруженный NAT - форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта."
Слегка неграмотно. "Компьютер транслируется" в порт. Транслируется тут соединение, точнее, адрес сокета на стороне инициатора. Ну и из текста следует, что каждому компьютеру (читай IP-адресу локальной сети) соответствует ОДИН порт. Ну и вопрос, открыл ты в двух браузерах на таком компе один сайт, как роутер поймет, в какой сокет отдавать пакет, пришедший на тот самый единственный порт?
Я думаю отдаст пакет в один и тот же сокет как на компьютере с прямым внешним ip происходит. А там уже так как пакеты из разных TCP сессий они дойдут до разных браузеров.
Понятно. Но тогда определение что Пара адрес и порт образует сокет является не совсем точным. На одном порту и адресе может быть несколько сокетов
Два, я так понимаю — 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" :)
Из 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 :-)
Делаешь успехи.
NAT (Network Address Translation) для новичков