Основы настройки NAT на оборудовании Cisco

Если мы говорим про циску, то НАТ в цисках есть. Более того, у цисок есть много разных видов НАТа. Тот вид НАТа, который есть в курсе, это самый простой, самый базовый тип НАТа, который у циски появился уже непонятно сколько лет назад, много, по крайней мере, и он настраивается немножко странным образом. Если вдруг у вас есть опыт настройки НАТа на оборудовании других вендоров, вам может показаться эта настройка НАТа довольно странной, но, поверьте, она довольно древняя. И существуют другие реализации НАТа прямо в самой циской ИОС. В принципе, если вы захотите, вы можете сказать: нам не нравится один механизм, который у нас здесь есть, мы будем использовать другой механизм, но и в курсе, и в экзамене, и чаще всего в реальной жизни используется именно тот вид НАТа, который мы сейчас с вами разберём. Итак, этот НАТ будет называться domain-based НАТ.

Этот термин встречается только в довольно продвинутой литературе, в базовых книжках уровня ICND1, ICND2 вы его не увидите, но тем не менее это domain-based НАТ, и он имеет довольно говорящее название. Domain-based означает, что у вас есть два адресных пространства, два домена, в одном из них допустимы кривые адреса, а в другом кривые адреса недопустимы. И называться эти два домена, два адресных пространства, будут inside и outside. Далеко не всегда, когда мы работаем с НАТом, у нас есть только два адресных пространства, и далеко не всегда ситуация будет именно такая, что у нас в одном есть и кривые адреса, и нормальные белые адреса, а в другом только белые. В реальности бывают существенно более изощрённые конфигурации, где адресных пространств будет 3, 4, 5, 10, и разные области видимости будут у адресов,

которые используются в этих адресных пространствах, но это всё будет существенно более сложной конфигурацией, чем те, которые будут проверяться на экзамене, и чем те, которые требуются в 99,99% случаев в небольших корпоративных сетях. Этот domain-based НАТ, который работает ровно с двумя адресными пространствами, закрывает потребности большинства нормальных организаций. Для того чтобы это всё работало, вам нужно будет указать, с какой стороны у вас будет какое адресное пространство. У вас есть роутер, у него есть некоторое количество интерфейсов. Может быть такое, что у вас будет два интерфейса, может быть такое, что у вас будет много этих интерфейсов, но каждый из этих интерфейсов должен смотреть либо в серую область, либо в белую область. Представим себе, что вот это адреса, которые смотрят в серое адресное пространство, а вот это адреса, которые смотрят в белое адресное пространство. А есть ещё адреса, которые непонятно куда смотрят. И если у вас интерфейс не смотрит ни в одно из адресных пространств,

то НАТ на нём работать не будет. Domain-based НАТ работает следующим образом. Если пакет приходит из одного адресного пространства в другое, то мы в нём выполняем трансляцию сетевых адресов. Если пакет приходит непонятно откуда, непонятно куда, то трансляцию мы в нём не выполняем. Учтите, что НАТ и маршрутизация никак между собой напрямую не связаны. Маршрутизация у вас работает отдельно по IP-адресам, которые есть в заголовке пакета. И НАТ, перебивка сетевых адресов, работает отдельно, никак на маршрутизацию не завязана. Команды, которыми мы размечаем адресные пространства на циске, будут в настройке интерфейса: IP NAT INSIDE и IP NAT OUTSIDE. Название у них довольно говорящее. IP NAT INSIDE — это интерфейс смотрит в область, в которой разрешены кривые адреса. IP NAT OUTSIDE — интерфейс смотрит в область, в которой не разрешены кривые адреса, например, в интернет. Дальше есть ещё одна дополнительная терминология,

которая нам сейчас потребуется, и она всегда вносит сумятицу. Если с адресными пространствами INSIDE и OUTSIDE всё более-менее ясно, то бывают ещё некоторые названия, которые надо будет просто запомнить, почему эти названия применяются тем или иным образом. И термины, которые нам сейчас потребуются, это термины local и global. Local — это те адреса, которые применимы в адресном пространстве INSIDE. Условно говоря, это адреса, которые могут быть либо серыми, либо белыми, но это адреса, которые встречаются в пакетах, идущих по интерфейсам, находящимся в этой серой зоне INSIDE. Global — это те адреса, которые будут использоваться в адресном пространстве OUTSIDE. Это адреса, которые заведомо белые. И если у нас есть какой-то пакет, который проходит через наш роутер, у него есть два адреса —

адрес source и адрес destination. Если пакет идёт из адресного пространства INSIDE в адресное пространство OUTSIDE, то пока этот пакет бежит по интерфейсу во внутреннем адресном пространстве INSIDE, у него и source адрес, и destination адрес локальны. Как только этот пакет проходит через маршрутизатор с НАТом и выплёвывается наружу через внешний интерфейс outside, у него те же самые source и destination поля содержат уже другие адреса. Это адреса после перебивки. У нас роутер с НАТом выполняет перебивку сетевых адресов. Он может перебивать как source адрес, так и destination адрес. Он гипотетически может перебивать и то, и другое. По факту мы чаще всего перебиваем только source адрес в такой ситуации, но destination адрес мы тоже можем перебивать. И в этой ситуации мы локальные адреса перебиваем на глобальные. То, что у нас в source адресе был локальный адрес, он становится глобальным. И destination тоже был локальный, он становится глобальным.

И пакет, который после перебивки отправляется в интернет, идёт с source адреса inside global в destination outside global. Тот же самый пакет, только после перебивки сетевых адресов. Адреса были локальные, оба стали глобальными. Если вдруг мы указываем, что мы хотим перебивать только source адреса, то source адрес здесь и source адрес здесь у нас будут разные, а destination адрес мы не меняем. И destination адрес до перебивки и destination адрес после перебивки мы не трогаем, они остаются точно такими же. Всё равно терминология у нас здесь сохраняется. Адрес outside local мы по некоторому правилу меняем на outside global. Это правило может заключаться в том, что мы адрес не изменяем никак. Но всё равно этот адрес будет после перебивки. Адрес до перебивки, адрес после перебивки — это адреса, может быть, очень похожие друг на друга, до бита похожие, но они всё равно будут разные.

