Источник: Сети для самых маленьких.

0. Планирование
1. Подключение к оборудованию cisco
2. Коммутация

3. Статическая маршрутизация

4. STP

5. ACL и NAT

Часть нулевая. Планирование

Это 1-я статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN’ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали об эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.

Схема сети

Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Следует несколько конкретизировать ситуацию.

  1. В данный момент у компании есть два офиса: 200 квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.
  2. Есть четыре группы пользователей: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера (С), которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.
  3. Пользователи групп С, Б и ФЭО будут только в офисе на Арбате, ПТО и Д будут в обоих офисах.

Прикинув количество пользователей, необходимые интерфейсы, каналы связи, вы готовите схему сети и IP-план.
При проектировании сети следует стараться придерживаться иерархической модели сети, которая имеет много достоинств по сравнению с “плоской сетью”:

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

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение — быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: как правило, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

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

Схема сети

На представленной схеме ядром (Core) будет маршрутизатор 2811, коммутатор 2960 отнесём к уровню распространения (Distribution), поскольку на нём агрегируются все VLAN в общий транк. Коммутаторы 2950 будут устройствами доступа (Access). К ним будут подключаться конечные пользователи, офисная техника, сервера.

Именовать устройства будем следующим образом: сокращённое название города (msk) — географическое расположение (улица, здание) (arbat) — роль устройства в сети + порядковый номер.
Соответственно их ролям и месту расположения выбираем hostname:
Маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз)
Коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch)
Коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch)

Документация сети

Вся сеть должна быть строго документирована: от принципиальной схемы, до имени интерфейса.
Прежде, чем приступить к настройке, я бы хотел привести список необходимых документов и действий:
Схемы сети L1, L2, L3 в соответствии с уровнями модели OSI (Физический, канальный, сетевой)
План IP-адресации = IP-план.
Список VLAN
Подписи (description) интерфейсов
• Список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAM\NVRAM, список интерфейсов)
• Метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах
• Единый регламент, определяющий все вышеприведённые параметры и другие.

Жирным выделено то, за чем мы будем следить в рамках программы-симулятора. Разумеется, все изменения сети нужно вносить в документацию и конфигурацию, чтобы они были в актуальном состоянии.

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

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

Метки на кабелях

Подготовим нужные нам документы:

Список VLAN
№ VLAN VLAN name Примечание
1 default Не используется
2 Management Для управления устройствами
3 Servers Для серверной фермы
4-100 Зарезервировано
101 PTO Для пользователей ПТО
102 FEO Для пользователей ФЭО
103 Accounting Для пользователей Бухгалтерии
104 Other Для других пользователей

Каждая группа будет выделена в отдельный влан. Таким образом мы ограничим широковещательные домены. Также введём специальный VLAN для управления устройствами.
Номера VLAN c 4 по 100 зарезервированы для будущих нужд.

IP-план
IP-адрес Примечание VLAN
172.16.0.0/16
172.16.0.0/24 Серверная ферма 3
172.16.0.1 Шлюз
172.16.0.2 Web
172.16.0.3 File
172.16.0.4 Mail
172.16.0.5 — 172.16.0.254 Зарезервировано
172.16.1.0/24 Управление 2
172.16.1.1 Шлюз
172.16.1.2 msk-arbat-dswl
172.16.1.3 msk-arbat-aswl
172.16.1.4 msk-arbat-asw2
172.16.1.5 msk-arbat-asw3
172.16.1.6 msk-rubl-aswl
172.16.1.6 — 172.16.1.254 Зарезервировано
172.16.2.0/24 Сеть Point-to-Point
172.16.2.1 Шлюз
172.16.2.2 — 172.16.2.254 Зарезервировано
172.16.3.0/24 ПТО 101
172.16.3.1 Шлюз
172.16.3.2 — 172.16.3.254 Пул для пользователей
172.16.4.0/24 ФЭО 102
172.16.4.1 Шлюз
172.16.4.2 — 172.16.4.254 Пул для пользователей
172.16.5.0/24 Бухгалтерия 103
172.16.5.1 Шлюз
172.16.5.2 — 172.16.5.254 Пул для пользователей
172.16.6.0/24 Другие пользователи 104
172.16.6.1 Шлюз
172.16.6.2 — 172.16.6.254 Пул для пользователей

Выделение подсетей в общем-то произвольное, соответствующее только числу узлов в этой локальной сети с учётом возможного роста. В данном примере все подсети имеют стандартную маску /24 (/24=255.255.255.0) — зачастую такие и используются в локальных сетях, но далеко не всегда. Советуем почитать о классах сетей. В дальнейшем мы обратимся и к бесклассовой адресации (cisco). Мы понимаем, что ссылки на технические статьи в википедии — это моветон, однако они дают хорошее определение, а мы попробуем в свою очередь перенести это на картину реального мира.
Под сетью Point-to-Point подразумеваем подключение одного маршрутизатора к другому в режиме точка-точка. Обычно берутся адреса с маской 30 (возвращаясь к теме бесклассовых сетей), то есть содержащие два адреса узла. Позже станет понятно, о чём идёт речь.

План подключения оборудования по портам

Разумеется, сейчас есть коммутаторы с кучей портов 1Gb Ethernet, есть коммутаторы с 10G, на продвинутых операторских железках, стоящих немалые тысячи долларов есть 40Gb, в разработке находится 100Gb (а по слухам уже даже есть такие платы, вышедшие в промышленное производство). Соответственно, вы можете выбирать в реальном мире коммутаторы и маршрутизаторы согласно вашим потребностям, не забывая про бюджет. В частности гигабитный свич сейчас можно купить незадорого (20-30 тысяч) и это с запасом на будущее (если вы не провайдер, конечно). Маршрутизатор с гигабитными портами стоит уже ощутимо дороже, чем со 100Mbps портами, однако оно того стоит, потому что FE-модели (100Mbps FastEthernet), устарели и их пропускная способность очень невысока.
Но в программах эмуляторах/симуляторах, которые мы будем использовать, к сожалению, есть только простенькие модели оборудования, поэтому при моделировании сети будем отталкиваться от того, что имеем: маршрутизатор cisco2811, коммутаторы cisco2960 и 2950.

Имя устройства Порт Название VLAN
Access Trunk
msk-arbat-gw1 FE0/1 UpLink
FE0/0 msk-arbat-dsw1 2,3,101,102,103,104
msk-arbat-dsw1 FE0/24 msk-arbat-gw1 2,3,101,102,103,104
GE1/1 msk-arbat-asw1 2,3
GE1/2 msk-arbat-asw3 2,101,102,103,104
FE0/1 msk-rubl-asw1 2,101,104
msk-arbat-asw1 GE1/1 msk-arbat-dsw1 2,3
GE1/2 msk-arbat-asw2 2,3
FE0/1 Web-server 3
FE0/2 File-server 3
msk-arbat-asw2 GE1/1 msk-arbat-asw1 2,3
FE0/1 Mail-Server 3
msk-arbat-asw3 GE1/1 msk-arbat-dsw1 2,101,102,103,104
FE0/1-FE0/5 PTO 101
FE0/6-FE0/10 FEO 102
FE0/11-FE0/15 Accounting 103
FE0/16-FE0/24 Other 104
msk-rubl-asw1 FE0/24 msk-arbat-dsw1 2,101,104
FE0/1-FE0/15 PTO 101
FE0/20 administrator 104

Почему именно так распределены VLAN’ы, мы объясним в следующих частях.

Excel-документ со списком VLAN, IP, портов

Схемы сети

На основании этих данных можно составить все три схемы сети на этом этапе. Для этого можно воспользоваться Microsoft Visio, каким-либо бесплатным приложением, но с привязкой к своему формату, или редакторами графики (можно и от руки, но это будет сложно держать в актуальном состоянии :)).

Не пропаганды опен сорса для, а разнообразия средств ради, воспользуемся Dia. Я считаю его одним из лучших приложений для работы со схемами под Linux. Есть версия для Виндоус, но, к сожалению, совместимости в визио никакой.

L1

Схема сети L1

То есть на схеме L1 мы отражаем физические устройства сети с номерами портов: что куда подключено.

L2

На схеме L2 мы указываем наши VLAN’ы

Схема сети L2

L3

Схема сети L3

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

Dia-файлы со схемами сети: L1, L2, L3

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

К этой первой статье мы не раз ещё вернёмся в будущем, равно как и вам придётся всегда возвращаться к тому, что вы изначально напланировали.
Собственно задание для тех, кто пока только начинает учиться и готов приложить для этого усилия: много читать про вланы, ip-адресацию, найти программы Packet Tracer и GNS3.
Что касается фундаментальных теоретических знаний, то советуем начать читать Cisco press: раз, два, три (русский язык). Это то, что вам совершенно точно понадобится знать.
В следующей части всё будет уже по-взрослому, с видео, мы будем учиться подключаться к оборудованию, разбираться с интерфейсом и расскажем, что делать нерадивому админу, забывшему пароль.


Часть первая (которая после нулевой). Подключение к оборудованию cisco

Тематику cisco на хабре нельзя назвать популярной, зачастую интересные статьи остаются почти незамеченными. Но нас приятно удивил ажиотаж вокруг нашей предыдущей публикации. Больше тысячи человек добавили её в избранное, и это определённо говорит о том, что продолжение необходимо.
Кроме того, много людей, имеющих опыт реального планирования и строительства сетей, делали очень правильные замечания по резервированию. Дело в том, что предложенная в прошлый раз схема сети — это макет, лаборатория, на который мы будем отрабатывать и понимать технологии, поэтому такими вещами мы не озадачивались. В реальной же жизни, особенно, если вы оператор связи/провайдер, необходимы различные схемы резервирования: VRRP, STP, Link Aggregation, протоколы динамической маршрутизации.
Все замечания мы постараемся учесть и в конце цикла, вероятно, рассмотрим то, как сеть должна строиться, чтобы через полгода после запуска инженеру не было мучительно больно.

Сегодня же мы обратимся к части немного скучной, но важной для начинающих: как подключиться, поставить или сбросить пароль, войти по telnet. Также рассмотрим существующие программы — эмуляторы ciscо и интерфейс оборудования.
Как и обещали, в этот раз всё по-взрослому: с видео.

Под катом то же в текстовой и чуть более подробной форме.
Итак, вот они приехали — заветные коробки с надписью Cisco на борту.

Среда

Начнём с того, в какой среде будем работать.

В данный момент есть два известных пакета программ, позволяющих моделировать сеть, построенную на оборудовании Cisco:

а) Цисковский же продукт Packet Tracer, который по идее свободно не распространяется. Это эмулятор и имеет лишь некоторые функции Cisco IOS. Вообще говоря, он сильно ограничен и многие вещи в нём реализованы лишь отчасти. Никаких тонких настроек. С другой стороны к настоящему моменту версия 5.3.2 поддерживает создание GRE-туннелей, протоколов динамической маршрутизации (и в их числе даже BGP!). Притом он очень прост в освоении и имеет в своём арсенале сервера (FTP, TFTP, DHCP, DNS, HTTP, NTP, RADIUS, SMTP, POP3), рабочие станции и свичи. Сейчас уже есть под Linux, хотя в былые времени он прекрасно запускался и из-под Wine.

б) Распространяемый по лицензии GNU GPL симулятор GNS3. В этом пакете необходимо загружать настоящие образы Cisco IOS. С одной стороны это плюс – вы работаете с настоящим интерфейсом cisco и ограничены лишь своей фантазией, существующими стандартами и производительностью рабочей станции, с другой, во-первых, эти IOS ещё нужно суметь достать, во-вторых, это более сложный продукт для понимания, и в-третьих, в нём есть только маршрутизаторы и «типа» коммутаторы.

Я считаю, что для знакомства с принципами лучше начать всё же с Packet Tracer’a, а потом переходить на тяжёлую артиллерию по мере надобности. Все мы не дети малые, где взять то, что нам нужно, рассказывать не будем.

Способы подключения

В Packet Tracer’e управлять оборудованием можно следующими способами:

  • GUI
  • CLI в окне управления
  • Терминальное подключение с рабочей станции через консольный кабель
  • telnet

Интерфейс последних трёх идентичный – отличается лишь способ подключения. Разумеется, GUI – не наш метод.
В реальной же жизни доступны:

  • Telnet/ssh
  • Терминальное подключение с рабочей станции через консольный кабель
  • Web-интерфейс (Cisco SDM).

Последний вариант даже не упоминайте в приличном обществе. Даже если вы адепт мыши и браузера, очень не советую.
На своём примере при работе с другим оборудованием я сталкивался с тем, что настроенное через веб не работает. Хоть ты тресни, но не работает. А у того же длинка вообще был баг в одной версии прошивки для свичей: если изменить настройки VLAN в веб-интерфейсе из под линукс, то свич становится недоступным для управления. Это официально признанная проблема).

Телнет – стандартная, всем известная утилита, как и ssh. Для доступа к cisco по этим протоколам нужно настроить пароли доступа, об этом позже. Возможность использования ssh зависит от лицензии IOS.

Управление по консоли

Ну вот принесли вы маршрутизатор, распечатали, питание на него дали. Он томно зашумел кулерами, подмигивает вам светодиодами своих портов. А чего дальше-то делать?
Воспользуемся один из древнейших и нестареющих способов управления практически любым умным устройством: консоль. Для этого вам нужен компьютер, само устройство и подходящий кабель.
Тут каждый вендор на что горазд. Какие только разъёмы они не используют: RJ-45, DB-9 папа, DB-9 мама, DB-9 с нестандартной распиновкой, DB-25.
У циски используется разъём RJ-45 на стороне устройства и DB-9 мама (для подключения к COM-порту) на стороне ПК.
Консольный порт выглядит так:

Консольный порт cisco

Консольный порт cisco

Всегда выделен голубым цветом. С недавних пор стало возможным управление по USB.
А это консольный кабель cisco:

Консольный кабель cisco

Раньше он поставлялся в каждой коробке, теперь зачастую стоит отдельных денег. В принципе подходит аналогичный кабель от HP.
Проблема в том, что современные ПК зачастую не имеют COM-порта. На выручку приходят частоиспользуемые конвертеры USB-to-COM:

Либо редкоиспользуемые для этих целей конвертеры RS232-Ethernet

После того, как вы воткнули кабель, определили номер COM-порта, для подключения можно использовать Hyperterminal или Putty в Виндоус и Minicom в Линукс.

Управление через консоль доступно сразу, а вот для телнета нужно установить пароль. Как это сделать?
Обратимся к PT.
Начнём с создания маршрутизатора: выбираем его на панели внизу и переносим на рабочее пространство. Даём какое-нибудь название

c2811

Что бы вы делали, если бы это был самый взаправдашний железный маршрутизатор? Взяли бы консольный кабель и подключились им в него и в компьютер. То же самое сделаем и тут:

Packet tracer console

Packet tracer console

Кликом по компьютеру вызываем окно настройки, в котором нас интересует вкладка Desktop. Далее выбираем Terminal, где нам даётся выбор параметров

Впрочем, все параметры по умолчанию нас устраивают, и менять их особо смысла нет.

Если в энергонезависимой памяти устройства отсутствует конфигурационный файл (startup-config), а так оно и будет при первом включении нового железа, нас встретит Initial Configuration Dialog prompt:

cisco interface

Вкратце, это такой визард, позволяющий шаг за шагом настроить основные параметры устройства (hostname, пароли, интерфейсы). Но это неинтересно, поэтому отвечаем no и видим приглашение

Router>

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

Грубо говоря, это режим для сетевого оператора, инженера первой линии техподдержки, чтобы он ничего там не повредил, не напортачил и лишнего не узнал.
Гораздо большие возможности предоставляет режим с говорящим названием привилегированный. Попасть в него можно, введя команду >enable. Теперь приглашение выглядит так:
Router#
Здесь список операций гораздо обширнее, например, можно выполнить одну из наиболее часто используемых команд, демонстрирующую текущие настройки устройства ака “конфиг” #show running-config. В привилегированном режиме вы можете просмотреть всю информацию об устройстве.

Прежде, чем приступать к настройке, упомянем несколько полезностей при работе с cisco CLI, которые могут сильно упростить жизнь:

— Все команды в консоли можно сокращать. Главное, чтобы сокращение однозначно указывало на команду. Например, show running-config сокращается до sh run. Почему не до s r? Потому, что s (в пользовательском режиме) может означать как команду show, так и команду ssh, и мы получим сообщение об ошибке % Ambiguous command: «s r» (неоднозначная команда).

— Используйте клавишу Tab и знак вопроса. По нажатию Tab сокращенная команда дописывается до полной, а знак вопроса, следующий за командой, выводит список дальнейших возможностей и небольшую справку по ним (попробуйте сами в PT).

— Используйте горячие клавиши в консоли:

Ctrl+A — Передвинуть курсор на начало строки
Ctrl+E — Передвинуть курсор на конец строки
Курсорные Up, Down — Перемещение по истории команд
Ctrl+W — Стереть предыдущее слово
Ctrl+U — Стереть всю линию
Ctrl+C — Выход из режима конфигурирования
Ctrl+Z — Применить текущую команду и выйти из режима конфигурирования
Ctrl+Shift+6 — Остановка длительных процессов (так называемый escape sequence)

— Используйте фильтрацию вывода команды. Бывает, что команда выводит много информации, в которой нужно долго копаться, чтобы найти определённое слово, например.
Облегчаем работу с помощью фильтрации: после команды ставим |, пишем вид фильтрации и, собственно, искомое слово(или его часть). Виды фильтрации (ака модификаторы вывода):

begin — вывод всех строк, начиная с той, где нашлось слово,
section — вывод секций конфигурационного файла, в которых встречается слово,
include — вывод строк, где встречается слово,
exclude — вывод строк, где НЕ встречается слово.

Но вернемся к режимам. Третий главный режим, наряду с пользовательским и привилегированным: режим глобальной конфигурации. Как понятно из названия, он позволяет нам вносить изменения в настройки устройства. Активируется командой #configure terminal из привилегированного режима и демонстрирует такое приглашение:
Router(config)#

В режиме глобальной конфигурации не выполняются довольно нужные порой команды других режимов (тот же show running-config, ping, etc.). Но есть такая полезная штука, как do. Благодаря ей мы можем, не выходя из режима конфигурирования, выполнять эти самые команды, просто добавляя перед ними do. Примерно так:
Router(config)#do show running-config

Настройка доступа по Telnet

