Трансляция сетевых адресов (NAT)

Следующий наш модуль в курсе ICND1 — это модуль, посвященный трансляции сетевых адресов, или NAT — Network Address Translation. Механизм очень интересный, очень важный, потому что используется в 100% случаев, и если вы будете подключать какую-то сеть к интернету, то с NAT вам в любом случае придется столкнуться. Что касается трансляции сетевых адресов, механизм этот очень простой по сути своей и заключается в том, что позволяет при транзите пакета через роутер перебивать IP-адреса в нем. Штатно мы при транзите IP-пакетов через роутер ничего в нем не меняем в части заголовка, в части IP-адресов. Мы меняем поля чек-сумма, мы меняем поле TTL, вычитаем из него как минимум единичку, мы вычитаем единичку, следовательно, чек-сумма у нас, естественно, портится.

Возможно, мы залезем в управление Quality of Service и запишем что-либо в Traffic Class. Да, поэтому частично кое-какие поля в заголовке IP, они, конечно, меняться при транзите могут. Но IP-адреса при транзите не меняются. В то же время иногда нам может очень сильно хотеться сделать так, чтобы адреса у нас менялись. И для этого как раз трансляция сетевых адресов и будет использоваться. Почему этот механизм вообще появился? Я думаю, рассказывать особо не надо, но на всякий случай, если вдруг возгложет любопытство, расскажу. Появился он как результат экономии IP-адресов, потому что до того, как появился этот механизм, любой узел, который должен был выходить в интернет, обязан был иметь белый IP-шник. Вы не могли выйти в интернет, если у вас не было на конечном хосте белого адреса. Вы хотели с любого компьютера в организации выходить в интернет — вам нужна была белая сеть.

Вы хотели из дома выходить в интернет — вам нужна была белая сеть, вам нужен был белый адрес. И в каждом канале у нас используются адреса, которые принадлежат этому каналу. Все адреса, которые с таким же Network ID, как у вас, они в этом канале использоваться могут, а в других каналах адреса с таким Network ID использоваться не могут. Поэтому изначально механизм, который был в IPv4 с классовой адресацией, и потом даже спустя некоторое время появившийся с бесклассовой адресацией, все равно этот механизм расходовал адреса исключительно неэффективно. Для того чтобы более эффективно расходовать IP-адреса, были предложены как раз механизмы трансляции сетевых адресов, и мы с ними сейчас будем разбираться. Для начала вспомним то, что в интернете у нас есть адреса, которые имеют право маршрутизироваться, и адреса, которые права маршрутизироваться не имеют. Мы их так и называем — частные адреса, и вот этот блок: 10.0.0.0 по 8-й маске, 172.16.0.0 по 12-й маске и 192.168.0.0 по 16-й маске.

Мы будем такие адреса называть частными, или более строго мы такие адреса будем называть RFC 1918. Это адреса, которые любой желающий может использовать для своих нужд без каких-либо предварительных ласк, и такие адреса могут быть назначены на абсолютно любой узел. Но есть нюанс, заключающийся в том, что в интернете взаимодействие с использованием этих адресов невозможно, потому что вы назначили себе такой IP-шник, ваш сосед Вася назначил себе такой IP-шник, Google назначил себе такой IP-шник, поэтому если вы отправили какой-то пакет куда-то в интернет, и он идет с таким частным адресом, непонятно, куда возвращать результат. Естественно, нельзя пакеты в интернет с такими частными адресами направлять, потому что, опять же, непонятно, кому именно они будут отправляться. Эти самые RFC 1918 адреса, по идее, маршрутизаторы на входе в свою сеть должны пристреливать, если вдруг они их увидят. И многие провайдеры действительно так и делают. Они, если вдруг вы попытаетесь отправить им пакет с указанием такого частного IP-шника,