Как на нём штамп авиационной безопасности на билете ставят — досмотрено. Это тоже адрес «досмотрено», никаких изменений в нём не внесено, но просто штампик поставили, что он мог бы быть перебит, но не перебит. Итак, что будут означать inside local и outside local? Локальные означают: до перебивки пакет находится в адресном пространстве inside и собирается идти в адресное пространство outside. Source address — это откуда пакет идёт. Пакет идёт из адресного пространства inside, destination — адресное пространство outside. До перебивки локальные адреса — оба. После того как пакет проходит через NAT, он по-прежнему идёт из inside в outside. Здесь у нас был inside, пакет прошёл через NAT и вышел в outside. Но source address как был из inside и destination address как был в outside, они так и остались. Только после перебивки мы, возможно, поменяли, а может быть и не поменяли эти адреса.

И когда пакет прошёл через NAT, отправился наружу, мы в нём адреса перебили, и то, что у нас было «пакет идёт из inside local в outside local», после перебивки стало «пакет идёт из inside global в outside global». Обратные пакеты, которые будут идти, будут менять местами всё, что у нас есть. Пакет идёт во внешней сети, во внешнем адресном пространстве, ещё не подвергся обратному NAT. Пакет идёт откуда? Из outside. И пакет с точки зрения NAT куда пойдёт? В inside. Поэтому destination у нас inside чего-то, source — outside чего-то. И поскольку пакеты ещё пока не прошли перебивку и находятся во внешнем адресном пространстве, то адреса, которые здесь будут указаны, глобальны. После перебивки у нас адрес источника — откуда пакет идёт — из outside, но уже после перебивки, локальный. Пакет идёт куда? Во внутреннее адресное пространство inside.

Но после перебивки он стал уже локальный. Outside global равно outside local. Зачем так мудрить? Дело в том, что в некоторых случаях мы будем менять и outside адреса тоже. Может быть такое, что пакет, который пройдёт через роутер, у него будут меняться и source адреса, и destination адреса. В некоторых случаях это будет нужно. Поэтому гипотетически мы можем поменять и то, и другое. А по факту чаще всего мы меняем только inside адреса, source, в пакетах, которые идут изнутри наружу. Inside local мы меняем на inside global. И в обратную сторону, когда пакеты идут снаружи вовнутрь, inside global мы меняем обратно на inside local. А outside local и outside global адреса чаще всего совпадают. Давайте, если вдруг вы запутались во всех этих терминах, покажем на примере. У нас есть какой-то внутренний узел, компьютер. У него есть IP-шник 192.168.1.1.

Он отправляет пакет на какой-то публичный адрес 198.51.102. Просто обычный IP-пакет, который идёт по проводу. Бежит, бежит, бежит. Втыкается в роутер с NAT. У этого роутера на интерфейсе написано IP NAT inside. Дальше запускается маршрутизация. Мы находим внешний интерфейс для этого пакета, через который он выйдет. На этом интерфейсе написано outside. Мы понимаем, что необходимо провести трансляцию, и мы что-то на что-то должны поменять. В source адресе у нас хранится inside local адрес до того, как он был перебит. Мы inside local адрес меняем на inside global. Это адрес, который был в том же самом месте, только он был перебит. 192.168.1.1 мы перебили на 203.0.113.1. Inside local перебили на inside global.

Пакет всё равно идёт из inside в outside. У него в source адресе всё равно что-то inside будет находиться. Но адреса до перебивки и адреса после перебивки — это локальные и глобальные адреса соответственно. Destination адрес мы не трогаем. Это не означает, что мы вообще никакого преобразования не производим. Мы производим пустое преобразование. Мы ничего с этим адресом не делаем, но мы ставим на нём штампик — досмотрено. И поэтому адрес, который у нас был в destination, это outside local, мы меняем на outside global. И inside local мы меняем на inside global. Outside local мы меняем на outside global. Если вам хочется зафиксировать это в какой-то бумажке, то вы можете записать примерно то, что здесь написано. Такую табличку чаще всего во всех книгах пытаются привести

для того, чтобы кто-то пытался запомнить, что здесь к чему соотносится. Inside — внутренний узел, локальный адрес до перебивки — 192.168.1.1. Это откуда идёт пакет. Inside local. После того как мы перебьём этот адрес, адрес будет какой-то уже публичный, он становится inside global. И destination адрес — это outside local, мы его перебиваем, оставляя таким же, он становится outside global. Когда обратные пакеты идут, они идут с адреса outside global на inside global. Пакеты до перебивки идут из outside в inside. После перебивки они становятся с outside local на inside local. Как был здесь 198.51.102, так и здесь он остался 198.51.102. Те адреса, которые красненькие, — это локальные адреса,

те адреса, которые синенькие, — это глобальные адреса. Я думаю, что вы немножко покурите эту схемку и поймёте, что я имею в виду. Если вдруг даже не поняли — не переживайте, на экзамене вряд ли вас будут по этому поводу очень сильно мучить. Но тем не менее разобраться в этой схеме полезно. Когда мы работаем с domain-based NAT, мы должны будем указать, что и на что мы меняем. И чаще всего мы меняем inside local на inside global. Это в подавляющем большинстве случаев именно наш вариант. Мы должны будем те адреса, которые кривые косые, при выпускании в интернет заменить на прямые белые. И потом, когда обратная трансляция будет осуществляться, прямые белые адреса обратно поменять на кривые косые. Эти кривые косые адреса в исходящих пакетах стоят в поле source. Там находятся inside local адреса. Мы их меняем на inside global. И наоборот. Destination inside global адреса

меняем на destination inside local для пакетов, которые идут в обратную сторону. Как понимаете, это типичный сценарий для доступа в интернет. Такой тип NAT, такой тип трансляции, называется inside source NAT. Это название может показаться сейчас немножко нелогичным, но оно абсолютно логичное. Оно отвечает на вопрос: что, где и на что меняем. Такое название полностью говорящее. Меняем inside адреса. У нас этих inside адресов две штуки: inside local и inside global. Мы их меняем местами. В пакете, где у нас есть inside local, мы меняем на inside global. В пакете, где есть inside global, мы меняем на inside local. И мы встречаем это в тех пакетах, где inside адрес стоит в поле source. Давайте посмотрим, где в этой схеме inside адреса стоят в поле source. Мы находим, что у нас есть один вариант — пакеты туда идут, другой вариант — пакеты обратно идут.

