Сети для самых маленьких. Часть пятая. ACL и NAT

Все выпуски


Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!
Но с развитием появляются и новые проблемы.
Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!
Итак, сегодня:
1) учимся настраивать различные списки контроля доступа (Access Control List)
2) пытаемся понять разницу между ограничением входящего и исходящего трафика
3) разбираемся с тем, как работает NAT, его плюсы, минусы и возможности
4) на практике организуем подключение к Интернету через NAT и увеличим безопасность сети, используя списки доступа.





Access Control List

Итак, что мы имеем сказать по спискам доступа? Вообще-то тема относительно простая и только ленивыми из курса CCNA не скопипащена. Но не разрывать же нам наше удивительное повествование из-за каких то предрассудков?

Каково предназначение списков доступа? Казалось бы, совершенно очевидный ответ — для ограничения доступа: кому-то что-то запретить, например. Вообще — это верно, но понимать нужно в более широком смысле: речь не только о безопасности. То есть, изначально, вероятно, так оно и было, отсюда permit и deny при настройке. Но на самом деле ACL — это универсальный и мощный механизм фильтрации. С их помощью можно определить на кого навешивать определённые политики, а на кого нет, кто будет участвовать в неких процессах, а кто нет, кого ограничиваем в скорость до 56k, а кого до 56M.
Чтобы было чуть-чуть понятнее, приведём простой пример. Опираясь на списки доступа, работает Policy-Based Routing (PBR). Можно сделать здесь так, чтобы пакеты приходящие из сети 192.168.1.0/24 отправлялись на next-hop 10.0.1.1, а из сети 192.168.2.0/24 на 10.0.2.1 (заметим, что обычная маршрутизация опирается на адрес назначения пакета и автоматически все пакеты отправляются на один next-hop):

В конце статьи пример настройки PBR и ограничения скорости на основе ACL.

Виды ACL
Ладно, забудем на время эту лирику.
Вообще говоря, списки доступа бывают разными:
  • Стандартные
  • Расширенные
  • Динамические
  • Рефлексивные
  • Повременные
Мы своё внимание остановим сегодня на первых двух, а более подробно обо всех вы можете прочитать у циски.

Входящий и исходящий трафик
Для почину давайте-ка разберёмся с одной вещью. Что понимать под входящим и исходящим трафиком? Это нам в будущем понадобится. Входящий трафик — этот тот, который приходит на интерфейс извне.

Исходящий — тот, который отправляется с интерфейса вовне.

Список доступа вы можете применить либо на входящий трафик, тогда неугодные пакеты не будут даже попадать на маршрутизатор и соответственно, дальше в сеть, либо на исходящий, тогда пакеты приходят на маршрутизатор, обрабатываются им, доходят до целевого интерфейса и только на нём дропятся.

Стандартный список доступа проверяет только адрес отправителя. Расширенный- адрес отправителя, адрес получателя, а также порт. Стандартные ACL рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).

Практика

Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”?
  1. WEB-сервер. Разрешить доступ всем по порту TCP 80 (протокол HTTP). Для того устройства, с которого будет производиться управление (у нас же есть админ) нужно открыть telnet и ftp, но ему мы дадим полный доступ. Всем остальным отбой
  2. Файловый сервер. На него у нас должны попадать резиденты Лифт ми Ап по портам для общих папок, а все остальные по FTP.
  3. Почтовый сервер. Тут у нас запущены SMTP и POP3, то есть порты TCP 25 и 110. Так же для админа открываем доступ на управление. Других блокируем
  4. Для будущего DNS-сервера нужно открыть порт UDP 53
  5. В сеть серверов разрешить ICMP-сообщения
  6. Поскольку сеть Other у нас для всех беспартийных, кто не вошёл в ФЭО, ПТО и Бухгалтерию, то мы их всех ограничим, а некоторым только дадим доступ (в числе них мы и админ)
  7. В сеть управления нужно пускать опять же только админа, ну и конечно себя любимого
  8. Не будем строить препоны общению между собой сотрудников отделов
1) Доступ на WEB-сервер
Тут у нас работает политика запрещено всё, что не разрешено. Поэтому нам сейчас надо кое-что открыть, а всё остальное закрыть.
Поскольку мы защищаем сеть серверов, то и лист будем вешать на интерфейс, идущий в сторону них то есть, на FE0/0.3 Вопрос только на in или на out нам нужно это делать? Если мы не хотим пускать пакеты в сторону серверов, которые уже оказались на маршрутизаторе, то это будет исходящий трафик. То есть адреса назначения (destination) у нас будут в сети серверов (из них мы будем выбирать на какой именно сервер идёт трафик), а адреса источников (source) могут быть любыми — как из нашей корпоративной сети, так и из интернета.
Ещё одно замечание: поскольку фильтровать мы будем в том числе по адресу назначения (на WEB-сервер одни правила, на почтовый — другие), то список контроля доступа нам понадобится расширенный (extended), только он позволяет делать это.

Правила в списке доступа проверяются по порядку сверху вниз до первого совпадения. Как только одно из правил сработало, независимо от того permit это или deny, проверка прекращается и обработка трафика происходит на основе сработавшего правила.
То есть если мы хотим защитить WEB-сервер, то в первую очередь нам нужно дать разрешение, потому что, если мы в первой же строке настроим deny ip any any — то оно всегда будет срабатывать и трафик не будет ходить вообще. Any — это специальное слово, которое означает адрес сети и обратную маску 0.0.0.0 0.0.0.0 и означает, что под правило подпадают абсолютно все узлы из любых сетей. Другое специальное слово — host — оно означает маску 255.255.255.255 — то есть именно один единственный указанный адрес.
Итак, первое правило: разрешить доступ всем по порту 80
msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# remark WEB
msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.2 eq 80

Разрешаем (permit) TCP-трафик от любого узла (any) на хост (host — именно один адрес) 172.16.0.2, адресованный на 80-й порт.
Пробуем повесить этот список доступа на интерфейс FE0/0.3:
msk-arbat-gw1(config)# int fa0/0.3
msk-arbat-gw1(config-subif)# ip access-group Servers-out out

Проверяем с любого из наших подключенных компьютеров:


Как видите страничка открывается, но что там у нас с пингом?


И так с любого другого узла?

Дело в том, что после всех правил в цисковских ACL в конце дописывается неявное deny ip any any (implicit deny). Что для нас это означает? Любой пакет, выходящий с интерфейса и не отвечающий ни одному правилу из ACL, подпадает под implicit deny и отбрасывается. То есть хоть пинг, хоть фтп, хоть что угодно здесь уже не пройдёт.

Идём дальше: надо дать полный доступ компьютеру, с которого будет производиться управление. Это будет компьютер нашего админа с адресом 172.16.6.66 из сети Other.
Каждое новое правило добавляется автоматически в конец списка, если он уже существует:
msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet

Вот и всё. Проверяем с нужного узла (поскольку серверами в РТ не поддерживается телнет, проверяем на FTP):


То есть FTP-сообщение пришло на маршрутизатор и должно уйти с интерфейса FE0/0.3. Маршрутизатор проверяет и видит, что пакет подходит под добавленное нами правило и пропускает его.

А с постороннего узла


пакет FTP не попадает ни под одно из правил, кроме неявного deny ip any any и отбрасывается.
2) Доступ на файловый сервер
Тут бы надо в первую очередь определиться с тем, кто будет “резидентом”, кому нужно дать доступ. Конечно, это те, кто имеет адрес из сети 172.16.0.0/16 — только им и дадим доступ.
Теперь с общими папками. В большинстве современных систем уже используется для этого протокол SMB, которому нужен порт TCP 445. На более старых версиях использовался NetBios, который кормился аж через три порта: UDP 137 и 138 и TCP 139. Договорившись с нашим админом, настроим 445 порт (правда проверить в рамках РТ, конечно, не получится). Но кроме этого, нам понадобятся порты для FTP — 20, 21, причём не только для внутренних хостов, но и для соединений из интернета:
msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.3 range 20 21

Тут мы повторно применили конструкцию range 20 21 — для того, чтобы в одной строке задать несколько портов. Для FTP, вообще говоря, недостаточно только 21-го порта. Дело в том, что если вы откроете только его, то авторизация у вас будет проходить, а передача файлов нет.

0.0.255.255 — обратная маска (wildcard mask). О том, что это такое, поговорим чуточку позже
3) Доступ на почтовый сервер
Продолжаем нарабатывать практику — теперь с почтовым сервером. В рамках того же списка доступа добавляем новые нужные нам записи.
Вместо номеров портов для широкораспространённых протоколов можно указывать их имена:
msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq pop3
msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq smtp

4) DNS-сервер
msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53

5) ICMP
Осталось исправить ситуацию с пингом. Ничего страшного нет в том, чтобы добавить правила в конец списка, но как-то эстетически приятнее будет увидеть их вначале.
Используем несложный чит для этого. Для это можно воспользоваться текстовым редактором, например. Скопируйте туда из show run кусок про ACL и добавьте следующие строки:
no ip access-list extended Servers-out
ip access-list extended Servers-out
permit icmp any any
remark WEB
permit tcp any host 172.16.0.2 eq www
permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet
remark FILE
permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
permit tcp any host 172.16.0.3 range 20 21
remark MAIL
permit tcp any host 172.16.0.4 eq pop3
permit tcp any host 172.16.0.4 eq smtp
remark DNS
permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53


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

Далее просто копируем всё скопом и вставляем в консоль. Интерфейс интерпретирует каждую строку как отдельную команду и выполняет её. Таким образом, мы заменили старый список новым.
Проверяем, что пинг есть:



Прекрасно.

Данный “чит” хорош для первоначальной конфигурации или если вы точно понимаете, что делаете. На рабочей сети, когда вы настраиваете удалённо ACL, вы рискуете остаться без доступа на настраиваемую железку.

Чтобы вставить правило в начало или в любое другое нужное место, вы можете прибегнуть к такому приёму:
ip access-list extended Servers-out
1 permit icmp any any

Каждое правило в списке пронумеровано с определённым шагом и если перед словом permit/deny вы поставите число, то правило будет добавлено не в конец, а в нужное вам место. К сожалению, такая фича не работает в РТ.
Если будет вдруг необходимо (заняты все подряд идущие числа между правилами) вы всегда можете перенумеровать правила (в этом примере назначается номер первого правила 10(первое число) и инкремент 10):
ip access-list resequence Servers-out 10 10


В итоге Access List на серверную сеть будет выглядеть так:
ip access-list extended Servers-out
permit icmp any any
remark WEB
permit tcp any host 172.16.0.2 eq www
permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet
remark FILE
permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
permit tcp any host 172.16.0.3 range 20 21
remark MAIL
permit tcp any host 172.16.0.4 eq pop3
permit tcp any host 172.16.0.4 eq smtp
remark DNS
permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53