будут такие пакеты удалять. Дальше. Если вдруг вы очень сильно хотите отправить IP-пакет из-под узла, у которого есть такой частный адрес, и вы хотите такой пакет выпустить в интернет, то, учитывая, что эти адреса выпускать в интернет нельзя, а иногда очень хочется, был придуман механизм, который позволял бы перебить эти частные IP-шники на какой-нибудь или какие-нибудь публичные адреса, которые вы действительно приобретаете законным образом. Вы берете эти адреса во временное пользование у организации, которая занимается распределением IP-шников. На самом деле, не у нее напрямую, а у ее представителей, либо региональных регистраторов, которых, как вы помните, пять штук. RIPE, ARIN, AfriNIC, LACNIC и APNIC. Либо их локальных представителей, или Local Internet Registry.

На самом деле, есть и другие адреса, которые нельзя выпускать в интернет, но нас сейчас они не сильно будут интересовать. Мы в основном сейчас ориентируемся на эти IP-шники, которые чаще всего используются в корпоративных сетях. Эти адреса необходимо, перед тем как вы отправите пакет в интернет, каким-то образом модифицировать. И транзитный роутер, на котором включена функция NAT, он будет эти самые адреса менять. NAT — это механизм, который именно преобразует адреса. Он не делает ничего больше. Очень частое заблуждение, что NAT как-то связан с другими механизмами, например, с маршрутизацией. И если маршрутизация отработала как-то не так, или NAT отработал как-то не так, то что-то там такое произойдет. Нет. На самом деле, это абсолютно независимый механизм. Отдельно работает маршрутизация, отдельно работает принятие решения, стоит ли пакет отправлять или не стоит, и отдельно работает механизм перебивки адресов в нем. Это не связанный с маршрутизацией механизм,

он совершенно отдельный. Для того чтобы адреса перебивать, вам нужно правило, по которому эти адреса будут меняться. Вам нужно указать, что и на что в каких пакетах мы меняем. При этом, если мы меняем что-то в проходящих IP-пакетах, то мы нарушаем тем самым требования протокола IP, и как следствие нам нужно будет убедиться, что приложение не заметит изменений, которые мы вносим в пакеты. Во-первых, если мы вносим какие-то изменения в IP-адреса в пакете, у нас как минимум меняется чек-сумма в пакете. Когда наш роутер, который будет пропускать через себя какой-то пакет и будет в этом пакете перебивать IP-адреса, он как минимум должен будет убедиться, что в заголовке IP чек-сумма будет правильной. Мы не просто перебиваем адрес, мы еще чек-сумму меняем. Во-вторых, он должен будет посмотреть, что внутри лежит. Потому что, например, если там лежит TCP, либо UDP, либо ICMP, у них есть своя собственная чек-сумма. И эта чек-сумма включает в себя IP-адреса. И поэтому, если вы залезли в заголовок IP,

поменяли там IP-шник, то этого мало. Надо заглянуть, что внутри лежит, проверить — не TCP, не UDP или не ICMP. И если вы что-то там перебили, то чек-сумму внутреннего протокола тоже надо будет поменять. Благо, она предсказуемая. В некоторых случаях, если вы отправляете какой-то пакет в рамках какого-то приложения, и внутри самого текста отправляемых данных вы указываете, какой у вас есть IP-адрес. Например, так делает FTP, File Transfer Protocol. И если вдруг вы меняете IP-адреса в заголовке IP-пакета, то у вас получается несоответствие того, что вы в тексте сообщения указываете, тому, что вы задекларировали в заголовке IP, если там адреса поменялись. Поэтому роутер, который выполняет трансляцию сетевых адресов, он не просто меняет IP-шники, не просто перебивает чек-сумму в IP, не просто заглядывает внутрь, что там лежит TCP, либо UDP, либо что-то еще, и меняет чек-сумму еще и там. Он должен расковыривать содержимое транзитных пакетов,

смотреть, что внутри передается, и менять еще иногда содержимое передаваемых данных. И если вы этого не сделаете, то приложение просто корректно работать не будет. Классический пример того, где требуется расковыривать полезные данные, это протокол FTP. Еще, например, есть протокол SIP, который для телефонии используется, Session Initiation Protocol. У него та же самая история. Он в открытом виде показывает тот IP-шник, с которого идет подключение. И если вдруг вы пропускаете такой SIP через NAT, то вам нужно будет специальным образом бороться с проблемой вида «вы перебили IP-адреса». Как уже было сказано, когда вы что-то меняете, у вас должно быть правило, что и на что мы меняем. И мало того, что вы перебиваете пакеты, которые проходят через ваш роутер, и частные адреса будете заменять на публичные, или какие-то другие адреса будете подставлять в общем случае. У вас будет правило,