Inside адреса в поле source — это как раз пакеты, выходящие наружу. Вот они. Меняем inside local на global. В обратных пакетах эти адреса inside стоят в destination. Обратная трансляция создаётся автоматически. Мы не должны её как-то специально создавать. Но всё-таки, если мы хотим выпускать пакеты в интернет, основное наше стремление будет именно обеспечить прохождение пакетов с частных адресов на публичные адреса, изнутри наружу. В случае если мы делаем inside source NAT, нам нужно будет, во-первых, разметить интерфейсы: пометить интерфейс внутренний как IP NAT inside, внешний как IP NAT outside, и затем создать правило, что и на что мы меняем. Если мы работаем с обычным, самым простым basic NAT, то мы указываем, что у нас есть один частный IP-шник, который мы меняем на один публичный IP-шник. Другие хосты, которые будут выходить в интернет,

они должны будут получить другие публичные IP-шники. Нам для такого basic NAT нужно будет много-много-много белых IP-адресов. Фактически мы создаём псевдоним: под белым IP-шником будет скрываться некий частный IP-шник. И вот у нас картинка. Есть внутренняя сеть с частным адресным пространством. И есть публичная сеть с глобальными адресами. И у нас есть адрес, который висит на самом интерфейсе, 203.0.113.1. И мы делаем ещё в этом же сегменте, в этом же домене виртуальный узел с IP-шником 203.0.113.2. И все пакеты, которые будут идти на этот IP-шник, наш роутер будет перенаправлять на этот внутренний узел. Мы сделали такой аватар, псевдоним, я не знаю, как это назвать, для внутреннего узла. Если у нас таких узлов много, нам потребуется много IP-шников. Разметили адресное пространство IP NAT inside, IP NAT outside на интерфейсах.

И создаём правило. IP NAT намекает на то, с каким механизмом мы работаем. Дальше. Какой тип NAT-а мы задействуем — inside source, в соответствии с тем, что было на предыдущем слайде. Мы хотим inside local адреса менять на inside global, там, где они стоят в поле source. Дальше. Мы указываем, что тип NAT-а — статический NAT. Мы жёстко прибиваем гвоздями, что IP-шник 192.168.1.2 мы меняем на 203.0.113.2 и наоборот. И мы в явном виде указываем адрес 192.168.1.2, 203.0.113.2. Это самый простой тип NAT-а, который одному частному узлу сопоставляет один публичный IP-шник, который у нас есть отдельный для этого узла. Если у нас здесь есть другие узлы, 192.168.1.3, 1.4, мы должны будем им сопоставить точно так же отдельные публичные IP-шники и для каждого из них сделать подобное правило. IP NAT inside source static, частный IP-шник, публичный IP-шник.

Вот этот адрес — это inside local. Вот этот адрес — это inside global. Outside local на global мы не меняем. Если хотите, там пустое преобразование. Они сохраняются и при трансляции никак не задействуются. Для того чтобы убедиться, что трансляция создана, есть команда show ip nat translations. Она покажет, что и на что мы меняем. Ту самую табличку она отображает, которая у роутера есть. И если вы создали такую трансляцию, то она будет помечена вот таким видом, что у нас есть трансляция, в которой inside local address 192.168.1.2 мы меняем на 203.0.113.2. Конкретные приложения, которые будут пользоваться этой трансляцией, конкретные потоки данных, которые через наш роутер проходят, также будут отслеживаться роутером, потому что он во всех проходящих соединениях должен будет выискивать следы частных IP-шников. Он должен будет выискивать всё в чек-суммах,

он должен будет смотреть внутри, не передаёте ли вы там свои частные IP-шники в каких-то хорошо известных местах, которые роутер умеет расковыривать, например, того же самого FTP или SIP или чего-то ещё. И он отслеживает, какие сессии по факту через эту трансляцию прошли. И он говорит: заметил UDP-шную трансляцию из-под IP-шника 192.168.1.2, из-под порта 23356-го, я, соответственно, частный IP-шник перебил, поставил 203.0.113.2, как мы и договаривались, и порт смог сохранить 23356. Outside Local и Global IP-шники и порты я не трогал, как вы и просили, мы меняем только Inside Local на Inside Global и наоборот. Соответственно, публичный IP-шник до перебивки, публичный IP-шник после перебивки. Номер порта, номер порта. Вот эти записи в show ip nat translations, они живут не очень долго.

Если у вас UDP-шная сессия закончилась, то она некоторое время ещё... UDP-шное взаимодействие, да, там нет такого понятия, как сессия. UDP-шное взаимодействие было, было, было, а потом закончилось. Никакой активности в рамках нет. И через некоторое время оно из этого списка пропадёт. Так. Далее. Со статическим NAT-ом не обязательно вы должны будете работать на уровне целого IP-адреса. Вы можете сделать статическую трансляцию для сокета. И от обычного типа NAT она будет отличаться только тем, что мы будем заглядывать внутрь заголовков TCP-UDP, у которых есть понятие сокет. И мы сможем на уровне этих самых TCP-UDP сказать, что публикуем наружу, сделаем псевдоним не для отдельного целиком IP-шника, а только для отдельного сокета или отдельного порта.

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

подключаться на наш собственный IP-шник на 25-й порт, они смогут подключаться по факту к этому внутреннему SMTP-серверу. Это очень удобная штука. И для того чтобы её реализовать, нам потребуется точно тот же самый NAT. Точно такой же IP NAT. Точно такой же inside source NAT. Смотрите, в чём фишка. Размечаем интерфейс IP NAT inside и IP NAT outside. Точно так же всё делаем. Это у нас внутреннее пространство inside. Это outside. Дальше. Указываем, что у нас есть трансляция, которую мы хотим создать. IP NAT. Что за механизм? Inside source. Какой тип NAT мы используем? Дальше указываем статический NAT и добавляем слово TCP. Мы будем работать на уровне TCP-шных сокетов. Предыдущий слайд не имел этого слова и не имел этих циферок. И там просто указывали IP-шник и IP-шник. Здесь мы работаем на уровне сокетов, указываем, что за тип сокетов нас интересует. TCP-шный или UDP-шный.