Сейчас наш админ имеет доступ только на WEB-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.
6) Права пользователей из сети Other
До сих пор нам нужно было не впускать кого-то куда-то, поэтому мы обращали внимание на адрес назначения и список доступа вешали на исходящий с интерфейса трафик. Теперь нам нужно не выпускать: никакие запросы от компьютеров из сети Other не должны выходить за пределы. Ну, конечно, кроме тех, которые мы специально разрешим.
msk-arbat-gw1(config)# ip access-list extended Other-in
msk-arbat-gw1(config-ext-nacl)# remark IAM
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 any
msk-arbat-gw1(config-ext-nacl)# remark ADMIN
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 any

Тут мы не могли сначала запретить всем, а потом разрешить избранным, потому что абсолютно все пакеты попадали бы под правило deny ip any any и permit не срабатывал бы вообще.
Применяем на интерфейс. На этот раз на вход:
msk-arbat-gw1(config)#int fa0/0.104
msk-arbat-gw1(config-subif)#ip access-group Other-in in

то есть все IP-пакеты от хоста с адресом 172.16.6.61 или 172.16.6.66 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.
7) Сеть управления
Ничего сложного. Правило будет выглядеть так:
msk-arbat-gw1(config)# ip access-list extended Management-out
msk-arbat-gw1(config-ext-nacl)# remark IAM
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 172.16.1.0 0.0.0.255
msk-arbat-gw1(config-ext-nacl)# remark ADMIN
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 172.16.1.0 0.0.0.255

Данный ACL применяем на out на интерфейс FE 0/0.2:
msk-arbat-gw1(config)# int fa0/0.2
msk-arbat-gw1(config-subif)#ip access-group Management-out out

8) Более никаких ограничений
Готово

Маска и обратная маска
До сих пор мы без объяснения давали странный параметр вида 0.0.255.255, подозрительно напоминающий маску подсети.
Немного сложная для понимания, но именно она — обратная маска — используется для определения хостов, которые подпадут под правило.
Чтобы понять что такое обратная маска, вы должны знать, что такое обычная.Начнём с самого простого примера.

Обычная сеть на 256 адресов: 172.16.5.0/24, например. Что означает эта запись?
А означает она ровно следующее

IP-адрес. Десятичная запись1721650
IP-адрес. Двоичная запись10101100000100000000010100000000
Маска подсети. Двоичная запись11111111111111111111111100000000
Маска подсети. Десятичная запись2552552550

IP-адрес — это параметр длиною 32 бита, поделенный на 4 части, который вы привыкли видеть в десятичной форме.
Маска подсети также имеет длину 32 бита — она фактически шаблон, трафарет, по которому определяется принадлежность адреса подсети. Там, где в маске стоят единицы, значение меняться не может, то есть часть 172.16.5 совершенно неизменна и она будет одинакова для всех хостов этой подсети, а вот та, где нули — варьируется.
То есть во взятом нами примере 172.16.5.0/24 — это адрес сети, а хосты будут 172.16.5.1-172.16.5.254 (последний 255 — широковещательный), потому что 00000001 — это 1, а 11111110 — 254 (речь о последнем октете адреса). /24 означает, что длина маски 24 бита, то есть у нас идёт 24 единицы — неизменная часть и 8 нулей.
Другой случай, когда маска у нас, например, 30 бит, а не 24.
К примеру 172.16.2.4/30. Распишем это так:
IP-адрес. Десятичная запись1721624
IP-адрес. Двоичная запись10101100000100000000001000000100
Маска подсети. Двоичная запись11111111111111111111111111111100
Маска подсети. Десятичная запись255255255252

Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 4 значения:
00000100 — адрес подсети (4 в десятичной системе)
00000101 — адрес узла (5)
00000110 — адрес узла (6)
00000111 — широковещательный (7)
Всё, что за пределами этого — уже другая подсеть

То есть теперь вам должно быть чуть-чуть понятно, что маска подсети — это последовательность 32-х бит, где сначала идут единицы, означающие адрес подсети, потом идут нули, означающие адрес хоста. При этом чередоваться нули и единицы в маске не могут чередоваться. То есть маска 11111111.11100000.11110111.00000000 невозможна

А что же такое обратная маска (wildcard)?
Для подавляющего большинства админов и некоторых инженеров — это не более, чем инверсия обычной маски. То есть нули вначале задают адрес части, которая должна совпадать обязательно, а единицы наоборот свободную часть.
То есть на взятом нами первом примере, если вы хотите отфильтровать все хосты из подсети 172.16.5.0/24, то вы зададите правило в Access-листе:
…. 172.16.5.0 0.0.0.255
Потому что обратная маска будет выглядеть так:

00000000.00000000.00000000.11111111

Во втором примере с сетью 172.16.2.4/30 обратная маска будет выглядеть так: 30 нулей и две единицы:

Обратная маска. Двоичная запись00000000000000000000000000000011
Обратная маска. Десятичная запись0003

Соответственно параметр в access-листе будет выглядеть так:
…. 172.16.2.4 0.0.0.3
Позже, когда вы съедите собаку на просчётах масок и обратных масок, вы запомните самые употребляемые цифры, количество хостов в той или иной маске, поймёте, что в описанных ситуациях последний октет обратной маски получается вычитанием из 255 цифры последнего октета обычной маски (255-252=3) и т.д. А пока нужно много трудиться и считать)

Но на самом деле обратная маска — это несколько более богатый инструмент, здесь вы можете объединять адреса внутри одной подсети или даже объединять подсети, но самое главное отличие, вы можете чередовать нули и единицы. Это позволяет вам, например, отфильтровать определённый узел (или группу) в нескольких подсетях одной строкой.

Пример 1
Дано: сеть 172.16.16.0/24
Надо: отфильтровать первые 64 адреса (172.16.16.0-172.16.16.63)
Решение: 172.16.16.0 0.0.0.63

Пример 2
Дано: сети 172.16.16.0/24 и 172.16.17.0/24
Надо: отфильтровать адреса из обеих сетей
Решение: 172.16.16.0 0.0.1.255

Пример 3
Дано: Сети 172.16.0.0-172.16.255.0
Надо: отфильтровать хост с адресом 4 из всех подсетей
Решение: 172.16.0.4 0.0.255.0

Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи.
Более подробно об обратных масках можно прочитать тут: http://habrahabr.ru/post/131712/

Работа ACL в картинках
Гипотетическая сеть:



1) На маршрутизаторе RT1 на интерфейсе FE0/1 на вход у нас разрешено всё, кроме ICMP.



2) На маршрутизаторе RT2 на интерфейсе FE0/1 на выход запрещены SSH и TELNET



Тесты
кликабельны
1) Пинг с компьютера ПК1 на Сервер1

2) TELNET с компьютера ПК1 на Сервер1

3) SSH с компьютера ПК1 на Сервер2

4) Пинг с Сервера2 на ПК1


Дополнения
1) Правила, действующие на исходящий трафик (out) не будут фильтровать трафик самого устройства. То есть, если нужно запретить самой циске доступ куда-либо, то вам придётся на этом интерфейсе фильтровать входящий трафик (ответный оттуда, куда надо запретить доступ).

2) C ACL надо быть аккуратнее. При небольшой ошибке в правиле, неправильном порядке настройки или вообще плохо продуманном списке вы можете остаться без доступа к устройству.
Например, вы хотите закрыть доступ куда угодно для сети 172.16.6.0/24, кроме своего адреса 172.16.6.61 и задаёте правила так:
deny ip 172.16.6.0 0.0.0.255 any
permit ip host 172.16.6.61 any

Как только вы примените ACL на интерфейс, вы сразу потеряете доступ к маршрутизатору, потому что вы попадаете под первое правило и второе даже не проверяется.
Вторая неприятная ситуация, которая может с вами приключиться: под ACL попадёт трафик, который не должен был попасть.
Вообразите такую ситуацию: у нас в серверной есть FTP-сервер в пассивном режиме. Для доступа к нему вы открыли 21-й порт в ACL Servers-out. После первичного установления соединения FTP-сервер сообщает клиенту порт, по которому он готов передавать/принимать файлы, например, 1523-й. Клиент пытается установить TCP-соединение на этот порт, но натыкается на ACL Servers-out, где такого разрешения нету — так и кончается сказка про успешный трансфер. В нашем примере выше, где мы настраивали доступ на файловый сервер, мы открыли доступ только по 20 и 21-му, потому что для примера этого достаточно. В реальной жизни придётся повозиться. Немного примеров конфигурации ACL для распространенных случаев.

3) Из 2-го пункта вытекает очень похожая и интересная проблема.
Вздумалось вам, например повесить на интерфейс в интернет такие вот ACL:
access-list out permit tcp host 1.1.1.1 host 2.2.2.2 eq 80
access-list in permit tcp host 2.2.2.2 any eq 80

Казалось бы: хосту с адресом 1.1.1.1 разрешён доступ по 80-му порту на сервер 2.2.2.2 (первое правило). И обратно от сервера 2.2.2.2 разрешены соединения внутрь.
Но нюанс тут в том, что компьютер 1.1.1.1 устанавливает соединение НА 80-й порт, но С какого-то другого, например, 1054, то есть ответный пакет от сервера приходит на сокет 1.1.1.1:1054, не подпадает под правило в ACL на IN и отбрасывается ввиду неявного deny ip any any.
Чтобы избежать такой ситуации, и не открывать всем пучком порты, можно прибегнуть к такой хитрости в ACL на in:
permit tcp host 2.2.2.2 any established. 

Подробности такого решения в одной из следующих статей.

4) Говоря про современный мир, нельзя обойти такой инструмент, как объектные группы (Object-group).

Допустим, надо составить ACL, выпускающий три определенных адреса в интернет по трем одинаковым портам c перспективой расширения количества адресов и портов. Как это выглядит без знания объектных групп:
ip access-list extended TO-INTERNET
permit tcp host 172.16.6.66 any eq 80
permit tcp host 172.16.6.66 any eq 8080
permit tcp host 172.16.6.66 any eq 443
permit tcp host 172.16.6.67 any eq 80
permit tcp host 172.16.6.67 any eq 8080
permit tcp host 172.16.6.67 any eq 443
permit tcp host 172.16.6.68 any eq 80
permit tcp host 172.16.6.68 any eq 8080
permit tcp host 172.16.6.68 any eq 443

При увеличении количества параметров сопровождать такой ACL становится всё труднее и труднее, легко ошибиться при настройке.
Зато, если обратиться к объектным группам, то это приобретает следующий вид:
object-group service INET-PORTS
description Ports allowed for some hosts
tcp eq www
tcp eq 8080
tcp eq 443

object-group network HOSTS-TO-INET
description Hosts allowed to browse the net
host 172.16.6.66
host 172.16.6.67
host 172.16.6.68

ip access-list extended INET-OUT
permit object-group INET-PORTS object-group HOSTS-TO-INET any

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

4) Очень полезную для траблшутинга информацию можно получить из вывода команды show ip access-lists %имя ACL%. Кроме собственно списка правил указанного ACL, эта команда показывает количество совпадений по каждому правилу.

