Лабораторная работа на NAT

Подготовительные действия для лабораторной работы на NAT я выполнил, и заключаются они в следующем. Все наши роутеры соединены с центральным роутером с помощью отдельного интерфейса. Это интерфейс Ethernet 01. Единственное, мой роутер как раз не подключен. Я на центральном роутере настроил некоторое количество интерфейсов, которые смотрят на наши роутеры, и мы на центральный роутер смотрим интерфейсом Ethernet 01. Я предлагаю сейчас это настроить: сказать, что диалог начальной настройки меня не интересует, включить интерфейс Ethernet 01 и получить связность с центральным роутером. Некоторое время потребуется на то, чтобы диалог начальной настройки прошёл,

после этого настраиваем. Интерфейс Ethernet 0.1. No shutdown. IP-адрес. Адрес я предлагаю использовать такой: 10.100. Номер вашего комплекта. У меня это роутер седьмого комплекта. И ещё раз номер комплекта. Если у вас комплект третий, будет 10.100.3.3. Если комплект седьмой, будет 10.100.7.7. 255.255.255.0. Этот интерфейс позволяет нашему роутеру связаться с центральным роутером. Для того чтобы проверить связность, я предлагаю сделать ход конём. Сказать, что у нас CDP на центральном роутере, CDP holdTime 10,

будет рассылать имя этого центрального роутера, то есть core R. HostName core, подчёркиваю, не R. В этом случае на наших роутерах мы увидим, что CDP притаскивает список соседей, то есть этот самый роутер core R. Выходим из диалога конфигурации. Show CDP neighbors. Нам покажет список всех соседей. Вот он, core R. У вас тоже он должен показываться. Что касается нашей лабораторной работы — мы сейчас будем направлять в сторону центрального роутера пакеты. И мы на нашем роутере сделаем так, чтобы коммутатор, пропуская пакеты через наш роутер, смог тоже достучаться до центрального. Что от нас сейчас потребуется? Нам потребуется, во-первых, проверить,

что с этим core R есть связность. PING 10.100. Номер вашего комплекта, у меня 7.100. Связь по идее должна быть. Да, она у нас есть. И нам нужно сделать так, чтобы наш коммутатор, который с маршрутизатором связан через интерфейс Ethernet 0.0, получил доступ к центральному роутеру тоже. Чтобы с коммутатора можно было попингать IP-адрес 10.100.7.100. Для этого нам нужно будет настроить как раз NAT. У меня, по-моему, на этом роутере не настроен внутренний интерфейс. Надо поправить. Interface Ethernet 0.0. No shutdown. Duplex full. IP-адрес. Если мне память не изменяет,

на интерфейсе Ethernet 0.0 у нас используются IP-адреса 10.0.0.номер_комплекта. Это седьмой комплект, значит 10.0.0.7. 255.255.255.0. Сейчас наши коммутаторы могут связаться с маршрутизатором. Проверяем. Давайте я восьмой комплект закрою. Подключаюсь к коммутатору седьмого комплекта. Enable. Conf t. Interface VLAN 1. No shutdown. IP-адрес. Не ошибся ли я здесь где-то? Мне кажется, какие-то другие адреса должны быть. Да, у нас на VLAN-интерфейсе нет никаких адресов.

Нам их надо будет настроить. Мы сейчас на коммутаторе создаём интерфейс VLAN 1 и вешаем на него IP-адрес. 10.0.0 и 100 плюс номер нашего комплекта. То есть 10.0.0.101, 10.0.0.102, 10.0.0.103, 10.0.0.107. 255.255.255.0. У нас сейчас получается, что коммутатор и маршрутизатор друг друга видят в сети 10.0.0.0 по 24-й маске. Проверяем. Ping 10.0.0.7. Пинги должны проходить. И точно — сейчас между нашим роутером и свитчом есть связь. Кроме того, есть связь между нашим роутером и центральным. С нашего роутера пингается центральный 10.100.7.100. Но если эту же команду выполнить на свитче,

то пинговаться она, конечно же, не будет. Не будет в первую очередь потому, что у нас нет маршрута. Давайте пропишем маршрут на коммутаторе, что все сети в мире доступны через наш маршрутизатор. Conf t. IP route 0.0.0.0 0.0.0.0 — мы создаём маршрут по умолчанию и указываем, что все сети в мире на коммутаторе доступны через маршрутизатор 10.0.0.7. Это тот самый IP-адрес. Пожалуйста, убедитесь, что это тот самый IP-адрес вашего роутера, который вы только что попингали. Казалось бы, у нас всё должно быть хорошо. Мы на свитче прописали маршрут, что пакеты до любых сетей в мире должны уходить на маршрутизатор. Маршрутизатор знает, как доставить трафик до центрального узла. Вопрос: будет ли сейчас пинговаться наш центральный роутер?