что и на что мы меняем. Надо еще будет в обратную сторону пакеты тоже менять. Если у вас есть внутренний какой-то узел, здесь компьютер находится, и он отправляет пакет с частного адреса 192.168.1.1 на какой-то публичный IP-шник. Такой пакет проходит через роутер, на котором работает NAT. И роутер говорит: мы не можем этот 192.168.1.1 оставить в пакете, потому что мы выпускаем такой пакет в интернет, мы должны частные IP-шники перебить. И у нас есть табличка, которая говорит: давайте поменяем 192.168.1.1 на какой-нибудь публичный адрес, который мы можем подставить. Например, 203.0.113.1. И такой пакет уходит наружу. И вроде все хорошо, да? Но мало пакет отправить наружу, надо еще ответные, встречные пакеты пробросить внутрь. И во встречных ответных пакетах у вас какие адреса будут стоять? Правильно, те, которые внешний узел получил в качестве адреса источника. Он увидит

этот 203.0.113.1, он на него и будет отправлять ответы. И у вас должно быть правило, что если вы меняете 192.168.1.1 на 203.0.113.1, то и в обратную сторону это правило должно тоже работать. Если вы видите пакет, идущий на 203.0.113.1 на, в кавычках, внешнем интерфейсе, вы такие адреса должны будете поменять обратно на внутренний, 192.168.1.1. Классический NAT, который изначально был придуман, предполагал, что у каждого узла, который сможет выйти в интернет, у него будет свой собственный внутренний адрес, и он должен иметь отдельный, свой собственный публичный IP-шник. Механизм предполагал, что сколько у вас есть хостов во внутренней сети, столько белых адресов вам и будет нужно. И очень часто здесь есть непонимание. Предполагается, что в современном мире так не используется, и кажется, что в современном мире не используется это из-за того, что катастрофически неэффективное расходование IP-адресов. Но на самом деле

это катастрофически неэффективное расходование IP-адресов по современным меркам было огромным прорывом в экономии IP-адресов по сравнению с тем, что было раньше. Фишка в том, что когда-то давным-давно у нас была классовая адресация, И, соответственно, если у вас была какая-то внутренняя частная сеть, локальная сеть, назовём её. И в этой локальной сети у вас было, например, 300 пользователей. Не так много. И вы хотели некоторым пользователям из этой сети давать выход в интернет. А всем вы не хотели давать выход в интернет, потому что скорости выхода в интернет были тогда не такие большие, как сегодня. И вам из этой сети надо было дать гипотетически, даже теоретическую возможность выхода в интернет только, например, 100 пользователям. Что вы должны были делать в классовом мире? Вы должны были сказать: 300 юзеров, значит, нам нужна сеть класса B. Если некоторым пользователям надо в этой сети выходить в интернет, значит, все эти IP-шники, все 65 536 IP-шников сети класса B должны быть белыми,

чтобы они чувствовали, что они находятся в одной сети, и чтобы некоторые из них могли выйти в интернет. Поэтому вы покупали публичную сеть класса B. Из 65 тысяч адресов, которые в этой сети были, по факту только 100 будут пользоваться услугами интернета, а всем остальным вы запрещаете ходить в интернет, вы делаете это на уровне фаервола. Действительно, в случае, если вы используете NAT, по сравнению с таким расходованием IP-адресов, NAT предлагает услугу экономии адресного пространства. Вместо того, чтобы назначать на узлы сетку класса B, классовую белую, вы берёте сетку класса B серую, вы берёте сеть, например, 172.16.0.0, классовая сеть класса B, назначаете её на все узлы в вашей локальной сети, а дальше покупаете белую сетку класса C. В ней намного меньше адресов, в ней 254 адреса, которые вы можете назначить на хосты.