msk-arbat-gw1#sh ip access-lists nat-inet
Extended IP access list nat-inet
permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www
permit ip 172.16.5.0 0.0.0.255 host 192.0.2.3
permit ip 172.16.5.0 0.0.0.255 host 192.0.2.4
permit ip host 172.16.4.123 any
permit ip host 172.16.6.61 any
permit ip host 172.16.6.66 any(4 match(es))
permit ip host 172.16.16.222 any
permit ip host 172.16.17.222 any
permit ip host 172.16.24.222 any


А дописав в конце любого правила log, мы сможем получать сообщения о каждом совпадении в консоль. (последнее не работает в PT)

NAT

Network Address Translation — механизм в хозяйстве совершенно необходимый уже с 1994-го года. Много сессий об него сломано и пакетов потеряно.
Нужен он чаще всего для подключения вашей локальной сети к Интернету. Дело в том, что теоретически существует 255*255*255*255=4 228 250 625. 4 миллиарда адресов. Даже если бы у каждого жителя планеты был всего один компьютер, адресов бы уже не хватало. А тут разве что утюги к Интернету не подключаются. Умные люди сообразили это ещё в начале 90-х и как временное решение предложили разделить пространство адресов на публичные (белые) и приватные (частные, серые).
К последним относятся три диапазона:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Их вы свободно можете использовать в своей частной сети, и поэтому, разумеется, они будут повторяться. Как же быть с уникальностью? Кому будет отвечать WEB-сервер, которому пришёл запрос с обратным адресом 192.168.1.1? Ростелекому? Компании Татнефть? Или вашему комнатному Длинку? В большом интернете никто ничего не знает о приватных сетях — они не маршрутизируются.
Тут и выходит на сцену NAT. По большому счёту, это обман, подстава. На натирующем устройстве ваш приватный адрес, грубо говоря, просто подменяется на белый адрес, который и будет фигурировать далее в пакете, пока он путешествует до WEB-сервера. А вот белые адреса очень даже хорошо маршрутизируются, и пакет точно вернётся обратно на натирующее устройство.
Но как оно в свою очередь поймёт, что с ним делать дальше? Вот с этим и разберёмся.

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

Настраивается следующей командой:
Router (config)# ip nat inside source static 172.16.6.5 198.51.100.2

Что происходит:
1) Узел 172.16.6.5 обращается WEB-серверу. Он отправляет IP-пакет, где в качестве адреса получателя стоит 192.0.2.2, а отправителя 172.16.6.5.



2) По корпоративной сети пакет доставляется к шлюзу 172.16.6.1, где и настроен NAT



3) Согласно настроенной команде, маршрутизатор снимает текущий заголовок IP и меняет его на новый, где в качестве адреса отправителя уже фигурирует белый адрес 198.51.100.2.



4) По большому Интернету обновлённый пакет достигает сервера 192.0.2.2.



5) Тот видит, что ответ надо слать на 198.51.100.2 И подготавливает ответный IP-пакет. В качестве адреса отправителя собственно адрес сервера 192.0.2.2, адрес назначения — 198.51.100.2



6) Пакет обратно летит через Интернет, причём не факт, что тем же путём.

7) На натирующем устройстве указано, что все запросы на адрес 198.51.100.2 нужно перенаправлять на 172.16.6.5. Маршрутизатор снова раздевает спрятанный внутри TCP-сегмент и задаёт новый IP-заголовок (адрес отправителя не меняется, адрес назначения 172.16.6.5).



8) По внутренней сети пакет возвращается инициатору, которому даже и невдомёк, какие чудеса с ним творились на границе.
И так будет с каждым.
При этом если соединение инициируется из Интернета, пакеты автоматически, проходя через натирующее устройство, попадают на внутренний хост.

Такой подход бывает полезным, когда у вас есть сервер внутри вашей сети, к которому необходим полный доступ извне. Разумеется, этот вариант вы не можете использовать, если хотите триста хостов выпустить в Интернет через один адрес. Такой вариант NAT’а никак не поможет сохранить белые IP-адреса, но тем не менее он бывает полезен.

Динамический
У вас есть пул белых адресов, например, провайдер выделил вам сеть 198.51.100.0/28 c 16-ю адресами. Два из них (первый и последний) — адрес сети и широковещательный, ещё два адреса назначаются на оборудование для обеспечения маршрутизации. 12 оставшихся адресов вы можете использовать для NAT’а и выпускать через них своих пользователей.
Ситуация похожа на статический NAT — один приватный адрес транслируется на один внешний, — но теперь внешний не чётко зафиксирован, а будет выбираться динамически из заданного диапазона.
Настраивается он так:
Router(config)#ip nat pool lol_pool 198.51.100.3 198.51.100.14 

Задали пул (диапазон) публичных адресов, из которого будет выбираться адрес для натирования
Router(config)
#access-list 100 permit ip 172.16.6.0 0.0.0.255 any

Задаём список доступа, который пропускает все пакеты с адресом источника 172.16.6.х, где х варьируется 0-255.
Router(config)#ip nat inside source list 100 pool lol_pool

Этой командой мы стыкуем созданный ACL и пул.

Этот вариант тоже не универсальный, своих 300 пользователей вы так же не сможете выпустить всех в Интернет, если у вас нет 300 внешних адресов. Как только белые адреса исчерпаются, никто новый уже не сможет получить доступ в Интернет. При этом те пользователи, что уже успели отхватить себе внешний адрес, будут работать. Скинуть все текущие трансляции и освободить внешний адреса вам поможет команда clear ip nat translation *
Помимо динамического выделения внешних адресов, этот динамически NAT отличается от статического тем, что без отдельной настройки проброса портов уже невозможно внешнее соединение на один из адресов пула.

Many-to-One
Следующий тип имеет несколько названий: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT.
Последнее название говорит само за себя — через один внешний адрес выходит в мир много приватных. Это позволяет решить проблему с нехваткой внешних адресов и выпустить в мир всех желающих.
Тут надо бы дать пояснение, как это работает. Как два приватных адреса транслируются в один можно представить, но как маршрутизатор понимает кому нужно переслать пакет, вернувшийся из Интернета на этот адрес?
Всё очень просто:
Предположим, что от двух хостов из внутренней сети приходят пакеты на натирующее устройство. Оба с запросом к WEB-серверу 192.0.2.2.
Данные от хостов выглядят так:

Адрес отправителяПорт отправителяАдрес получателяПорт получателя
172.16.6.523761192.0.2.280
172.16.4.539800192.0.2.280

Маршрутизатор расчехляет IP-пакет от первого хоста, извлекает из него TCP-сегмент, распечатывает его и узнаёт, с какого порта устанавливается соединение. У него есть внешний адрес 198.51.100.2, на который будет меняться адрес из внутренней сети.
Далее он выбирает свободный порт, например, 11874. И что он делает дальше? Все данные уровня приложений он упаковывает в новый TCP сегмент, где в качестве порта назначения по-прежнему остаётся 80 (именно на него ждёт коннектов WEB-сервер), а порт отправителя меняется с 23761 на 11874. Этот TCP-сегмент инкапсулируется в новый IP-пакет, где меняется IP-адрес отправителя с 172.16.6.5 на 198.51.100.2.
То же самое происходит для пакета от второго хоста, только выбирается следующий свободный порт, например 11875. “Свободный” означает, что он ещё не занят другими такими соединениями.
Данные, которые отправляются в интернет, теперь буду выглядеть так.

Адрес отправителяПорт отправителяАдрес получателяПорт получателя
198.51.100.211874192.0.2.280
198.51.100.211875192.0.2.280

В свою NAT-таблицу он заносит данные отправителей и получателей

Локальный адрес отправителяЛокальный порт отправителяГлобальный адрес отправителяГлобальный порт отправителяАдрес получателяПорт получателя
172.16.6.523761198.51.100.211874192.0.2.280
172.16.4.539800198.51.100.211875192.0.2.280

Для WEB-сервера — это два совершенно разных запроса, которые он должен обработать каждый индивидуально. После этого он отсылает ответ, который выглядит так:

Адрес отправителяПорт отправителяАдрес получателяПорт получателя
192.0.2.280198.51.100.211874
192.0.2.280198.51.100.211875

Когда один из этих пакетов доходит до нашего маршрутизатора, тот сопоставляет данные в этом пакете со своими записями в NAT-таблице. Если совпадение найдено, происходит обратная процедура — пакету и TCP сегменту возвращаются его изначальные параметры только в качестве назначения:

Адрес отправителяПорт отправителяАдрес получателяПорт получателя
192.0.2.280172.16.6.523761
192.0.2.280172.16.4.539800

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

Каждое ваше обращение — это отдельное соединение. То есть попытались вы открыть WEB-страницу — это протокол HTTP, использующий порт 80. Для этого ваш компьютер должен установить TCP-сессию с удалённым сервером. Такая сессия (TCP или UDP) определяется двумя сокетами: локальный IP-адрес: локальный порт и удалённый IP-адрес: удалённый порт. В обычной ситуации у вас устанавливается одно соединение компьютер-сервер, в случае же NATа соединения будет как бы два:, маршрутизатор-сервер и компьютер думает, что у него есть сессия компьютер-сервер.

Настройка отличается совершенно незначительно: добавочным словом overload:
Router(config)#access-list 101 permit 172.16.4.0 0.0.0.255
Router(config)#ip nat inside source list 101 interface fa0/1 overload

При этом, разумеется, сохраняется возможность настроить пул адресов:
Router(config)#ip nat pool lol_pool 198.51.100.2 198.51.100.14 
Router(config)#access-list 100 permit 172.16.6.0 0.0.0.255
Router(config)#ip nat inside source list 100 pool lol_pool overload

Перенаправление портов
Иначе говорят ещё проброс портов или mapping.
Когда мы только начали говорить про NAT, трансляция у нас была один-в-один и все запросы, приходящие извне автоматически перенаправлялись на внутренний хост. Таким образом можно было бы выставить сервер наружу в Интернет.
Но если у вас нет такой возможности — вы ограничены в белых адресах, или не хотите выставлять всем пучком портов его наружу, что делать?
Вы можете указать, что все запросы, приходящие на конкретный белый адрес и конкретный порт маршрутизатора, должны быть перенаправлены на нужный порт нужного внутреннего адреса.
Router(config)#ip nat inside source static tcp 172.16.0.2 80 198.51.100.2 80 extendable

Применение данной команды означает, что TCP-запрос, пришедший из интернета на адрес 198.51.100.2 по порту 80, будет перенаправлен на внутренний адрес 172.16.0.2 на тот же 80-й порт. Разумеется, вы можете пробрасывать и UDP и делать перенаправление с одного порта на другой. Это, например, может оказаться полезным, если у вас есть два компьютера, к которым нужен доступ по RDP извне. RDP использует порт 3389. Один и тот же порт вы не можете пробросить на разные хосты (при использовании одного внешнего адреса). Поэтому вы можете сделать так:
Router(config)# ip nat inside source static tcp 172.16.6.61 3389 198.51.100.2 3389 
Router(config)# ip nat inside source static tcp 172.16.6.66 3389 198.51.100.2 3398