Из этого-то режима мы и настроим интерфейс для подключения компьютера через telnet:
Команда для перехода в режим конфигурации интерфейса FastEthernet 0/0:
# Router(config)# interface fa0/0
По умолчанию все интерфейсы отключены (состояние administratively down). Включаем интерфейс:
Router(config-if)#no shutdown
Настроим IP-адрес:
Router(config-if)#ip address 192.168.1.1 255.255.255.0

shutdown — означает “выключить интерфейс”. Соответственно, если вы хотите отменить действие команды, то используйте слово no перед ней. Это правило общее для CLI и применимо к большинству команд.

Подключаемся. Для этого надо использовать кроссоверный кабель. (Хотя в реальной жизни это зачастую уже необязательно – все карточки умеют понимать приём/передачу, однако встречаются ещё маршрутизаторы, порты которых не поднимаются при использовании неправильного типа кабеля — так что будьте внимательны)

crossover cable
Настраиваем IP-адрес компьютера через Desktop.

IP адрес

И пробуем подключиться, выбрав Command Prompt в панели Desktop:

Packet Tracer telnet

Как и ожидалось, циска не пускает без пароля. В реальной жизни обычно выдаёт фразу “Password required, but none set”

Пароли

Подключение по telnet или ssh называется виртуальным терминалом (vt) и настраивается следующим образом:

Router(config)#line vty 0 4
Router(config-line)#password cisco
Router(config-line)#login

0 4 — это 5 пользовательских виртуальных терминалов=telnet сессий.
Этого уже достаточно, чтобы попасть в пользовательский режим, но недостаточно для привилегированного:

Packet Tracer telnet

Настроим пароль для enable-режима:

Router(config)#enable secret test

Packet Tracer

Чем отличается secret от password? Примерно тем же, чем ssh от telnet. При настройке secret пароль хранится в зашифрованном виде в конфигурационном файле, а password – в открытом. Поэтому рекомендуется использование secret.
Если вы всё-таки задаёте пароль командой password, то следует применить так же service password-encryption, тогда ваш пароль в конфигурационном файле будет зашифрован:

line vty 0 4
password 7 08255F4A0F0A0111

Один мой знакомый рассказал мне историю:
Стоял он как-то курил возле одного из своих узлов, находящемся в жилом доме. С сумкой для инструментов, ноутбук в руках. Вдруг подходит двое алкашей с пакетом и предлагают купить, раскрывая пакет и показывая какой-то свич. Просят 500 рублей. Ну он купил. По меткам и модели свича парень сделал вывод какому провайдеру он принадлежит. Пришёл домой, начал ковырять — телнет закрыт, консоль запаролена. Слил конфиг по snmp. Пароли в открытом виде хранятся, имя с головой выдаёт провайдера. С их админом он знаком лично, позвонил ему вместо “Здрасьти” выдал логин и пароль в трубку. Слышно было, как скрипел мозг первые секунд 20: везде аксес-листы, авторизация, привязка к мак-адресу. Как?! В общем, всё хорошо, что хорошо кончается.

Немного об этом можно почитать здесь. Ну или чуть более по-русски, тут.

Хотим обратить ваше внимание:
сейчас принятно настраивать доступы не через виртуальные терминалы, а командами #username и #aaa new-model. В версии PT 5.3.2 они уже есть и вполне работают.
Для этого нужно выполнить:

Router(config)#aaa new-model
Router(config)#username admin password 1234

Первая команда служит для активации новой модели ААА (Authentication, Authorization, Accounting). Это нужно для того, чтобы была возможность использовать для аунтетификации на устройстве RADIUS или TACACS сервер. Если отдельно это не настроено, то будет использоваться локальная база пользователей, задаваемая командой username.

Будьте внимательны: приоритет команды aaa new-model выше, чем команд виртуальных терминалов и поэтому даже несмотря на то, что у вас настроен password в режиме line vty, если у вас не будет пользователей в локальной базе, зайти на устройство удалённо уже не получится.

Теперь при подключении маршрутизатор запросит имя пользователя и соответствующий ему пароль.

При более глубокой настройке line vty существует одна опасность.
Есть такой параметр: access-class. Его настройка позволяет ограничить IP-адреса, с которых возможно подключение. И вот однажды я, как умная маша, решил заняться безопасностью в сети и на всём почти оборудование понаставил эти аксес-листы, чтобы комар не пролетел. В один прекрасный момент пришлось выехать в поле и в тот день я проклял свою аккуратность – никуда не мог достучаться – малейшей лазейки не оставил. В общем будьте с этой командой внимательны или оставляйте для себя лазейки.
При работе с access-list’ами и прочими опасными вещами, неправильная настройка которых может лишить вас доступа к устройству, можно использовать замечательную команду reload in min, где min время в минутах. Эта команда перезагрузит устройство по истечении указанного времени, если ее не прервать командой reload cancel. Т.е. схема работы такова: вы удаленно копаете что-то, что может в теории (закон Мерфи не забываем) прервать ваш сеанс связи с устройством. Сохраняем текущий (рабочий) конфиг в startup-config (он используется при загрузке), ставим reload in 15, вводим ключевую команду, относительно которой у нас сомнения ;-), и получаем обрыв связи, худшие опасения оправдались. Ждем 15 минут, устройство перегружается с рабочим конфигом, коннект — вуаля, связь есть. Либо (если связь не прервалась) проверяем, что все работает, и делаем reload cancel.

Если вы хотите ограничить паролем доступ через консольный порт, вам понадобятся команды
Router(config)#line console 0
Router(config-line)#login
Router(config-line)#password cisco

Privilege Level

Ещё один важный момент, которому в статьях уделяют мало внимания: privelege level.
Как понятно из латинского звучания — это уровень прав пользователя. Всего существует 16 уровней: 0-15.
privilege level 0 — это команды disable, enable, exit, help и logout, которые работают во всех режимах
privilege level 1 — Это команды пользовательского режима, то есть как только вы попадаете на циску и увидите приглашение Router> вы имеете уровень 1.
privilege level 15 — Это команды привилегированного режима, вроде, как root в Unix’ах

Пример1

Router(config)#line vty 0 4
Router(config-line)privilege level 15

После входа на маршрутизатор при такой настройке вы сразу увидите Router# со всеми вытекающими правами.

Все уровни со 2 по 14 настраиваются вручную. То есть, например, вы можете дать добро пользователю с privelege level 2 на выполнение команды show running-config

Пример2

Настроить права для конкретного пользователя поможет уже упомянутая прежде команда username

Router(config)#username pooruser privilege 2 secret poorpass
Router(config)#privilege exec level 2 show running-config
Router(config)#enable secret level 2 l2poorpass

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

После этого из пользовательского режима вы можете выполнить команду enable 2 и введя пароль l2poorpass попасть в привилегированный режим, в котором будут доступны все команды уровня 1 + команды уровня 2.

Для чего это может быть нужно? В российских реалиях практически ни для чего, потому что обычно на устройство нужно заходить инженерам сразу с полными правами. Ну разве что 15-й уровень ставят, чтобы двойную аутентификацию не проходить. А все другие уровни опять же для того, чтобы персонал младшего состава (техподдержка, например) мог зайти и промониторить какие-то параметры или настроить некритичную функцию.

SSH

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

Router(config)#hostname R0
Router(config)#ip domain-name cisco-dmn
Router(config)#crypto key generate rsa
Router(config)#line vty 0 4
Router(config-line)#transport input ssh

Имя хоста должно отличаться от Router, обязательно должно быть задано имя домена. Третьей строкой генерируется ключ и далее разрешается только ssh. Длина ключа должна быть более 768 бит, если вы желаете использовать ssh версии 2, а вы желаете этого. Всё.

Ещё одно финальное внимание новичкам: не забывайте о команде write memory — это сохранение текущей конфигурации. Впрочем, достаточно два раза обжечься, забыв сохранить, чтобы навсегда заработать иммунитет к этому — кто кодил по ночам или писал курсовую, тот поймёт.

Используя PT, мы будем настраивать оборудование не через терминал или телнет, а непосредственно через CLI устройства, которое вызывается кликом по иконке роутера — так удобнее:

CLI

Ну и на сладенькое: сброс пароля

Так, а что же делать, если на стол легла вам бушная циска с неизвестным паролем или вы очень невовремя забыли его? Вообще-то это многократно описано и легко гуглится, но повторить это необходимо.
Практически на любом сетевом устройстве есть возможность сбросить пароль, имея физический доступ. Если сделать это невозможно или это отдельная платная услуга, то скорее всего в ваших руках находится какая-то русская поделка (не в обиду, конечно, нашим производителям, но дважды я такие строки читал в документации:))
Итак, cisco:
1) Подключаетесь к устройству консольным кабелем,
2) Отправляете его в ребут (хоть по питанию, хоть командой #reload)
3) Когда на экране побежит такая строчка ########…###, означающая загрузку образа (40-60 секунд после включения), необходимо отправить сигнал Break. Как это сделать в разных программах читать тут. Вы попадаете в режим ROMMON.
4) В этом режиме введите команду: confreg 0x2142, она заставит устройство игнорировать startup-config при загрузке.
5) Введите reset для перезагрузки
6) После загрузки running-config будет девственно чистым, а startup-config содержит по-прежнему последнюю сохранённую конфигурацию. Сейчас самое время поменять пароль или слить конфиг.
7) Самое важное: верните обратно регистры:
Router(config)#config-register 0x2102
Если вы этого не сделаете, то вся ваша конфигурация будет актуальна до первого ребута) И хорошо, если это устройство стоит рядом, и вы вспомните, что накосячили. Мне не повезло)

В следующей статье мы обратимся к вланам и локальной сети. Обязательно к прочтению:
OSI.
VLAN


Сети для самых маленьких. Часть вторая. Коммутация


.После скучного рассказа о подключении к кошкам переходим к настройке сети. В этот раз темы будут для новичков сложные, для старичков избитые. Впрочем сетевым аксакалам едва ли удастся почерпнуть что-то новое из этого цикла. Итак, сегодня:
а) аккуратно впитываем теорию о коммутаторах, уровнях сетевой модели, понятии инкапсуляции и заголовков (не пугайтесь — еще не время),
б) собираем спланированную в нулевой части цикла сеть,
в) настраиваем VLAN’ы, разбираемся с access и trunk-портами и тегированными Ethernet-фреймами,
г) соотносим текущие знания со стеком протоколов TCP/IP и моделью OSI (да, наконец-то мы ее коснёмся).

Перед тем, как вы обратитесь к практике, настоятельно рекомендуем почитать нулевую часть, где мы всё спланировали и запротоколировали.

Теория

Для начала необходимо определится с определениями и детерминировать терминологию. В начале пути с этим могут быть трудности, несмотря на горы википедии и прорву технических статей.
Рассмотрим самые общие термины, поскольку что такое коммутатор и маршрутизатор вы, во-первых, представляете, во-вторых, по ходу не раз ещё их затронем. Итак, тронулись:
СКС — структурированная кабельная система — это определение вы в любом яндексе найдёте. На деле это все провода, розетки, патчпанели и патчкорды, то есть грубо говоря, это физика вашей сети в узком смысле, в широком — это совокупность сетей: ЛВС, телефонные сети, системы видеонаблюдения и прочее. Это отдельный очень большой и порой сложный пласт знаний и технологий, который вообще не имеет точек пересечения с настройкой, поэтому к нему мы более обращаться не будем. Привели мы этот термин по большей части для того, чтобы читатель чувствовал отличие от следующего.
ЛВС = Локальная Вычислительная Сеть = LAN = Local Area Network. Актуальность слова “Вычислительная” сейчас можно поставить под сомнение, так же, как в слове ЭВМ. Всё-таки, говоря о современных сетях и устройствах, мы давно уже не держим в уме термин «вычисления», несмотря на то, что глубинная суть осталась неизменной. В этом плане буржуйские термин более универсален и даёт более простое представление о своём значении.
Итак, локальная сеть — в первом приближении — это сеть вашей организации. Вот, к примеру, обслуживаем мы сейчас сеть компании «Лифт ми Ап» с двумя офисам, так вот сети этих двух офисов и будут являться локальной сетью.
При втором приближении, локальной называют сеть, которая находится под управлением одного сетевого администратора. То есть, например, вы отвечаете за районный сегмент сети провайдера, в таком случае ваша районная сеть со всеми подсетями будет являться локальной, в то время, как вышестоящая сеть и сети других районов уже нет, так как за них отвечает уже другие люди. Вообще говоря, это уже MAN — Metropolian Area Network — сеть уровня города. Но в какой-то степени к ней можно применить понятие LAN и уж тем более VLAN.
С точки зрения меня, как абонента этого провайдера, моя локальная сеть — это всё, что до моего домашнего роутера. Интуитивно, наверно, все понимают о чём идёт речь.
Именно с локальными сетями мы и будем иметь дело в ближайших выпусках.

И последнее, что хотелось бы отметить в связи с ЛВС — это IP-адресация.
Все вы знаете, что когда вы включаете какой-нибудь домашний Wi-Fi-роутер в сеть, он обычно выдаёт вам IP-адрес, вроде 192.168.1.x. Почему именно 192.168 в начале?

Дело в том, что все IP адреса делятся на приватные (private, он же внутренний, “серый”, локальный), и публичные. Публичные используются в интернет, каждый адрес уникален, их распределение контролирует организация IANA(Internet Assigned Numbers Authority).

Приватные используются для адресации хостов (ну, строго говоря, не хостов, а интерфейсов) внутри ЛВС, их распределение никто не контролирует. Для них выделили три диапазона адресов (по одному из каждого класса):

10.0.0.0 — 10.255.255.255
172.16.0.0 — 172.31.255.255
192.168.0.0 — 192.168.255.255

Важный момент касаемо “классов адресов”, об этом уже как-то писали на хабре: классов адресов уже давно не существует. Позже мы обстоятельно поговорим об адресации, но пока рекомендация такая: забыть про существование классов адресов, чтобы не попасть впросак на собеседовании или в разговоре.

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

Если вернуться к нашей старой схеме то вы увидите, что для своей сети мы выбрали приватные адреса из диапазона 172.16.0.0 — 172.31.255.255.
Достаточно подробно об IP-адресах можно почитать тут и тут.
У всех провайдеров и во внутренней сети любой крупной организации используются именно эти серые подсети. Если только вы не государственный ВУЗ, которому в своё время выпала сеть на несколько тысяч публичных адресов: Кемеровский Государственный Университет, к примеру, не озадачивается NAT’ом и прочей чепухой — просто на все компьютеры университетской сети раздаются белые IP.

Широковещательный домен — область сети, в которой происходит обмен широковещательными сообщениями, и устройства могут отправлять друг другу сообщения непосредственно, без участия маршрутизатора.
О чём это мы тут говорим? Ну, например, послал ваш компьютер широковещательный запрос в сеть в поисках DHCP-сервера. Фрейм этот (он же кадр) адресован всем устройствам и имеет MAC-адрес получателя FF:FF:FF:FF:FF:FF. Сначала он попадает на коммутатор, с которого его копии рассылаются на все порты. Потом часть попадает на другие компьютеры, часть уходят в соседние коммутаторы, кто-то доходит до маршрутизатора, а одну копию принимает-таки DHCP-сервер. И вот участок сети, внутри которого могут жить эти кадры и называется широковещательным доменом. А кончают свою жизнь они на конечных хостах (компьютеры, серверы) или на маршрутизаторах, которые их отбрасывают, если они им не предназначены:
Broadcast Example
Если же на коммутаторе заведены VLAN’ы, то они также разделяют широковещательные домены, потому что пакет между ними обязательно должен проходить через маршрутизатор, который отбросит широковещательные сообщения. Таким образом, один VLAN — это один широковещательный домен.
Broadcast with VLANs Example

Ещё раз: у нас есть три способа разграничить широковещательные домены:
1) Поставить маршрутизатор и разнести хосты в разные подсети,
2) Разделить сеть VLAN’ами,
3) Порвать кабель.

Ну и самая жесть, которой часто сторонятся начинающие: OSI. Open System Interconnection. Вообще в двух словах, чтобы мозг не захламить за одно занятие. Эту модель называют эталонной, потому что в реальном мире дело не дошло до реализации. Но она само совершенство, поэтому инженеры и админы вворачивают это слово повсюду.
В основе лежат 7 китов сетевой иерархии: 7 уровней. Сегодня коснёмся двух нижних: первый — физический — это представление информации в виде сигналов, прямо скажем, битов. Задача этого уровня сгенерировать электрический, оптический или радиосигнал, передать его в среду и принять его. К нему относится вся физика: интерфейсы, кабели, антенны, медиаконвертеры (конвертеры среды), репитеры, старые хабы. В общем низкоуровневая это работа. Это первый уровень модели OSI и стека TCP/IP.
Второй — канальный. На этом уровне работают коммутаторы. Идентификатор устройства здесь, это MAC-адрес. У каждого узла (компьютер, маршрутизатор, ноутбук, IP-телефон, любой Wi-Fi-клиент) есть этот уникальный адрес, который однозначно определяет устройство в локальной сети. В теории MAC-адреса не должны повторяться вообще, но на практике такое однако случается и в рамках одного широковещательного домена может приводить к сложноотлавливаемым проблемам.
Наиболее известным протоколом этого уровня является Ethernet. Данные на этом уровне передаются кусками, каждый из которых называется Ethernet-фрейм (он же Ethernet-кадр, он же PDU канального уровня). Что он представляет из себя?

*Картинку гнусно спёрли из википедии, потому что красивее не нарисуем*

Payload — это полезная нагрузка — данные сетевого уровня, которые вкладываются (инкапсулируются) в кадр. MAC Header (Заголовок) — это служебная информация канального (второго) уровня. Самые важные пока для нас элементы — это source MAC-address (адрес отправителя кадра) и Destination MAC-address (адрес получателя кадра).

Третий уровень — сетевой (IP, ARP)
Четвёртый — транспортный (TCP, UDP, ICMP)
С пятого по седьмой — сеансовый, представления и прикладной (в стеке TCP/IP они не различаются и называются просто прикладным. На нём работают протоколы вроде HTTP, FTP, telnet и многие другие)

В английской википедии утверждается, что ICMP относится к 3-му уровню, что является спорным моментом.

Сегодня мы акцентируемся на 1-м и 2-м уровнях, особенно на втором. Третьего и четвертого коснёмся в следующих выпусках.


Теперь проследим нелёгкий путь кадра.
Состояние покоя сети — утопия.