Здесь понятно, TCP-шный. И дальше говорим: вот этот частный сокет, inside local сокет. И вот это, соответственно, inside global сокет. Точно так же в show IP NAT translations это всё будет фигурировать. Но в чём преимущество по сравнению с предыдущей схемой? Вы можете иметь только один IP-шник на внешнем интерфейсе. Вы не обязаны иметь для каждого внутреннего сервиса эти самые отдельные адреса. И когда вы будете настраивать это, получится, что у вас в трансляциях есть трансляция inside global, inside local адрес, те, которые вы заказали. Но и по факту, если вдруг какое-то взаимодействие будет идти с указанием 25 в адресе получателя снаружи, эта трансляция сама сработает. Вам не надо, чтобы этот сервер изнутри какое-то предварительное действие делал для того, чтобы эту трансляцию поставить. Она уже создана в момент, когда вы её занесли в таблицу вручную командой IP NAT inside source.

Поэтому если какой-то узел снаружи будет пытаться подключиться на 25-й порт, никаких проблем, вы его промаршрутизируете вовнутрь, перебьёте IP-адреса и промаршрутизируете вовнутрь. Этот узел, он даже IP-шник источника здесь увидит тогда неизменный. И, соответственно, обратные пакеты, которые будут идти, они будут идти с 25-го порта на какой-то там случайный порт, не знаю, 34567. В таблице трансляции, show ip nat translations, вот оно как раз и видно. У нас есть какой-то внешний узел, который посылает данные со своего IP-шника 198.51.102, с какого-то случайного порта на наш красивый IP-шник 203.0.113.2, 25-й порт. Это наш публичный адрес, который висит на интерфейсе. Если двоечка должна быть. И мы говорим: окей, у нас есть трансляция, что всё, что идёт на 203.0.113.2 на 25-й порт, мы должны перебить на 192.168.1.2, на 25-й порт.

И дальше по таблице маршрутизации пускаем такие пакеты вовнутрь. И конечный этот сервер, он видит пакеты, идущие на хорошо известный 25-й порт, с какого-то случайного 34567-го порта с IP-шника 198.51.102. Обратный пакет он отправляет на публичный IP-шник 198.51.102, на случайный порт 34567, и они нормально проходят через таблицу трансляции и возвращаются на исходный IP-шник, на исходный порт. Да, это тот самый проброс портов. Когда вы хотите опубликовать один порт наружу, вот это он и есть. Обратите внимание, механизм NAT-а здесь используется один и тот же. Что вы публикуете целиком узел внутри сети, что вы используете проброс порта или публикуете только один сокет, это один и тот же механизм inside source NAT-а. Более того, я вам скажу, мы сейчас посмотрим, как NAT с overloading-ом делается,

тот самый PAT, если хотите, в Cisco, динамический или NAPT в терминах RFC, и вы увидите, что на самом деле там всё тот же inside source NAT и будет присутствовать. Для того чтобы посмотреть, какой тип NAT-а используется в современном мире, нам сейчас потребуется один ещё хитрый тип NAT-а, который когда-то давным-давно был придуман, опять же, для экономии публичных IP-шников, но сегодня используется крайне редко. Это динамический NAT, который умеет работать только на уровне IP-адресов. У вас есть роутер, на котором вы согласны делать NAT. У вас в этом роутере есть частная сетка, и в этой сети у нас много-много-много абонентов. Но эти абоненты, например, это, не знаю, машинный зал, open space. И в этом open space гипотетически работают, не знаю, 500 человек, но не одновременно. Всего у вас рабочих мест в этом open space 100. И каждый человек может прийти в этот open space со своим ноутбуком,

подключиться и дальше выйти в интернет. Количество абонентов, которые одновременно могут пользоваться интернетом, только 100 штук. Но количество всего абонентов интернета у вас, например, 500 штук. И в этой ситуации, если бы вы делали обычный NAT, basic static NAT, вы должны были бы купить 500 публичных IP-шников. Опять же, в классовом мире это означает, что вы должны будете купить сетку класса B. И это дорого. Как в такой ситуации быть? Если мы знаем, что у нас зал всего на 100 человек, просто у нас сотрудники сегодня пришли одни, завтра другие, они там посменно работают. В такой ситуации мы можем воспользоваться механизмом, который мы периодически встречаем в IT-шных технологиях. Механизм заключается в том, что у нас есть пул IP-адресов, из которого мы при необходимости берём IP-шники и назначаем хостам. А затем, если вдруг видим, что узел не пользуется этим адресом в течение некоторого времени, мы этот адрес возвращаем обратно в пул.

Примерно так же работает, на самом деле, DHCP. Когда у нас есть узел, который хочет пользоваться IP-шником, он, соответственно, выдаёт этому узлу в своё распоряжение IP-адрес. После того как узел перестаёт пользоваться IP-адресом, адрес возвращается в пул и может быть выдан кому-нибудь ещё. Здесь такая же штука. Единственное, что здесь нет процедуры аренды адреса или продления аренды адреса. У вас либо есть активность в рамках трансляции, тогда трансляция поддерживается как живая и актуальная, либо трансляция неактивная, по ней трафик не ходит, и, соответственно, через некоторое время после неактивности эта трансляция уничтожается. Для того чтобы эта штука работала, нужно будет сделать в Cisco следующую вещь. Во-первых, нужно будет разметить интерфейсы. IP NAT inside, outside я уже на слайдах не привожу, потому что само собой разумеется. Во-вторых, вы должны будете разметить белые адреса, которые вы будете использовать. Если у вас есть какой-то набор белых адресов,

то вы должны будете сделать тот самый пул, в котором эти адреса будут жить. Это будет команда IP NAT, намекает на то, с каким механизмом мы работаем. Дальше. Ключевое слово — pool и название пула. Здесь используется название din-nat, но вы можете использовать любое название, которое вы захотите. Понятное дело, что название не влияет на результат. Далее. Вы указываете неразрывный диапазон адресов. В нашем случае с 203.0.113.2 по 203.0.113.10. И все адреса, которые в этом диапазоне находятся, они все будут вашими белыми адресами. Если захотите, вы можете сделать разрывный диапазон, тогда надо будет с одним и тем же названием просто команду IP NAT pool выполнить несколько раз и указать все кусочки вашего диапазона. И ещё один параметр, который нужно обязательно указывать при создании строчки в пуле. Это либо netmask, либо prefix-length.

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

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