Тогда, чтобы попасть на компьютер 172.16.6.61 вы запускаете RDP-сессию на порт 198.51.100.2:3389, а на 172.16.6.66 — 198.51.100.2:3398. Маршрутизатор сам раскидает всё, куда надо.

Кстати, эта команда — частный случай самой первой: ip nat inside source static 172.16.6.66 198.51.100.2. Только в этом случае речь идёт о пробросе всего трафика, а в наших примерах — конкретных портов протокола TCP.

Вот так в общих чертах фунциклирует NAT. Про его особенности, плюсы/минусы написано куча статей, но не отметить их нельзя.

Слабости и силости NAT
+
— В первую очередь NAT позволяет сэкономить публичные IP-адреса. Собственно для этого он и был создан. Через один адрес, теоретически можно выпустить больше 65000 серых адресов (по количеству портов).
— Во-вторых, PAT и динамический NAT является в какой-то степени файрволом, препятствуя внешним соединениям доходить до конечных компьютеров, на которых может не оказаться своего файрвола и антивируса. Дело в том, что если извне на натирующее устройство приходит пакет, который тут не ожидается или не разрешён, он просто отбрасывается.
Чтобы пакет был пропущен и обработан, должны выполниться следующие условия:
1) В NAT-таблице должна быть запись для этого внешнего адреса, указанного как адрес отправителя в пакете
И
2) Порт отправителя в пакете должен совпадать с портом для этого белого адреса в записи
И
3) Порт назначения в пакете, совпадает с портом в записи.
ИЛИ
Настроен проброс портов.
Но не нужно рассматривать NAT именно как файрвол — это не более, чем дополнительная его плюшка.

— В-третьих, NAT скрывает от посторонних глаз внутреннюю структуру вашей сети — при трассировке маршрута извне вы не увидите ничего далее натирующего устройства.

-
Есть у NAT’а и минусы. Самые ощутимые из них, пожалуй, следующие:
— Некоторые протоколы не могут работать через NAT без костылей. Например, FTP или протоколы туннелирования (несмотря на то, как просто я настроил FTP в лабораторке, в реальной жизни это может создать кучу проблем)
— Другая проблема кроется в том, с одного адреса идёт много запросов на один сервер. Многие были свидетелем этого, когда заходишь на какой-нибудь Rapidshare, а он говорит, что с вашего IP уже было соединение, вы думаете, что “врёт, собака”, а это ваш сосед уже сосет. По этой же причине бывали проблемы c ICQ, когда сервера отказывали в регистрации.
— Не очень актуальная сейчас проблема: нагрузка на процессор и оперативную память. Поскольку объём работы довольно велик по сравнению с простой маршрутизацией (это надо не просто глянуть заголовок IP, надо его снять, TCP-заголовок снять, в таблицу занести, новые заголовки прикрутить) в мелких конторах с этим бывают проблемы.
Я сталкивался с такой ситуацией.
Одно из возможных решений — вынести функцию NAT на отдельный ПК либо на специализированное устройство, например Cisco ASA.
Для больших игроков, у которых маршрутизаторы ворочают по 3-4 BGP full-view, сейчас это не составляет проблем.

Что ещё нужно знать?
— NAT применяется в основном для обеспечения доступа в Интернет хостам с приватными адресами. Но бывает и иное применение — связь между двумя частными сетями с пересекающимися адресными пространствами.
Например, ваша компания покупает себе филиал в Актюбинске. У вас адресация 10.0.0.0-10.1.255.255, а у них 10.1.1.0-10.1.10.255. Диапазоны явно пересекаются, настроить маршрутизацию никак не получится, потому что один и тот же адрес может оказаться и в Актюбинске и у вас в штаб-квартире.
В таком случае на месте стыка настраивается NAT. Поскольку серых адресов у нас не мерено, можно выделить, к примеру, диапазон 10.2.1.0-10.2.10.255 и делать трансляцию один-в-один:
10.1.1.1-10.2.1.1
10.1.1.2-10.2.1.2

10.1.10.255-10.2.10.255

— В больших игрушках для взрослых NAT может быть реализован на отдельной плате (и часто так и есть) и без неё не заработает. А на офисных железках, напротив, есть почти всегда.

— С повсеместным внедрением IPv6 необходимость в NAT’e будет сходить на нет. Уже сейчас большие заказчики начинают интересоваться функционалом NAT64 — это когда у вас выход в мир через IPv4, а внутренняя сеть уже на IPv6

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

Практика NAT
Чего от нас требует реальность?
1) Сеть управления не имеет доступа в интернет вообще
2) Хосты из сети ПТО имеют доступ только к профильным сайтам, например, Linkmeup.ru
3) Милым дамам из бухгалтерии нужно вырубить окно в мир клиент-банков.
4) ФЭО не выпускать никуда, за исключением финансового директора
5) В сети Other наш компьютер и компьютер админа — им дадим полный доступ в интернет. Всем остальным можно открывать по письменному запросу.
6) Не забудем про филиалы в Питере и в Кемерово. Для простоты настроим полный доступ для эникиев из этих подсетей.
7) С серверами отдельная песня. Для них мы настроим перенаправление портов. Всё, что нам нужно:
а) WEB-сервер должен быть доступен по 80-му порту
б) Почтовый сервер по 25-му и 110-му
в) Файловый сервер доступен из мира по FTP.
8) Компьютеры админа и наш должны быть доступны из Интернета по RDP. Вообще-то это неправильный путь — для удалённого подключения нужно использовать VPN-подключение и уже будучи в локальной сети использовать RDP, но это тема отдельной совсем другой статьи.

Сначала подготовим тестовую площадку:

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

Сервера нам понадобятся следующие:
1. Два клиент-банка для бухгалтеров (sperbank.ru, mmm-bank.ru)
2. Linkmeup.ru для ПТОшников
3. яндекс (yandex.ru)



Для такого подключения мы поднимем ещё один влан на msk-arbat-gw1. Его номер, разумеется, согласуется с провайдером. Пусть это будет VLAN 6
Предположим, провайдер предоставляет нам подсеть 198.51.100.0/28. Первые два адреса используются для организации линка (198.51.100.1 и 198.51.100.2), а оставшиеся мы используем, как пул для NAT’a. Впрочем, никто совершенно нам не мешает использовать и адрес 198.51.100.2 для пула. Так и сделаем: пул: 198.51.100.2-198.51.100.14
Для простоты предположим, что публичные сервера у нас находятся в одной подсети:
192.0.2.0/24.
Как настроить линк и адреса вы вполне уже в курсе.
Поскольку у нас только один маршрутизатор в сети провайдера, и все сети подключены непосредственно к нему, то необходимости настраивать маршрутизацию нету.
А вот наш msk-arbat-gw1 должен знать куда отправлять пакеты в Интернет, поэтому нам нужен маршрут по умолчанию:
msk-arbat-gw1(config)# ip route 0.0.0.0 0.0.0.0 198.51.100.1

Теперь по порядку

Во первых настроим пул адресов
msk-arbat-gw1(config)# ip nat pool main_pool 198.51.100.2 198.51.100.14 netmask 255.255.255.240

Теперь собираем ACL:
msk-arbat-gw1(config)# ip access-list extended nat-inet

1) Сеть управления
не имеет доступа в интернет вообще
Готово
2) Хосты из сети ПТО
Имеют доступ только к профильным сайтам, например, Linkmeup.ru
msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq 80

3) Бухгалтерия
Даём доступ всем хостам на оба сервера
msk-arbat-gw1(config-ext-nacl)# permit ip 172.16.5.0 0.0.0.255 host 192.0.2.3
msk-arbat-gw1(config-ext-nacl)# permit ip 172.16.5.0 0.0.0.255 host 192.0.2.4

4) ФЭО
Даём разрешение только финансовому директору — это только один хост.
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.4.123 any

5) Other
Наши компьютеры с полным доступом
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 any
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 any

6) Филиалы в Санкт-Петербурге и Кемерово
Пусть адреса эникиев будут одинаковыми: 172.16.х.222
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.16.222 any
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.17.222 any
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.24.222 any


Вот так выглядит сейчас ACL полностью:
ip access-list extended nat-inet
remark PTO
permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www
remark ACCOUNTING
permit ip 172.16.5.0 0.0.0.255 host 192.0.2.3
permit ip 172.16.5.0 0.0.0.255 host 192.0.2.4
remark FEO
permit ip host 172.16.4.123 any
remark IAM
permit ip host 172.16.6.61 any
remark ADMIN
permit ip host 172.16.6.66 any
remark SPB_VSL_ISLAND
permit ip host 172.16.16.222 any
remark SPB_OZERKI
permit ip host 172.16.17.222 any
remark KMR
permit ip host 172.16.24.222 any


Запускаем:
msk-arbat-gw1(config)# ip nat inside source list nat-inet pool main_pool overload

Но счастье не будет полным без настройки интерфейсов:
На внешнем интерфейсе нужно дать команду ip nat outside
На внутреннем: ip nat inside
msk-arbat-gw1(config)# int fa0/0.101
msk-arbat-gw1(config-subif)# ip nat inside
msk-arbat-gw1(config)# int fa0/0.102
msk-arbat-gw1(config-subif)# ip nat inside
msk-arbat-gw1(config)# int fa0/0.103
msk-arbat-gw1(config-subif)# ip nat inside
msk-arbat-gw1(config)# int fa0/0.104
msk-arbat-gw1(config-subif)# ip nat inside
msk-arbat-gw1(config)# int fa0/1.6
msk-arbat-gw1(config-subif)# ip nat outside


Это позволит маршрутизатору понять откуда ждать пакеты, которые нужно будет обработать и куда их потом слать.

Чтобы сервера в интернете были доступны по доменному имени, нам бы неплохо было обзавестись DNS-сервером в нашей сети:



Естественно его, нужно прописать на тех устройствах, с которых будем проверять доступ:


Show must go on!

С компьютера админа доступно всё:


Из сети ПТО есть доступ только на сайт linkmeup.ru по 80-му порту (HTTP):




В сети ФЭО в мир выходит только 4.123 (финдиректор)




В бухгалтерии работают только сайты клиент-банков. Но, поскольку разрешение дано полностью на протокол IP, то их можно и пинговать:



7) Cервера
Тут нам нужно настроить проброс портов, чтобы к ним можно было обращаться из Интернета:


a) Веб-сервер
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.2 80 198.51.100.2 80

Сразу проверяем, например, мы можем это делать с тестового ПК c аресом 192.0.2.7.
Сейчас ничего не заработает, потому что для сети серверов у нас не настроен интерфейс на msk-arbat-gw1:
msk-arbat-gw1(config)# int fa0/0.3
msk-arbat-gw1(config-subif)# ip nat inside

А теперь:


б) Файловый сервер
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 20 198.51.100.3 20
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 21 198.51.100.3 21

Вот для этого в ACL Servers-out мы открывали также и 20-21-й порты для всех


в) Почтовый сервер
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.4 25 198.51.100.4 25
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.4 110 198.51.100.4 110

Проверить также не сложно. Следуйте инструкциям:
Сначала настраиваем почтовый сервер. Указываем домен и создаём двух пользователей.