Вы пытаетесь пропинговать, например, адрес соседнего компьютера командой ping 192.168.1.118. Данные этого приложения показаны фиолетовым параллелепипедом.

За это отвечает протокол ICMP. В него инкапсулируется информация от приложения — это означает, что к данным 5-го уровня добавляется заголовок со служебной информацией 4-го уровня.

Его данные упаковываются (инкапсулируются) в IP-пакеты, где в заголовке указан IP-адрес получателя (192.168.1.118) и IP-адрес отправителя — логические адреса.

А затем всё это инкапсулируется в Ethernet-кадры с MAC-адресами отправителя и получателя — физическими адресами.

При формировании кадров в заголовке в качестве MAC-адреса источника (source) подставляется адрес вашего компьютера, а адресом получателя (destinantion) будет MAC-адрес компьютера — владельца IP-адреса 192.168.1.118 (о механизмах такого преобразования поговорим в следующий раз). То есть если бы вы смогли сфотографировать кадр, то вы бы увидели все эти данные в разрезе, так сказать.

На самом деле, нет ничего проще: запускаете какой-нибудь анализатор трафика, например, замечательный Wireshark и Ethereal, на своём компьютере и пингуете другой хост. Вот такую картину вы сможете лицезреть:

Dump

Вы это можете сделать прямо сейчас, читая эти строки, просто установив и запустив анализатор трафика.

В последнюю очередь сетевая карта вашего компьютера дробит фрейм на биты и отправляет их в кабель.

Коммутатор из поступивших битов собирает первоначальный кадр

Далее начинается интеллектуальный труд: из заголовка извлекается адрес получателя, перетрясается таблица MAC-адресов на предмет совпадения и, как только оное найдено, кадр без изменений отправляется в указанный порт. Если же адреса пока ещё нет или кадр пришёл широковещательный, то он направляется на все порты, кроме того, откуда пришёл.

Если адреса отправителя в таблице до сих пор не было, то в этот момент коммутатор добавит его.
Естественно, кадр опять передаётся в виде битов — это закон электроники, и вы должны просто всегда иметь это в виду.

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

Далее он сравнивает MAC-адрес получателя со своим и, если они совпадают, то заголовок второго уровня отбрасывается, а IP-данные передаются на обработку вышестоящему протоколу. Если адреса не совпадают, то кадр отбрасывается вместе со всем содержимым.


Далее сравниваются IP-адрес получателя и этого устройства. Если совпадают, то заголовок сетевого уровня отбрасывается, и данные передаются транспортному уровню (ICMP)

Конечный хост обработал ICMP-запрос (echo-request) и готов послать ICMP-ответ (echo-reply) вашему компьютеру с адресом 192.168.1.131 и далее пункты 1-3 повторяются уже для нового кадра

То, о чём мы писали до сих пор — это принцип работы любого коммутатора. Так делают даже простые длинки за 300 рублей.

VLAN

Ну а теперь, давайте, коллеги, финальный рывок: добавим сюда ещё VLAN’ы.

С ними работают уже только управляемые коммутаторы.
Напомним, что вланы нужны для разделения сетей. Соответственно появляется некий идентификатор, которым маркируется трафик разных подсетей на коммутаторе.
Говоря о VLAN’ах, часто используют заклинание 802.1q. Это и есть стандарт, описывающий как именно кадр маркируется/тегируется. Пугаться такого шифра не стоит. Так же, например, Wi-Fi описывается стандартом 802.11n, а протокол аутентификации — 802.1x. Нам с этим предстоит столкнуться в будущем, поэтому отложите это в своей энергонезависимой памяти.

Что же именно происходит на кухне коммутации?
Внутрь фрейма после Source MAC-адреса добавляется ещё одно поле, очень грубо говоря, содержащее номер VLAN’а. Длина, выделенная для номера влана равна 12 битам, это означает, что максимальное число вланов 4096. Мы хотим обратить внимание молодых инженеров на такие подробности. Дело в том, что мы в своём цикле в силу объективных причин, не можем обо всём рассказать, но такие вопросы, во-первых, часто задают на собеседованиях, во-вторых, это просто надо знать.

Кадр Ethernet с полем 802.1q

Кадры первого влана обычно не тегируются — он является родным вланом (native vlan).

Каждый коммутатор принимает теперь решение на основе этой метки-тега (или его отсутствия).
В таблицу МАС-адресов добавляется ещё столбец с номером VLAN’а и при поиске пары MAC-адрес/порт теперь будет сравниваться тег кадра с номером VLAN’а в таблице.

Существует два типа портов:
1. Access port — порт доступа — к нему подключаются, как правило, конечные узлы. Трафик между этим портом и устройством нетегированный. За каждым access-портом закреплён определённый VLAN, иногда этот параметр называют PVID. Весь трафик, приходящий на этот порт от конечного устройства, получает метку этого влана, а исходящий уходит без метки.

2. Trunk port. У этого порта два основных применения — линия между двумя коммутаторами или от коммутатора к маршрутизатору. Внутри такой линии, называемой в народе, что логично, транком, передаётся трафик нескольких вланов. Разумеется, тут трафик уже идёт с тегами, чтобы принимающая сторона могла отличить кадр, который идёт в бухгалтерию, от кадра, предназначенного для ИТ-отдела. За транковым портом закрепляется целый диапазон вланов.
Кроме того, существует вышеупомянутый native vlan. Трафик этого влана не тегируется даже в транке, по умолчанию это 1-й влан и по умолчанию он разрешён. Вы можете переопределить эти параметры.
Нужен он для совместимости с устройствами, незнакомыми с инкапсуляцией 802.1q. Например, вам нужно через Wi-Fi мост передать 3 влана, и один из них является вланом управления. Если Wi-Fi-модули не понимают стандарт 802.1q, то управлять ими вы сможете, только если этот влан настроите, как native vlan с обеих сторон.

Что происходит в сети с вланами?

1) Итак, от вашего компьютера с IP-адресом, например, 192.168.1.131 отправляется пакет другому компьютеру в вашей же сети. Этот пакет инкапсулируется в кадр, и пока никто ничего не знает о вланах, поэтому кадр уходит, как есть, на ближайший коммутатор.
2) На коммутаторе этот порт отмечен, как член, например, 2-го VLAN’а командой

Switch0#interface fa0/1
Switch0(config)#description “I am using simple frames”
Switch0(config-if)#switchport mode access
Switch0(config-if)#switchport access vlan 2

Это означает, что любой кадр, пришедший на этот интерфейс, автоматический тегируется: на него вешается ленточка с номером VLAN’а. В данном случае с номером 2.
Далее коммутатор ищет в своей таблице MAC-адресов среди портов, принадлежащих 2-му влану, порт, к которму подкдчено устройство с MAC-адресом получателя.
3) Если получатель подключен к такому же access-порту, то ленточка с кадра отвязывается, и кадр отправляется в этот самый порт таким, каким он был изначально. То есть получателю также нет необходимости знать о существовании вланов.
4) Если же искомый порт, является транковым, то ленточка на нём остаётся.

Switch(config)#interface fa0/2
Switch(config-if)#description “I am using tagged frames”
Switch(config-if)#switchport mode trunk

Попробуем провести аналогию с реальными миром. Вы с другом, например, пакеты-туристы и летите отдыхать дикарями самолётом авиалиний Ethernet Airlines. Но по дороге вы поссорились, и потому, когда в аэропорту назначения, вас спрашивают в какую гостиницу вас везти, вы отвечаете “Рога”, а ваш товарищ говорит “Копыта”. И сразу после этого вас инкапсулируют в разные кадры-машины: вас в такси с тегом “Таксопарк “На рогах”, а вашего товарища с его грузом в КамАЗ с тегом “Транспортная компания “В копыто”. Теперь вам нельзя на автобусные полосы, а вашему другу под знаки, запрещающие проезд грузовиков.
Так вот две гостиницы — это МАС-адреса назначения, а ограничения по маршруту — порты других вланов.
Петляя, по улочкам, вам, как IP-пакету не о чем беспокоиться — кадр-автомобиль доставит вас до места назначения, и, грубо говоря, в зависимости от тега на каждом перекрёстке будет приниматься решение, как ехать дальше.

FAQ:

Q: Что произойдёт, если тегированный кадр прилетит на access-порт?
A: Он будет отброшен.

Q: Что произойдёт, если нетегированный кадр прилетит на trunk-порт?
A: Он будет помещён в Native VLAN. По умолчанию им является 1-й VLAN. Но вы можете поменять его командой switchport trunk native vlan 2
В этом случае все кадры, помеченные 2-м вланом будут уходить в этот порт нетегироваными, а нетегированные кадры, приходящий на этот интерфейс, помечаться 2-м вланом.
Кадры с тегами других вланов останутся неизменными, проходя, через такой порт.

Q: Можно ли конечным узлам (компьютерам, ноутбукам, планшетам, телефонам) отправлять тегированные кадры и соответственно подключать их к транковым портам?
A: Да, можно. Если сетевая карта и программное обеспечение поддерживает стандарт 802.1q, то узел может работать с тегированными кадрами.

Q: Что будет с тегированными кадрами, если они попадут на обычный неуправляемый коммутатор или другое устройство, не понимающее стандарт 802.1q?
A: Поскольку при добавлении тега заголовок кадра не меняется, то все устройства второго уровня без поддержки этого стандарта вполне справляются с коммутацией такого кадра. Поэтому, если например, вы захотите организовать канал через Wi-Fi мост, то это никак не помешает вам пробросить через него несколько вланов в транке.

Практика. Настройка сети “Лифт ми Ап”

Ну и наконец-то обратимся к настройке. Вива ля практис!

Будет у нас такая сеть:

Вспомним, как мы её планировали:

Советуем на дополнительной вкладке отрыть их, потому что мы будем обращаться туда периодически.

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

Порты доступа (access)

Поэтому начнём с простого: настроим два порта на msk-arbat-asw3 как access для влана 101 (ПТО):

msk-arbat-asw3(config)#interface FastEthernet0/1
msk-arbat-asw3(config-if)#description PTO
msk-arbat-asw3(config-if)#switchport mode access
msk-arbat-asw3(config-if)#switchport access vlan 101
% Access VLAN does not exist. Creating vlan 101

msk-arbat-asw3(config)#interface FastEthernet0/2
msk-arbat-asw3(config-if)#description PTO
msk-arbat-asw3(config-if)#switchport access vlan 101
msk-arbat-asw3(config-if)switchport mode access

Все настройки делаем сразу в соответствии с планом.

Заметили, что коммутатор ругается на отсутствие влана? Тут надо быть аккуратным. Некоторые версии ПО работают несколько нелогично.
Даже если вы его не создадите, то настройки применятся и при отладке на первый взгляд всё будет нормально, но связи не будет. Причём коварство заключается в том, что фраза Creating vlan 101 вовсе не означает, что этот самый влан будет создан. Поэтому отправляемся в режим глобальной конфигурации и создаём его (а заодно и все другие вланы, нужные на этом коммутаторе):

Switch>enable
Switch#configure terminal
Switch(config)#hostname msk-arbat-dsw1
msk-arbat-dsw1(config)#vlan 2
msk-arbat-dsw1(config-vlan)#name Management
msk-arbat-dsw1(config-vlan)#vlan 3
msk-arbat-dsw1(config-vlan)#name Servers
msk-arbat-dsw1(config-vlan)#vlan 101
msk-arbat-dsw1(config-vlan)#name PTO
msk-arbat-dsw1(config-vlan)#vlan 102
msk-arbat-dsw1(config-vlan)#name FEO
msk-arbat-dsw1(config-vlan)#vlan 103
msk-arbat-dsw1(config-vlan)#name Accounting
msk-arbat-dsw1(config-vlan)#vlan 104
msk-arbat-dsw1(config-vlan)#name Other

Теперь подключите компьютеры к портам FE0/1 и FE0/2, настройте на них адреса 172.16.3.2 и 172.16.3.3 с маской подсети 255.255.255.0 и шлюзом 172.16.3.1 и проверьте связь:

После того, как это получилось, настроим порт FE0/16, как access, для 104-го влана (сеть других пользователей):

msk-arbat-asw3(config)#interface FastEthernet0/16
msk-arbat-asw3(config-if)#description Other
msk-arbat-asw3(config-if)#switchport access vlan 104
msk-arbat-asw3(config-if)switchport mode access

Подключите к нему компьютер и настройте адрес из той же подсети, что ПТО, например, 172.16.3.5 с маской 255.255.255.0.
Если вы попытаетесь теперь пропинговать этот адрес, то у вас не должно этого получиться — компьютеры находятся в разных вланах и изолированы друг от друга:

То есть ещё раз, что происходит? От вашего компьютера приходит на 1-й порт широковещательный запрос: “Кто такой 172.16.3.5”, потому что сам компьютер пока не знает MAC-адреса получателя. Кадр, который несёт в себе этот запрос помечается, как принадлежащий 101-му VLAN’у в соответствии с портом, на который он поступил. И далее, чтобы узнать где-же находится компьютер 172.16.3.5, кадр рассылается на все порты-члены 101-го VLAN’а. А в их числе нет порта FE0/16, поэтому, естественно, этот адрес считается недостижимым, что приводит к ответу “Request timed out”.

Внимание! Если в этом VLAN’е все-таки окажется устройство с таким IP, то это не будет тем же самым ноутбуком Other и при этом они не буду конфликтовать друг с другом, поскольку логически находятся в разных широковещательных доменах.

Транковые порты (trunk)

Итак, врата для вас открылись, теперь вам предстоит создать коридор — транк между тремя коммутаторами: msk-arbat-asw3, msk-arbat-dsw1 и msk-rubl-asw1.

Uplink портом на msk-arbat-asw3 является GE1/1. Ну а поскольку нам всё равно все вланы нужно будет пробросить, то сделаем это сейчас, то есть помимо 101 и 104 пропишем 2, 102 и 103:

msk-arbat-asw3(config)#interface GigabitEthernet1/1
msk-arbat-asw3(config-if)#description msk-arbat-dsw1
msk-arbat-asw3(config-if)#switchport trunk allowed vlan 2,101-104
msk-arbat-asw3(config-if)#switchport mode trunk

На самом деле на интерфейсе достаточно команды #switchport mode trunk, чтобы у вас через этот порт уже пошли тегированные кадры всех вланов, потому что по умолчанию транковый порт пропускает всё. Но мы же инженеры, а не эникейщики. Где это видано, чтобы безлимит творился за нашей спиной? Поэтому через нас проходит только то, что мы разрешаем. Как только вы дали команду switchport trunk allowed vlan 101, через порт не пройдёт кадр никаких вланов, кроме 101 (VLAN 1 ходит по умолчанию и нетегированным).

Внимание! Если вы хотите в транковый порт добавить ещё один влан, то вам необходимо использовать следующий синтаксис команды:

msk-arbat-dsw1(config-if)#switchport trunk allowed vlan add 105

В противном случае (написав switchport trunk allowed vlan 105) вы сотрёте все старые разрешения и добавите новый 105-й влан. И хорошо ещё, если при этом вы не потеряете доступ на этот коммутататор. Но за простой связи всё равно вы получите по пятое число)

Переходим к msk-arbat-dsw1. На нём необходимо создать все вланы и настроить два порта:
GE1/2 в сторону msk-arbat-asw3
FE0/1 в сторону msk-rubl-asw1:

msk-arbat-dsw1(config)#interface GigabitEthernet1/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw3
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104
msk-arbat-dsw1(config-if)#switchport mode trunk

msk-arbat-dsw1(config)#interface FastEthernet0/1
msk-arbat-dsw1(config-if)#description msk-rubl-asw1
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101,104
msk-arbat-dsw1(config-if)#switchport mode trunk

Ну и настроим, конечно, порты на msk-rubl-asw1:

msk-rubl-asw1(config)interface FastEthernet0/24
msk-rubl-asw1(config-if)switchport trunk allowed vlan 2,101,104
msk-rubl-asw1(config-if)switchport mode trunk

msk-rubl-asw1(config)#int FastEthernet0/1
msk-rubl-asw1(config-if)#description PTO
msk-rubl-asw1(config-if)#switchport mode access
msk-rubl-asw1(config-if)#switchport access vlan 101
% Access VLAN does not exist. Creating vlan 101

Снова нужно настроить вланы. И заметьте, при настройке транковых портов никаких сообщений нет.

Если вы всё настроили правильно (в чём не приходится сомневаться), то с первого порта msk-rubl-asw1 вы увидите компьютеры ПТО, подключённые к msk-arbat-asw3.

Для уверенности проверим ещё и 104-й влан. Через транк мы его сюда уже доставили.

msk-rubl-asw1(config)#interface FastEthernet 0/16
msk-rubl-asw1(config-if)#switchport mode access
msk-rubl-asw1(config-if)#switchport access vlan 104

Подключаем компьютер к 16-му порт и настраиваем на нём IP-адрес 172.16.6.3 с маской 255.255.255.0 и шлюзом 172.16.6.1. А IP-адрес ноутбука на арбате поменяйте на 172.16.6.2 с теми же маской и шлюзом.

Сеть управления

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

msk-arbat-dsw1:

msk-arbat-dsw1(config)#interface vlan 2
msk-arbat-dsw1(config-if)#description Management
msk-arbat-dsw1(config-if)#ip address 172.16.1.2 255.255.255.0

msk-arbat-asw3:

msk-arbat-asw3(config)#interface vlan 2
msk-arbat-asw3(config-if)#description Management
msk-arbat-asw3(config-if)#ip address 172.16.1.5 255.255.255.0

С msk-arbat-asw3 запускаем пинг до msk-arbat-dsw1:

msk-arbat-asw3#ping 172.16.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
..!!!
Success rate is 60 percent (3/5), round-trip min/avg/max = 4/4/4 ms

Первые пару пакетов могут потеряться на работу протокола ARP: определение соответствия IP-адрес — MAC-адрес. При этом MAC-адрес, порт и номер влана добавляются в таблицу коммутатора.
Самостоятельно настройте IP-адреса сети управления на остальных коммутаторах и проверьте их доступность

Собственно вот и вся магия. Зачастую к подобного рода действиям и сводится вся настройка, если вы не работаете в провайдере. С другой стороны, если вы работаете в провайдере, то, наверняка, такие вещи вам объяснять не нужно.
Если желаете знать больше об этом, читайте: VTP, QinQ, зарезервированные номера VLAN

Ещё один небольшой инструмент, который может немного увеличить удобство работы: banner. Это объявление, которое циска покажет перед авторизацией на устройство.