говорим на те IP-шники, которые мы должны будем перебить. В нашем случае мы говорим 192.168.1.0 по маске 0.0.0.255. Вот это у нас указывает на inside local адреса. А вот это укажет, соответственно, какие inside global адреса мы должны будем назначить. И дальше нам нужно указать правила трансляции. Какие inside local адреса, На какие inside global адреса мы перебиваем. IP NAT. Что за механизм NAT задействуем? Inside source. Дальше. Где берем inside local адреса и в какие inside global их перебиваем? List 1, pool denat. Эта команда IP NAT inside source list 1 pool denat указывает, что и на что перебиваем. Почему я сказал, что есть нюанс? Потому что вы можете, если захотите, в команде по созданию аксесс-листа использовать расширенный аксесс-лист. И таким образом вы с помощью расширенного аксесс-листа отберете те самые пакеты,

в которых нужно будет выполнить трансляцию. И вы с помощью аксесс-листа не обязаны ориентироваться только на адреса источника. Если вы делаете стандартный аксесс-лист, то вы ориентируетесь только на адреса источника, и тем самым вы фактически говорите, какие inside local адреса мы перебиваем. Потому что стандартный аксесс-лист смотрит только на IP-шник, и получается, что логика там ровно та самая, которую мы хотели. Но если вы захотите, вы можете сделать более сложное правило. Вы можете сделать расширенный аксесс-лист, который будет говорить: давайте мы сделаем отдельный пул адресов, например, для TCP-трансляции и отдельный пул адресов для UDP-трансляции. И тогда TCP-шные сессии будут транслироваться в одно, а UDP-шные сессии будут транслироваться в другое. Или, например, мы можем сказать, что у нас есть внутри сети несколько групп пользователей. Например, есть бухгалтерия, есть водители,

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

другой аксесс-лист используется для другого приложения, другой пул адресов используется для другого приложения, и другое правило связывает другой аксесс-лист и другой пул адресов. Если вдруг вы захотите каких-то эксклюзивных настроек, то с помощью стандартных и расширенных аксесс-листов вы можете сделать достаточно гибкую конфигурацию. Но в маленьких сетях это востребовано не очень часто. Если мы говорим про сценарий, который будет проверяться на экзамене, то от вас потребуется понимание динамического NAT: что мы создаём стандартный аксесс-лист, дальше мы указываем пул адресов и связываем список контроля доступа и пул адресов. IP NAT, inside source, частные адреса, публичные адреса. В show IP NAT translations у вас будут показываться, какие частные IP-шники в какие публичные перебиваются прямо сейчас. Показывается, например, что у нас здесь inside local адрес 192.168.1.2 перебивается в 203.0.113.2,

потому что у нас прямо сейчас в моменте есть UDP-шная трансляция с такого порта 192.168.1.2 на 198.51.102 на 53-й порт. Их перебили, соответственно, в 203.0.113.2, с таким кривым портом. Outside global не трогали. И рядышком 203.0.113.3. Белый публичный IP-шник выдали узлу 192.168.1.4, потому что он по TCP подключался со своего IP-шника 192.168.1.4 с такого кривого порта на 198.51.110 на 25-й порт, судя по всему, это SMTP. Этот механизм позволяет зафиксировать за каждым отдельным внутренним узлом публичный IP-шник, который он получает в своё полное распоряжение. Пока жива трансляция, любые подключения на 203.0.113.3 будут приходить на 192.168.1.4.

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

состоящим из всего одного адреса. Если у вас, например, есть просто роутер, и на этом роутере есть просто интерфейс, на котором вы получаете всего один публичный IP-шник, например, по протоколу DHCP, то этот один адрес с помощью Basic NAT или Dynamic NAT можно выдать либо одному внутреннему узлу, либо можно попилить на отдельные сокеты. И если у вас будут отдельные сокеты, то этих сокетов будет много. Будет 65 тысяч TCP-шных сокетов, 65 тысяч UDP-шных сокетов. Адрес один, а сокетов много. И когда у нас появляется клиент, который хочет получить себе взаимодействие с помощью одного сокета, мы говорим, окей, не проблема, мы тебе один сокет отдадим, у нас ещё много останется. Появляется другой клиент, говорит, я хочу вести взаимодействие с неким сокетом, и мы говорим, не проблема, на тебе ещё один сокет. У нас этих сокетов довольно много. Не то чтобы бесконечно много, потому что портов в рамках протокола TCP или UDP,

которыми мы можем распоряжаться, будет 65 тысяч штук, 65 536. Причём через NAT обычно раздаётся не весь диапазон, а только динамические порты, поэтому там 64 тысячи этих самых портов будет. И больше чем 64 тысячи трансляций вы через один адрес пропустить, в принципе, не сможете. Это может показаться довольно большим числом, но на самом деле, если вы ведёте взаимодействие через NAT, то один даже пользователь, который пытается открыть какой-то довольно тяжёлый сайт, типа того же Facebook, он одновременно открывает сразу много сессий HTTP-шных и HTTPS-ных, и там одновременно грузится сначала главная страница, а потом начинают подгружаться всякие CSS, JavaScript, скрипты. И этих сессий, которые браузер одного пользователя генерирует, может быть довольно большое количество. Если у вас, например, 100 пользователей, и все эти 100 пользователей активно сидят в интернете, то вы вполне возможно довольно быстро выжрете

все свои 65 тысяч трансляций. Как это настраивается? Есть вариант настроить это всё с пулом, так же как мы на предыдущем шаге делали: мы создаём пул командой IP NAT pool, дальше название пула, например, DIN pool. Дальше даём диапазон IP-шников: 203.0.113.1, 203.0.113.10. И дальше netmask 255.255..., указываем какую-то маску. И дальше можно прикрутить этот пул. Команда будет очень похожа на ту, которую мы видели на предыдущем шаге. Но чаще всего вам незачем в такой ситуации делать пул адресов, и вы должны будете сказать, что у нас всего один IP-шник на интерфейсе есть. Этот единственный адрес, который у нас есть, он в нашем распоряжении будет, и мы только его пилим на отдельные сокеты.

Не пачку IP-шников, которые у нас есть, пилим на отдельные сокеты, а один IP-шник пилим на отдельные сокеты. И этот же IP-шник висит у нас на интерфейсе. И в таком случае эта команда немножко редуцируется, она указывает IP NAT, с каким механизмом мы работаем, какой тип NAT мы задействуем — inside source, что мы транслируем inside local адреса. По большому счёту inside local адреса, а на самом деле, если более детально разобраться, это какие пакеты попадают под трансляцию. И где мы берём inside global адреса для трансляции. Так, слушайте, а где-то у меня здесь... Здесь написано outside local. Здесь не outside local, конечно же, я ошибся. Здесь был inside global. И, соответственно, inside local мы меняем на inside global.