Но вам достаточно, чтобы из этой сети только 100 узлов получили IP-шники, и вы делаете такое соответствие. Вы говорите: узлу 172.16.1.1 вы даёте вот такой адрес. Узлу 172.16.1.2 вы даёте другой адрес. И вы сопоставляете, если хотите, псевдонимы из белой сети узлам внутри вашей серой сети. И каждый узел у вас получает отдельный белый адрес. У него есть свой собственный адрес, назначенный на интерфейсе. И это адрес из серой сети. И есть отдельный IP-шник, который на нём нигде не прописан, но который используется для выхода в интернет. И именно транзитный роутер, у него есть таблица соответствия: какой частный IP-шник какому публичному IP-шнику будет соответствовать. Зачем так нужно делать? Почему нельзя, допустим, всем сделать один и тот же IP-шник? А именно потому, что вы должны будете потом обратный трафик вернуть. Когда у вас пакет идёт от узла 192.168.1.1

наружу, вы его перебиваете в 203.0.113.1. Когда возвращаются пакеты на 203.0.113.1, вы возвращаете их ровно на того, за кем этот IP-шник зафиксирован. Если какой-то другой узел 192.168.1.200 направляет пакеты изнутри наружу, вы его перебиваете в другой IP-шник, 203.0.113.200, и пакеты, которые идут обратно на уже этот адрес, вы возвращаете не на 192.168.1.1, а именно на 192.168.1.200. Эта штука перебивает только сетевой адрес, а также контрольные суммы, все необходимые, а также заглядывает внутрь протоколов. Но она оперирует именно IP-адресами для того, чтобы понять, на кого надо вернуть исходный пакет. Это то, как был придуман изначально NAT. Он называется Network Address Translation, и он перебивает сетевые адреса. Здесь NAT — это, соответственно, Network Address Translation. Network Address — это адрес, сетевой адрес, Translation — это трансляция. Трансляция сетевых адресов. Ровно то, что написано, ровно то, как он называется, оно и делает. Ничего больше не делает.

Чем хорош такой механизм NAT по сравнению с его отсутствием? Тем, что позволяет экономить публичные IP-шники по сравнению с классовым назначением IP-адресов, который был до него. Чем он плохой? То, что очевидно, каждому узлу потребуется публичный IP-шник дать. В некоторых случаях это будет не очень удобно. Не очень большая экономия будет наблюдаться. Прямо скажем, её там даже не будет наблюдаться. Вторая проблема будет заключаться в том, что вы, используя такой механизм NAT, можете оперировать только IP-адресами. И даже то, что вы будете оперировать только IP-адресами, но не будете изменять никакие другие полезные данные, возможно, будет означать, что приложения у вас будут страдать. Некоторые приложения можно будет научить работать через NAT. Механизмы, которые позволяют обойти NAT, будут называться NAT Traversal. Это общее название технологий, которое позволяет пройти через NAT.

NATT или NAT Traversal. Некоторые приложения будут требовать этого дополнительного механизма. Очевидно, что TCP, UDP, которые считают контрольные суммы от псевдозаголовка, то есть от IP-адресов, они потребуют этих процедур, но это предполагается штатно, что у вас роутер будет пропускать через себя TCP, UDP, поэтому он все эти процедуры делает безусловно. В некоторых случаях вы не можете на роутере вообще ничего сделать. Например, протокол, который является частью стека IPsec, называется ESP, который шифрует все данные и плюс подписывает все данные цифровой подписью. И у него цифровая подпись включает в себя IP-заголовок. Если вы вносите изменения в IP-заголовок, то ESP от этого страдает. У него цифровая подпись теперь не сходится. И ничего с этим не сделаешь, потому что транзитный роутер не может поменять цифровую подпись. У него нет для этого необходимой ключевой пары.