Switch(config)#banner motd q
Enter TEXT message. End with the character 'q'.
It is just banner.
q

Switch(config)#

После motd вы указываете символ, который будет служить сигналом о том, что строка закончена. В это примере мы поставили “q”.

Относительно содержания баннера. Существует такая легенда: хакер вломился в сеть, что-то там поломал\украл, его поймали, а на суде оправдали и отпустили. Почему? А потому, что на пограничном роутере(между интернет и внутренней сетью), в banner было написано слово “Welcome”. “Ну раз просят, я и зашел”)). Поэтому считается хорошей практикой в баннере писать что-то вроде “Доступ запрещен!”.

Для упорядочивания знаний по пунктам разберём, что вам необходимо сделать:

1) Настроить hostname. Это поможет вам в будущем на реальной сети быстро сориентироваться, где вы находитесь.
Switch(config)#hostname HOSTNAME

2) Создать все вланы и дать им название
Switch(config)#vlan VLAN-NUMBER
Switch(config-vlan)#name NAME-OF-VLAN

3) Настроить все access-порты и задать им имя
Switch(config-if)#description DESCRIPTION-OF-INTERFACE
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan VLAN-NUMBER

Удобно иногда бывает настраивать интерфейсы пачками:

msk-arbat-asw3(config)#interface range fastEthernet 0/6 — 10
msk-arbat-asw3(config-if-range)#description FEO
msk-arbat-asw3(config-if-range)#switchport mode access
msk-arbat-asw3(config-if-range)#switchport access vlan 102

4) Настроить все транковые порты и задать им имя:
Switch(config-if)#description DESCRIPTION-OF-INTERFACE
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan VLAN-NUMBERS

5) Не забывайте сохраняться:
Switch#copy running-config startup-config

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

Здесь вы можете скачать конфигурацию всех устройств:
Lift-me-Up_Configuration.zip
И наш проект РТ:
Lift-me-UP_v2-VLANs.pkt

P.S.
Важное дополнение: в предыдущей части, говоря о native vlan мы вас немного дезинформировали. На оборудовании cisco такая схема работы невозможна.
Напомним, что нами предлагалось передавать на коммутатор msk-rubl-asw1 нетегированными кадры 101-го влана и принимать их там в первый.
Дело в том, что, как мы уже упомянули выше, с точки зрения cisco с обеих сторон на коммутаторах должен быть настроен одинаковый номер влана, иначе начинаются проблемы с протоколом STP и в логах можно увидеть предупреждения о неверной настройке. Поэтому 101-й влан мы передаём на устройство обычным образом, кадры будут тегированными и соответственно, 101-й влан тоже необходимо создавать на msk-rubl-asw1.

Ещё раз хотим заметить, что при всём желании мы не сможем охватить все нюансы и тонкости, поэтому и не ставим перед собой такой задачи. Такие вещи, как принцип построения MAC-адреса, значения поля Ether Type или для чего нужен CRC в конце кадра, вам предстоит изучить самостоятельно.


Часть 4-я. STP

В прошлом выпуске мы остановились на статической маршрутизации. Теперь надо сделать шаг в сторону и обсудить вопрос стабильности нашей сети.
Однажды, когда вы — единственный сетевой админ фирмы “Лифт ми Ап” — отпросились на полдня раньше, вдруг упала связь с серверами, и директора не получили несколько важных писем. После короткой, но ощутимой взбучки вы идёте разбираться, в чём дело, а оказалось, по чьей-то неосторожности выпал из разъёма единственный кабель, ведущий к коммутатору в серверной. Небольшая проблема, которую вы могли исправить за две минуты, и даже вообще избежать, существенно сказалась на вашем доходе в этом месяце и возможностях роста.

Итак, сегодня обсуждаем:

  • проблему широковещательного шторма
  • работу и настройку протокола STP и его модификаций (RSTP, MSTP, PVST, PVST+)
  • технологию агрегации интерфейсов и перераспределения нагрузки между ними
  • некоторые вопросы стабильности и безопасности
  • как изменить схему существующей сети, чтобы всем было хорошо

Оборудование, работающее на втором уровне модели OSI (коммутатор), должно выполнять 3 функции: запоминание адресов, перенаправление (коммутация) пакетов, защита от петель в сети. Разберем по пунктам каждую функцию.

Запоминание адресов и перенаправление пакетов: Как мы уже говорили ранее, у каждого свича есть таблица сопоставления MAC-адресов и портов (aka CAM-table — Content Addressable Memory Table). Когда устройство, подключенное к свичу, посылает кадр в сеть, свич смотрит MAC-адрес отправителя и порт, откуда получен кадр, и добавляет эту информацию в свою таблицу. Далее он должен передать кадр получателю, адрес которого указан в кадре. По идее, информацию о порте, куда нужно отправить кадр, он берёт из этой же CAM-таблицы. Но, предположим, что свич только что включили (таблица пуста), и он понятия не имеет, в какой из его портов подключен получатель. В этом случае он отправляет полученный кадр во все свои порты, кроме того, откуда он был принят. Все конечные устройства, получив этот кадр, смотрят MAC-адрес получателя, и, если он адресован не им, отбрасывают его. Устройство-получатель отвечает отправителю, а в поле отправителя ставит свой адрес, и вот свич уже знает, что такой-то адрес находится на таком-то порту (вносит запись в таблицу), и в следующий раз уже будет переправлять кадры, адресованные этому устройству, только в этот порт. Чтобы посмотреть содержимое CAM-таблицы, используется команда show mac address-table. Однажды попав в таблицу, информация не остаётся там пожизненно, содержимое постоянно обновляется и если к определенному mac-адресу не обращались 300 секунд (по умолчанию), запись о нем удаляется.
Тут всё должно быть понятно. Но зачем защита от петель? И что это вообще такое?

Широковещательный шторм

Часто, для обеспечения стабильности работы сети в случае проблем со связью между свичами (выход порта из строя, обрыв провода), используют избыточные линки (redundant links) — дополнительные соединения. Идея простая — если между свичами по какой-то причине не работает один линк, используем запасной. Вроде все правильно, но представим себе такую ситуацию: два свича соединены двумя проводами (пусть будет, что у них соединены fa0/1 и fa0/24).

Одной из их подопечных — рабочих станций (например, ПК1) вдруг приспичило послать широковещательный кадр (например, ARP-запрос). Раз широковещательный, шлем во все порты, кроме того, с которого получили.

Второй свич получает кадр в два порта, видит, что он широковещательный, и тоже шлет во все порты, но уже, получается, и обратно в те, с которых получил (кадр из fa0/24 шлет в fa0/1, и наоборот).

Первый свич поступает точно также, и в итоге мы получаем широковещательный шторм (broadcast storm), который намертво блокирует работу сети, ведь свичи теперь только и занимаются тем, что шлют друг другу один и тот же кадр.

Как можно избежать этого? Ведь мы, с одной стороны, не хотим штормов в сети, а с другой, хотим повысить ее отказоустойчивость с помощью избыточных соединений? Тут на помощь нам приходит STP (Spanning Tree Protocol)

STP

Основная задача STP — предотвратить появление петель на втором уровне. Как это сделать? Да просто отрубить все избыточные линки, пока они нам не понадобятся. Тут уже сразу возникает много вопросов: какой линк из двух (или трех-четырех) отрубить? Как определить, что основной линк упал, и пора включать запасной? Как понять, что в сети образовалась петля? Чтобы ответить на эти вопросы, нужно разобраться, как работает STP.

STP использует алгоритм STA (Spanning Tree Algorithm), результатом работы которого является граф в виде дерева (связный и без простых циклов)

Для обмена информацией между собой свичи используют специальные пакеты, так называемые BPDU (Bridge Protocol Data Units). BPDU бывают двух видов:

  • конфигурационные (Configuration BPDU) и
  • панические “ААА, топология поменялась!” TCN (Topology Change Notification BPDU).

Первые регулярно рассылаются корневым свичом (и ретранслируются остальными) и используются для построения топологии, вторые, как понятно из названия, отсылаются в случае изменения топологии сети (проще говоря, подключении\отключении свича). Конфигурационные BPDU содержат несколько полей, остановимся на самых важных:

  • идентификатор отправителя (Bridge ID)
  • идентификатор корневого свича (Root Bridge ID)
  • идентификатор порта, из которого отправлен данный пакет (Port ID)
  • стоимость маршрута до корневого свича (Root Path Cost)

Что все это такое и зачем оно нужно, объясню чуть ниже. Так как устройства не знают и не хотят знать своих соседей, никаких отношений (смежности/соседства) они друг с другом не устанавливают. Они шлют BPDU из всех работающих портов на мультикастовый ethernet-адрес 01-80-c2-00-00-00 (по умолчанию каждые 2 секунды), который прослушивают все свичи с включенным STP.

Итак, как же формируется топология без петель?

Сначала выбирается так называемый корневой мост/свич (root bridge). Это устройство, которое STP считает точкой отсчета, центром сети; все дерево STP сходится к нему. Выбор базируется на таком понятии, как идентификатор свича (Bridge ID). Bridge ID это число длиной 8 байт, которое состоит из

  • Bridge Priority (приоритет, от 0 до 65535, по умолчанию 32768+номер vlan или инстанс MSTP, в зависимости от реализации протокола), и
  • MAC-адреса устройства.

В начале выборов каждый коммутатор считает себя корневым, о чем и заявляет всем остальным с помощью BPDU, в котором представляет свой идентификатор как ID корневого свича. При этом, если он получает BPDU с меньшим Bridge ID, он перестает хвастаться своим и покорно начинает анонсировать полученный Bridge ID в качестве корневого. В итоге, корневым оказывается тот свич, чей Bridge ID меньше всех.

Такой подход таит в себе довольно серьезную проблему. Дело в том, что, при равных значениях Priority (а они равные, если не менять ничего) корневым выбирается самый старый свич, так как мак адреса прописываются на производстве последовательно, соответственно, чем мак меньше, тем устройство старше (естественно, если у нас все оборудование одного вендора). Понятное дело, это ведет к падению производительности сети, так как старое устройство, как правило, имеет худшие характеристики. Подобное поведение протокола следует пресекать, выставляя значение приоритета на желаемом корневом свиче вручную, об этом в практической части.

Роли портов

После того, как коммутаторы померились айдями и выбрали root bridge, каждый из остальных свичей должен найти один, и только один порт, который будет вести к корневому свичу. Такой порт называется корневым портом (Root port). Чтобы понять, какой порт лучше использовать, каждый некорневой свич определяет стоимость маршрута от каждого своего порта до корневого свича. Эта стоимость определяется суммой стоимостей всех линков, которые нужно пройти кадру, чтобы дойти до корневого свича. В свою очередь, стоимость линка определяется просто- по его скорости (чем выше скорость, тем меньше стоимость). Процесс определения стоимости маршрута связан с полем BPDU “Root Path Cost” и происходит так:

  1. Корневой свич посылает BPDU с полем Root Path Cost, равным нулю
  2. Ближайший свич смотрит на скорость своего порта, куда BPDU пришел, и добавляет стоимость согласно таблице
    Скорость порта Стоимость STP (802.1d)
    10 Mbps 100
    100 Mbps 19
    1 Gbps 4
    10 Gbps 2
  3. Далее этот второй свич посылает этот BPDU нижестоящим коммутаторам, но уже с новым значением Root Path Cost, и далее по цепочке вниз

Если имеют место одинаковые стоимости (как в нашем примере с двумя свичами и двумя проводами между ними — у каждого пути будет стоимость 19) — корневым выбирается меньший порт.

Далее выбираются назначенные (Designated) порты. Из каждого конкретного сегмента сети должен существовать только один путь по направлению к корневому свичу, иначе это петля. В данном случае имеем в виду физический сегмент, в современных сетях без хабов это, грубо говоря, просто провод. Назначенным портом выбирается тот, который имеет лучшую стоимость в данном сегменте. У корневого свича все порты — назначенные.

И вот уже после того, как выбраны корневые и назначенные порты, оставшиеся блокируются, таким образом разрывая петлю.


*На картинке маршрутизаторы выступают в качестве коммутаторов. В реальной жизни это можно сделать с помощью дополнительной свитчёвой платы.

Состояния портов

Чуть раньше мы упомянули состояние блокировки порта, теперь поговорим о том, что это значит, и о других возможных состояниях порта в STP. Итак, в обычном (802.1D) STP существует 5 различных состояний:

  • блокировка (blocking): блокированный порт не шлет ничего. Это состояние предназначено, как говорилось выше, для предотвращения петель в сети. Блокированный порт, тем не менее, слушает BPDU (чтобы быть в курсе событий, это позволяет ему, когда надо, разблокироваться и начать работать)
  • прослушивание (listening): порт слушает и начинает сам отправлять BPDU, кадры с данными не отправляет.
  • обучение (learning): порт слушает и отправляет BPDU, а также вносит изменения в CAM- таблицу, но данные не перенаправляет.
  • перенаправление\пересылка (forwarding): этот может все: и посылает\принимает BPDU, и с данными оперирует, и участвует в поддержании таблицы mac-адресов. То есть это обычное состояние рабочего порта.
  • отключен (disabled): состояние administratively down, отключен командой shutdown. Понятное дело, ничего делать не может вообще, пока вручную не включат.

Порядок перечисления состояний не случаен: при включении (а также при втыкании нового провода), все порты на устройстве с STP проходят вышеприведенные состояния именно в таком порядке (за исключением disabled-портов). Возникает закономерный вопрос: а зачем такие сложности? А просто STP осторожничает. Ведь на другом конце провода, который только что воткнули в порт, может быть свич, а это потенциальная петля. Вот поэтому порт сначала 15 секунд (по умолчанию) пребывает в состоянии прослушивания — он смотрит BPDU, попадающие в него, выясняет свое положение в сети — как бы чего ни вышло, потом переходит к обучению еще на 15 секунд — пытается выяснить, какие mac-адреса “в ходу” на линке, и потом, убедившись, что ничего он не поломает, начинает уже свою работу. Итого, мы имеем целых 30 секунд простоя, прежде чем подключенное устройство сможет обмениваться информацией со своими соседями. Современные компы грузятся быстрее, чем за 30 секунд. Вот комп загрузился, уже рвется в сеть, истерит на тему “DHCP-сервер, сволочь, ты будешь айпишник выдавать, или нет?”, и, не получив искомого, обижается и уходит в себя, извлекая из своих недр айпишник автонастройки. Естественно, после таких экзерсисов, в сети его слушать никто не будет, ибо “не местный” со своим 169.254.x.x. Понятно, что все это не дело, но как этого избежать?

Portfast

Для таких случаев используется особый режим порта — portfast. При подключении устройства к такому порту, он, минуя промежуточные стадии, сразу переходит к forwarding-состоянию. Само собой, portfast следует включать только на интерфейсах, ведущих к конечным устройствам (рабочим станциям, серверам, телефонам и т.д.), но не к другим свичам.

Есть очень удобная команда режима конфигурации интерфейса для включения нужных фич на порту, в который будут включаться конечные устройства: switchport host. Эта команда разом включает PortFast, переводит порт в режим access (аналогично switchport mode access), и отключает протокол PAgP (об этом протоколе подробнее в разделе агрегация каналов).

Виды STP

STP довольно старый протокол, он создавался для работы в одном LAN-сегменте. А что делать, если мы хотим внедрить его в нашей сети, которая имеет несколько VLANов?

Стандарт 802.1Q, о котором мы упоминали в статье о коммутации, определяет, каким образом вланы передаются внутри транка. Кроме того, он определяет один процесс STP для всех вланов. BPDU по транкам передаются нетегированными (в native VLAN). Этот вариант STP известен как CST (Common Spanning Tree). Наличие только одного процесса для всех вланов очень облегчает работу по настройке и разгружает процессор свича, но, с другой стороны, CST имеет недостатки: избыточные линки между свичами блокируются во всех вланах, что не всегда приемлемо и не дает возможности использовать их для балансировки нагрузки.

Cisco имеет свой взгляд на STP, и свою проприетарную реализацию протокола — PVST (Per-VLAN Spanning Tree) — которая предназначена для работы в сети с несколькими VLAN. В PVST для каждого влана существует свой процесс STP, что позволяет независимую и гибкую настройку под потребности каждого влана, но самое главное, позволяет использовать балансировку нагрузки за счет того, что конкретный физический линк может быть заблокирован в одном влане, но работать в другом. Минусом этой реализации является, конечно, проприетарность: для функционирования PVST требуется проприетарный же ISL транк между свичами.

Также существует вторая версия этой реализации — PVST+, которая позволяет наладить связь между свичами с CST и PVST, и работает как с ISL- транком, так и с 802.1q. PVST+ это протокол по умолчанию на коммутаторах Cisco.

RSTP

Все, о чем мы говорили ранее в этой статье, относится к первой реализация протокола STP, которая была разработана в 1985 году Радией Перлман (ее стихотворение использовано в качестве эпиграфа). В 1990 году эта реализации была включена в стандарт IEEE 802.1D. Тогда время текло медленнее, и перестройка топологии STP, занимающая 30-50 секунд (!!!), всех устраивала. Но времена меняются, и через десять лет, в 2001 году, IEEE представляет новый стандарт RSTP (он же 802.1w, он же Rapid Spanning Tree Protocol, он же Быстрый STP). Чтобы структурировать предыдущий материал и посмотреть различия между обычным STP (802.1d) и RSTP (802.1w), соберем таблицу с основными фактами:

STP (802.1d) RSTP (802.1w)
В уже сложившейся топологии только корневой свич шлет BPDU, остальные ретранслируют Все свичи шлют BPDU в соответствии с hello-таймером (2 секунды по умолчанию)
Состояния портов
— блокировка (blocking)
— прослушивание (listening)
— обучение (learning)
— перенаправление\пересылка (forwarding)
— отключен (disabled)
— отбрасывание (discarding), заменяет disabled, blocking и listening
— learning
— forwarding
Роли портов
— корневой (root), участвует в пересылке данных, ведет к корневому свичу
— назначенный (designated), тоже работает, ведет от корневого свича
— неназначенный (non-designated), не участвует в пересылке данных
— корневой (root), участвует в пересылке данных
— назначенный (designated), тоже работает
— дополнительный (alternate), не участвует в пересылке данных
— резервный (backup), тоже не участвует
Механизмы работы
Использует таймеры:
Hello (2 секунды)
Max Age (20 секунд)
Forward delay timer (15 секунд)
Использует процесс proposal and agreement (предложение и соглашение)
Свич, обнаруживший изменение топологии, извещает корневой свич, который, в свою очередь, требует от всех остальных очистить их записи о текущей топологии в течение forward delay timer Обнаружение изменений в топологии влечет немедленную очистку записей
Если не-корневой свич не получает hello- пакеты от корневого в течение Max Age, он начинает новые выборы Начинает действовать, если не получает BPDU в течение 3 hello-интервалов
Последовательное прохождение порта через состояния Blocking (20 сек) — Listening (15 сек) — Learning (15 сек) — Forwarding Быстрый переход к Forwarding для p2p и Edge-портов