Далее вносим домен в DNS. Этот шаг необязательный — можно к серверу обращаться и по IP, но почему бы и нет?


Настраиваем компьютер из нашей сети:


Из внешней:


Готовим письмо:


На локальном хосте нажимаем Receive:


8) Доступ по RDP к компьютерам админа и нашему
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.6.61 3389 198.51.100.10 3389
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.6.66 3389 198.51.100.10 3398


Безопасность
На последок одно замечание. Скорее всего натирующее устройство, у вас смотрит своим ip nat outside интерфейсом наружу — в Интернет. Поэтому на этот интерфейс не помешало бы повешать ACL, где вы запретите, разрешите, то что вам нужно. На этом вопросе не будем останавливаться уже в данной статье.

На этом первое знакомство с технологией NAT можно считать законченным.
В качестве ещё одного ДЗ ответьте на вопрос, почему нет доступа в Интернет с компьютеров эникиев в Питере и в Кемерово. Ведь мы их добавили уже в список доступа.

Материалы выпуска

Новый IP-план, планы коммутации по каждой точке и регламент
Файл РТ с лабораторной
Конфигурация устройств

Дополнительные ссылки:
Два провайдера+NAT
Полезная информация от cisco
Наш коллега хабраюзер написал несколько статей по особенностям NAT. Особенно интересна может быть данная статья.
Но как бы то ни было, никто не напишет о cisco лучше, чем cisco
Обратная маска

Бонусы

PBRВ режиме глобальной конфигурации.
Добавляем маршрут по умолчанию:
ip route 0.0.0.0 0.0.0.0 10.0.1.1

В списке доступа отфильтровываем трафик из сети 192.168.2.0/24
access-list 101 permit ip 192.168.2.0 0.0.0.255 any

Создаём карту маршрутов, где обозначаем, что если пакет из сети 192.168.2.0/24, то для него назначить next-hop 10.0.2.1 (вместо 10.0.1.1)

route-map CLIENT permit 5
match ip address 101
set ip next-hop 10.0.2.1

Применяем карту на интерфейс:
ip policy route-map CLIENT

Это лишь одно из применений мощного инструмента Policy-Based Routing, который, к сожалению, ни в каком виде не реализован в РТ.

rate-limit
На том же примере ограничим скорость для сети 192.168.1.0/24 до 1.5 Мб/с, а для 192.168.2.0/24 до 64 кб/с.
На 10.0.1.1 можно выполнить следующие команды:
Router(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any
Router(config)# access-list 101 permit ip 192.168.2.0 0.0.0.255 any
Router(config)# interface fa0/0
Router(config-if)# rate-limit output access-group 100 1544000 64000 64000 conform-action transmit exceed-action drop
Router(config-if)# rate-limit output access-group 101 64000 16000 16000 conform-action transmit exceed-action drop


Авторы:

Марат eucariot
Максим aka gluck

Отдельная благодарность за помощь в подготовке статьи Дмитрию JDima.

163 комментария

avatar
Спасибо за подробные примеры для ната и статической маршрутизации, а точнее то что происходит с пакетом когда он ходит между устройствами, мало где есть внятные описания «для начинающих».
avatar
Сам очень долго разбирался в своё время с этим. Это было не столько оттого, что нет хорошей документации, сколько оттого, что я вообще не понимал что это)
avatar
Подскажите пожалуйста как с помощью NAT сделать замену ip адреса получателя. Например, чтобы при запросе в браузере mail.ru, открывался google.com?
avatar
У механизма NAT нет таких возможностей. Это организуют различные прокси сервера.
avatar
Значит, средствами маршрутизатора эту задачу решить невозможно? (Чтобы хост, запрашивающий один сайт, переадресовывался на другой)
avatar
Вероятно, на некоторых устройствах это возможно реализовать политиками, но поверьте — это костыли, и вам не следует этого делать.
avatar
Задачу решил при помощи команды ip nat outside source static.
avatar
IP NAT outside? Признаться, не слышал вообще о её применении на практике. Можете более подробно рассказать?
avatar
смотри ссылку, 2 дня ломал голову как решить quiz
www.costiser.ro/2013/01/19/quiz-3/#comment-98
за описание спасибо все на пальцах =)
avatar
Вот уж не знал о таких возможностях. Спасибо за ссылку. Интересно пишет автор.)
avatar
Спасибо за урок!
У меня остались 2 вопроса:
1)
1.Мы создали main-pool.
2.Мы прикрепили «main-pool» к «nat-inet».
Мы не должны прикрепить список «nat-inet» к интерфейсу, как мы делали в ACL?
Если нет, то зачем создаётся идентификатор «nat-inet» если он некуда не прикрепляется и не как не применяется?
2)В каких случаях используется команда «outside»(Например:ip nat outside source static tcp ___________________)?
avatar
«IP NAT outside? Признаться, не слышал вообще о её применении на практике. Можете более подробно рассказать?»- не заметил)
avatar
Как заметили выше, ip nat outside можно применять для перенаправления запросов на конкретный хост на другой хост.
avatar
В статье приведена команда
msk-arbat-gw1(config)# ip nat inside source list nat-inet pool main_pool overload

Здесь как раз таки привязывается ACL к пулу NAT, указывается, кому можно, кому нет.
avatar
Здравствуйте.
Спасибо за проделанную работу. Очень познавательно.
Вот по данной статье возник вопрос.
Вроде все прочел, вроде все настроил так же, но вот возникает нюанс.
Все машины из внутренней сети прекрасно видят удаленные сервера, то есть ACL как то не срабатывает.
При этом на msk-arbat-gw1# при просмотре командой «show ip nat translations»
видны только те запросы которые прописаны и разрешены в ACL ( то есть если я открываю в браузере 192.0.2.2 то вижу следующее
Pro Inside global Inside local Outside local Outside global
tcp 198.51.100.2:1077 172.16.3.4:1077 192.0.2.2:80 192.0.2.2:80
открывающиеся другие страницы с этого адреса в translations не отображаются, но работают, то же самое и с других подсетей)
Вот и возникает вопрос с чем такое может быть связанно?
avatar
Разобрался.
Оказывается сделал лишний маршрут со стороны провайдера.
avatar
Это, кстати, очень любопытный момент! Вот тут статья на этот счет, если я правильно все понял.
avatar
Внезапно! Даже не думал о такой возможности.
Но для атаки, как описано в статье, насколько я понимаю, надо иметь возможность такой пакет (с адресом назначения из приватной сети) доставить до внешнего интерфейса бордера.
avatar
Респект за проект.
Вопрос по ДЗ:
С двух компов эникеев (VSL и KMR) доступ есть, а с озерков (Ozerki) доступа не добился.
Дайте, пожалуйста, подсказку.
avatar
Первый шаг траблшутинга в этом случае — трассировка. Проверяем таблицы маршрутизации и ACL на интерфейсах по ходу движения трафика.
avatar
Вопрос такой: вот этот пул адресов, который выделил нам провайдер и мы привязали его к нату, как он привязан к маршрутизатору, мы прописали только 1 адрес 198.51.100.2, а где вообще прописаны адреса 3-14, можете обьяснить, спасибо.
avatar
Не, по-другому.
Провайдер мог выдать нам допустим /24 маску. А из неё мы сами можем сделать 4 пула по 64 адреса. То есть пул в данном случае — это не то, что выдал нам пров, а тот диапазон, который вы вычленили.
Пулом мы задаём адреса, которые будут использоваться NAT'ом. Он их будет подставлять автоматически.
Если не настроен overload — то каждый новый NAT-client будет получать новый IP-адрес.
Если настроен overload, то как только исчерпаются TCP-порты в первом, NAT начнёт выделять порты из второго адреса и т.д.
Если же вы хотите распоряжаться каждым адресом отдельно, то нужно делать несколько пулов.
avatar
А если выделен 1 адрес, я так понимаю команда будет ip nat inside source list any interface fa0/1 overload.
и еще вопрос, в куске acl nat-inet: permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www нужно в конце дописывать established
avatar
1) Верно. Только после list имя ACL, а не просто any :)
2) Нет, в этом случае не надо. Establised означает, что будут разрешаться только TCP пакеты, для которых уже установлена сессия. Это подходит для ACL, который будет применяться на Uplink на inbound. То есть хост из приватной сети уже установил сессию (established), тогда ответные TCP будут пропускаться, иначе — нет.
avatar
Спасибо огромное за работу, очень сильно помогло в понимании что к чему.
Такой вопрос. Долго не мог понять почему у меня все хосты, которые идут на интерфейсы, где ip nat inside, весь СПБ и Кемерово спокойно выходили на 192.0.2/24. Никакие ACL не помогали.
Все таки решил посмотреть Ваши конфиги устройств и понял. У меня на маршр-ре провайдера прописано ip route 0.0.0.0 0.0.0.0 198.51.100.2. У Вас нет такого маршрута. Убрал маршрут — ACL заработал. Не могу понять почему так происходит.
avatar
Кстати, выше на пару комментов этот вопрос уже поднимался.
ACL вам нужен для того, чтобы пакеты попали под NAT.
Что происходит, если у вас есть обратный маршрут?
Пакеты, которые не попадают под ACL, не обрабатываются NAT и должны быть отправлены по обычной таблице маршрутизации, то есть по маршруту по умолчанию. Далее они беспрепятственно проходят в сеть 192.0..., имея сорс адрес из частной сети — на выход ACL не стоит.
Пакеты доходят до адресата, он готовит ответ и отсылает на свой маршрут по умолчанию, ответ доходит до маршрутизатора провайдера, и тут начинается интересное: на маршрутизаторе провайдера почему-то настроен дефолт в сторону клиента и пакет отправляется туда.
Понятно объяснил?

По-хорошему всё должно было бы закончиться на out-интерфейсе нашей сети и in-интерфейсе маршрутизатора провайдера — там должен быть ACL, который не выпускает приватные сети. Дельное замечание, кстати.
avatar
Добрый день! Благодарю за ваши статьи, очень интересно.
Не могли бы разъяснить пару моментов?
1. Касается пункта 7) Сеть управления. Кроме двух хостов, доступ в сеть 172.16.1.0 всем закрыт. При пинге адреса, скажем, 172.16.1.2 с хоста, скажем, 172.16.3.2, пинги не проходят — все логично. Но при пинге адреса 172.16.1.1 с того же хоста — запросы успешно проходят. Это нормальная ситуация? Ведь адрес 172.16.1.1 — это тоже часть сети 172.16.1.0/24
2. Вопрос касается все того же пункта 7) Сеть управления. В данном примере разве есть необходимость использования расширенных списков? Ведь критерием разрешения/запрета в любом случае выступает адрес отправителя.
3. Это скорее замечание-просьба. Дополнения, п.3: «Немного примеров конфигурации ACL для распространенных случаев.» Ссылка на примеры отсутствует, очень интересно про это почитать.
Заранее благодарен!
avatar
1. В статье есть ответ на ваш первый вопрос — ACL не действует на трафик, генерируемый самим маршрутизатором.
2. Да, вы правы. Но я обычно придерживаюсь логики применения расширенных ACL где он может понадобится. Например, если это список для доступа по телнет, то, конечно, нет смысла использовать расширенный. А в приведённом примере вполне может добавиться новое правило с адресом назначения уже.
3. Ссылку поправил.