Закрытого ключа оригинального отправителя у него, естественно, нет. Поэтому протокол ESP будет очень сильно страдать от того, что где-то в NAT будут вноситься изменения. Но у него тоже есть механизм NAT Traversal, который заключается в том, что исходный отправитель, понимая, что он работает за NAT, может взять IP-пакет, который он сформировал в ESP, и обернуть его UDP-шным заголовком, и завернуть его в новый IP-шный заголовок. То есть сделать два заголовка. Один, который будет защищён цифровой подписью, а другой, который он специально на заклание отправляет, так, чтобы его NAT испортил. Но получатель примет такой испорченный заголовок, который не покрывается цифровой подписью, откроет, увидит содержимое, которое защищено цифровой подписью, и проверит, что это содержимое работает корректно. Если вдруг вам интересно, ESP будет использовать UDP порт 4500, по-моему, для таких задач.

NAT — механизм, который позволил IPv4 прожить намного дольше по сравнению с тем, сколько он должен был прожить. В принципе, уже в начале 90-х годов было понятно, что IPv4 не приспособлен для масштаба интернета. Но за счёт того, что в 92-м году NAT появился, даже сегодня, в 2019-м году, спустя, сколько получается? 27 лет. Мы продолжаем считать, что IPv4 — это доминирующий протокол в интернете. Он действительно такой. И в принципе ближайшие лет 10 ему вряд ли что-то угрожает. Это всё возможно благодаря NAT. Но NAT нарушает базовый принцип, который в IP изначально был. Это связанность от края до края. Любой узел, который участвует в IPv4 взаимодействии, в глобальном IPv4 взаимодействии, должен либо иметь возможность достучаться до любого другого узла, либо это должно быть запрещено просто административно. Не то, что это в принципе невозможно сделать,

а это запрещено делать. Понимаете разницу? NAT делает именно физически невозможным взаимодействие между любыми двумя узлами, если один из этих узлов или два из этих узлов находятся за NAT. Поэтому базовый принцип связанности от края до края будет нарушаться благодаря этому самому NAT. Для некоторых протоколов, в частности для TCP и UDP, есть механизм, который дополнительно к тому, что делает базовый Basic NAT, позволяет ещё лучше экономить IP-адреса. Даже классический NAT, который перебивает только IP-адреса, всё равно позволяет эти адреса экономить. Но есть механизм, который намного более эффективно экономит эти самые адреса, и это будет называться механизм Network Address and Port Translation. Это официальное название по RFC, которое, однако, в индустрии не очень популярно. Сама Cisco называет его Port Address Translation.

Суть та же самая, но при этом она предпочитает термин PAT. Во многих других реализациях используются термины маскарадинг, NAT с overload, NAT с перегрузкой, many-to-one NAT и прочие разные другие названия. И обозначает всё это одно и то же по сути своей. Обозначает это подмену не только IP-адресов. Если мы сравним название RFC, Network Address and Port Translation, и сравним его со словом NAT, Network Address Translation, мы увидим, что там что-то про порты упоминается. И действительно, когда мы работаем с механизмом Network Address and Port Translation, перебиваться будут не только IP-адреса. IP-адреса тоже будут перебиваться, но порты при этом будут перебиваться тоже. И этот механизм, который позволяет перебивать порты для TCP и UDP, будет как раз существенно расширять возможности трансляции сетевых адресов. По сути своей,

если мы запускаем обычный классический NAT, то мы подменяем IP-адреса. У нас есть указание, что и на что мы меняем. В случае с Network Address and Port Translation мы будем менять не IP-адрес, а пару IP-шник плюс порт. И эта пара IP-шник плюс порт будет называться словом сокет. И когда мы отправляем какой-то пакет, содержащий, например, TCP-шную датаграмму или UDP-шную датаграмму, в этих TCP-шных или UDP-шных датаграммах у нас есть порт отправителя, порт получателя. И фактически мы можем сказать, что эта датаграмма идёт с одного сокета на одном компьютере на другой сокет на другом компьютере. Если мы будем отправлять некий пакет и менять в нём и IP-шник, и порт, мы можем сказать, что мы меняем какой-то один сокет на другой. В чём фишка этого механизма по сравнению с классическим NAT? А в том, что вы можете, после того, как вы подменяете какие-то одни сокеты на другие,