Как мы видим, в RSTP остались такие роли портов, как корневой и назначенный, а роль заблокированного разделили на две новых роли: Alternate и Backup. Alternate — это резервный корневой порт, а backup — резервный назначенный порт. Как раз в этой концепции резервных портов и кроется одна из причин быстрого переключения в случае отказа. Это меняет поведение системы в целом: вместо реактивной (которая начинает искать решение проблемы только после того, как она случилась) система становится проактивной, заранее просчитывающей “пути отхода” еще до появления проблемы. Смысл простой: для того, чтобы в случае отказа основного переключится на резервный линк, RSTP не нужно заново просчитывать топологию, он просто переключится на запасной, заранее просчитанный.

Ранее, для того, чтобы убедиться, что порт может участвовать в передаче данных, требовались таймеры, т.е. свич пассивно ждал в течение означенного времени, слушая BPDU. Ключевой фичей RSTP стало введение концепции типов портов, основанных на режиме работы линка- full duplex или half duplex (типы портов p2p или shared, соответственно), а также понятия пограничный порт (тип edge p2p), для конечных устройств. Пограничные порты назначаются, как и раньше, командой spanning-tree portfast, и с ними все понятно- при включении провода сразу переходим к forwarding-состоянию и работаем. Shared-порты работают по старой схеме с прохождением через состояния BLK — LIS — LRN — FWD. А вот на p2p-портах RSTP использует процесс предложения и соглашения (proposal and agreement). Не вдаваясь в подробности, его можно описать так: свич справедливо считает, что если линк работает в режиме полного дуплекса, и он не обозначен, как пограничный, значит, на нем только два устройства- он и другой свич. Вместо того, чтобы ждать входящих BPDU, он сам пытается связаться со свичом на том конце провода с помощью специальных proposal BPDU, в которых, конечно, есть информация о стоимости маршрута к корневому свичу. Второй свич сравнивает полученную информацию со своей текущей, и принимает решение, о чем извещает первый свич посредством agreement BPDU. Так как весь этот процесс теперь не привязан к таймерам, происходит он очень быстро- только подключили новый свич- и он практически сразу вписался в общую топологию и приступил к работе (можете сами оценить скорость переключения в сравнении с обычным STP на видео). В Cisco-мире RSTP называется PVRST (Per-Vlan Rapid Spanning Tree).

MSTP

Чуть выше, мы упоминали о PVST, в котором для каждого влана существует свой процесс STP. Вланы это довольно удобный инструмент для многих целей, и поэтому, их может быть достаточно много даже в некрупной организации. И в случае PVST, для каждого будет рассчитываться своя топология, тратиться процессорное время и память свичей. А нужно ли нам рассчитывать STP для всех 500 вланов, когда единственное место, где он нам нужен- это резервный линк между двумя свичами? Тут нас выручает MSTP. В нем каждый влан не обязан иметь собственный процесс STP, их можно объединять. Вот у нас есть, например, 500 вланов, и мы хотим балансировать нагрузку так, чтобы половина из них работала по одному линку (второй при этом блокируется и стоит в резерве), а вторая- по другому. Это можно сделать с помощью обычного STP, назначив один корневой свич в диапазоне вланов 1-250, а другой- в диапазоне 250-500. Но процессы будут работать для каждого из пятисот вланов по отдельности (хотя действовать будут совершенно одинаково для каждой половины). Логично, что тут хватит и двух процессов. MSTP позволяет создавать столько процесов STP, сколько у нас логических топологий (в данном примере- 2), и распределять по ним вланы. Думаем, нет особого смысла углубляться в теорию и практику MSTP в рамках этой статьи (ибо теории там ого-го), интересующиеся могут пройти по ссылке.

Агрегация каналов

Но какой бы вариант STP мы не использовали, у нас все равно существует так или иначе неработающий линк. А возможно ли задействовать параллельные линки по полной и при этом избежать петель? Да, отвечаем мы вместе с циской, начиная рассказ о EtherChannel.

Иначе это называется link aggregation, link bundling, NIC teaming, port trunkinkg
Технологии агрегации (объединения) каналов выполняют 2 функции: с одной стороны, это объединение пропускной способности нескольких физических линков, а с другой — обеспечение отказоустойчивости соединения (в случае падения одного линка нагрузка переносится на оставшиеся). Объединение линков можно выполнить как вручную (статическое агрегирование), так и с помощью специальных протоколов: LACP (Link Aggregation Control Protocol) и PAgP (Port Aggregation Protocol). LACP, опеределяемый стандартом IEEE 802.3ad, является открытым стандартом, то есть от вендора оборудования не зависит. Соответственно, PAgP — проприетарная цисковская разработка.
В один такой канал можно объединить до восьми портов. Алгоритм балансировки нагрузки основан на таких параметрах, как IP/MAC-адреса получателей и отправителей и порты. Поэтому в случае возникновения вопроса: “Хей, а чего так плохо балансируется?” в первую очередь смотрите на алгоритм балансировки.

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

Port security

Теперь расскажем вкратце, как обеспечить безопасность сети на втором уровне OSI. В этой части статьи теория и практическая конфигурация совмещены. Увы, Packet Tracer не умеет ничего из упомянутых в этом разделе команд, поэтому все без иллюстраций и проверок.

Для начала, следует упомянуть команду конфигурации интерфейса switchport port-security, включающую защиту на определенном порту свича. Затем, с помощью switchport port-security maximum 1 мы можем ограничить количество mac-адресов, связанных с данным портом (т.е., в нашем примере, на данном порту может работать только один mac-адрес). Теперь указываем, какой именно адрес разрешен: его можно задать вручную switchport port-security mac-address адрес, или использовать волшебную команду switchport port-security mac-address sticky, закрепляющую за портом тот адрес, который в данный момент работает на порту. Далее, задаем поведение в случае нарушения правила switchport port-security violation {shutdown | restrict | protect}: порт либо отключается, и потом его нужно поднимать вручную (shutdown), либо отбрасывает пакеты с незарегистрированного мака и пишет об этом в консоль (restrict), либо просто отбрасывает пакеты (protect).

Помимо очевидной цели — ограничение числа устройств за портом — у этой команды есть другая, возможно, более важная: предотвращать атаки. Одна из возможных — истощение CAM-таблицы. С компьютера злодея рассылается огромное число кадров, возможно, широковещательных, с различными значениями в поле MAC-адрес отправителя. Первый же коммутатор на пути начинает их запоминать. Одну тысячу он запомнит, две, но память-то оперативная не резиновая, и среднее ограничение в 16000 записей будет довольно быстро достигнуто. При этом дальнейшее поведение коммутатора может быть различным. И самое опасное из них с точки зрения безопасности: коммутатор может начать все кадры, приходящие на него, рассылать, как широковещательные, потому что MAC-адрес получателя не известен (или уже забыт), а запомнить его уже просто некуда. В этом случае сетевая карта злодея будет получать все кадры, летающие в вашей сети.

DHCP Snooping

Другая возможная атака нацелена на DHCP сервер. Как мы знаем, DHCP обеспечивает клиентские устройства всей нужной информацией для работы в сети: ip-адресом, маской подсети, адресом шюза по умолчанию, DNS-сервера и прочим. Атакующий может поднять собственный DHCP, который в ответ на запрос клиентского устройства будет отдавать в качестве шлюза по умолчанию (а также, например, DNS-сервера) адрес подконтрольной атакующему машины. Соответственно, весь трафик, направленный за пределы подсети обманутыми устройствами, будет доступен для изучения атакующему — типичная man-in-the-middle атака. Либо такой вариант: подлый мошенник генерируют кучу DHCP-запросов с поддельными MAC-адресами и DHCP-сервер на каждый такой запрос выдаёт IP-адрес до тех пор, пока не истощится пул.

Для того, чтобы защититься от подобного вида атак, используется фича под названием DHCP snooping. Идея совсем простая: указать свичу, на каком порту подключен настоящий DHCP-сервер, и разрешить DHCP-ответы только с этого порта, запретив для остальных. Включаем глобально командой ip dhcp snooping, потом говорим, в каких вланах должно работать ip dhcp snooping vlan номер(а). Затем на конкретном порту говорим, что он может пренаправлять DHCP-ответы (такой порт называется доверенным): ip dhcp snooping trust.

IP Source Guard

После включения DHCP Snooping’а, он начинает вести у себя базу соответствия MAC и IP-адресов устройств, которую обновляет и пополняет за счет прослушивания DHCP запросов и ответов. Эта база позволяет нам противостоять еще одному виду атак — подмене IP-адреса (IP Spoofing). При включенном IP Source Guard, каждый приходящий пакет может проверяться на:

  • соответствие IP-адреса источника адресу, полученному из базы DHCP Snooping (иными словами, айпишник закрепляется за портом свича)
  • соответствие MAC-адреса источника адресу, полученному из базы DHCP Snooping

Включается IP Source Guard командой ip verify source на нужном интерфейсе. В таком виде проверяется только привязка IP-адреса, чтобы добавить проверку MAC, используем ip verify source port-security. Само собой, для работы IP Source Guard требуется включенный DHCP snooping, а для контроля MAC-адресов должен быть включен port security.

Dynamic ARP Inspection

Как мы уже знаем, для того, чтобы узнать MAC-адрес устройства по его IP-адресу, используется проткол ARP: посылается широковещательный запрос вида “у кого ip-адрес 172.16.1.15, ответьте 172.16.1.1”, устройство с айпишником 172.16.1.15 отвечает. Подобная схема уязвима для атаки, называемой ARP-poisoning aka ARP-spoofing: вместо настоящего хоста с адресом 172.16.1.15 отвечает хост злоумышленника, заставляя таким образом трафик, предназначенный для 172.16.1.15 следовать через него. Для предотвращения такого типа атак используется фича под названием Dynamic ARP Inspection. Схема работы похожа на схему DHCP-Snooping’а: порты делятся на доверенные и недоверенные, на недоверенных каждый ARP-ответ подвергаются анализу: сверяется информация, содержащаяся в этом пакете, с той, которой свич доверяет (либо статически заданные соответствия MAC-IP, либо информация из базы DHCP Snooping). Если не сходится- пакет отбрасывается и генерируется сообщение в syslog. Включаем в нужном влане (вланах): ip arp inspection vlan номер(а). По умолчанию все порты недоверенные, для доверенных портов используем ip arp inspection trust.

Практика

Наверное, большинство ошибок в Packet Tracer допущено в части кода, отвечающего за симуляцию STP, будте готовы. В случае сомнения сохранитесь, закройте PT и откройте заново

Итак, переходим к практике. Для начала внесем некоторые изменения в топологию — добавим избыточные линки. Учитывая сказанное в самом начале, вполне логично было бы сделать это в московском офисе в районе серверов — там у нас свич msk-arbat-asw2 доступен только через asw1, что не есть гуд. Мы отбираем (пока, позже возместим эту потерю) гигабитный линк, который идет от msk-arbat-dsw1 к msk-arbat-asw3, и подключаем через него asw2. Asw3 пока подключаем в порт Fa0/2 dsw1. Перенастраиваем транки:

msk-arbat-dsw1(config)#interface gi1/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw2
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-dsw1(config-if)#int fa0/2
msk-arbat-dsw1(config-if)#description msk-arbat-asw3
msk-arbat-dsw1(config-if)#switchport mode trunk
msk-arbat-dsw1(config-if)#switchport trunk allowed vlan 2,101-104

msk-arbat-asw2(config)#int gi1/2
msk-arbat-asw2(config-if)#description msk-arbat-dsw1
msk-arbat-asw2(config-if)#switchport mode trunk
msk-arbat-asw2(config-if)#switchport trunk allowed vlan 2,3
msk-arbat-asw2(config-if)#no shutdown

Не забываем вносить все изменения в документацию!

Скачать актуальную версию документа.

Теперь посмотрим, как в данный момент у нас самонастроился STP. Нас интересует только VLAN0003, где у нас, судя по схеме, петля.

msk-arbat-dsw1>en
msk-arbat-dsw1#show spanning-tree vlan 3

Разбираем по полочкам вывод команды

Итак, какую информацию мы можем получить? Так как по умолчанию на современных цисках работает PVST+ (т.е. для каждого влана свой процесс STP), и у нас есть более одного влана, выводится информация по каждому влану в отдельности, каждая запись предваряется номером влана. Затем идет вид STP: ieee значит PVST, rstp — Rapid PVST, mstp то и значит. Затем идет секция с информацией о корневом свиче: установленный на нем приоритет, его mac-адрес, стоимость пути от текущего свича до корневого, порт, который был выбран в качестве корневого (имеет лучшую стоимость), а также настройки таймеров STP. Далее- секция с той же информацией о текущем свиче (с которого выполняли команду). Затем- таблица состояния портов, которая состоит из следующих колонок (слева направо):

  • собственно, порт
  • его роль (Root- корневой порт, Desg- назначенный порт, Altn- дополнительный, Back- резервный)
  • его статус (FWD- работает, BLK- заблокирован, LIS- прослушивание, LRN- обучение)
  • стоимость маршрута до корневого свича
  • Port ID в формате: приоритет порта.номер порта
  • тип соединения

Итак, мы видим, что Gi1/1 корневой порт, это дает некоторую вероятность того, что на другом конце линка корневой свич. Смотрим по схеме, куда ведет линк: ага, некий msk-arbat-asw1.

msk-arbat-asw1#show spanning-tree vlan 3

И что же мы видим?

VLAN0003
 Spanning tree enabled protocol ieee
 Root ID    Priority    32771
            Address     0007.ECC4.09E2
            This bridge is the root
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

Вот он, наш корневой свич для VLAN0003.

А теперь посмотрим на схему. Ранее, мы увидели в состоянии портов, что dsw1 блокирует порт Gi1/2, разрывая таким образом петлю. Но является ли это оптимальным решением? Нет, конечно. Сейчас наша новая сеть работает точь-в-точь как старая- трафик от asw2 идет только через asw1. Выбор корневого маршрутизатора никогда не нужно оставлять на совесть глупого STP. Исходя из схемы, наиболее оптимальным будет выбор в качестве корневого свича dsw1- таким образом, STP заблокирует линк между asw1 и asw2. Теперь это все надо объяснить недалекому протоколу. А для него главное что? Bridge ID. И он неслучайно складывается из двух чисел. Приоритет- это как раз то слагаемое, которое отдано на откуп сетевому инженеру, чтобы он мог повлиять на результат выбора корневого свича. Итак, наша задача сводится к тому, чтобы уменьшить (меньше-лучше, думает STP) приоритет нужного свича, чтобы он стал Root Bridge. Есть два пути:

1) вручную установить приоритет, заведомо меньший, чем текущий:

msk-arbat-dsw1>enable
msk-arbat-dsw1#configure terminal
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority?
<0-61440> bridge priority in increments of 4096
msk-arbat-dsw1(config)#spanning-tree vlan 3 priority 4096

Теперь он стал корневым для влана 3, так как имеет меньший Bridge ID:

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 4099
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

2) дать умной железке решить все за тебя:

msk-arbat-dsw1(config)#spanning-tree vlan 3 root primary

Проверяем:

msk-arbat-dsw1#show spanning-tree vlan 3
VLAN0003
Spanning tree enabled protocol ieee
Root ID Priority 24579
Address 000B.BE2E.392C
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Мы видим, что железка поставила какой-то странный приоритет. Откуда взялась эта круглая цифра, спросите вы? А все просто- STP смотрит минимальный приоритет (т.е. тот, который у корневого свича), и уменьшает его на два шага инкремента (который составляет 4096, т.е. в итоге 8192). Почему на два? А чтобы была возможность на другом свиче дать команду spanning-tree vlan n root secondary (назначает приоритет=приоритет корневого-4096), что позволит нам быть уверенными, что, если с текущим корневым свичом что-то произойдет, его функции перейдут к этому, “запасному”. Вероятно, вы уже видите на схеме, как лампочка на линке между asw2 и asw1 пожелтела? Это STP разорвал петлю. Причем именно в том месте, в котором мы хотели. Sweet! Зайдем проверим: лампочка — это лампочка, а конфиг — это факт.

msk-arbat-asw2#show spanning-tree vlan 3
VLAN0003
 Spanning tree enabled protocol ieee
 Root ID    Priority    24579
            Address     000B.BE2E.392C
            Cost        4
            Port        26(GigabitEthernet1/2)
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

 Bridge ID  Priority    32771  (priority 32768 sys-id-ext 3)
            Address     000A.F385.D799
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
            Aging Time  20

Interface        Role    Sts    Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa0/1            Desg    FWD    19        128.1    P2p
Gi1/1            Altn    BLK    4         128.25   P2p
Gi1/2            Root    FWD    4         128.26   P2p

Теперь полюбуемся, как работает STP: заходим в командную строку на ноутбуке PTO1 и начинаем бесконечно пинговать наш почтовый сервер (172.16.0.4). Пинг сейчас идет по маршруту ноутбук-asw3-dsw1-gw1-dsw1(ну тут понятно, зачем он крюк делает — они из разных вланов)-asw2-сервер. А теперь поработаем Годзиллой из SimСity: нарушим связь между dsw1 и asw2, вырвав провод из порта (замечаем время, нужное для пересчета дерева).

Пинги пропадают, STP берется за дело, и за каких-то 30 секунд коннект восстанавливается. Годзиллу прогнали, пожары потушили, связь починили, втыкаем провод обратно. Пинги опять пропадают на 30 секунд! Мда-а-а, как-то не очень быстро, особенно если представить, что это происходит, например, в процессинговом центре какого-нибудь банка.

Но у нас есть ответ медленному PVST+! И ответ этот — Быстрый PVST+ (так и называется, это не шутка: Rapid-PVST). Посмотрим, что он нам дает. Меняем тип STP на всех свичах в москве командой конфигурационного режима: spanning-tree mode rapid-pvst