Команда ping 10.100.7.100. Пробуем её выполнить и видим, что пинги не проходят. Несмотря на то, что мы вроде бы прописали маршрут, пинга нет. И пинга нет не потому, что пакеты не уходят в сторону центрального роутера. Я сейчас выполню команду на центральном роутере: debug ip icmp. Эта команда каждый раз, когда на центральный роутер будет приходить ICMP-пакет, будет выводить на экран сообщение о том, что пришёл пакет. Если я сейчас со свитча отправлю пакеты на IP-адрес центрального роутера, они туда дойдут. Вот пробегают сообщения, что кто-то пингует 10.100.7.100, но IP-адрес источника показывает 10.0.0.107, то есть тот самый IP-адрес свитча. Загвоздка заключается в том, что центральный роутер не знает, как вернуть ответы

на этот адрес 10.0.0.107. В его таблице маршрутизации такого маршрута просто нет. Show IP route. Он знает, как добраться до третьей сети, до седьмой сети и до восьмой сети в диапазоне 10.100, но не знает, как отправить пакет на адрес 10.0.0.107. Для того чтобы мы смогли отправлять пинги с нашего свитча на центральный роутер и эти пинги проходили, нам придётся воспользоваться NAT. После того как мы убедились, что пинги со свитча до центрального роутера доходят, но не возвращаются, мы должны будем создать правила трансляции, чтобы наш роутер пакеты от свитча до core-роутера немного модифицировал. Сейчас, если мы посмотрим на те пакеты, которые приходят на core-роутер, они приходят с IP-адреса,

который непонятно куда девать. 10.0.0 — его в таблице маршрутизации нет. Мы хотим, чтобы там были адреса, которые у нас будут connected, чтобы мы знали, куда возвращать ответы. Для этого нам на нашем роутере потребуется сделать правила трансляции. Помимо самих правил трансляции, надо сделать базовую разметку интерфейсов. Интерфейс, который для нашего роутера будет внутренним, то есть на котором допустимы «серые» адреса, которые надо перебивать, и «белые» адреса, которые в нашем случае будут хорошие. Это будет интерфейс Ethernet 0.0. Мы его должны будем пометить как IP NAT inside. IP NAT inside мы помечаем на интерфейсе Ethernet 0.0. Это наш внутренний интерфейс, которым мы смотрим на свитч. Если вы включаете команду IP NAT inside на наших железках, то через некоторое время пробегает сообщение о том, что у нас появился

дополнительный интерфейс NVI 0. Это нормально, это не является какой-то большой проблемой. Дело в том, что наши роутеры поддерживают хитрый механизм NAT. Когда мы используем domain-based NAT, фактически запускается другой тип NAT. Это происходит прозрачно для конечного пользователя. В рамках работы этого другого типа NAT поднимается виртуальный интерфейс NVI 0. Когда этот интерфейс поднимается, на некоторое время железка задумывается. Сейчас она где-то секунд 30 не реагировала на клавиатуру. Через некоторое время она приходит в себя и начинает работать. Разметил внутренний интерфейс. Интерфейс Ethernet 0.1. Размечаем наружный интерфейс. Outside.

Дальше. Нам нужно будет указать, какие пакеты подлежат трансляции, а для этого нам нужен будет access list. Я предлагаю сделать простенький access list — сказать, что любые пакеты, которые приходят через inside-интерфейс и выходят через outside, подлежат трансляции. Access list 1. Permit any. Такой простенький access list, который говорит, что всё будем транслировать. Не будет ничего, что трансляции не должно подвергаться. И наконец последнее правило. Указываем, что трансляция, которая будет осуществляться для пакетов, вошедших через inside, выходящих через outside и попадающих под access list 1, должна перебивать inside local адреса в inside global, причём inside global надо брать с внешнего интерфейса. IP NAT. С чем мы работаем? Inside source.

Какой тип NAT мы задействуем? Что перебиваем? Пакеты, которые попадают под список номер 1. На что перебиваем inside local адреса? На адрес с интерфейса Ethernet 0.1. И не забываем overload. Это правило указывает на то, что мы будем менять inside local на inside global адреса там, где они стоят в поле source, если пакет попадает под access list номер 1, а под него попадает любой пакет, и при этом пакет пришёл через inside-интерфейс и выходит через outside после маршрутизации. Inside global адрес для перебивки мы берём с интерфейса Ethernet 0.1. На нём висит IP-адрес 10.100.7.7 в нашем случае. И сейчас у нас должно