Там, где они стоят в поле source. И в такой ситуации получается, что у нас есть один единственный IP-шник, который висит на интерфейсе gigabit 0/1. И мы говорим, что любые пакеты, которые попадают под лист номер один, которые приходят через inside interface и выходят через outside interface, и при этом попадают под список номер один, у них inside local адрес будет меняться на inside global. И какой этот inside global адрес будет? Ровно тот, который здесь указан. Обратите внимание, здесь не указывается, что пакет обязательно должен выйти через gigabit 0/1 интерфейс. Здесь указывается тот адрес inside global, на который пакет будет перебит. Совершенно не факт, что пакет выйдет через этот интерфейс. Может вполне такое быть, что у вас, например, гипотетически будет какая-то конфигурация. Например, у вас есть

воображаемый интерфейс, который называется loopback 0. Loopback 0. И на нём висит IP-шник 203.0.113.2. И вы создаёте правило IP NAT, с чем работаем — inside source, какой тип NAT задействуем, список номер один, который создан командой access list. И дальше interface loopback 0. И в этом случае у вас inside local адреса меняются на inside global адреса. Inside global адрес берётся с интерфейса loopback 0. По факту пакеты, как приходили через этот интерфейс, так и будут выходить через интерфейс, который определяется таблицей маршрутизации. А эта штука указывает всего лишь на то, где брать IP-шник. Если у вас висит IP-шник на интерфейсе loopback 203.0.113.2, то именно на этот inside global адрес будут перебиваться inside local адреса.

На путь прохождения трафика команда IP NAT не влияет никоим образом. Отдельно маршрутизация, которая находит внутренний интерфейс, внешний интерфейс, определяет, что этот интерфейс inside, этот интерфейс outside. После этого она говорит, да, нам нужно выполнить трансляцию, у нас есть правило, которое определяет, что пакеты, приходящие через inside, выходящие через outside и попадающие под список номер один, попадают под трансляцию. Здесь уже точно определено, через какой интерфейс пакет вошёл, через какой он уже выйдет. И дальше мы просто говорим, подменяем IP-адрес источника. в этом пакете на тот же, который висит на интерфейсе loopback. Очень частое заблуждение, что вот люди почему-то считают, что пакет должен выйти через интерфейс gigabit 0. Нет, он не обязан выходить через интерфейс gigabit 0. Он часто выходит через этот интерфейс, потому что единственный неповторимый публичный IP-шник у нас часто вот на этом интерфейсе находится, и мы через него же хотим, естественно, выпустить пакет. Но это далеко не обязательное требование.

Это всего лишь просто логичное требование, которое в большинстве ситуаций срабатывает. Но и возникает вопрос. Окей, если мы указали, какие адреса мы меняем и на что мы меняем, то в чем разница тогда с предыдущим механизмом NATA? Здесь мы указывали inside local адреса, здесь мы указываем inside global адреса. В общем, никакой разницы не видно. А разница заключается вот в этом ключевом слове overload. Если вы его указываете, то у вас IP-шники будут меняться на сокеты. Ну, в смысле, IP-шники будут разделяться на сокеты и транслироваться в проходящих пакетах, будут именно сокеты. Если слова overload нет, у вас будут подстанавливаться IP-адреса. И вот в диапазоне inside global адресов у вас с помощью команды interface можно задать только один единственный адрес. Соответственно, если вы не укажете overload, у вас один частный узел получит возможность распоряжаться одним публичным IP-шником, который у вас висит на интерфейсе.

Вот, например, 192.168.1.2 узел получит возможность выхода в интернет, если вы забудете слово overload. А 192.168.1.4 уже, соответственно, будет натыкаться на непонимание, и ему свободного IP-шника не достанется. Если же вы укажете overload, то у вас взаимодействия будут вести роутер при трансляции не с IP-адресами, а с сокетами, и сокетов у него этих самых много. У него один публичный IP-шник может разделить на 65 тысяч сокетов TCP, на 65 тысяч сокетов UDP и так далее. Вот. Вот этот вот механизм, который по факту в большинстве современных сетей используется, ну, в каких большинстве? Во всех современных сетях, за крайне редкими исключениями, используется именно механизм Dynamic Pad. Именно его нужно будет знать на экзамене. Для того, чтобы запомнить, что в этом механизме задействуется, во-первых, разметка интерфейсов IP NAT, inside, IP NAT, outside. Во-вторых, определение того, какие пакеты попадают под трансляцию

с помощью обычного аксесс-листа. В-третьих, собственно, само правило трансляции. IP NAT, с чем работаем, inside source, какой тип NAT используем, какие пакеты попадают под трансляцию, во что перебиваем публичные IP-шники, и overload указывает на необходимость работы с отдельными сокетами. Если мы используем такой тип трансляции, то в show IP NAT translations у нас показывается только конкретные трансляции, которые по факту воспользовались определенными сокетами, которые мы им предоставили. Мы вот здесь видим, что 192.168.1.2 из-под какого-то случайного порта пошел на 192.5.1.102 на 23-й порт по TCP. Ну и, соответственно, мы 192.168.1.2 перебили на Inside Global 203.0.1.1.1. Порт попытались сохранить. Ну и рядышком другой узел 192.168.1.4 с какого-то другого порта попытался на 192.5.1.1.10

на 25-й порт выйти. Окей. Значит, мы тот же самый IP-шник ему выдали, но порт уже за ним зафиксировали другой. Обратные пакеты, которые пойдут снаружи вовнутрь, они по IP-шникам будут одинаковые. Они все будут идти на тот самый единственный IP-шник, который зафиксирован за нашим роутером, но у них будут разные вот эти вот номера портов. И именно по этим номерам портов часть пакетов будет отправляться на один узел, часть пакетов на другой узел. Вот. Да. Что здесь еще хотелось бы заметить? Для того, чтобы пакеты смогли пройти из инсайда в аутсайд, нам потребуется выполнение базового правила. Пакеты должны войти через интерфейс инсайд. Инсайд. Инсайд. И пакеты должны выйти через аутсайд. То есть в этом случае пакеты, которые идут изнутри,

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