Снова запускаем пинг, вызываем Годзиллу… Эй, где пропавшие пинги? Их нет, это же Rapid-PVST. Как вы, наверное, помните из теоретической части, эта реализация STP, так сказать, “подстилает соломку” на случай падения основного линка, и переключается на дополнительный (alternate) порт очень быстро, что мы и наблюдали. Ладно, втыкаем провод обратно. Один потерянный пинг. Неплохо по сравнению с 6-8, да?

EtherChannel

Помните, мы отобрали у офисных работников их гигабитный линк и отдали его в пользу серверов? Сейчас они, бедняжки, сидят, на каких-то ста мегабитах, прошлый век! Попробуем расширить канал, и на помощь призовем EtherChannel. В данный момент у нас соединение идет от fa0/2 dsw1 на Gi1/1 asw3, отключаем провод. Смотрим, какие порты можем использовать на asw3: ага, fa0/20-24 свободны, кажется. Вот их и возьмем. Со стороны dsw1 пусть будут fa0/19-23. Соединяем порты для EtherChannel между собой. На asw3 у нас на интерфейсах что-то настроено, обычно в таких случаях используется команда конфигурационного режима default interface range fa0/20-24, сбрасывающая настройки порта (или портов, как в нашем случае) в дефолтные. Packet tracer, увы, не знает такой хорошей команды, поэтому в ручном режиме убираем каждую настройку, и тушим порты (лучше это сделать, во избежание проблем)

msk-arbat-asw3(config)#interface range fa0/20-24
msk-arbat-asw3(config-if-range)#no description
msk-arbat-asw3(config-if-range)#no switchport access vlan
msk-arbat-asw3(config-if-range)#no switchport mode
msk-arbat-asw3(config-if-range)#shutdown

ну а теперь волшебная команда

msk-arbat-asw3(config-if-range)#channel-group 1 mode on

то же самое на dsw1:

msk-arbat-dsw1(config)#interface range fa0/19-23
msk-arbat-dsw1(config-if-range)#channel-group 1 mode on

поднимаем интерфейсы asw3, и вуаля: вот он, наш EtherChannel, раскинулся аж на 5 физических линков. В конфиге он будет отражен как interface Port-channel 1. Настраиваем транк (повторить для dsw1):

msk-arbat-asw3(config)#int port-channel 1
msk-arbat-asw3(config-if)#switchport mode trunk
msk-arbat-asw3(config-if)#switchport trunk allowed vlan 2,101-104

Как и с STP, есть некая трудность при работе с etherchannel в Packet Tracer’e. Настроить-то мы, в принципе, можем по вышеописанному сценарию, но вот проверка работоспособности под большим вопросом: после отключения одного из портов в группе, трафик перетекает на следующий, но как только вы вырубаете второй порт — связь теряется и не восстанавливается даже после включения портов.

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

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

Новый план коммутации
Файл PT с лабораторной.
Конфигурация устройств
STP или STP
Безопасность канального уровня
Агрегация каналов

По сложившейся традиции все неотвеченные вопросы безымянными читателями хабра задаются в блоге цикла в ЖЖ.


Комментарии:
CBT Nuggets. Jeremy Cioara — парень который ведёт все курсы циски у них. Cisco,  курс ICND
IA/EIA-568, очень толковый стандарт


Часть третья. Статическая маршрутизация

Итак, поворотный момент в истории компании “Лифт ми Ап”. Руководство понимает, что компания, производящая лифты, едущие только вверх, не выдержит борьбы на высококонкурентном рынке. Необходимо расширять бизнес. Принято решение о покупке двух заводов: в Санкт-Петербурге и Кемерово.
Нужно срочно организовывать связь до новых офисов, а у вас ещё даже локалка не заработала.
Сегодня:
1. Настраиваем маршрутизацию между вланами в нашей сети (InterVlan routing)
2. Пытаемся разобраться с процессами, происходящими в сети, и что творится с данными.
3. Планируем расширение сети (IP-адреса, вланы, таблицы коммутации)
4. Настраиваем статическую маршрутизацию и разбираемся, как она работает.
5. Используем L3-коммутатор в качестве шлюза

Содержание:

InterVlan Routing

Чуточку практики для взбадривания.
В предыдущий раз мы настроили коммутаторы нашей локальной сети. На данный момент устройства разных вланов не видят друг друга. То есть фактически ФЭО и ПТО, например, находятся в совершенно разных сетях и не связаны друг с другом. Так же и серверная сеть существует сама по себе. Надо бы исправить эту досадную неприятность.
В нашей московской сети для маршрутизации между вланами мы будем использовать роутер cisco 2811. Иными словами он будет терминировать вланы. Кадры здесь заканчивают свою жизнь: из них извлекаются IP-пакеты, а заголовки канального уровня отбрасываются.

Процесс настройки маршрутизатора очень прост:

0) Сначала закончим с коммутатором msk-arbat-dsw1. На нём нам нужно настроить транковый порт в сторону маршрутизатора, чего мы не сделали в прошлый раз.

msk-arbat-dsw1(config)#interface FastEthernet0/24
msk-arbat-dsw1(config-if)# description msk-arbat-gw1
msk-arbat-dsw1(config-if)# switchport trunk allowed vlan 2-3,101-104
msk-arbat-dsw1(config-if)# switchport mode trunk

1) Назначаем имя маршрутизатора командой hostname, а для развития хорошего тона, надо упомянуть, что лучше сразу же настроить время на устройстве. Это поможет вам корректно идентифицировать записи в логах.

Router0#clock set 12:34:56 7 august 2012
Router0# conf t
Router0(config)#hostname msk-arbat-gw1

Желательно время на сетевые устройства раздавать через NTP (любую циску можно сделать NTP-сервером, кстати)

2) Далее переходим в режим настройки интерфейса, обращённого в нашу локальную сеть и включаем его, так как по умолчанию он находится в состоянии Administratively down.

msk-arbat-gw1(config)#interface fastEthernet 0/0
msk-arbat-gw1(config-if)#no shutdown

3) Создадим виртуальный интерфейс или иначе его называют подинтерфейс или ещё сабинтерфейс (sub-interface).

msk-arbat-gw1(config)#interface fa0/0.2
msk-arbat-gw1(config-if)#description Management

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

4) Теперь вспомним о стандарте 802.1q, который описывает тегирование кадра меткой влана. Следующей командой вы обозначаете, что кадры, исходящие из этого виртуального интерфейса будут помечены тегом 2-го влана. А кадры, входящие на физический интерфейс FastEthernet0/0 с тегом этого влана будут приняты виртуальным интерфейсом FastEthernet0/0.2.

msk-arbat-gw1(config-if)#encapsulation dot1Q 2

5) Ну и как на обычном физическом L3-интерфейсе, определим IP-адрес. Этот адрес будет шлюзом по умолчанию (default gateway) для всех устройств в этом влане.

msk-arbat-gw1(config-if)#ip address 172.16.1.1 255.255.255.0

Аналогичным образом настроим, например, 101-й влан:

msk-arbat-gw1(config)#interface FastEthernet0/0.101
msk-arbat-gw1(config-if)#description PTO
msk-arbat-gw1(config-if)#encapsulation dot1Q 101
msk-arbat-gw1(config-if)#ip address 172.16.3.1 255.255.255.0

и теперь убедимся, что с компьютера из сети ПТО мы видим сеть управления:

Работает и отлично, настройте пока все остальные интерфейсы. Проблем с этим возникнуть не должно.

Физика и логика процесса межвланной маршрутизации

Что происходит в это время с вашими данными?

Мы рассуждали в прошлый раз, что происходит, если вы пытаетесь связаться с устройством из той же самой подсети, в которой находитесь вы.
Под той же самой подсетью мы понимаем следующее.
Например, на вашем компьютере настроено следующее:
IP: 172.16.3.2
Mask: 255.255.255.0
GW: 172.16.3.1

Все устройства, адреса которых будут находиться в диапазоне 172.16.3.1-172.16.3.254 с такой же маской, как у вас будут являться членами вашей подсети. Что происходит с данными, если вы отправляет их на устройство с адресом из этого диапазона?
Повторим это с некоторыми дополнениями.
Для отправки данных они должны быть упакованы в Ethernet-кадр, в заголовок которого должен быть вставлен MAC-адрес удалённого устройства. Но откуда его взять?
Для этого ваш компьютер рассылает широковещательный ARP-запрос. В качестве IP-адреса узла назначения в IP-пакет с этим запросом будет помещён адрес искомого хоста. Сетевая карта при инкапсуляции указывает MAC-адрес FF:FF:FF:FF:FF:FF — это значит, что кадр предназначен всем устройствам. Далее он уходит на ближайший коммутатор и копии рассылаются на все порты нашего влана (ну, кроме, конечно, порта, из которого получен кадр). Получатели видят, что запрос широковещательный и они могут оказаться искомым хостом, поэтому извлекают данные из кадра. Все те устройства, которые не обладают указанным в ARP-запросе IP-адресом, просто игнорируют запрос, а вот устройство-настоящий получатель ответит на него и вышлет первоначальному отправителю свой MAC-адрес. Отправитель (в данном случае, наш компьютер) помещает полученный MAC в свою таблицу соответствия IP и MAC адресов ака ARP-кэш. Как выглядит ARP-кэш на вашем компьютере прямо сейчас, вы можете посмотреть с помощью команды arp -a

Потом ваши полезные данные упаковываются в IP-пакет, где в качестве получателя ставится тот адрес, который вы указали в команде/приложении, затем в Ethernet-кадр, в заголовок которого помещается полученный ARP-запросом MAC-адрес. Далее кадр отправляется на коммутатор, который согласно своей таблице MAC-адресов, решает, в какой порт его переправить дальше.

Но что происходит, если вы пытаетесь достучаться до устройства в другом влане? ARP-запрос ничего не вернёт, потому что широковещательные L2 сообщения кончаются на маршрутизаторе(т.е., в пределах широковещательного L2 домена), нужная сеть находится за ним, а коммутатор не пустит кадры из одного влана в порт другого. И вот для этого нужен шлюз по умолчанию (default gateway) на вашем компьютере.
То есть, если устройство-получатель в вашей же подсети, кадр просто отправляется в порт с мак-адресом конечного получателя. Если же сообщение адресовано в любую другую подсеть, то кадр отправляется на шлюз по умолчанию, поэтому в качестве MAC-адреса получателя подставится MAC-адрес маршрутизатора.

Проследим за ходом событий.

1) ПК с адресом 172.16.3.2/24 хочет отправить данные компьютеру с адресом 172.16.4.5.

Он видит, что адрес из другой подсети, следовательно, данные должны уйти на шлюз по умолчанию. Но в таком случае, ПК нужен MAC-адрес шлюза. ПК проверяет свой ARP-кэш в поисках соответствия IP-адрес шлюза — MAC-адрес и не находит нужного

2) ПК отправляет широковещательный ARP-запрос в локальную сеть. Структура ARP-запроса:
— на канальном уровне в качестве получателя — широковещательный адрес ( FF:FF:FF:FF:FF:FF), в качестве отправителя — MAC-адрес интерфейса устройства, пытающегося выяснить IP
— на сетевом — собственно ARP запрос, в нем содержится информация о том, какой IP и кем ищется.

3) Коммутатор, на который попал кадр, рассылает его копии во все порты этого влана (того, которому принадлежит изначальный хост), кроме того, откуда он получен.

4) Все устройства, получив этот кадр и, видя, что он широковещательный, предполагают, что он адресован им.

5) Распаковав кадр, все хосты, кроме маршрутизатора, видят, что в ARP-запросе не их адрес. А маршрутизатор посылает unicast’овый ARP-ответ со своим MAC-адресом.

6) Изначальный хост получает ARP-ответ, теперь у него есть MAC-адрес шлюза. Он формирует пакет из тех данных, что ему нужно отправить на 172.16.4.5. В качестве MAC-адреса получателя ПК ставит адрес шлюза. При этом IP-адрес получателя в пакете остаётся 172.16.4.5

7) Кадр посылается в сеть, коммутаторы доставляют его на маршрутизатор.

8) На маршрутизаторе, в соответствии с меткой влана, кадр принимается конкретным сабинтерфейсом. Данные канального уровня откидываются.

9) Из заголовка IP-пакета, рутер узнаёт адрес получателя, а из своей таблицы маршрутизации видит, что тот находится в непосредственно подключенной к нему сети на определённом сабинтерфейсе (в нашем случае FE0/0.102).

C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104

10) Маршрутизатор отправляет ARP-запрос с этого сабинтерфейса — узнаёт MAC-адрес получателя.

11) Изначальный IP-пакет, не изменяясь инкапсулируется в новый кадр, при этом:

— в качестве MAC-адреса источника указывается адрес интерфейса шлюза
— IP-адрес источника — адрес изначального хоста (в нашем случае 172.16.3.2)
— в качестве MAC-адреса получателя указывается адрес конечного хоста
— IP-адрес получателя — адрес конечного хоста (в нашем случае 172.16.4.5)

и отправляется в сеть с сабинтерфейса FastEthernet0/0.102, получая при этом метку 102-го влана.

12) Кадр доставляется коммутаторами до хоста-получателя.

Планирование расширения

Теперь обратимся к планированию. В нулевой части мы уже затронули эту тему, но тогда речь была только о двух офисах в Москве, теперь же сеть растёт.

Будет она вот такой:

То есть прибавляются две точки в Санкт-Петербурге: небольшой офис на Васильевском острове и сам завод в Озерках — и одна в Кемерово в районе Красная горка.

Для простоты у нас будет один провайдер “Балаган Телеком”, который на выгодных условиях предоставит нам L2VPN до обеих точек.
В одном из следующих выпусков мы тему различных вариантов подключения раскроем в красках. А пока вкратце: L2VPN — это, очень грубо говоря, когда вам провайдер предоставляет влан от точки до точки (можно для простоты представить, что они включены в один коммутатор).

Следует сказать несколько слов об IP-адресации и делении на подсети.
В нулевой части мы уже затронули вопросы планирования, весьма вскользь надо сказать.
Вообще, в любой более или менее большой компании должен быть некий регламент — свод правил, следуя которому вы распределяете IP-адреса везде. Сеть у нас сейчас разрастается и разработать его очень важно.

Ну вот к примеру, скажем, что для офисов в других городах это будет так:

Это весьма упрощённый регламент, но теперь мы во всяком случае точно знаем, что у шлюза всегда будет 1-й адрес, до 12-го мы будем выдавать коммутаторам и всяким wi-fi-точкам, а все сервера будем искать в диапазоне 172.16.х.13-172.16.х.23. Разумеется, по своему вкусу вы можете уточнять регламент вплоть до адреса каждого сервера, добавлять в него правило формирования имён устройств, доменных имён, политику списков доступа и т.д.
Чем точнее вы сформулируете правила и строже будете следить за их выполнением, тем проще разбираться в структуре сети, решать проблемы, адаптироваться к ситуации и наказывать виновных.
Это примерно, как схема запоминания паролей: когда у вас есть некое правило их формирования, вам не нужно держать в голове несколько десятков сложнозапоминаемых паролей, вы всегда можете их вычислить.
Вот так же и тут. Я некогда работал в средних размеров холдинге и знал, что если я приеду в офис где-нибудь в забытой коровами деревне, то там точно x.y.z.1 — это циска, x.y.z.2 — дистрибьюшн-свитч прокурва, а x.y.z.101 — компьютер главного бухгалтера, с которого надо дать доступ на какой-нибудь контур-экстерн. Другой вопрос, что надо это ещё проверить, потому что местные ИТшники такого порой наворотят, что слезами омываешься сквозь смех.

Было дело парнишка решил сам управлять всем доступом в интернет (обычно это делал я на маршрутизаторе). Поставил proxy-сервер, случайно поднял на нём NAT и зарулил туда трафик локальной сети, на всех машинах прописав его в качестве шлюза по умолчанию, а потом я минут 20 разбирался, как так: у них всё работает, а мы их не видим.

IP-план

Теперь нам было бы весьма кстати составить IP-план. Будем исходить из того, что на всех трёх точках мы будем использовать стандартную сеть с маской 24 бита (255.255.255.0) Это означает, что в них может быть 254 устройства.

Почему это так? И как вообще понять все эти маски подсетей? В рамках одной статьи мы не сможем этого рассказать, иначе она получится длинная, как палуба Титаника и запутанная, как одесские катакомбы. Крайне рекомендуем очень плотно познакомиться с такими понятиями, как IP-адрес, маска подсети, их представления в двоичном виде и CIDR (Classless InterDomain Routing) самостоятельно. Мы же далее будем только аргументировать выбор конкретного размера сети. Как бы то ни было, полное понимание придёт только с практикой.
Вообще, очень неплохо эта тема раскрыта в этой статье: http://habrahabr.ru/post/129664/

В данный момент (вспомним нулевой выпуск) у нас в Москве использованы адреса 172.16.0.0-172.16.6.255. Предположим, что сеть может ещё увеличиться здесь, допустим, появится офис на Воробьёвых горах и зарезервируем ещё подсети до 172.16.15.0/24 включительно.
Все эти адреса: 172.16.0.0-172.16.15.255 — можно описать так: 172.16.0.0/20. Эта сеть (с префиксом /20) будет так называемой суперсетью, а операция объединения подсетей в суперсети называется суммированием подсетей (суммированием маршрутов, если быть точным, route summarization)

Очень наглядный IP-калькулятор. Я и сейчас им периодически пользуюсь, хотя со временем приходит интуитивное и логическое понимание соответствия между длиной маски и границами сети.

Теперь обратимся к Питеру. В данный момент в этом прекрасном городе у нас 2 точки и на каждой из них подсети /24. Допустим это будут 172.16.16.0/24 и 172.16.17.0/24. Зарезервируем адреса 172.16.18.0-172.16.23.255 для возможного расширения сети.

172.16.16.0-172.16.23.255 можно объединить в 172.16.16.0/21 — в общем-то исходя именно из этого мы и оставляем в резерв именно такой диапазон.

В Кемерово нам нет смысла оставлять такие огромные запасы /21, как в Питере (2048 адресов или 8 подсетей /24), или тем более /20, как в Москве (4096 или 16 подсетей /24). А вот 1024 адреса и 4 подсети /24, которым соответствует маска /22 вполне рационально.

Таким образом сеть 172.16.24.0/22 (адреса 172.16.24.0-172.16.27.255) будет у нас для Кемерово.

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