всё запинговаться. Я переключился на switch, и этот же пинг должен пройти. И он пингуется. При этом, если я переключусь на core-роутер, то видно, что пинги приходят уже не с адреса 10.0.0 чего-то там, а с адреса 10.100.номер_комплекта.номер_комплекта. Мы на роутере перебили «частные» IP-адреса 10.0.0 на «публичные» IP-адреса 10.100. Именно такое правило трансляции позволит вам выставить в интернет ваших пользователей, позволить им подключаться к интернету. Если вдруг вы захотите сделать правило трансляции для отдельного порта, опубликовав тем самым один сокет, то делается это очень похожей командой. Будет IP NAT inside source, дальше вы указываете, вместо того чтобы указывать, что всё попадает под access list, вы указываете static,

TCP, частный сокет, публичный сокет. Когда у вас работает правило трансляции, давайте выполним show IP NAT translations — видно, что трансляций у нас никаких нет, но если мы сейчас быстренько попингаем соседа и снова выполним эту команду, то будет видно, что трансляция у нас есть. Она идёт с адреса 10.0.0.107 на адрес 10.100.7.100, и мы перебили частный адрес в публичный 10.100.7.7. Двоеточие 5 — это тот самый sequence number, за который зацепился движок цисковского port address translation. У ICMP, вообще говоря, портов нет, но кое-что, за что можно зацепиться, есть.

Именно за это PAT и зацепился и перебил нам в исходящих пакетах не порты, а кое-что другое. И обратный трафик возвращается именно на нужный нам inside local адрес. Именно за счёт того, что у нас есть идентификатор, который хоть каким-то образом позволяет отделить одни запросы от других. Это был NAT. Show IP NAT statistics покажет нам список счётчиков. Интерфейсы, которые размечены, здесь тоже показываются. Показывается, сколько одновременных трансляций у нас было, сколько правил трансляции у нас есть. У нас есть одна трансляция inside source, которая отбирает трафик по access list первому и перебивает

IP-адреса источника в адрес с интерфейса Ethernet 0.1. Ещё я хотел показать debug IP NAT. Эту команду никогда не надо пытаться включать на боевом роутере, но если у вас есть роутер, который вы только что настроили и знаете, что боевого трафика через него не идёт, то эту команду с осторожностью можно включить. Команда будет показывать сообщение каждый раз, когда пакет пробегает через роутер и с ним совершаются трансляции. Я сейчас снова попингую центральный роутер, и по каждому отдельному пакету показывается отдельная строчка, что NAT сработал. Пакет, который мы отправляли со свитча с адреса 10.0.0.107, перебился в 10.100.7.7 в качестве адреса источника. Эта часть — про адрес источника.

IP NAT inside source. Destination-адрес мы не перебивали, он у нас остался нетронутым. В обратную сторону идут пакеты с адреса outside global. Мы его не меняем, то есть outside local будет таким же. А в destination у нас стоят наши inside local и inside global, и мы inside global меняем на inside local. Потом следующий пакет — то же самое туда-обратно, следующий пакет туда-обратно, следующий пакет туда-обратно, и следующий пакет тоже туда-обратно. Видим, что пакеты проходят. Это то, что касалось NAT. Трансляции потихонечку протухают. Видно, что NAT очистил трансляцию, и сейчас в show IP NAT translations уже ничего нет. Выключаем дебаг после того, как на него посмотрели — очень плохая идея оставлять живой дебаг на железках. Выключается undebug

all. Выключить все виды дебага, которые только есть. На центральном роутере тоже не помешает это выключить. Undebug all. С очень большой осторожностью следует включать дебаг на боевых железках. Это не то чтобы с вероятностью единица, но с вероятностью 99% может привести к тому, что железка зависнет, если вы неаккуратно на загруженной железке попытаетесь задебажить что-то ресурсоёмкое. Например, есть такая команда debug ip packet. Она включает отображение на консоли строчки каждый раз, когда вообще какой-нибудь пакет через железку проходит. Теперь представьте себе, что будет с железкой, если через неё проходит 100 тысяч пакетов в секунду. Она должна будет по каждому из этих пакетов показать текстовую строчку на консоль. Естественно, она с этим не справится и просто зависнет. То же самое и с debug ip nat. Если это нагруженная железка,

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