Вот. Для обратных пакетов механизм будет немножко другой. Здесь проблема будет вот в чем. Если у вас интерфейс помечен как outside, и, соответственно, пакет приходит на публичный outside интерфейс, он приходит на вот какой-то адрес, 203.0.13.1. Мы не можем сначала выполнить маршрутизацию, потому что это наш собственный айфишник. Ничего маршрутизации здесь не скажут, кроме того, что направьте это на центральный процессор. Поэтому если пакет входит в outside интерфейс, мы сначала выполняем трансляцию обратную и находим внутренний адрес 192.168.1.2. После этого по этому адресу выполняем маршрутизацию, и в этот момент, когда мы выполнили маршрутизацию снаружи вовнутрь, уже не проверяется, будет ли интерфейс inside. Вот здесь вот этот момент, что мы при прохождении пакетов изнутри наружу сначала выполняем маршрутизацию, а потом над. При прохождении пакетов снаружи вовнутрь

мы проверяем лишь то, что пакет вошел через outside, и дальше мы сразу выполняем трансляцию, после этого выполняем маршрутизацию, и после этого мы уже не можем проверить, а стоило ли эту самую трансляцию выполнять. Потому что может быть такое гипотетически, что выходным интерфейсом будет интерфейс без указания IP над inside. Но естественно, что в подавляющем большинстве ситуаций у вас, если трансляция будет выполняться обратно, то она будет выполняться, понятное дело, через тот же самый интерфейс, как не трансляция, она будет транслировать обратно адреса в пакете таким образом, чтобы эти адреса были доступны через IP над inside интерфейс. Потому что обратная трансляция, она никуда из воздуха не возьмется, она возьмется только из-за того, что у нас пакеты прошли туда, из inside в outside. Поэтому обратные пакеты чаще всего будут идти из outside в inside. Вот.

Небольшой втопик. Правильно ли вы понимаете, что NAT может быть двойным, тройным? Да, никаких проблем. То есть каждый роутер, который трансляцию NAT выполняет, никоим образом не зависит от всех остальных роутеров. Он либо перебивает адреса, либо не перебивает. Если у вас 20 роутеров в цепочке, вы можете хоть 20 NAT сделать. Опять же, никто нигде не контролирует, что был ли NAT уже сделан в какой-то другой точке или не было. Так, резюмируя то, что я вам рассказал только что, для пакетов из inside в outside сначала проверяем, что пакет вошел через inside интерфейс, помечаем пакет как, возможно, транслируемый. Дальше. Проводим маршрутизацию по содержимому пакета. Чаще всего пакеты, которые у нас идут из inside в outside, у них outside local address будет совпадать с outside global. Поэтому там ничего не изменится от того, что мы сначала выполним маршрутизацию. Находим выходной интерфейс. И если интерфейс выходной не помечен как IP NAT outside,

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

все, что необходимо для нас. Ну и направляем пакет в сеть назначения. Для NAT у нас будут использоваться механизмы диагностики. И, соответственно, есть команда showipinatranslations, которую мы уже видели на некоторых слайдах. Эта команда позволяет посмотреть те трансляции, которые активны прямо сейчас. Здесь нужно будет учитывать следующие моменты. Первый момент заключается в том, что в зависимости от конкретного протокола, от состояния, скажем, сессии в рамках конкретного протокола, если протокол поддерживает сессии, у вас время жизни этой трансляции в табличке может быть сильно разным. То есть, например, TCP-шная трансляция будет активна все время, пока у вас есть активность в этой TCP-шной сессии. И если вдруг в рамках TCP-шной сессии прошло официальное ее завершение, там есть специальные флажки SYN или RST, то, соответственно, у вас эта TCP-шная сессия с таблицей трансляции после своего окончания

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

своих секвенс-номеров. Понятное дело, что если в TCP, в UDP мы порт источника поменять можем, то в ICMP секвенс-номер поменять уже будет нельзя. Это нехорошо. Поэтому время жизни ICMP-шной трансляции очень маленькое. Говоря конкретнее, если вы пингаете из внутреннего какого-то узла какой-то внешний узел, у вас в таблице трансляции будет появляться соответствующая строчка в ICMP протоколе, но у нее срок жизни будет обычно 15 секунд. И если вдруг вы хотите посмотреть в show ip nat translations, есть у вас определенная трансляция или нет, и вы кого-то попингали, бежите к Cisco, вводите show ip nat translations, и вы долго вводите эту команду, то может быть такое, что когда вы ее выполняете, эта трансляция уже протухнет, и уже там ничего не будет показываться. И если вы хотите посмотреть, оно вообще было когда-нибудь или нет, то на Cisco ведутся счетчики, которые покажут,

сколько этих самых трансляций у вас вообще осуществлялось. Есть команда show ip nat statistics, которая покажет счетчик количества трансляций, и если у вас эти трансляции создаются, этот счетчик будет непрерывно расти. Зачем эта команда полезна? Как раз для ситуации, когда у вас есть некие трансляции, которые вы хотите отловить, они вообще были или нет. Обычно это происходит в ситуации, когда вы не понимаете, у вас интернет вообще работает, или это какая-то проблема, например, с NAT. Вы пингаете соседа и бежите к Cisco, смотрите show ip nat translations и видите, что там пусто. Это не означает, что у вас вообще не работает ничего, например, NAT. Возможно, трансляция просто протухла, и show ip nat statistics покажет счетчик: если выросли, то да, вы просто не успели. А если они не выросли, если они остались на своем старом значении, то трансляции просто никогда и не было, и вам следует траблшутить проблему, почему ваш роутер не выполняет эти трансляции.

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

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

Нет, не спасет. Еще ошибка, которую можно встретить при работе с NAT — это неправильная разметка интерфейсов. Если мы неправильно разметили Inside и Outside адресные пространства, то у нас сессии устанавливаться не будут, трансляции устанавливаться не будут. Может быть, мы некорректно зададим access-лист для отбора — здесь написано частных адресов, более правильно сказать, для отбора тех пакетов, которые попадут под правила трансляции. Может быть такое, что мы перебьем Inside Local адреса в Inside Global тоже некорректно. Пакеты мы перебьем, и все действительно перебьется, такие пакеты уйдут дальше в интернет, а из интернета возвращаться ответные пакеты не будут, потому что не туда будут возвращаться. Допустим, мы должны перебить свои 192.168.x в 203.0.113.1, а мы перебили в 198.54.0.17. Какой-то совершенно левый айпишник. Естественно, что пакеты обратно будут приходить не на ваш роутер, а на какой-то