ip route 172.16.16.0 255.255.255.0 172.16.2.2
ip route 172.16.17.0 255.255.255.0 172.16.2.2
ip route 172.16.18.0 255.255.255.0 172.16.2.2
……
ip route 172.16.23.0 255.255.255.0 172.16.2.2

Это 8 команд и 8 записей в таблице. Но при этом пришедший на маршрутизатор пакет в любую из сетей 172.16.16.0/21 в любом случае будет отправлен на устройство с адресом 172.16.2.2.
Вместо этого мы поступим так:

ip route 172.16.16.0 255.255.248.0 172.16.2.2

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

Теперь ещё несколько слов о “линковых” сетях. В среде сетевых администраторов так называются сети точка-точка (Point-to-Point) между двумя маршрутизаторами.
Вот опять же в примере с Питером. Два маршрутизатора (в Москве и в Петербурге) соединены друг с другом прямым линком (неважно, что у провайдера это сотня коммутаторов и маршрутизаторов — для нас это просто влан). То есть кроме вот этих 2-х устройств здесь не будет никаких других. Мы знаем это наверняка. В любом случае на интерфейсах обоих устройств (смотрящих в сторону друг друга) нужно настраивать IP-адреса. И нам точно незачем назначать на этом участке сеть /24 с 254 доступными адресами, ведь 252 в таком случае пропадут почём зря. В этом случае есть прекрасный выход — бесклассовая IP-адресация.

Почему она бесклассовая? Если вы помните, то в нулевой части мы говорили о трёх классах подсетей: А, В и С. По идее только их вы и могли использовать при планировании сети. Бесклассовая междоменная маршрутизация (CIDR) позволяет очень гибко использовать пространство IP-адресов.

Мы просто берём сеть с самой маленькой возможной маской — 30 (255.255.255.252) — это сеть на 4 адреса. Почему мы не можем взять сеть с ещё более узкой маской? Ну 32 (255.255.255.255) по понятными причинам — это вообще один единственный адрес, сеть 31 (255.255.255.254) — это уже 2 адреса, но один из них (первый) — это адрес сети, а второй (последний) — широковещательный. В итоге на адреса хостов у нас и не осталось ничего. Поэтому и берём маску 30 с 4 адресами и тогда как раз 2 адреса остаются на наши два маршрутизатора.

Вообще говоря, самой узкой маской для подсетей в cisco таки является /31. При определённых условиях их можно использовать на P-t-P-линках.
Что же касается маски /32, то такие подсети, которые суть один единственный хост используются для назначения адресов Loopback-интерфейсам.

Именно так мы и поступим. Для этого, собственно, в нулевой части мы и оставили сеть 172.16.2.0/24 — её мы будем дробить на мелкие сетки /30. Всего их получится 64 штуки, соответственно можно назначить их на 64 линка.

Здесь мы поступили так же, как и в предыдущем случае: сделали небольшой резерв для Питера, и резерв для Кемерово. Вообще резерв — это всегда очень хорошо о чём бы мы ни говорили. 😉

Принципы маршрутизации

Перед началом настройки стоит определиться с тем, для чего нужна маршрутизация вообще.
Рассмотрим такую сеть:

Вот к примеру с компьютера ПК1 — 172.16.3.2 я хочу подключиться по telnet к L3-коммутатору с адресом 172.16.17.1.
Как мой компьютер узнает что делать? Куда слать данные?

1) Как вы уже знаете, если адрес получателя из другой подсети, то данные нужно отправлять на шлюз по умолчанию.

2) По уже известной вам схеме компьютер с помощью ARP-запроса добывает MAC-адрес маршрутизатора.

3) Далее он формирует кадр с инкапсулированным в него пакетом и отсылает его в порт. После того, как кадр отправлен, компьютеру уже по барабану, что происходит с ним дальше.

4) А сам кадр при этом попадает сначала на коммутатор, где решается его судьба согласно таблице MAC-адресов. А потом достигает маршрутизатора RT1.

5) Поскольку маршрутизатор ограничивает широковещательный домен — здесь жизнь этого кадра и заканчивается. Циска просто откидывает заголовок канального уровня — он уже не пригодится — извлекает из него IP-пакет.

6) Теперь маршрутизатор должен принять решение, что с ним делать дальше. Разумеется, отправить его на какой-то свой интерфейс. Но на какой?
Для этого существует таблица маршрутизации, которая есть на любом рутере. Выяснить, что у нас в данный момент находится в таблице маршрутизации, можно с помощью команды show ip route:

172.16.0.0/16 is variably subnetted, 10 subnets, 3 masks
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
S 172.16.17.0/24 [1/0] via 172.16.2.2

Каждая строка в ней — это способ добраться до той или иной сети.
Вот к примеру, если пакет адресован в сеть 172.16.17.0/24, то данные нужно отправить на устройство с адресом 172.16.2.2.
Таблица маршрутизации формируется из:
— непосредственно подключенных сетей (directly connected) — это сети, которые начинаются непосредственно на нём. В примере 172.16.3.0/24 и 172.16.2.0/30. В таблице они обозначаются буквой C
— статический маршруты — это те, которые вы прописали вручную командой ip route. Обозначаются буквой S
— маршруты, полученные с помощью протоколов динамической маршрутизации (OSPF, EIGRP, RIP и других).

7) Итак, данные в сеть 172.16.17.0 (а мы хотим подключиться к устройству 172.16.17.1) должны быть отправлены на следующий хоп — следующий прыжок, которым является маршрутизатор 172.16.2.2. Причём из таблицы маршрутизации видно, что находится следующий хоп за интерфейсом FE0/1.4 (подсеть 172.16.2.0/30).

8)Если в ARP-кэше циски нет MAC-адреса, то надо снова выполнить ARP-запрос, чтобы узнать MAC-адрес устройства с IP-адресом 172.16.2.2. RT1 посылает широковещательный кадр с порта FE0/1.4. В этом широковещательном домене у нас два устройства, и соответственно только один получатель. RT2 получает ARP-запрос, отбрасывает заголовок Ethernet и, понимая из данных протокола ARP, что искомый адрес принадлежит ему отправляет ARP-ответ со своим MAC-адресом.

9) Изначальный IP-пакет, пришедший на RT1 не меняется, он инкапсулируется в совершенно новый кадр и отправляется в порт FE0/1.4, получая при этом метку 4-го влана.

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

11) Последний маршрутизатор видит, что искомый адрес принадлежит ему самому, а извлекая данные транспортного уровня, понимает, что это телнет и передаёт все данные верхним уровням.

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

Настройка

Каким образом мы организуем каналы связи? Как мы уже сказали выше, в нашем офисе на Арбате есть некий провайдер Балаган-Телеком. Он обещает нам предоставить всё, что мы только захотим почти задарма. И мы заказываем у него две услуги L2VPN, то есть он отдаст нам два влана на Арбате в Москве, и по одному в Питере и Кемерово.
Вообще говоря, номера вланов вам придётся согласовывать с вашим провайдером по той простой причине, что у него они могут быть просто заняты. Поэтому вполне возможно, что у вас будет влан, например, 2912 или 754. Но предположим, что нам повезло, и мы вольны сами выбирать номер.

Москва. Арбат

На циске в Москве у нас два интерфейса, к одному — FE0/0 — уже подключена наша локальная сеть, а второй (FE0/1)мы будем использовать для выхода в интернет и для подключения удалённых офисов.
Как и в самом начале создадим саб-интерфейсы. Выделим для Санкт-Петербурга и Кемерова 4 и 5-й вланы соответственно. IP-адреса берём из нового IP-плана.

msk-arbat-gw1(config)#interface FastEthernet 0/1.4
msk-arbat-gw1(config-subif)#description Saint-Petersburg
msk-arbat-gw1(config-subif)#encapsulation dot1Q 4
msk-arbat-gw1(config-subif)#ip address 172.16.2.1 255.255.255.252

msk-arbat-gw1(config)#interface FastEthernet 0/1.5
msk-arbat-gw1(config-subif)#description Kemerovo
msk-arbat-gw1(config-subif)#encapsulation dot1Q 5
msk-arbat-gw1(config-subif)#ip address 172.16.2.17 255.255.255.252

Провайдер

Разумеется, мы не будем строить всю сеть провайдера. Вместо этого просто поставим коммутатор, ведь по сути сеть провайдера с нашей точки зрения будет одним огромным абстрактным коммутатором.

Тут всё просто: принимаем транком линк с Арбата в один порт и с двух других портов отдаём их на удалённые узлы. Ещё раз хотим подчеркнуть, что все эти 3 порта не принадлежат одному коммутатору — они разнесены на сотни километров, между ними сложная MPLS-сеть с кучей коммутаторов.

Настраиваем “эмулятор провайдера”:

Switch(config)#vlan 4
Switch(config-vlan)#vlan 5
Switch(config)#interface fa0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk allowed vlan 4-5
Switch(config-if)#exit
Switch(config)#int fa0/2
Switch(config-if)#switchport trunk allowed vlan 4
Switch(config-if)#int fa0/3
Switch(config-if)#switchport trunk allowed vlan 5

Санкт-Петербург. Васильевский остров

Теперь обратимся к нашему spb-vsl-gw1. Тут у нас тоже 2 порта, но решим вопрос нехватки портов иначе: добавим сюда плату. Плата с двумя FastEthernet-портам и двумя слотами для WIC вполне подойдёт.

Пусть встроенные порты будут для локальной сети, а порты на дополнительной плате мы используем для аплинка и связи с Озерками.

Здесь вы можете увидеть отличие в нумерации портов и понять их смысл.
FastEthernet — это тип порта (Ethernet, Fastethernet, GigabitEthernet, POS, Serial или другие)
x/y/z.w=Slot/Sub-slot/Interface.Sub-interface.

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

spb-vsl-gw1(config)interface FastEthernet1/0.4
spb-vsl-gw1(config-if)description Moscow
spb-vsl-gw1(config-if)encapsulation dot1Q 4
spb-vsl-gw1(config-if)ip address 172.16.2.2 255.255.255.252

Добавим ещё локальную сеть:

spb-vsl-gw1(config)#int fa0/0
spb-vsl-gw1(config-if)#description LAN
spb-vsl-gw1(config-if)#ip address 172.16.16.1 255.255.255.0

Вернёмся в Москву. С msk-arbat-gw1 мы можем увидеть адрес 172.16.2.2:

msk-arbat-gw1#ping 172.16.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/7/13 ms

Но так же не видим 172.16.16.1:

msk-arbat-gw1#ping 172.16.16.1

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

Success rate is 0 percent (0/5)

Опять же, потому что маршрутизатор не знает, куда слать пакет:

msk-arbat-gw1#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104

Исправим это недоразумение:

msk-arbat-gw1(config)#ip route 172.16.16.0 255.255.255.0 172.16.2.2

msk-arbat-gw1#sh ip route
Codes: C — connected, S — static, I — IGRP, R — RIP, M — mobile, B — BGP
D — EIGRP, EX — EIGRP external, O — OSPF, IA — OSPF inter area
N1 — OSPF NSSA external type 1, N2 — OSPF NSSA external type 2
E1 — OSPF external type 1, E2 — OSPF external type 2, E — EGP
i — IS-IS, L1 — IS-IS level-1, L2 — IS-IS level-2, ia — IS-IS inter area
* — candidate default, U — per-user static route, o — ODR
P — periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/24 [1/0] via 172.16.2.2

Теперь пинг появляется:

msk-arbat-gw1#ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/24 ms

Вот, казалось бы оно — счастье, но проверим связь с компьютера:

В чём дело?!
Компьютер знает, куда отправлять пакет — на свой шлюз 172.16.3.1, маршрутизатор тоже знает — на хост 172.16.2.2. Пакет уходит туда, принимается spb-vsl-gw1, который знает, что пингуемый адрес 172.16.16.1 принадлежит ему. А обратно нужно отправить пакет на адрес 172.16.3.3, но в сеть 172.16.3.0 у него нет маршрута. А пакеты, сеть назначения которых неизвестна, просто дропятся — отбрасываются.

spb-vsl-gw1#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.2.0/30 is directly connected, FastEthernet1/0.4
C 172.16.16.0/24 is directly connected, FastEthernet0/0

Но, почему же, спросите вы, с msk-arbat-gw1 до 172.16.16.1 пинг был? Какая разница 172.16.3.1 или 172.16.3.2? Всё просто.
Из таблицы маршрутизации всем видно, что следующий хоп — 172.16.2.2, при этом адрес из 172.16.2.1 принадлежит интерфейсу этого маршрутизатора, поэтому он и ставится в заголовок в качестве IP-адреса отправителя, а не 172.16.3.1. Пакет отправляется на spb-vsl-gw1, тот его принимает, передаёт данные приложению пинг, которое формирует echo-reply. Ответ инкапсулируется в IP-пакет, где в качестве адреса получателя фигурирует 172.16.2.1, а 172.16.2.0/30 — непосредственно подключенная к spb-vsl-gw1 сеть, поэтому без проблем пакет доставляется по назначению. То етсь в сеть 172.16.2.0/30 маршрут известен, а в 172.16.3.0/24 нет.

Для решения этой проблемы мы можем прописать на spb-vsl-gw1 маршрут в сеть 172.16.3.0, но тогда придётся прописывать и для всех других сетей. Для всех сетей в Москве, потом в Кемерово, потом в других городах — очень большой объём настройки.
И тут стоить заметить, что по сути у нас только один выход в мир — через Москву. Узел в Озерках — тупиковый, а других нет. То есть в основном все данные будут уходить в Москву, где большая часть подсетей и будет выход в интернет.
Чем нам это может помочь? Есть такое понятие — маршрут по умолчанию, ещё он носит романтическое название шлюз — последней надежды. И второму есть объяснение. Когда маршрутизатор решает, куда отправить пакет, он просматривает всё таблицу маршрутизации и, если не находит нужного маршрута, пакет отбрасывается — это если у вас не настроен шлюз последней надежды, если же настроен, то сиротливые пакеты отправляются именно туда — просто не глядя, предоставляя право уже следующему хопу решать их дальнейшую судьбу. То есть если некуда отправить, то последняя надежда — маршрут по умолчанию.
Настраивается он так:

spb-vsl-gw1(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.1

И теперь тадааам:

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

Санкт-Петербург. Озерки

Теперь озаботимся Озерками. Здесь мы поставим L3-коммутатор. Допустим, связаны они у нас будут арендованным у провайдера волокном (конечно, это идеализированная ситуация для маленькой компании, но можно же помечтать).
Использование коммутаторов третьего уровня весьма удобно в некоторых случаях. Во-первых, интервлан роутинг в этом случае делается аппаратно и не нагружает процессор, в отличие от маршрутизатора. Кроме того, один L3-коммутатор обойдётся вам значительно дешевле, чем L2-коммутатор и маршрутизатор по отдельности. Правда, при этом вы лишаетесь ряда функций, естественно. Поэтому при выборе решения будьте аккуратны.

Настроим маршрутизатор на Васильевском острове, согласно плану:

spb-vsl-gw1(config)interface fa1/1
spb-vsl-gw1(config-if)#description Ozerki
spb-vsl-gw1(config-if)#ip address 172.16.2.5 255.255.255.252

Поскольку мы уже запланировали сеть для Озерков 172.16.17.0/24, то можем сразу прописать туда маршрут:

spb-vsl-gw1(config)#ip route 172.16.17.0 255.255.255.0 172.16.2.6

В качестве некст хопа ставим адрес, который мы выделили для линковой сети на Озерках — 172.16.2.6

Теперь перенесёмся в сами Озерки:

Подключим кабель в уже настроенный порт fa1/1 на стороне Васильевского острова и в 24-й порт 3560 в Озерках.
По умолчанию все порты L3-коммутатора работают в режиме L2, то есть это обычные “свитчёвые” порты, на которых мы можем настроить вланы. Но любой из них мы можем перевести в L3-режим, сделав портом маршрутизатора. Тогда на нём мы сможем настроить IP-адрес:

Switch(config)#hostname spb-ozerki-gw1
spb-ozerki-gw1(config)#interface fa0/24
spb-ozerki-gw1(config-if)#no switchport
spb-ozerki-gw1(config-if)#ip address 172.16.2.6 255.255.255.252

Проверяем связь:

spb-ozerki-gw1#ping 172.16.2.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
.!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/18/61 ms

Настроим ещё локальную сеть. Напомним, что Cisco и другие производители и не только производители не рекомендуют использовать 1-й влан, поэтому, мы воспользуемся 2-м:

spb-ozerki-gw1(config)#vlan 2
spb-ozerki-gw1(config-vlan)#name LAN
spb-ozerki-gw1(config-vlan)#exit
spb-ozerki-gw1(config)#interface vlan 2
spb-ozerki-gw1(config-if)#description LAN
spb-ozerki-gw1(config-if)#ip address 172.16.17.1 255.255.255.0
spb-ozerki-gw1(config)#interface fastEthernet 0/1
spb-ozerki-gw1(config-if)#description Pupkin
spb-ozerki-gw1(config-if)#switchport mode access
spb-ozerki-gw1(config-if)#switchport access vlan 2

После этого все устройства во втором влане будут иметь шлюзом 172.16.17.1

Чтобы коммутатор превратился в почти полноценный маршрутизатор, надо дать ещё одну команду:

spb-ozerki-gw1(config)#ip routing

Таким образом мы включим возможность маршрутизации.

Никаких других маршрутов, кроме как по умолчанию нам тут не надо:

spb-ozerki-gw1(config)#ip route 0.0.0.0 0.0.0.0 172.16.2.5

Связь до spb-vsl-gw1 есть:

spb-ozerki-gw1#ping 172.16.16.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.16.1, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/50/234 ms

А до Москвы нет:

spb-ozerki-gw1#ping 172.16.3.1

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

Success rate is 0 percent (0/5)

Опять же дело в отсутствии маршрута. Вообще удобный инструмент для нахождения примерного места расположения проблемы traceroute:

spb-ozerki-gw1#traceroute 172.16.3.1
Type escape sequence to abort.
Tracing the route to 172.16.3.1

1 172.16.2.5 4 msec 2 msec 5 msec
2 * * *
3 * * *
4 *

Как видите, что от spb-vsl-gw1 ответ приходит, а дальше глухо. Это означает, как правило, что или на хопе с адресом 172.16.2.5 не прописан маршрут в нужную сеть (вспоминаем, что у нас настроен там маршрут по умолчанию, которого достаточно) или на следующем нету маршрута обратно:

msk-arbat-gw1#sh ip rou

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 9 subnets, 2 masks
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
S 172.16.16.0/24 [1/0] via 172.16.2.2

Действительно маршрута в подсеть 172.16.17.0/24 нет. Мы можем прописать его, вы это уже умеете, а можем вспомнить, что целую подсеть 172.16.16.0/21 мы выделили под Питер, поэтому вместо того, чтобы по отдельности добавлять маршрут в каждую новую сеть, мы пропишем агрегированный маршрут:

msk-arbat-gw1(config)#no ip route 172.16.16.0 255.255.255.0 172.16.2.2
msk-arbat-gw1(config)#ip route 172.16.16.0 255.255.248.0 172.16.2.2

Проверяем:

msk-arbat-gw1#ping 172.16.17.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.17.1, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/18 ms

Но странной неожиданностью для вас может стать то, что с spb-ozerki-gw1 вы не увидите Москву по-прежнему:

spb-ozerki-gw1#ping 172.16.3.1

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

Success rate is 0 percent (0/5)

Но при этом, если в качестве адреса-источника мы укажем 172.16.17.1:

spb-ozerki-gw1#ping
Protocol [ip]:
Target IP address: 172.16.3.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: ping172.16.17.1
% Invalid source
Source address or interface: 172.16.17.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
Packet sent with a source address of 172.16.17.1
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/9/14 ms

И даже с компьютера 172.16.17.26 связь есть:

Как же так? Ответ, вы не поверите, так же прост — проблемы с маршрутизацией.

Дело в том, что msk-arbat-gw1 о подсети 172.16.17.0/24 знает, а о 172.16.2.4/30 нет. А именно адрес 172.16.2.6 — адрес ближайшего к адресату интерфейса (или интерфейса, с которого отправляется IP-пакет) подставляет по умолчанию в качестве источника. Об этом забывать не нужно.

msk-arbat-gw1(config)#ip route 172.16.2.4 255.255.255.252 172.16.2.2

spb-ozerki-gw1#ping 172.16.3.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.1, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/62/269 ms

Ещё интересный опыт: а что если адрес на маршрутизаторе на Васильевском острове маршрут в подсеть 172.16.3.0/24 пропишем на Озерки, а не в Москву? Ну чисто для интереса. Что произойдёт в этом случае?

spb-vsl-gw1(config)#ip route 172.16.3.0 255.255.255.0 172.16.2.6

В РТ вы этого не увидите, почему-то, но в реальной жизни получится кольцо маршрутизации. Сети 172.16.3.0/24 и 172.16.16.0/21 не будут видеть друг друга:
пакет идущий с spb-ozerki-gw1 в сеть 172.16.3.0 попадает в первую очередь на spb-vsl-gw1, где сказано: “172.16.3.0/24 ищите за 172.16.2.6”, а это снова spb-ozerki-gw1, где сказано: “172.16.3.0/24 ищите за 172.16.2.5” и так далее. Пакет будет шастать туда-обратно, пока не истечёт значение в поле TTL.
Дело в том, что при прохождении каждого маршрутизатора поле TTL в IP-заголовке, изначально имеющее значение 255, уменьшается на 1. И если вдруг окажется, что это значение равно 0, то пакет погибает, точнее маршрутизатор, увидевший это, задропит его.
Таким образом обеспечивается стабильность сети — в случае возникновения петли пакеты не будут жить бесконечно, нагружая канал до его полной утилизации.
Кстати, в Ethernet такого механизма нет и если получается петля, то коммутатор только и будет делать, что плодить широковещательные запросы, полностью забивая канал — это называется широковещательный шторм (эта проблема решается с помощью специальной технологии\протокола STP- об этом в следующем выпуске).

В общем, если вы пускаете пинг из сети 172.16.17.0 на адрес 172.16.3.1, то ваш IP-пакет будет путешествовать между двумя маршрутизаторами, пока не истечёт срок его жизни, пройдя при этом по линку между Озерками и Васильевским островом 254 раза.
Кстати, следствием из работы этого механизма является то, что не может существовать связная сеть, где между узлами больше 255 маршрутизаторов. Впрочем это и не очень актуальная потребность. Сейчас даже самый долгий трейс занимает пару-тройку десятков хопов.

Кемерово. Красная горка

Рассмотрим последний небольшой пример — маршрутизатор на палочке (router on a stick).

Название навеяно схемой подключения:

Маршрутизатор связан с коммутатором лишь одним кабелем и по разным вланам внутри него передаётся трафик и локальной сети, и внешний. Делается это, как правило, для экономии средств (на маршрутизаторе только один порт и не хочется покупать дополнительную плату).

Подключим следующим образом:

Настройка коммутатора уже не должна для вас представлять проблем. На UpLink-интерфейсе настраиваем оговоренный с провайдером 5-й влан транком:

Switch(config)#hostname kmr-gorka-sw1
kmr-gorka-sw1(config)#vlan 5
kmr-gorka-sw1(config-vlan)#name Moscow

kmr-gorka-sw1(config)#int fa0/24
kmr-gorka-sw1(config-if)#description Moscow
kmr-gorka-sw1(config-if)#switchport mode trunk
kmr-gorka-sw1(config-if)#switchport trunk allowed vlan 5

В качестве влана для локальной сети выберем vlan 2 и это ничего, что он уже используется и в Москве и в Питере — если они не пересекаются и вы это можете контролировать, то номера могут совпадать. Тут каждый решает сам: вы можете везде использовать, например, 2-й влан, в качестве влана локальной сети или напротив разработать план, где номера вланов уникальны во всей сети.

kmr-gorka-sw1(config)#vlan 2
kmr-gorka-sw1(config-vlan)#name LAN
kmr-gorka-sw1(config)#int fa0/1
kmr-gorka-sw1(config-if)#description syn_generalnogo
kmr-gorka-sw1(config-if)#switchport mode access
kmr-gorka-sw1(config-if)#switchport access vlan 2

Транк в сторону маршрутизатора, где 5-ым вланом будут тегироваться кадры внешнего трафика, а 2-м — локального.

kmr-gorka-sw1(config)#int fa0/23
kmr-gorka-sw1(config-if)#description kmr-gorka-gw1
kmr-gorka-sw1(config-if)#switchport mode trunk
kmr-gorka-sw1(config-if)#switchport trunk allowed vlan 2,5

Настройка маршрутизатора:

Router(config)#hostname kmr-gorka-gw1
kmr-gorka-gw1(config)#int fa0/0.5
kmr-gorka-gw1(config-subif)#description Moscow
kmr-gorka-gw1(config-subif)#encapsulation dot1Q 5
kmr-gorka-gw1(config-subif)#ip address 172.16.2.18 255.255.255.252

kmr-gorka-gw1(config)#int fa0/0
kmr-gorka-gw1(config-if)#no sh

kmr-gorka-gw1(config)#int fa0/0.2
kmr-gorka-gw1(config-subif)#description LAN
kmr-gorka-gw1(config-subif)#encapsulation dot1Q 2
kmr-gorka-gw1(config-subif)#ip address 172.16.24.1 255.255.255.0

Полагаем, что маршрутизацию здесь между Москвой и Кемерово вы теперь сможете настроить самостоятельно.

Дополнительно

В случае, если с маршрутизацией не всё в порядке для траблшутинга вам понадобятся две команды:

traceroute

и

show ip route

У первой бывает полезным, как вы видели, задать адрес источника. А последнюю можно применять с параметрами, например:

msk-arbat-gw1#sh ip route 172.16.17.0
Routing entry for 172.16.16.0/21
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 172.16.2.2
Route metric is 0, traffic share count is 1

Несмотря на то, что в таблице маршрутизации нет отдельной записи для подсети 172.16.17.0, маршрутизатор покажет вам, какой следующий хоп.

И ещё хотелось бы повторить самые важные вещи:

— Когда блок данных попадает на маршрутизатор, заголовок Ethernet полностью отбрасывается и при отправке формируется совершенно новый кадр. Но IP-пакет остаётся неизменным.

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

— Поиск в таблице идёт НЕ до первой попавшейся подходящей записи, а до тех пор, пока не будет найдено самое точное соответствие (самая узкая маска). Например, если у вас таблица маршрутизации выглядит так:

172.16.0.0/16 is variably subnetted, 6 subnets, 3 masks
S 172.16.0.0/16 [1/0] via 172.16.2.22
C 172.16.2.20/30 is directly connected, FastEthernet0/0
C 172.16.2.24/30 is directly connected, FastEthernet0/0.2
C 172.16.2.28/30 is directly connected, FastEthernet0/0.3
S 172.16.10.0/24 [1/0] via 172.16.2.26
S 172.16.10.4/30 [1/0] via 172.16.2.30

И вы передаёте данные на 172.16.10.5, то он не пойдёт ни по маршруту через 172.16.2.22 ни через 172.16.2.26, а выберет самую узкую маску (самую длинную) /30 через 172.16.2.30.

— Если IP-адресу получателя не будет соответствовать ни одна запись в таблице маршрутизации и не настроен маршрут по умолчанию (шлюз последней надежды), пакет будет просто отброшен.

На этом первое знакомство с маршрутизацией можно закончить. Нам кажется, что читатель сам видит, сколько сложностей поджидает его здесь, может предположить, какой объём работы предстоит ему, если сеть разрастётся до нескольких десятков маршрутизаторов. Но надо сказать, что в современном мире статическая маршрутизация, не то чтобы не используется, конечно, ей есть место, но в подавляющем большинстве сетей, крупнее районного пионер-нета внедрены протоколы динамической маршрутизации. Среди них OSPF, EIGRP, IS-IS, RIP, которым мы посвятим отдельный выпуск и, скорее всего, не один. Но настройка статической маршрутизации в значительной степени поможет вашему общему пониманию маршрутизации.

В качестве самостоятельного задания попробуйте настроить маршрутизацию между Москвой и Кемерово и ответить на вопрос, почему не пингуются устройства из сети управления.

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

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

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

Все заинтересованные, но незарегистрированные приглашаются на беседу в ЖЖ.
За подготовку статьи большое спасибо моему соавтору thegluck и моей жене за львиное терпение.

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


Сети для самых маленьких. Часть пятая. 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 рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).

Практика

Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”?

а) WEB-сервер. Разрешить доступ всем по порту TCP 80 (протокол HTTP). Для того устройства, с которого будет производиться управление (у нас же есть админ) нужно открыть telnet и ftp, но ему мы дадим полный доступ. Всем остальным отбой.

б) Файловый сервер. На него у нас должны попадать резиденты Лифт ми Ап по портам для общих папок, а все остальные по FTP.

в) Почтовый сервер. Тут у нас запущены SMTP и POP3, то есть порты TCP 25 и 110. Так же для админа открываем доступ на управление. Других блокируем.

г) Для будущего DNS-сервера нужно открыть порт UDP 53

д) В сеть серверов разрешить ICMP-сообщения

е) Поскольку сеть Other у нас для всех беспартийных, кто не вошёл в ФЭО, ПТО и Бухгалтерию, то мы их всех ограничим, а некоторым только дадим доступ (в числе них мы и админ)

ё) В сеть управления нужно пускать опять же только админа, ну и конечно себя любимого.

ж) Не будем строить препоны общению между собой сотрудников отделов.

а) Доступ на 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 и отбрасывается.

б)Доступ на файловый сервер

Тут бы надо в первую очередь определиться с тем, кто будет “резидентом”, кому нужно дать доступ. Конечно, это те, кто имеет адрес из сети 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). О том, что это такое, поговорим чуточку позже

в) Доступ на почтовый сервер

Продолжаем нарабатывать практику — теперь с почтовым сервером. В рамках того же списка доступа добавляем новые нужные нам записи.
Вместо номеров портов для широкораспространённых протоколов можно указывать их имена:

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

г) 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

д) 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-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.

е) Права пользователей из сети 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 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.

ё) Сеть управления

Ничего сложного. Правило будет выглядеть так:

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

ж) Более никаких ограничений

Готово

Маска и обратная маска

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

Начнём с самого простого примера.

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

IP-адрес. Десятичная запись     172     16     5     0
IP-адрес. Двоичная запись     10101100     00010000     00000101     00000000
Маска подсети. Двоичная запись     11111111     11111111     11111111     00000000
Маска подсети. Десятичная запись     255     255     255     0

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-адрес. Десятичная запись     172     16     2     4
IP-адрес. Двоичная запись     10101100     00010000     00000010     00000100
Маска подсети. Двоичная запись     11111111     11111111     11111111     11111100
Маска подсети. Десятичная запись     255     255     255     252

Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 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 нулей и две единицы:

Обратная маска. Двоичная запись     00000000     00000000     00000000     00000011
Обратная маска. Десятичная запись     0     0     0     3

Соответственно параметр в 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.16.0 0.0.255.4

Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи.
Более подробно об обратных масках можно прочитать тут: 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.103.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.5     23761     192.0.2.2     80
172.16.4.5     39800     192.0.2.2     80

Маршрутизатор расчехляет 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.2     11874     192.0.2.2     80
198.51.100.2     11875     192.0.2.2     80

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

Локальный адрес отправителя     Глобальный адрес отправителя     Локальный порт отправителя     Глобальный порт отправителя     Адрес получателя     Порт получателя
172.16.6.5     23761     198.51.100.2     11874     192.0.2.2     80
172.16.4.5     39800     198.51.100.2     11875     192.0.2.2     80

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

Адрес отправителя     Порт отправителя     Адрес получателя     Порт получателя
192.0.2.2     80     198.51.100.2     11874
192.0.2.2     80     198.51.100.2     11875

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

Адрес отправителя     Порт отправителя     Адрес получателя     Порт получателя
192.0.2.2     80     172.16.6.5     23761
192.0.2.2     80     172.16.4.5     39800

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

Каждое ваше обращение — это отдельное соединение. То есть попытались вы открыть 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.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

Перенаправление портов

Иначе говорят ещё проброс портов или 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-план, планы коммутации по каждой точке и регламент
Файл РТ с лабораторной
Конфигурация устройств

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

Бонусы

Настройка PBR для примера из статьи

Ограничение скорости на интерфейсе на основе ACL

Назревшие вопросы безхаберным людям можно реализовать в ЖЖ.


.

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 рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).

Практика

Давайте сразу к практике. Что бы нам такого наограничивать в нашей маленькой сети “Лифт ми Ап”?

а) WEB-сервер. Разрешить доступ всем по порту TCP 80 (протокол HTTP). Для того устройства, с которого будет производиться управление (у нас же есть админ) нужно открыть telnet и ftp, но ему мы дадим полный доступ. Всем остальным отбой.

б) Файловый сервер. На него у нас должны попадать резиденты Лифт ми Ап по портам для общих папок, а все остальные по FTP.

в) Почтовый сервер. Тут у нас запущены SMTP и POP3, то есть порты TCP 25 и 110. Так же для админа открываем доступ на управление. Других блокируем.

г) Для будущего DNS-сервера нужно открыть порт UDP 53

д) В сеть серверов разрешить ICMP-сообщения

е) Поскольку сеть Other у нас для всех беспартийных, кто не вошёл в ФЭО, ПТО и Бухгалтерию, то мы их всех ограничим, а некоторым только дадим доступ (в числе них мы и админ)

ё) В сеть управления нужно пускать опять же только админа, ну и конечно себя любимого.

ж) Не будем строить препоны общению между собой сотрудников отделов.

а) Доступ на 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 и отбрасывается.

б)Доступ на файловый сервер

Тут бы надо в первую очередь определиться с тем, кто будет “резидентом”, кому нужно дать доступ. Конечно, это те, кто имеет адрес из сети 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). О том, что это такое, поговорим чуточку позже

в) Доступ на почтовый сервер

Продолжаем нарабатывать практику — теперь с почтовым сервером. В рамках того же списка доступа добавляем новые нужные нам записи.
Вместо номеров портов для широкораспространённых протоколов можно указывать их имена:

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

г) 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

д) 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-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.

е) Права пользователей из сети 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 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.

ё) Сеть управления

Ничего сложного. Правило будет выглядеть так:

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

ж) Более никаких ограничений

Готово

Маска и обратная маска

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

Начнём с самого простого примера.

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

IP-адрес. Десятичная запись 172 16 5 0
IP-адрес. Двоичная запись 10101100 00010000 00000101 00000000
Маска подсети. Двоичная запись 11111111 11111111 11111111 00000000
Маска подсети. Десятичная запись 255 255 255 0

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-адрес. Десятичная запись 172 16 2 4
IP-адрес. Двоичная запись 10101100 00010000 00000010 00000100
Маска подсети. Двоичная запись 11111111 11111111 11111111 11111100
Маска подсети. Десятичная запись 255 255 255 252

Как видите, для этой подсети могут меняться только последние два бита. Последний октет может принимать следующие 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 нулей и две единицы:

Обратная маска. Двоичная запись 00000000 00000000 00000000 00000011
Обратная маска. Десятичная запись 0 0 0 3

Соответственно параметр в 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.16.0 0.0.255.4

Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи.
Более подробно об обратных масках можно прочитать тут: 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.103.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.5 23761 192.0.2.2 80
172.16.4.5 39800 192.0.2.2 80

Маршрутизатор расчехляет 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.2 11874 192.0.2.2 80
198.51.100.2 11875 192.0.2.2 80

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

Локальный адрес отправителя Локальный порт отправителя Глобальный адрес отправителя Глобальный порт отправителя Адрес получателя Порт получателя
172.16.6.5 23761 198.51.100.2 11874 192.0.2.2 80
172.16.4.5 39800 198.51.100.2 11875 192.0.2.2 80

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

Адрес отправителя Порт отправителя Адрес получателя Порт получателя
192.0.2.2 80 198.51.100.2 11874
192.0.2.2 80 198.51.100.2 11875

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

Адрес отправителя Порт отправителя Адрес получателя Порт получателя
192.0.2.2 80 172.16.6.5 23761
192.0.2.2 80 172.16.4.5 39800

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

Каждое ваше обращение — это отдельное соединение. То есть попытались вы открыть 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.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

Перенаправление портов

Иначе говорят ещё проброс портов или 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-план, планы коммутации по каждой точке и регламент
Файл РТ с лабораторной
Конфигурация устройств

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

Бонусы

Настройка PBR для примера из статьи

Ограничение скорости на интерфейсе на основе ACL

Назревшие вопросы безхаберным людям можно реализовать в ЖЖ.
Спасибо моему соавтору thegluck
Отдельная благодарность за помощь в подготовке статьи JDima