Спасибо. В среду будет новая статья — VPN. Приглашаю к прочтению.
avatar
Добрый день!

Возвращаясь к вопросу №1 — так как все таки ограничить доступ на 172.16.1.1? Чтобы доступ к маршрутизатору был только у 172.16.6.66 и 172.16.6.61.

Отличные статьи, большое спасибо.
avatar
С помощью ACL. Просто вам нужно разрешить в ACL только пакеты с этих адресов на адрес 172.16.1.1 по определённому протоколу. ACL можно применить на интерфейсы, но более правильно решение — применить его на line vty — тогда это будет ограничивать конкретно доступ на роутер для управления.
avatar
Спасибо, все получилось!
avatar
Здравствуйте.

По поводу эникеев и жутко специфической задачи из пример 3: permit ip 172.16.0.0 0.0.255.25 any (у меня эникеи на 25)
Хотя в жизни да — жутко. Просто когда я добрался до Красноярска (выпуск 6) мне просто каждый раз лень стало дописывать хосты в инет.

Спасибо за выпуски.
avatar
Ну в реале они встречаются чуть чаще, чем никогда, на самом деле. Их обслуживать будет очень непросто.
avatar
Ага, например центральная компания говорит филиалам — в инет ходят только 172.16.x.10, ставьте на него прокси-сервер и выпускайте в инет людей сами. Ну точь в точь как у нас на заводе :)
avatar
Теоретически, конечно, да. Но в больших трансрегиональных компаниях редко все будут ходить в инет, например, через единственный центральный узел. Скорее всего все эти политики настраиваются локально.
Есть, конечно, вариант организации доступа к корпоративному серверу. Но там не всегда такие строгие услови.
Я не отрицаю применимости такой схемы, но логичнее задавать явные правила.
avatar
Добрый день!

тренировал НАТ дома на железе, в более успрощенной схеме. Появился вопрос: веб-сервер у меня свой и стоит внутри сети, снаружи виден (при обращении к нему из других сетей), из локалки не виден.

Нат прописал:
ip nat inside source list 1 interface FastEthernet0/0 overload
ip nat inside source static tcp 192.168.1.3 80 БЕЛЫЙ_АЙПИ 80 extendable
!
access-list 1 permit 192.168.2.0 0.0.0.255
access-list 1 permit 192.168.1.0 0.0.0.255

Вланов нет.
Вэб сервер стоит по адресу 192.168.1.3
Насколько я понимаю, надо завернуть запросы, которые поступают из локалки на белый адрес вэб сервера с помощью ДНС.
ДНС сервера внутри локалки у меня нет. Рельно ли выполнить такой «заворот» запросов механизмами Cisco?

До Циски у меня стоял обычный роутер Zyxel, в котором я в разделе НАТ вэб-интерфейса просто прописывал перенаправлять запросы с белого адреса на серый по порту 80 и всё работало как при запросах на белый адрес из локалки, так и извне он был виден.
avatar
а вы к серверу по имени обращаетесь или по айпишнику?
avatar
И по имени и по белому IP из локальной сети вэб-сервер не виден. С мобильного интернета тестил — виден и по имени и по белому IP.
avatar
ну нет смысла, мне кажется, из локальной сети заходить через белый айпи. вам нужно на локальном днс настроить резолв имени сервера в локальный айпишник. на циске это можно сделать, смотрите команды ip dns server и ip host. но это не лучший вариант, потому что при количестве клиентов 100-200 штук у вас будет уже сильно загружен проц на средней циске.
avatar
Смысл был в том, чтобы проверять доступность сайта как его видят пользователи извне. Странно, что на Зикселе за 50 баксов всё работало без конфигурации.
avatar
Прежде всего огромное спасибо вам за вашу работу!
В видео опечатка на 12:43 в диапазоне 172.168.0.0 — 172.168.255.255
avatar
Конечно вы правы… почти 192.168.
Спасибо.
avatar
Забавно))) Точно!!!))))
avatar
Доброго всем дня!!!
начал возиться с NAT и напоролся на занятную ситуацию
При включении NAT теряются пакеты и замечена слишком сильная потеря в скорости (примерно 70мб/с при канале в 1.5мб/с)
Прошу прощения за ссылку на сторонний ресурс, но вопрос уже описан
forum.learncisco.ru/index.php/topic,326.0.html
avatar
Не встречался с такой ситуацией, но считаю, нужно больше тестов. Во-первых, вы используете виртуальную машину. Попробуйте хотя бы просто с двух компьютеров без всяких наворотов.

Как себя ведёт пинг большими пакетами?
Наиболее частые причины такого поведения:
загрузка CPU
потери пакетов на интерфейсах
проблемы с MTU.

Кстати, у нас появился адрес helpme@linkmeup.ru для технических вопросов, чтобы не разводить флуд в комментах.
avatar
Пинг с виртуалки на интернет шлюз длинна пакета 1500

[11:10]root@srv[/root]# ping -s 1500 195.0.1.2
PING 195.0.1.2 (195.0.1.2): 1500 data bytes
1508 bytes from 195.0.1.2: icmp_seq=0 ttl=63 time=67.823 ms
1508 bytes from 195.0.1.2: icmp_seq=1 ttl=63 time=55.953 ms
1508 bytes from 195.0.1.2: icmp_seq=2 ttl=63 time=55.330 ms

— 195.0.1.2 ping statistics — 3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 55.330/59.702/67.823/5.748 ms

Пинг с виртуалки на интернет шлюз стандартная длинна пакета

[11:11]root@srv[/root]# ping 195.0.1.2
PING 195.0.1.2 (195.0.1.2): 56 data bytes
64 bytes from 195.0.1.2: icmp_seq=1 ttl=63 time=25.253 ms
64 bytes from 195.0.1.2: icmp_seq=2 ttl=63 time=22.596 ms

— 195.0.1.2 ping statistics — 3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 22.596/23.925/25.253/1.328 ms

попытался ограничить MTU во FreeBsd до 1450 — результат тот же
На роутере MTU не ограничивал поскольку проблем с пингами от самого роутера не замечал
avatar
Маленькая выборка. Надо пробовать пинг пакетов на 100 с ключом -f, чтобы пакет не фрагментировался.
MTU и MSS нужно настраивать как раз таки на шлюзе. Когда запускаете пинг со шлюза, он
1) использует сразу внешний адрес.
2) никак не задействует интерфейс в сторону локалки. В общем некорректное сравнение.

Ещё предложение дампами или по статистике посмотреть где именно теряется пакет — на входе или на выходе.
И ещё раз говорю, попробуйте исключить виртуалку.
avatar
Вот, кстати, длинная ветка по похожей проблеме: www.certification.ru/cgi-bin/forum.cgi?archive=1&action=thread&id=35170&page=1
avatar
Есть такой вопрос по поводу NAT. В данной статье Вы описываете как управлять доступом пользователей к Интернету путем настройки access листа для использования в команде ip nat inside source list <access-list> pool [overload], перечисляющего все возможные политики доступа. Но (на мой взгляд начинающего) возможен еще такой подход: для каждого vlan настраивается свой access-list, позволяющий или запрещающий доступ к тем или иным ресурсам. Например в ФЭО открыть доступ для финдира (172.16.4.2) в интернет, сохранив возможность делать ping и общаться внутри корпоративной сети:
ip access-list extended FEO-in
permit icmp any any
permit ip 172.16.4.0 0.0.0.255 172.16.0.0 0.0.0.255
permit tcp host 172.16.4.2 0.0.0.255 any eq 80


Этот access-list вешается на входящий (из vlan в роутер) интерфейс:

interface fa0/0.102
ip access-group FEO-in in

И так устанавливаются политики для каждой группы пользователей (интерфейсы и направления трафика для ACL выбираются в зависимости от конкретной политики). А access-list для NAT будет выглядеть так:
acess-list 101 ip 172.16.0.0 0.0.255.255 any, и будет отвечать только за трансляцию адресов, не имея отношения к политикам доступа.

Имеет ли такой подход право на существование? Он гораздо более громоздкий, чем перечисление всех политик в одном ACL для NAT, но, по-моему, его применение позволит избежать обсужденной выше проблемы с маршрутизацией за натирующий роутер.
avatar
Да, ваш вариант применим, но учитывая следующие моменты:

1) децентрализованное управление. Вместо того, чтобы править в одном месте, вам придётся править во многих, но отсюда и плюс — если неправильно примените правило в ACL, то коснётся это меньшего числа пользователей

2) Выпускать всех в Интернет безусловно опасно — забыли где-то повесить ACL на VLAN и они по умолчанию имеют доступ.

Не уловил связи между вашим подходом и вышеуказанной проблемой.
avatar
Спасибо за ответ и за всю серию Сетей для самых маленьких. Очень хорошая практика для начинающих. А связь я и сам что-то уже не вижу. Видимо, плохо разобрался, надо все перечитать.
avatar
Пожалуйста. И я приглашаю вас 24-го к чтению нового выпуска — восьмого, посвящённого BGP.
А 25-го числа будет опубликован 4-й выпуск подкаста ЛинкМиАп.
avatar
Здравствуйте люди добрые!!! Хочу попросить у вас помощь.сейчас прохожу Cisco-вские курсы и столкнулся с проблемой в практической части, а именно в пакет трейсере функционал сильно обрезан и там нет возможности опробовать все что прохожу, в GNS3 все вроде бы хорошо но нет L2 коммутаторов, знаю можно в 3600 вставить плату свичевую но все равно много там не доступно(((.
Узнал что есть эмулятор Cisco IOU -перерыл весь интернет нашел кучу статей по настройке его, но они явно предназначены для понимания «Великим мастерам»)!!!
Скажите если кто знает как его правильно установить, на что его ставить, как подключаться только желательно простым понятным детальным языком.Всем заранее спасибо!)
avatar
Router(config-if)# rate-limit output access-group 100 1544000 64000 64000 conform-action transmit exceed-action drop
Router(config-if)# rate-limit output access-group 101 64000 16000 16000 conform-action transmit exceed-action drop

Можно по подробнее про эти конфиги. как влияет каждое слово в этом конфиге и при чем тут 64000? в плане же написано что нужно снизить скорость до 1.5 мб
avatar
Позже в выпуске по QoS, если мы таковым всё-таки разродимся, мы расскажем подробно об этом всём.
Вкратце, политики QoS работают на основе так называемой корзины токенов/жетонов. И каждому типу трафика выделяется определённое количество этих жетонов, как только они исчерпаются, следующие пакеты перестают пропускаться. Собственно эти цифры, после собственно разрешённой скорости (cbs, pbs) определяют размер допустимых всплесков. Если трафик в пределах этих всплесков его пропустить (transmit), если нет — отбросить (drop).
Формулы расчёта этих значений cbs, pbs существуют и вообще это разобрано крайне подробно.
avatar
6400 означает предельно допустимую норму? всплеска чего?
avatar
Лучше почитать об этом в готовых источниках, хотя это мало где качественно описано.
Но для отправных точек вот:
ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B5%D0%B3%D0%BE_%D0%B2%D0%B5%D0%B4%D1%80%D0%B0

www.eng.tau.ac.il/~shavitt/courses/PrinComNet/2012/TokenBucket.ppt
avatar
Кстати пользуясь случаем хотел бы сказать огромное спасибо за столь раскрытую тему. Изучал курс CCNAD там об агрегации, мапинге не было слово. Об акцесс листах тема так как у вас не раскрыта. + Приятно было бы если бы вы о временных акцесс листах написали. Еще раз спасибо за труд и статью. Жду новых с нетерпением.
avatar
Спасибо, очень лестно это читать)
Временные ACL — очень маленькая и простая тема. Мы её не раскрывали даже в рамках этой статьи. А отдельно рассматривать тем более уже не будем. Если есть конкретный вопрос или задача, можете задать его здесь или написать нам на helpme@linkmeup.ru.
avatar
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 20 198.51.100.3 20
msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 21 198.51.100.3 21