совершенно другой. И да, NAT не заменяет маршрутизацию. То, что у вас в сети должны быть маршруты для боевого трафика, и эти маршруты никак не связаны с NAT. Это, собственно, медицинский факт. Поэтому сначала настраиваем корректную маршрутизацию, а потом включаем трансляцию сетевых адресов. Вот пример. У нас есть загадка. Загадка заключается вот в чем. Администратор начинающий взял роутер и на роутере попытался настроить НАТО. Картинка сетевая у нас вот такая вот. То есть, есть какой-то интерфейс, на нем висит айпишник 192.168.1.1, к нему подключен напрямую пользователь 192.168.1.2. здесь же еще соответственно будут 192.168.1.3 192.168.1.4 и так далее. И здесь у нас интернет. И, соответственно, вот он попытался что-то настроить

и что-то как-то у него плохо работает. Возникает вопрос, где ошибся этот начинающий администратор и как поправить то, что у него в итоге получилось. забегая вперед, скажу, что здесь целых 4 ошибки и вот предлагается все эти 4 ошибки найти. Итак, что здесь можно будет посмотреть? Ну, давайте прям сразу с первой строчки начнем разбираться. Интерфейс гигабит 0.0. айпи на адрес 192.168.1.1. 255.255.255.0. Ну, похоже на правду. Вот он, значит, гигабит 0.0. айпи над аутсайд. И тут мы предполагаем, что здесь что-то неправильное есть, потому что аутсайд и инсайд явно не так должны быть расположены. Но они расположены почему-то криво-косо. Ну, понятное дело, что здесь их надо поменять местами. Вот этот товарищ должен стать инсайдом, а вот этот соответственно аутсайдом. Это первая ошибка. Дальше. Гигабит Ethernet 0.1. 203.0.131.

Вот он. 203.0.131. Гигабит 0.1. А и маска здесь 255.255.255.254. Это, соответственно, 31 маска. Далее. IP ROLL 0.0.0.0.0.0.0.0.0.203.0.113.2. Зоркий глаз здесь может заметить, что 203.0.1.132 не входит в сеть 203.0.1.13.0. по 31 маске. Что в этой сети ровно два IP-шника. Нулевой и первый. И, соответственно, 203.0.1.132 это IP-шник ну, не connected. То есть этот маршрут не устанавливается в таблицу маршрутизации. Как следствие, маршрута у нас нет. И когда пакеты приходят из внутренней сети наружу, они не попадают в outside-интерфейс или в inside-интерфейс в нашем случае, даже если мы их поменяем обратно. Сделаем вот этот вот интерфейс inside-ом, а вот этот вот интерфейс outside-ом, то outside-интерфейс

таблицы маршрутизации нам не найдет, потому что вот этот вот маршрут он в таблицу не поставится. Как непривычно 254-ю маску видят. Ну да, да, да. Такие вещи нужно будет отлавливать глазками. То есть внимательно смотреть, на что вас пытаются поймать. Вряд ли вас будут на экзамене ловить на 31-ю маску, конечно же. То есть попроще там все-таки задачки будут. Но такого вот характера подвохи они могут, в принципе, быть. Дальше. IP-road. Ну, допустим, да, что мы здесь, скажем, 203, там, 113.0 или там здесь, вот скажем, слэш 0, второй IP-шник. Ну, короче говоря, допустим, разобрались с IP-адресами. Следующая строчка. Аксесс-лист 1, пермит, 192, 168, 1, 0, 255, 255, 255, 0. Ну, опять же, зоркий глаз может сказать, что с аксесс-листами у нас работают кривые маски. И, соответственно, вместо вот этого вот должно быть 0, 0, 0, 255.

В противном случае мы для того, чтобы перебивать IP-адреса в пакетах, ловим такие пакеты, которые заканчиваются на 0 в адресе источника. Таких пакетов будет не очень много. Ну и, соответственно, вот третью проблему мы таким образом тоже нашли. Понятное дело, что четвертая проблема это вот последняя строчка. Здесь нам ничего не остается. Я сказал, что есть четыре проблемы, и осталась одна строчка, так что в ней точно есть какая-то проблема. IP-ад, inside source, list 1, вот он, list 1, интерфейс gigabit 0.1, это на какой IP-шник мы перебиваем адреса, вот это вот inside local, это у нас inside global, ну и здесь не хватает слова overload. Если мы делаем для настоящей реальной сети взаимодействие, то мы хотим, разумеется, сделать трансляцию сокетов. Мы хотим вот эту вот самую нацперегрузку. И без ключевого слова overload у вас вот этот вот узел получит доступ в интернет,

а другие узлы не получат доступа в интернет. Они, соответственно, будут сидеть без связи. Поэтому вот его надо бы не забывать. Работать будет только для одного узла. То есть для 192, 168, 1, 2, да, связь будет. Правда, если он первый. А если кто-то другой попытается выйти в интернет, то будет для него работать. Но все равно, да, трансляция установится на уровне самого IP-шника. Весь IP-шник 203, 0, 113, 1 будет отдан целиком IP-шнику, там, 192, 168, 1, 2 или 192, 168, 1, 2, 181.4. И он не будет разбит на отдельные сокеты. И, соответственно, целиком будет отдан какому-то внутреннему узлу. Все остальные получат фигу. Любопытный нюанс заключается в том, что если вдруг у вас трансляция не может быть установлена, потому что нету свободных inside global, либо адресов, либо сокетов, то трансляция не устанавливается. Но это никаким образом не влияет на прохождение пакета. Пакеты от 192.168.1.2

наружу ходить будут, и они будут перебиваться. Если забыть слово overload, они будут перебиваться в 203.0.113.1. Пакеты из-под 192.168.1.4 наружу тоже ходить будут. Только они не будут перебиваться, они будут идти из-под адреса 192.168.1.4. И, естественно, здесь их будут убивать, потому что нечего такие пакеты наружу выпускать. А если даже их не прибьют, если даже такие пакеты дойдут до сети назначения, то она не будет знать, куда девать ответ. И, соответственно, она ответы тоже не сможет вернуть на наш узел 192.168.1.4. Так можно запороть конфигурацию NAT. Не ловитесь на такие ошибки. И если настраиваете NAT, делайте так, чтобы всё было правильно и корректно.