эти самые другие сокеты выбирать таким образом, чтобы IP-шник у этих сокетов был одинаковый, а порты при этом были разные. Но гарантии сохранности порта при этом нет, поэтому такое можно делать только в ситуации, когда вы знаете, что протокол использует динамические порты. Но для большинства ситуаций, когда мы хотим выпустить некоторые пакеты в интернет, это как раз и будет актуально. У нас, как правило, пакеты идут на хорошо известный порт, и в этом случае ни IP-шник, ни порт мы менять права не имеем. Но это адреса назначения, они и так белые. А вот частный адрес и порт источника мы имеем право менять. Частный адрес мы, больше скажем, обязаны поменять на какой-то публичный. А порт источника, он, как правило, динамический, и его можно смело перебивать на что-нибудь другое. И мы можем в этом случае, например, если у нас есть какой-то узел, который отправляет UDP-шную датаграмму из-под частного IP-шника,

из-под какого-то динамического порта, мы можем протранслировать и сделать так, чтобы этот пакет шёл из-под другого IP-адреса и из-под другого порта. Но IP-шник получателя и порт получателя мы, конечно же, трогать права не имеем. Если у нас будут какие-то другие подключения идти с других внутренних адресов, мы можем эти адреса перебивать в такой же публичный адрес. Мы можем в такой же адрес источника менять. У всех исходящих подключений в этом случае IP-шник источника может быть одинаковый. Но возникает вопрос: как мы сможем разобраться, какой обратный трафик кому надо протранслировать вовнутрь? А именно как раз по портам. Мы будем записывать, какой внешний сокет мы кому дали. И когда у нас будут приходить пакеты, они будут приходить на эти сокеты, и мы по этим сокетам будем принимать решение, на какой внутренний сокет надо это всё дело перебить.

В этом случае у нас опять же будет табличка трансляции, но в этой табличке у нас уже будут не IP-адреса, а сокеты. Есть один узел с адресом 192.168.1.1, который из-под порта 54321 отправляет UDP-шную датаграмму, и она идёт на какой-то публичный IP-шник, на публичный порт. Окей, не проблема. Меняем IP-шник на какой-нибудь, которым мы распоряжаемся, и меняем порт на какой-нибудь. А может быть, не меняем. Если у нас есть такая возможность, если мы знаем, что порт свободный, то мы можем его оставить. Чаще всего реализации NAT так и стараются делать. Если порт есть возможность сохранить, они его стараются сохранить. В этом случае мы говорим, окей, у нас частный IP-шник 192.168.1.1 меняется на публичный IP-шник 203.0.113.1. Порт мы в этом случае смогли сохранить, и мы такой пакет отправляем наружу. Обратные пакеты, которые будут приходить

на этот IP-шник, на этот порт, мы будем транслировать на 192.168.1.1 на тот самый порт, который мы записали. И у нас есть в табличке запись, что такой-то сокет мы меняем на такой-то сокет. Пару IP-шника и порта меняем на другую пару IP-шника и порта. Можем рядышком записать также, на какой IP-шник мы отправляли данные, если вдруг зачем-то нам это будет интересно. Но большинство реализаций как раз не записывают, на какой IP-шник отправлялись данные. Им достаточно только того, что IP-шник-источник меняется на другой IP-шник-источник. Если вдруг есть какой-то другой узел, 192.168.1.200, который будет отправлять пакеты из-под того же самого порта, мы IP-шник, откуда отправляются данные, можем, например, поставить такой же, как он был, 203.0.113.1. Но для того, чтобы обратные пакеты, которые будут приходить, разделить на те, которые предназначены для 192.168.1.1, и для 192.168.1.200,

мы уже не можем дать такой порт, который уже был задействован под другую сессию. Поэтому даже если вдруг этот узел захотел такой же порт 54321, мы говорим, извини, товарищ, но мы не можем тебе такой же порт дать. Мы тебе меняем и IP-шник, и порт, и делаем тебе порт 54322. И пакеты, которые идут на 54322, мы уже транслируем обратно вовнутрь на 192.168.1.200. Если вдруг какой-то ещё узел захочет какой-нибудь свободный порт заиметь, никаких проблем, мы ему выдадим свободный порт. Таким образом эта штука работает. В табличку, кто и на что был изменён, вы изменения вносите либо ручками, указываете, какие IP-шники источника с какими портами вы на что меняете. Но это чаще всего не очень удобно, потому что эти порты у вас придумываются динамически,