Можно ли объединить эти 2 команды в одну?
avatar
Каким образом? Вы указываете точно соответствие между портами: с 20 на 20, с 21 на 21.
avatar
хм я подумал если ip nat inside source static tcp 172.16.0.3 20,21 198.51.100.3 20,21 написать то он 1 запись локального порта сравнит с 1 записью глобального. Но хотел спросить у вас возможно ли так.
avatar
Нет, в таком виде не работает. Один порт — одна команда.
avatar
Благодарю
avatar
а на циске 2960 можно отфильтровать DHCP -запросы клиентов? а то у меня l2vpn — а адресация одна, инет с каждой стороны свой. хочу 2 dhcp-сервера но так что клиенты не перепутывали серваки
avatar
Ну вообще, нужно пробовать. В принципе, у DHCP есть идентификаторы, как номер порта, например. Правда, не понимаю, зачем такие сложности. Почему нельзя использовать один сервер?
avatar
Часто падает L2vpn — и в результате один из офисов «с инетом но без него», так что есть потребность в своем собственном AD,DNS,DHCP
avatar
иденификатор есть udp 67-68, но вот только коммутаторы ведь вроде L2 — а это уже L3
avatar
Есть коммутаторы, которые позволяют и такое.
avatar
Может, есть смысл оформить резервирование? Чтобы один сервер резервировал другой.
Либо выделить для них разные пулы из одного диапазона и тогда не будет пересечений. Но первый вариант мне больше нравится.
avatar
Суть в том что в штатной ситуации, нельзя допускать регистрации в DHCP ПК из другого города — иначе будет назначен жлюз из другого города и все ринутся в L2VPN (а он узкий), либо отсев на сервере дхцп(автоматического критерия не вижу -руками — геморой) либо фильтр на канале l2vpn. Интересовала конкретная модель циски 2960
avatar
ну а скопы по-любасу разводить придется
avatar
Сложная схема, непрозрачная. Не лучше ли разнести по разным сетям?
avatar
Да пока роутеров нормальных нет
а что в чем непрозрачность\недостатки? что в этом может не работать?
avatar
да и к тому же — это не планируемая сеть — а уже существующая — я как бы правлю что б нормально работало
avatar
Ну недостатков как таковых в этой схеме, конечно нет. Вполне себе часто применяемая.
Но в вашем, например, случае, не обращаясь к дополнительной настройке DHCP и коммутаторов, сделать достаточно гибкую систему сложно.
Плюс, широковещательный трафик будет ходить между филиалами.

Я бы всё-таки попробовал настроить L3 ACL. Зачастую коммутаторы их поддерживают. Хотя, конечно зависит от железа и софта.
avatar
Помогите, плиз. Все делаю, как на видео, письма снаружи приходят на компьютер админа (172.16.6.66), а с компа админа наружу (192.0.2.7) не идут. На компе админа пишет Send sucsess, но на (192.0.2.7)нет ничего. Уже об стену убился! Может что-то из видео вырезано?
avatar
Прошу прощения, нашел ошибку
avatar
Здравствуйте, уважаемые авторы!
Большая к вам просьба выкладывать стартовый файл в начале главы, как вы это делаете в конце, т.к. в вашем случае они не совпадают после 3ей главы.
avatar
СпёрБанк
:) ;) Улыбнуло, за статьи спасибо
avatar
Всегда пожалуйста)
avatar
Здравствуйте!
А не подскажите почему пытаюсь применить список к интерфейсу, а нельзя указать направление out. Только in.

(config-if)#ip access-group to_dispetcher out
^
% Invalid input detected at '^' marker.

(config-if)#ip access-group to_dispetcher?
in inbound packets
avatar
Если речь о реальном оборудовании, это может быть ограничение платформы.
avatar
Да, это реальное оборудование — Cisco WS-C2960-48TC-L. А как можно обойти это ограничение? Может помочь обновление IOS? Есть ли способ точно узнать ограничение это платформы или нет?
avatar
Ответьте, пожалуйста. Очень надо.
avatar
Официальная документация Cisco гласит «For Layer 2 port ACLs, the switch does not support logging or outbound ACLs.»
Вы явно пытаетесь сделать что-то не то.
avatar
2960 — это Layer 2 коммутатор, они как правило поддерживают ACL только на in.
avatar
Ясно, спасибо.
А есть другой способ запретить любой трафик с порта к машине, кроме определенного ip адреса?
avatar
Port Security позволяет отфильтровывать по mac-адресам.
avatar
Спасибо!
avatar
Для меня оказалось неожиданностью, что 2960 ограниченно поддерживает Layer3.
Только статическая маршрутизация, но в некоторых схемах какие-то сети можно вынести на маршрутизацию на коммутатор. В таком случае и ACL исходящие должен поддерживать.
avatar
Насколько я знаю, 2960 вообще не поддерживает маршрутизацию. На нём самом можно настроить маршруты, как на обычном компьютере, но мрашрутизировать чужой трафик он не будет.
avatar
А вот и нет. Был этому также удивлён и сам бы вряд ли нашёл, если бы на глаза не попались материалы по новому CCNA R&S
www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swipstatrout.html

Они в своих учебных материалах как раз предлагают 2960 как _ограниченный_ Layer3 использовать
avatar
Признаюсь, я устарел. Не знал, что 29600 поддерживает маршрутизацию.
avatar
Очевидно в статье опечатка в месте где описывается NAT Динамический и Many-to-one.
Сказано
12 оставшихся адресов вы можете использовать для NAT’а и выпускать через них своих пользователей.

Но в примере настройки пула для динамического:
Router(config)#ip nat pool lol_pool 198.51.100.3 198.51.103.14 
и Many-to-one:
Router(config)#ip nat pool lol_pool 198.51.100.2 198.51.103.14 
Router(config)#access-list 100 permit 172.16.6.0 0.0.0.255
Router(config)#ip nat inside source list 100 pool lol_pool overload
В обоих случаях должно быть 100.
avatar
Да, спасибо большое, вы правы. *Поправлено*
avatar
Интересен вопрос как сделать «проброс не одного, а диапазона портов»
Стандартные схемы описанные выше уже не подходят
avatar
Вот пример, если я правильно понял, чего вы хотите:
nixman.info/?p=2258
avatar
Так как это вопрос с которым только столкнулся (и был очень удивлён что привычная схема проброса одного порта тут не годится), то не могу сказать точно ли это нужное решение.
Нашёл два варианта — тот что по ссылке + Policy-Based Routing.

Что лучше и выполняют ли они поставленные задачи — предстоит протестировать (на скорую руку нашёл жалобы что способ по ссылке не решает чьи-то задачи, но пока не разбирался почему).
avatar
Здравствуйте, и сразу же спасибо за цикл (крайне доступно и полезно) :) При работе с материалом возникла такая ситуация. Попробовал немного переделать пример, рассматриваемый в цикле, и вместо арендуемого L2VPN между Москвой, Кемерово и Питером решил поднять на маршрутизаторах два GRE over IPSec туннеля (Москва-Питер, Москва-Кемерово). Все получилось — правда, возникла проблема с настройкой NAT. При прокладке туннеля на маршрутизаторах указывается Tunnel Source (на московском у меня — 100.0.0.1 — внешний интерфейс местного шлюза). При, например, ICMP-запросах из московской сети в интернет NAT выбирает адрес из прописанного на маршрутизаторе пула (у меня — 100.0.0.3-100.0.0.14) — здесь все хорошо, но как только я формирую ICMP в питерскую или кемеровскую сеть, то пакеты не доходят, потому как в качестве Tunnel Source указан адрес 100.0.0.1, а NAT назначает адрес из указанного пула. В связи с этим вопрос: в какую сторону смотреть, когда нужно настроить NAT с уже поднятыми туннелями? :)
avatar
Здравствуйте. Всегда пожалуйста.

Касательно вашего вопроса я бы посоветовал посмотреть следующую статью.

При отправке пакета в туннель, не должна происходить трансляция. У вас правильно прописаны маршруты?
avatar
Здравствуйте, нет ли у вас этой статьи в doc формате для ворда? Заранее спасибо
avatar
Здравствуйте.
Вот только так.
avatar
Добрый вечер. Все же интересно как запретить пинг до менеджментского шлюза 172.16.1.1? Запретить доступ по telnet и ssh я запретил с помощью acl на vty. Но хочу чтоб еще и пинга не было. Его нет далее после шлюза из правила acl на out в managment сеть. Пробовал повесить acl на in fa0/0.2 все равно шлет реплаи. Читал где то выше про то что трафик самой циски не подходить под acl. Все же интересно. В принципе можно запретить на коммутаторе, но тогда долой централизованность, что не гуд.
avatar
Решил вопрос таким образом. Повесил на acl Other-in in
ip access-list extended Other-in
remark ADMIN
permit ip host 172.16.6.10 any — админский комп
remark all to inet
permit tcp 172.16.6.0 0.0.0.255 any eq www
deny icmp any 172.16.1.0 0.0.0.255 echo
permit icmp any any.
Не знаю насколько правильно. Все же интересно, есть ли иной способ?
avatar
А. Чуть не забыл. Прошу прощения за мой ask-flooding.
Настроили пул для ната. После чего пробросили сервера наружу, причем каждый на разном ip из пула.
Но если попробовать пропинговать, реплай будет только от 198.51.100.2 (ну и разумеется, он же у нас настроен на физическом интерфейсе)
Но тем не менее, все таки натит, значит принимает соединения и перенаправляет. Почему в такой ситуации невозможен пинг?
avatar
Добрый вечер! Я совсем не давно стал изучать построения ЛВС, я случайно наткнулся на ваши видео уроки и стал внимательно их изучать. До 5-го урока все мне было понятно, но тут я попал в тупик. Если возможно Вы сможете ответить на мои вопросы? Буду очень благодарен
avatar
Можете попробовать. :)
avatar
К примеру это действие — msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.2 eq 80, я не понимаю почему после permit прописывается TCP и как узнать какой порт необходимо указывать в конце? в данном случае почему именно 80?
В этом действии — msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445, Вы разрешаете сети 172.16.0.0 иметь доступ к File серверу, но от куда взялся 445 порт?
Заранее благодарю и прошу прощения за беспокойство.
avatar
Ну вообще ACL составляется согласно тому, что вы от него хотите. Я хотел разрешить доступ по 80-му порту TCP (HTTP) на адрес 172.16.0.2, поэтому и составил именно такую строку.
avatar
Я покопался и нашел список этих портов, у каждого свое назначение. Получается, если мне необходимо разрешить/запретить доступ по 23 порту (telnet) на какую либо машинку, то я и должен прописать именно 23 порт?
avatar
Совершенно верно!
avatar
Огромное спасибо! Если что, извините за нелепые вопросы.
avatar
Доброго времени суток! Хотелось бы узнать, этой ли командой открывается доступ Админу на всю сеть? permit tcp host 172.16.6.4 172.16.0.0 0.0.255.255 range 20 ftp
avatar
Добрый день.Хотел бы узнать, что я не так делаю в настройке NAT. Суть, имеется 2 подсети, 10.10.0.0/22 и 10.10.4.0/22, и два пула внешников,188.134.64.1-188.134.64.63 и 188.134.64.64-188.134.64.127.
NAT настроен так:
ip nat inside source list 1 pool r001_pool overload
ip nat inside source list 2 pool r002_pool overload
Пулы описаны соответственно:
Внешние:
ip nat pool r001_pool 188.134.64.1 188.134.64.63 netmask 255.255.255.192
ip nat pool r002_pool 188.134.64.64 188.134.64.127 netmask 255.255.255.192
Локальные:
access-list 1 permit 10.10.0.0 0.0.3.255
access-list 2 permit 10.10.4.0 0.0.3.255
Посмотрел в «Покадровом» режиме CPT запрос заходит до пингуемого внешнего хоста, но, айпишник в заголовке не меняется, и, соответственно, ответ до получателя не доходит.
В чем всё таки может быть причина? Ибо пол вечера уже бьюсь
avatar
IP nat inside, outside, ACL?
avatar
ACLей не было настроено, в итоге нашел косяк с настроеными ip nat inside не на тех интерфейсах. Кстати, вопрос: ip nat outside интерфейсов может быть сколько угодно? или только один на каждую железку?
avatar
Может быть несколько, например в случае с несколькими провайдерами.
avatar
Марат, Максим, в «Пример 3» раздел ACL,
вместо
Решение: 172.16.16.0 0.0.255.4
мне кажется должно быть
Решение: 172.16.0.4 0.0.255.0
avatar
Спасибо. Исправлено.
avatar
Добрый день Марат, Максим.
Во первых огромное спасибо за созданный вами проект, именно он помог мне перейти с 1 уровня поддержки, на второй.
Благодоря вам я расстался с Help Desk)).
Незнаю ведете ли вы статистику по слушателям подкаста, но могу сказать что СНГ в вас нуждается.
Половина IT Узбекистана вас слушает и радуется.

И позвольте такой вот вопрос, я честно говоря только начинаю свой путь в телекоммуникациях.
Начал работу в провайдере, и мы с коллегами спорим о выводе одной комманды.

matches: all traffic
params: 1024000 bps, 128000 limit, 196000 extended limit
conformed 461356268 packets, 94665M bytes; action: transmit
exceeded 0 packets, 0 bytes; action: drop
last packet: 0ms ago, current burst: 0 bytes
last cleared 23w6d ago, conformed 52000 bps, exceeded 0 bps

Суть спора такова, что мы пытаемся определить какой параметр вывода show int… rate-limit. Показывает текущую загрузку канала.
одни (в том числе и я) утверждаем что это current burst: 0 bytes. Другие, что это conformed 52000 bps.
Cisco говорит, что при конфигурации CAR нужно смотреть на параметр «conformed» и его необходимо высчитывать по формуле:
(conformed bits since last clear counter)/(time in seconds elapsed since last clear counter).
Но если высчитывать именно так, то выставленная ширина канала не совпадает с тем что выходит по формуле.
Немогли бы вы пояснить на какой параметр все-таки нужно смотреть. Как мне показалась статья на Cisco.com довольно размазанная, но может просто мой английский плох. Надо по совету Дмитрия из Cisco TAС учить английский)).
avatar
Здравствуйте.
Очень рад слышать, что подкасты и статьи нужны вам!

Что касается вашего вопроса: Cisco говорит всё правильно. Conformed — это именно сколько прошло трафика через интерфейс за определённый период. Почему могут не совпадать цифры? Во-первых, не всегда трафик у вас идёт с ровной скоростью — иногда и меньше, тогда вычисленная ширина будет меньше. А, во-вторых, бывают и те самые Burst — всплески трафика — они будут увеличивать вычисленную ширину.
avatar
Добрый день!
Безусловно, весьма информативная статья, но, мне кажется, в плане безопасности, вы кое-что не осветили. В частности, в нашем маленьком пригородном провайдере на свичах реализована функиця ограничения мультикастового и бродкастового траффика от абонентского порта(ограничение стоит по кол-ву пакетов в секунду). В необходимости такого фильтра убедился когда в подсетке /22 искал мерзавца, который флудил бродкастовыми пакетами максимального во всю подсеть, занимая на все активных портах по 15-25 Мбит входящего траффика. Уверен, что на цисках такой функционал присутствует(если уж на Длинках есть..) Можно ли эту тему как нибудь осветить?
avatar
Здравствуйте.

Вообще говоря, целью статьи не было осветить вопросы безопасности, потому что в этом случае пришлось бы поднимать огромнейший пласт знаний. Это и защита процессора и элементарный ARP-Spoofing и проблемы VTP и многое многое другое. Связывать это всё с данной темой, только потому что ACL относится к безопасности… Про это пишут книги, а не одну статью)

Плюс в вашей ситуации вполне мог быть
avatar
могла быть петля, а не негодяй :) Впрочем одно не исключает другое — петля от негодяя. И отследить это как правило легко по счётчику широковещательных потоков на интерфейсах.
avatar
Тоже верно. В итоге это был негодяй :) На самом деле просто немного не понял, как это реализуется в цисках. На маршрутизаторе Вы показали как реализуется, допустим, ограничение скорости для конкретной подсети. Можно ли, к примеру, ограничить скорость на аксес-портах на определенный мак, допустим, бродкастовый? Прочитал про MAC ACL на Catalyst'ах… Через него, видимо, можно ограничить бродкаст и мультикаст траффик?
avatar
Можно, всё можно. Есть ещё такой функционал, как storm control или broadcast supression. Есть и всякие проприетарные фичи.
avatar
«Я — полное безразличие джека» wtf? Мульт?
avatar
Уважаемый автор. Ваши статьи вызывают восхищение у меня :)
Вот только не пойму, где более полная версия Ваших трудов? На хабре, тут или еще где?
avatar
Валентин, полное собрание сочинений тут и только тут. И оно ещё будет пополняться, конечно.
avatar
А почему на хабре я видел 9 часть, а тут нет?
Этот сайт полностью Ваш? Т.е. я не смогу здесь встретить статьи других авторов?
avatar
Сети для самых маленьких. Часть девятая. Мультикаст

Сайт полностью наш, но есть несколько статей, написанных другими авторами для нас специально.
avatar
Так а что насчет 9 части?
avatar
упс, не увидел ссылку. сори. :)
avatar
Вопрос: Зачем ACL вешать на out интерфейс? Это же лишняя нагрузка на роутер. Почему нельзя повесить на входящий то же самое?
avatar
Разумеется, вы правы. На out вешаются ACL для трафика, который приходит извне.
avatar
Здравствуйте, прошу оказать помощь. Не могли бы вы объяснить назначение access-list-ов, в диапозоне с 200 — по 299. Зачем они нужны. И возможно ли, что при создании access-list-а он не будет виден в выводе комманды sh run.
Заранее благодарю.
avatar
Первая ссылка не рабочая
Общая информация и распределение нагрузки TCP
avatar
Спасибо за информацию. Жаль, хороший был материал.
комментарий был удален
комментарий был удален
avatar
По домашнему заданию.
Проверяю доступ от озерков. Всю сеть видно, а интернета нет.
Трасировка указывает на 172.16.2.1 — msk-arbat-gw1. Там все и заворачивается, но почему? Ведь маршрут есть:
ip route 0.0.0.0 0.0.0.0 198.51.100.1

ACL проверяю командой:
show ip access-lists nat-inet
Вижу что счетчики не увеличиваются… Так и не понял что происходит =(
avatar
Разобрался! Внимание спойлер подсказка: проверяйте настройку ната…
avatar
Доброго времени суток, спасибо за проделанную работу, возникла трудность, не пингуется маршрутизатор msk-arbat-gw.

Router(config)#do ping 198.51.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.2, timeout is 2 seconds:

Success rate is 0 percent (0/5)

с маршрутизатора провайдера и обратно, может я маршрутизацию не прописал )?
avatar
Здравствуйте.
Ну, смотря откуда вы пингуете.
В первую очередь, конечно, смотрите маршрутизацию — есть ли маршруты к сети 198.51.100.2, есть ли маршруты обратно.
avatar

C маршрутизатора провайдера, не пингуется маршрутизатор msk-arbat-gw
avatar
Тоже долго голову над этим ломал, а оказалось, что я забыл указать на свитче провайдера транковые порты…
avatar
Решил проблему, заново прошёлся по материалу и всё заработало, спасибо большое за ваш труд!!!
avatar
1) Сеть управления
не имеет доступа в интернет вообще

А если в этой сети у меня находятся например ИБП, которому нужен инет для отправки алертов. Как быть в таком случае?
avatar
Здравствуйте.
У меня возник вопрос, но сначала скажу, что у вас авторизации через Google не работает.
А теперь к делу. При настройке соединения между маршрутизатором провайдера и маршрутизатором в Москве я задал маску 30. Все шло хорошо до момента проверки ftp и почты, они оказывались работать из вне, а доступ к web серверу отлично работал. Хорошо подумав я понял, что маршрутизатор провайдера не знает куда отправить запрос с ip получателя 100.3 и 100.4. Вместо того чтобы менять маску я добавил маршрут по уполномочию на маршрутизатор провайдера в сторону Москвы, но ftp и почта все равно не заработали. Еще лучше подумав я понял, что на маршрутизаторе в Москве тоже стоит маршрут по уполномочию на маршрутизатор провайдера и он этот пакет отправляет ему же. В итоге я просто поменял маску на 28 и все заработало.
Вопрос: почему имея соединение с провайдером типа точка точка и прописанном маршруте по уполномочию пакет не уходит в строну сервера? Ведь в правилах nat указанно что пакет с получателем 198.51.100.3 должен уходить на адрес 172.16.0.3, а этот адрес есть в списке маршрутизации. То есть получается, что пакет сначала сверятся со списком маршрутизации, а потом только с nat, так?