и предусмотреть все варианты IP-шников и портов, которые динамически генерятся, будет очень сложно. Поэтому чаще всего вы говорите, что всё, что приходит изнутри, вы наружу отправляете, порт стараетесь сохранить, а IP-шник, в который перебивается, чаще всего у вас либо один, либо их какое-то очень ограниченное количество, и вы просто выбираете первый попавшийся из некоторой маленькой кучки. Этот механизм NAT с трансляцией портов — это тот самый механизм, который сегодня повсеместно используется в интернете для выпускания пользователей в интернет, если вам так будет удобно. У этого механизма есть особенности. Это одновременно и достоинства, и недостатки. Смотря с какой стороны посмотреть. Достоинство заключается в том, что вы не должны будете перечислять, например, все частные адреса, которые у вас есть. Трансляции в табличку будут добавляться динамически, и никаких специальных настроек для работы отдельного приложения вам, как правило, делать не нужно.

Но это же и недостаток, на самом деле, потому что вы заранее, как пользователь приложения, не знаете, из-под какого IP-адреса у вас будут отправляться пакеты, например, с какого порта они будут отправляться, потому что в обычном случае, когда у вас есть какое-то приложение, оно знает, из-под какого порта вы ставите сессию. Но если вы знаете, что ваше приложение будет использоваться через NAT, то вы не можете предположить даже, с какого порта по факту с NAT-роутера ваши пакеты будут уходить. Для решения этой проблемы в некоторых случаях нужно использовать внешние механизмы. Для телефонии, например, часто используются механизмы, которые называются либо STUN, либо TURN. Механизм STUN позволяет приложению подключиться к некоторому серверу внешнему в интернете и посмотреть, из-под какого IP-адреса, из-под какого порта идёт подключение. Иногда эта штука

срабатывает достаточно неплохо, если у вас конечное приложение всегда получает одни и те же IP-адреса, одни и те же порты. Но если у вас NAT-роутер каждому приложению под каждую отдельную сессию выдаёт отдельную пару IP-шника и порта, то эта штука может не сработать, и тогда TURN — это фактически UDP-прокси. Вы отправляете пакеты на внешний сервер, а он уже отправляет эти пакеты куда-нибудь ещё. Эти два механизма чаще всего в телефонии используются. Если говорить про какие-то механизмы попроще, то механизмы попроще — это как раз протокол, про который у нас есть слайд. Это протокол, называемый часто UPnP, Universal Plug and Play. На самом деле это неверное название, это маркетинговый термин, а протокол по факту называется IGD, Internet Gateway Device Control Protocol. И этот механизм позволяет приложению подключиться к роутеру, который выполняет NAT-трансляцию,

с помощью стандартных механизмов запросить у этого роутера какие-то действия. Например, можно спросить, какой у меня будет публичный IP-шник, если я буду подключаться к интернету. Или какой у меня будет номер порта, если я сейчас поставлю сессию, какой номер порта ты мне выдашь. Или какие трансляции по факту установлены. Такие вещи UPnP позволяет делать. Естественно, чаще всего это не применяется в корпоративных сетях, потому что добавить новую трансляцию к существующим — это какая-то очень сомнительная операция с точки зрения корпоративной иерархии, когда конечное приложение на хосте клиента вдруг начинает указывать роутеру, как ему дальше существовать. Но в домашних сетях, например, эта штука часто используется. Если говорить про конкретное оборудование, которое это поддерживает, это обычно всякие линейки оборудования small office, home office. Более-менее серьёзные

сетевые операционные системы этот протокол чаще всего не поддерживают. Например, те же самые циски. Это что касалось теории по механизму NAT. Давайте посмотрим на то, как работает NAT на практике. Конкретно довольно специфическая, но всё-таки реализация NAT в Cisco IOS. Редактор субтитров А. Семкин, Корректор А. Егорова