return

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

3 ноября 2012, 17:10

Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!

Но с развитием появляются и новые проблемы.

Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!

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


Содержание выпуска

  1. ACL — Access Control List
  2. NAT — Network Address Translation
  3. Бонусы
  4. Материалы выпуска



Access Control List

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

Каково предназначение списков доступа? Казалось бы, совершенно очевидный ответ — для ограничения доступа: кому-то что-то запретить, например. Вообще — это верно, но понимать нужно в более широком смысле: речь не только о безопасности. То есть, изначально, вероятно, так оно и было, отсюда permit и deny при настройке. Но на самом деле ACL — это универсальный и мощный механизм фильтрации. С их помощью можно определить на кого навешивать определённые политики, а на кого нет, кто будет участвовать в неких процессах, а кто нет, кого ограничиваем в скорость до 56k, а кого до 56M.

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


Виды ACL

Ладно, забудем на время эту лирику.
Вообще говоря, списки доступа бывают разными:

  • Стандартные
  • Расширенные
  • Динамические
  • Рефлексивные
  • Повременные

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

Входящий и исходящий трафик

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

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

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

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


Практика

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

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

1) Доступ на WEB-сервер

Тут у нас работает политика запрещено всё, что не разрешено. Поэтому нам сейчас надо кое-что открыть, а всё остальное закрыть.

Поскольку мы защищаем сеть серверов, то и лист будем вешать на интерфейс, идущий в сторону них то есть, на FE0/0.3 Вопрос только на in или на out нам нужно это делать? Если мы не хотим пускать пакеты в сторону серверов, которые уже оказались на маршрутизаторе, то это будет исходящий трафик. То есть адреса назначения (destination) у нас будут в сети серверов (из них мы будем выбирать на какой именно сервер идёт трафик), а адреса источников (source) могут быть любыми — как из нашей корпоративной сети, так и из интернета. Ещё одно замечание: поскольку фильтровать мы будем в том числе по адресу назначения (на WEB-сервер одни правила, на почтовый — другие), то список контроля доступа нам понадобится расширенный (extended), только он позволяет делать это.

Правила в списке доступа проверяются по порядку сверху вниз до первого совпадения. Как только одно из правил сработало, независимо от того permit это или deny, проверка прекращается и обработка трафика происходит на основе сработавшего правила.

То есть если мы хотим защитить WEB-сервер, то в первую очередь нам нужно дать разрешение, потому что, если мы в первой же строке настроим deny ip any any — то оно всегда будет срабатывать и трафик не будет ходить вообще. Any — это специальное слово, которое означает адрес сети и обратную маску 0.0.0.0 0.0.0.0 и означает, что под правило подпадают абсолютно все узлы из любых сетей. Другое специальное слово — host — оно означает маску 255.255.255.255 — то есть именно один единственный указанный адрес.

Итак, первое правило: разрешить доступ всем по порту 80

msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# remark WEB
msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.2 eq 80

Разрешаем (permit) TCP-трафик от любого узла (any) на хост (host — именно один адрес) 172.16.0.2, адресованный на 80-й порт.

Пробуем повесить этот список доступа на интерфейс FE0/0.3:

msk-arbat-gw1(config)# int fa0/0.3
msk-arbat-gw1(config-subif)# ip access-group Servers-out out

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

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

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

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

Каждое новое правило добавляется автоматически в конец списка, если он уже существует:

msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
msk-arbat-gw1(config-ext-nacl)# permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet

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

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

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

пакет FTP не попадает ни под одно из правил, кроме неявного deny ip any any и отбрасывается.

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

Тут бы надо в первую очередь определиться с тем, кто будет “резидентом”, кому нужно дать доступ. Конечно, это те, кто имеет адрес из сети 172.16.0.0/16 — только им и дадим доступ. Теперь с общими папками. В большинстве современных систем уже используется для этого протокол SMB, которому нужен порт TCP 445. На более старых версиях использовался NetBios, который кормился аж через три порта: UDP 137 и 138 и TCP 139. Договорившись с нашим админом, настроим 445 порт (правда проверить в рамках РТ, конечно, не получится). Но кроме этого, нам понадобятся порты для FTP — 20, 21, причём не только для внутренних хостов, но и для соединений из интернета:

msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.3 range 20 21

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

0.0.255.255 — обратная маска (wildcard mask). О том, что это такое, поговорим чуточку позже

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

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

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

msk-arbat-gw1(config)# ip access-list extended Servers-out
msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq pop3
msk-arbat-gw1(config-ext-nacl)#permit tcp any host 172.16.0.4 eq smtp

4) DNS-сервер

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

5) ICMP

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

Используем несложный чит для этого. Для это можно воспользоваться текстовым редактором, например. Скопируйте туда из show run кусок про ACL и добавьте следующие строки:

no ip access-list extended Servers-out
ip access-list extended Servers-out
permit icmp any any
remark WEB
permit tcp any host 172.16.0.2 eq www
permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet
remark FILE
permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
permit tcp any host 172.16.0.3 range 20 21
remark MAIL
permit tcp any host 172.16.0.4 eq pop3
permit tcp any host 172.16.0.4 eq smtp
remark DNS
permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53

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

Прекрасно.

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

Чтобы вставить правило в начало или в любое другое нужное место, вы можете прибегнуть к такому приёму:

ip access-list extended Servers-out
1 permit icmp any any

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

ip access-list resequence Servers-out 10 10

В итоге Access List на серверную сеть будет выглядеть так:

ip access-list extended Servers-out
permit icmp any any
remark WEB
permit tcp any host 172.16.0.2 eq www
permit tcp host 172.16.6.66 host 172.16.0.2 range 20 ftp
permit tcp host 172.16.6.66 host 172.16.0.2 eq telnet
remark FILE
permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445
permit tcp any host 172.16.0.3 range 20 21
remark MAIL
permit tcp any host 172.16.0.4 eq pop3
permit tcp any host 172.16.0.4 eq smtp
remark DNS
permit udp 172.16.0.0 0.0.255.255 host 172.16.0.5 eq 53

Сейчас наш админ имеет доступ только на WEB-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.

6) Права пользователей из сети Other

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

msk-arbat-gw1(config)# ip access-list extended Other-in
msk-arbat-gw1(config-ext-nacl)# remark IAM
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 any
msk-arbat-gw1(config-ext-nacl)# remark ADMIN
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 any

Тут мы не могли сначала запретить всем, а потом разрешить избранным, потому что абсолютно все пакеты попадали бы под правило deny ip any any и permit не срабатывал бы вообще. Применяем на интерфейс. На этот раз на вход:

msk-arbat-gw1(config)#int fa0/0.104
msk-arbat-gw1(config-subif)#ip access-group Other-in in

то есть все IP-пакеты от хоста с адресом 172.16.6.61 или 172.16.6.66 разрешено передавать куда бы они ни были предназначены. Почему мы тут используем тоже расширенный список доступа? Ведь, казалось бы, мы проверяем только адрес отправителя. Потому что админу мы дали полный доступ, а вот гостю компании “Лифт ми Ап”, например, который попадёт в эту же сеть совсем ни к чему доступ куда-либо, кроме как в Интернет.

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

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

msk-arbat-gw1(config)# ip access-list extended Management-out
msk-arbat-gw1(config-ext-nacl)# remark IAM
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.61 172.16.1.0 0.0.0.255
msk-arbat-gw1(config-ext-nacl)# remark ADMIN
msk-arbat-gw1(config-ext-nacl)# permit ip host 172.16.6.66 172.16.1.0 0.0.0.255

Данный ACL применяем на out на интерфейс FE 0/0.2:

msk-arbat-gw1(config)# int fa0/0.2
msk-arbat-gw1(config-subif)#ip access-group Management-out out

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

Готово


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

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

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

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

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

IP-адрес. Десятичная запись 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.0.4 0.0.255.0
Признаться ни разу в жизни не приходилось встречаться с последним сценарием применения. Это какие-то жутко специфические должны быть задачи.
Более подробно об обратных масках можно прочитать тут: https://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
    

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

  5. Очень полезную для траблшутинга информацию можно получить из вывода команды show ip access-lists %имя ACL%. Кроме собственно списка правил указанного ACL, эта команда показывает количество совпадений по каждому правилу.
    msk-arbat-gw1#sh ip access-lists nat-inet
    Extended IP access list nat-inet
    permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www
    permit ip 172.16.5.0 0.0.0.255 host 192.0.2.3
    permit ip 172.16.5.0 0.0.0.255 host 192.0.2.4
    permit ip host 172.16.4.123 any
    permit ip host 172.16.6.61 any
    permit ip host 172.16.6.66 any(4 match(es))
    permit ip host 172.16.16.222 any
    permit ip host 172.16.17.222 any
    permit ip host 172.16.24.222 any
    

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


NAT

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

К последним относятся три диапазона:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16

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

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

Но как оно в свою очередь поймёт, что с ним делать дальше? Вот с этим и разберёмся.


Типы NAT

Статический

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

Настраивается следующей командой:

Router (config)# ip nat inside source static 172.16.6.5 198.51.100.2

Что происходит:

  1. Узел 172.16.6.5 обращается WEB-серверу. Он отправляет IP-пакет, где в качестве адреса получателя стоит 192.0.2.2, а отправителя 172.16.6.5.
  2. По корпоративной сети пакет доставляется к шлюзу 172.16.6.1, где и настроен NAT
  3. Согласно настроенной команде, маршрутизатор снимает текущий заголовок IP и меняет его на новый, где в качестве адреса отправителя уже фигурирует белый адрес 198.51.100.2.

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

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

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

И так будет с каждым.

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

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

Динамический

У вас есть пул белых адресов, например, провайдер выделил вам сеть 198.51.100.0/28 c 16-ю адресами. Два из них (первый и последний) — адрес сети и широковещательный, ещё два адреса назначаются на оборудование для обеспечения маршрутизации. 12 оставшихся адресов вы можете использовать для NAT’а и выпускать через них своих пользователей.

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

Router(config)#ip nat pool lol_pool 198.51.100.3 198.51.100.14 

Задали пул (диапазон) публичных адресов, из которого будет выбираться адрес для натирования

Router(config)
#access-list 100 permit ip 172.16.6.0 0.0.0.255 any

Задаём список доступа, который пропускает все пакеты с адресом источника 172.16.6.х, где х варьируется 0-255.

Router(config)#ip nat inside source list 100 pool lol_pool

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

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

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

Many-to-One

Следующий тип имеет несколько названий: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT.

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

Всё очень просто:

Предположим, что от двух хостов из внутренней сети приходят пакеты на натирующее устройство. Оба с запросом к WEB-серверу 192.0.2.2.

Данные от хостов выглядят так:

Адрес отправителя Порт отправителя Адрес получателя Порт получателя
172.16.6.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.100.14 
Router(config)#access-list 100 permit 172.16.6.0 0.0.0.255
Router(config)#ip nat inside source list 100 pool lol_pool overload

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

Иначе говорят ещё проброс портов или mapping.

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

Но если у вас нет такой возможности — вы ограничены в белых адресах, или не хотите выставлять всем пучком портов его наружу, что делать?

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

Router(config)#ip nat inside source static tcp 172.16.0.2 80 198.51.100.2 80 extendable

Применение данной команды означает, что TCP-запрос, пришедший из интернета на адрес 198.51.100.2 по порту 80, будет перенаправлен на внутренний адрес 172.16.0.2 на тот же 80-й порт. Разумеется, вы можете пробрасывать и UDP и делать перенаправление с одного порта на другой. Это, например, может оказаться полезным, если у вас есть два компьютера, к которым нужен доступ по RDP извне. RDP использует порт 3389. Один и тот же порт вы не можете пробросить на разные хосты (при использовании одного внешнего адреса). Поэтому вы можете сделать так:

Router(config)# ip nat inside source static tcp 172.16.6.61 3389 198.51.100.2 3389 
Router(config)# ip nat inside source static tcp 172.16.6.66 3389 198.51.100.2 3398 

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

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

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


Слабости и силости NAT

Cилости NAT

  • В первую очередь NAT позволяет сэкономить публичные IP-адреса. Собственно для этого он и был создан. Через один адрес, теоретически можно выпустить больше 65000 серых адресов (по количеству портов).
  • Во-вторых, PAT и динамический NAT является в какой-то степени файрволом, препятствуя внешним соединениям доходить до конечных компьютеров, на которых может не оказаться своего файрвола и антивируса. Дело в том, что если извне на натирующее устройство приходит пакет, который тут не ожидается или не разрешён, он просто отбрасывается.

    Чтобы пакет был пропущен и обработан, должны выполниться следующие условия:

    1. В NAT-таблице должна быть запись для этого внешнего адреса, указанного как адрес отправителя в пакете
    2. Порт отправителя в пакете должен совпадать с портом для этого белого адреса в записи
    3. Порт назначения в пакете, совпадает с портом в записи.

    ИЛИ

    Настроен проброс портов.

    Но не нужно рассматривать NAT именно как файрвол — это не более, чем дополнительная его плюшка.

  • В-третьих, 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 можно считать законченным.

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


Бонусы

PBR в режиме глобальной конфигурации

Добавляем маршрут по умолчанию:

ip route 0.0.0.0 0.0.0.0 10.0.1.1

В списке доступа отфильтровываем трафик из сети 192.168.2.0/24

access-list 101 permit ip 192.168.2.0 0.0.0.255 any

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

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

Применяем карту на интерфейс:

ip policy route-map CLIENT

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

rate-limit

На том же примере ограничим скорость для сети 192.168.1.0/24 до 1.5 Мб/с, а для 192.168.2.0/24 до 64 кб/с. На 10.0.1.1 можно выполнить следующие команды:

Router(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any
Router(config)# access-list 101 permit ip 192.168.2.0 0.0.0.255 any
Router(config)# interface fa0/0
Router(config-if)# rate-limit output access-group 100 1544000 64000 64000 conform-action transmit exceed-action drop
Router(config-if)# rate-limit output access-group 101 64000 16000 16000 conform-action transmit exceed-action drop

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


Благодарности

За помощь в подготовке статьи спасибо Дмитрию JDima.


Авторы

Оставайтесь на связи

Пишите нам: info@linkmeup.ru
Канал в телеграме: t.me/linkmeup_podcast
Канал на youtube: youtube.com/c/linkmeup-podcast
Подкаст доступен в iTunes, Google Подкастах, Яндекс Музыке, Castbox
Сообщество в вк: vk.com/linkmeup
Группа в фб: www.facebook.com/linkmeup.sdsm
Добавить RSS в подкаст-плеер.
Пообщаться в общем чате в тг: https://t.me/linkmeup_chat

Поддержите проект:

like 19 views 1216486 message 165

165 коментариев

  • int gi1/gi2
    ip nat outside/inside
    access-list 1 permit 192/172 0.0.0.255
    ip nat inside source list 1 interface Gi1 overload

    interface Tunnel 1
    ip address 172.16.1.1/2 255…
    tunnel mode gre ip
    tunnel source 4.4.4.100
    tunnel destination 5.5.5.100

    router eigrp 6500
    network 192/172 0.0.0.255
    network 172.16.1.0 0.0.0.255

    crypto isakmp policy 1
    encr aes
    authentication pre-share
    hash sha256
    group 14
    crypto isakmp key cisco address 5.100/4.100
    crypto isakmp nat keepalive 5
    crypto ipsec transform-set имя esp-aes 256 esp-sha256-hmac
    mode tunnel
    crypto ipsec profile VTI
    set transform-set имя
    interface Tunnel1
    tunnel mode ipsec ipv4
    tunnel protection ipsec profile VTI

    ip access-list extended Lnew
    permit tcp any any established
    permit udp host 4.4.4.100 eq 53 any
    permit udp host 5.5.5.1 eq 123 any
    permit tcp any host 4.4.4.100 eq 80
    permit tcp any host 4.4.4.100 eq 443
    permit tcp any host 4.4.4.100 eq 2222
    permit udp host 5.5.5.100 host 4.4.4.100 eq 500
    permit esp any any
    permit icmp any any
    int gi 1
    ip access-group Lnew in
    ——
    ip access-list extended Rnew
    permit tcp any any established
    permit tcp any host 5.5.5.100 eq 80
    permit tcp any host 5.5.5.100 eq 443
    permit tcp any host 5.5.5.100 eq 2244
    permit udp host 4.4.4.100 host 5.5.5.100 eq 500
    permit esp any any
    permit icmp any any
    int gi 1
    ip access-group Rnew in

    (L) ip nat inside source static tcp 192.168.100.100 22 4.4.4.100 2222
    ip nat inside source static tcp/udp 192.168.100.200 53 4.4.4.100 53
    (R) ip nat inside source static tcp 172.16.100.100 22 5.5.5.100 2244

    /etc/chrony/chrony.conf
    (ISP) local stratum 4
    allow 4.4.4.0/24
    allow 3.3.3.0/24

    (webL-R) pool ntp.int.demo.wsr iburst
    allow 192.168.100.0/24

    ip domain name int.demo.wsr
    ip name-server 192.168.100.200
    ntp server ntp.int.demo.wsr (ip)
    raid
    /root/.smbclient
    username/password
    /etc/fstab
    //srv.int.demo.wsr/диск /opt/share cifs user,rw,_netdev,credentials=/root/.smbclient 0 0
    mkdir /opt/share
    mount -a

    apt install -y docker-ce
    systemctl start docker
    systemctl enable docker
    mkdir /mnt/app
    mount /dev/sr1 /mnt/app
    docker load < /mnt/app/app.tar
    docker images
    docker run —name app -p 8080:80 -d app

    docker ps
    no ip http secure-server
    reload
    (L) ip nat inside source static tcp 192.168.100.100 80 4.4.4.100 80
    ip nat inside source static tcp 192.168.100.100 443 4.4.4.100 443
    (R) ip nat inside source static tcp 172.16.100.100 80 5.5.5.100 80
    ip nat inside source static tcp 172.16.100.100 443 5.5.5.100 443
    nginx
    cd /opt/share
    openssl pkcs12 -nodes -nocerts -in http://www.pfx -out http://www.key
    openssl pkcs12 -nodes -nokeys -in http://www.pfx -out http://www.cer

    cp /opt/share/www.key /etc/nginx/www.key
    cp /opt/share/www.cer /etc/nginx/www.cer
    nano /etc/nginx/snippets/snakeoil.conf
    ssl_certificate /etc/nginx/www.cer;
    ssl_certificate_key /etc/nginx/www.key;
    /etc/nginx/sites-available/default
    upstream backend {
    server 192.168.100.100:8080 fail_timeout=25;
    server 172.16.100.100:8080 fail_timeout=25;
    }

    server {
    listen 443 ssl default_server;
    include snippers/snakeoil.conf;

    server_name http://www.demo.wsr;

    location / {
    proxy_pass http://backend ;
    }
    }
    server {
    listen 80 default_server;
    server_name _;
    return 301 https://www.demo.wsr;
    }
    (CLI) scp -P 2244 'root@5.5.5.100:/opt/share/ca.cer' C:\Users\user\Desktop\

    Install-WindowsFeature -Name AD-Certificate, ADCS-Web-Enrollment -IncludeManagementTools
    Install-AdcsCertificationAuthority -CAType StandaloneRootCa -CACommonName "Demo.wsr" -force
    Install-AdcsWebEnrollment -Confirm -force
    New-SelfSignedCertificate -subject "localhost"
    Get-ChildItem cert:\LocalMachine\My
    Move-item Cert:\LocalMachine\My\rключ -destination Cert:\LocalMachine\Webhosting\
    New-IISSiteBinding -Name 'Default Web Site' -BindingInformation "*:443:" -Protocol https -CertificateThumbPrint ключ
    Start-WebSite -Name "Default Web Site"
    Get-CACrlDistributionPoint | Remove-CACrlDistributionPoint -force
    Get-CAAuthorityInformationAccess |Remove-CAAuthorityInformationAccess -force
    Get-CAAuthorityInformationAccess
    |Remove-CAAuthorityInformationAccess -force
    Restart-Service CertSrc

    22 мая 2022, 20:22
  • Анна Шихардина

    И снова я) Нужна помощь телепата)
    У меня дропаются пакеты на роутере который в 198.51.100.0 сеть. Причем дропаются на обратном пути, с формулировкой «The packet is a non-ICMP packet to the outgoing port’s subnet ID or broadcast. The device drops the packet», — это если по http. Насколько я поняла, это потому что поле src. IP заменилось на броадкастовый 198.51.100.3/30, а вот почему оно заменилось, не пойму(( Подскажите, пожалуйста, в чём косяк(

    29 февраля 2016, 10:51
    • int gi1/gi2
      ip nat outside/inside
      access-list 1 permit 192/172 0.0.0.255
      ip nat inside source list 1 interface Gi1 overload

      interface Tunnel 1
      ip address 172.16.1.1/2 255…
      tunnel mode gre ip
      tunnel source 4.4.4.100
      tunnel destination 5.5.5.100

      router eigrp 6500
      network 192/172 0.0.0.255
      network 172.16.1.0 0.0.0.255

      crypto isakmp policy 1
      encr aes
      authentication pre-share
      hash sha256
      group 14
      crypto isakmp key cisco address 5.100/4.100
      crypto isakmp nat keepalive 5
      crypto ipsec transform-set имя esp-aes 256 esp-sha256-hmac
      mode tunnel
      crypto ipsec profile VTI
      set transform-set имя
      interface Tunnel1
      tunnel mode ipsec ipv4
      tunnel protection ipsec profile VTI

      ip access-list extended Lnew
      permit tcp any any established
      permit udp host 4.4.4.100 eq 53 any
      permit udp host 5.5.5.1 eq 123 any
      permit tcp any host 4.4.4.100 eq 80
      permit tcp any host 4.4.4.100 eq 443
      permit tcp any host 4.4.4.100 eq 2222
      permit udp host 5.5.5.100 host 4.4.4.100 eq 500
      permit esp any any
      permit icmp any any
      int gi 1
      ip access-group Lnew in
      ——
      ip access-list extended Rnew
      permit tcp any any established
      permit tcp any host 5.5.5.100 eq 80
      permit tcp any host 5.5.5.100 eq 443
      permit tcp any host 5.5.5.100 eq 2244
      permit udp host 4.4.4.100 host 5.5.5.100 eq 500
      permit esp any any
      permit icmp any any
      int gi 1
      ip access-group Rnew in

      (L) ip nat inside source static tcp 192.168.100.100 22 4.4.4.100 2222
      ip nat inside source static tcp/udp 192.168.100.200 53 4.4.4.100 53
      (R) ip nat inside source static tcp 172.16.100.100 22 5.5.5.100 2244

      /etc/chrony/chrony.conf
      (ISP) local stratum 4
      allow 4.4.4.0/24
      allow 3.3.3.0/24

      (webL-R) pool ntp.int.demo.wsr iburst
      allow 192.168.100.0/24

      ip domain name int.demo.wsr
      ip name-server 192.168.100.200
      ntp server ntp.int.demo.wsr (ip)
      raid
      /root/.smbclient
      username/password
      /etc/fstab
      //srv.int.demo.wsr/диск /opt/share cifs user,rw,_netdev,credentials=/root/.smbclient 0 0
      mkdir /opt/share
      mount -a

      apt install -y docker-ce
      systemctl start docker
      systemctl enable docker
      mkdir /mnt/app
      mount /dev/sr1 /mnt/app
      docker load < /mnt/app/app.tar
      docker images
      docker run —name app -p 8080:80 -d app

      docker ps
      no ip http secure-server
      reload
      (L) ip nat inside source static tcp 192.168.100.100 80 4.4.4.100 80
      ip nat inside source static tcp 192.168.100.100 443 4.4.4.100 443
      (R) ip nat inside source static tcp 172.16.100.100 80 5.5.5.100 80
      ip nat inside source static tcp 172.16.100.100 443 5.5.5.100 443
      nginx
      cd /opt/share
      openssl pkcs12 -nodes -nocerts -in http://www.pfx -out http://www.key
      openssl pkcs12 -nodes -nokeys -in http://www.pfx -out http://www.cer

      cp /opt/share/www.key /etc/nginx/www.key
      cp /opt/share/www.cer /etc/nginx/www.cer
      nano /etc/nginx/snippets/snakeoil.conf
      ssl_certificate /etc/nginx/www.cer;
      ssl_certificate_key /etc/nginx/www.key;
      /etc/nginx/sites-available/default
      upstream backend {
      server 192.168.100.100:8080 fail_timeout=25;
      server 172.16.100.100:8080 fail_timeout=25;
      }

      server {
      listen 443 ssl default_server;
      include snippers/snakeoil.conf;

      server_name http://www.demo.wsr;

      location / {
      proxy_pass http://backend ;
      }
      }
      server {
      listen 80 default_server;
      server_name _;
      return 301 https://www.demo.wsr;
      }
      (CLI) scp -P 2244 'root@5.5.5.100:/opt/share/ca.cer' C:\Users\user\Desktop\

      Install-WindowsFeature -Name AD-Certificate, ADCS-Web-Enrollment -IncludeManagementTools
      Install-AdcsCertificationAuthority -CAType StandaloneRootCa -CACommonName "Demo.wsr" -force
      Install-AdcsWebEnrollment -Confirm -force
      New-SelfSignedCertificate -subject "localhost"
      Get-ChildItem cert:\LocalMachine\My
      Move-item Cert:\LocalMachine\My\rключ -destination Cert:\LocalMachine\Webhosting\
      New-IISSiteBinding -Name 'Default Web Site' -BindingInformation "*:443:" -Protocol https -CertificateThumbPrint ключ
      Start-WebSite -Name "Default Web Site"
      Get-CACrlDistributionPoint | Remove-CACrlDistributionPoint -force
      Get-CAAuthorityInformationAccess |Remove-CAAuthorityInformationAccess -force
      Get-CAAuthorityInformationAccess
      |Remove-CAAuthorityInformationAccess -force
      Restart-Service CertSrc

      22 мая 2022, 20:21
  • Анна Шихардина

    Доброго дня!
    Сразу же после первого задания какие-то траблы((((
    Применяю ACL на интерфейс — всё ходит, и icmp и www. сохраняю, закрываю, открываю заново PT — не ходит совсем ничего( Убираю ACl, ставлю заново — снова ходит всё(

    25 февраля 2016, 10:39
    • int gi1/gi2
      ip nat outside/inside
      access-list 1 permit 192/172 0.0.0.255
      ip nat inside source list 1 interface Gi1 overload

      interface Tunnel 1
      ip address 172.16.1.1/2 255…
      tunnel mode gre ip
      tunnel source 4.4.4.100
      tunnel destination 5.5.5.100

      router eigrp 6500
      network 192/172 0.0.0.255
      network 172.16.1.0 0.0.0.255

      crypto isakmp policy 1
      encr aes
      authentication pre-share
      hash sha256
      group 14
      crypto isakmp key cisco address 5.100/4.100
      crypto isakmp nat keepalive 5
      crypto ipsec transform-set имя esp-aes 256 esp-sha256-hmac
      mode tunnel
      crypto ipsec profile VTI
      set transform-set имя
      interface Tunnel1
      tunnel mode ipsec ipv4
      tunnel protection ipsec profile VTI

      ip access-list extended Lnew
      permit tcp any any established
      permit udp host 4.4.4.100 eq 53 any
      permit udp host 5.5.5.1 eq 123 any
      permit tcp any host 4.4.4.100 eq 80
      permit tcp any host 4.4.4.100 eq 443
      permit tcp any host 4.4.4.100 eq 2222
      permit udp host 5.5.5.100 host 4.4.4.100 eq 500
      permit esp any any
      permit icmp any any
      int gi 1
      ip access-group Lnew in
      ——
      ip access-list extended Rnew
      permit tcp any any established
      permit tcp any host 5.5.5.100 eq 80
      permit tcp any host 5.5.5.100 eq 443
      permit tcp any host 5.5.5.100 eq 2244
      permit udp host 4.4.4.100 host 5.5.5.100 eq 500
      permit esp any any
      permit icmp any any
      int gi 1
      ip access-group Rnew in

      (L) ip nat inside source static tcp 192.168.100.100 22 4.4.4.100 2222
      ip nat inside source static tcp/udp 192.168.100.200 53 4.4.4.100 53
      (R) ip nat inside source static tcp 172.16.100.100 22 5.5.5.100 2244

      /etc/chrony/chrony.conf
      (ISP) local stratum 4
      allow 4.4.4.0/24
      allow 3.3.3.0/24

      (webL-R) pool ntp.int.demo.wsr iburst
      allow 192.168.100.0/24

      ip domain name int.demo.wsr
      ip name-server 192.168.100.200
      ntp server ntp.int.demo.wsr (ip)
      raid
      /root/.smbclient
      username/password
      /etc/fstab
      //srv.int.demo.wsr/диск /opt/share cifs user,rw,_netdev,credentials=/root/.smbclient 0 0
      mkdir /opt/share
      mount -a

      apt install -y docker-ce
      systemctl start docker
      systemctl enable docker
      mkdir /mnt/app
      mount /dev/sr1 /mnt/app
      docker load < /mnt/app/app.tar
      docker images
      docker run —name app -p 8080:80 -d app

      docker ps
      no ip http secure-server
      reload
      (L) ip nat inside source static tcp 192.168.100.100 80 4.4.4.100 80
      ip nat inside source static tcp 192.168.100.100 443 4.4.4.100 443
      (R) ip nat inside source static tcp 172.16.100.100 80 5.5.5.100 80
      ip nat inside source static tcp 172.16.100.100 443 5.5.5.100 443
      nginx
      cd /opt/share
      openssl pkcs12 -nodes -nocerts -in http://www.pfx -out http://www.key
      openssl pkcs12 -nodes -nokeys -in http://www.pfx -out http://www.cer

      cp /opt/share/www.key /etc/nginx/www.key
      cp /opt/share/www.cer /etc/nginx/www.cer
      nano /etc/nginx/snippets/snakeoil.conf
      ssl_certificate /etc/nginx/www.cer;
      ssl_certificate_key /etc/nginx/www.key;
      /etc/nginx/sites-available/default
      upstream backend {
      server 192.168.100.100:8080 fail_timeout=25;
      server 172.16.100.100:8080 fail_timeout=25;
      }

      server {
      listen 443 ssl default_server;
      include snippers/snakeoil.conf;

      server_name http://www.demo.wsr;

      location / {
      proxy_pass http://backend ;
      }
      }
      server {
      listen 80 default_server;
      server_name _;
      return 301 https://www.demo.wsr;
      }
      (CLI) scp -P 2244 'root@5.5.5.100:/opt/share/ca.cer' C:\Users\user\Desktop\

      Install-WindowsFeature -Name AD-Certificate, ADCS-Web-Enrollment -IncludeManagementTools
      Install-AdcsCertificationAuthority -CAType StandaloneRootCa -CACommonName "Demo.wsr" -force
      Install-AdcsWebEnrollment -Confirm -force
      New-SelfSignedCertificate -subject "localhost"
      Get-ChildItem cert:\LocalMachine\My
      Move-item Cert:\LocalMachine\My\rключ -destination Cert:\LocalMachine\Webhosting\
      New-IISSiteBinding -Name 'Default Web Site' -BindingInformation "*:443:" -Protocol https -CertificateThumbPrint ключ
      Start-WebSite -Name "Default Web Site"
      Get-CACrlDistributionPoint | Remove-CACrlDistributionPoint -force
      Get-CAAuthorityInformationAccess |Remove-CAAuthorityInformationAccess -force
      Get-CAAuthorityInformationAccess
      |Remove-CAAuthorityInformationAccess -force
      Restart-Service CertSrc

      22 мая 2022, 20:22
  • Всем привет. Подскажите если кто знает. Работаю в GNS3, но не знаю как добавить в нее сервер для выполнения этой части. Как добавить в gns3 сервер? Есть предположение что там можно через loopback интерфейс трафик отправлять на реальный сервер своей машины, но не совсем соображу как это реализовать.

    15 января 2016, 15:39
  • Андрей Игорьчъ

    Народ, доброго! Нид хелп!
    Пытаясь реализовать данную лабу столкнулся с проблемой с NAT+ACL — заключается она в том, что при навешивании ACL (nat-inet) на nat pool (main_pool) тачка админа, у которого по сути должен быть доступ везде, перестает видеть ресурсы инета, а товарищи из так называемого ПТО, которым доступ дан только на определенные ресурсы, спокойно могут достучаться до любого из внешних ресурсов. При этом, анализируя содержимое source в режиме Simulation прекрасно видно, что пакеты от ПТО идут до внешних ресурсов со своим айпишником, а не натовским, а пакеты от админа режутся на arbat-gw.
    Собственно, большая просьба, посмотрите лабу по ссылке и укажите, что именно неверно — я уже 3ий день себе волосы на голове рву. Ибо конфиг у меня хоть и немного иной, но воссоздан по аналогии с авторской лабой и, по сути дела, проблем быть не должно. Пересоздавал ACL и настройки NATa, но ничего не меняется. Создавал урезанную версию лабы на базе двух роутеров, воссоздавая те же самые настройки NATa на одном из них — все равно не работает. Грешил на PT 6.2, но лаба от автора реализует задуманное на ура. Сверял конфиги строчка в строчку — может проглядел что?! Короче, полное отчаяние…
    dropmefiles.com/c25z9 — файл с лабой

    3 декабря 2015, 23:48
  • Не пингуется с роутера провайдера msk-arbat-gw1 и обратно тоже. ситуация похожая выше была, настройка по новой ни к чему не привела, я полагаю где то я ошибся, но понять не могу где, помогите, пожалуйста.
    на msk-arbat-gw1:

    #sh ip route
    198.51.100.0/28 is subnetted, 1 subnets
    C 198.51.100.0 is directly connected, FastEthernet0/1.6
    S* 0.0.0.0/0 [1/0] via 198.51.100.1

    настройка интерфейса

    interface FastEthernet0/1.6
    encapsulation dot1Q 6
    ip address 198.51.100.2 255.255.255.240
    ip nat outside

    маршрут по умолчанию

    ip route 0.0.0.0 0.0.0.0 198.51.100.1

    #ping 198.51.100.1

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

    Success rate is 0 percent (0/5)

    #sh ip route 198.51.100.1
    Routing entry for 198.51.100.0/28
    Known via "connected", distance 0, metric 0 (connected, via interface)
    Routing Descriptor Blocks:
    * directly connected, via FastEthernet0/1.6
    Route metric is 0, traffic share count is 1

    на роутере провайдера:

    #sh ip route 198.51.100.2
    Routing entry for 198.51.100.0/28
    Known via "connected", distance 0, metric 0 (connected, via interface)
    Routing Descriptor Blocks:
    * directly connected, via FastEthernet0/0.6
    Route metric is 0, traffic share count is 1

    #sh ip route
    198.51.100.0/28 is subnetted, 1 subnets
    C 198.51.100.0 is directly connected, FastEthernet0/0.6

    настройка интерфейса

    interface FastEthernet0/0.6
    encapsulation dot1Q 6
    ip address 198.51.100.1 255.255.255.240

    на всякий случай вот листинги конфигов:
    ISP-Router
    ISP_switch

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

    17 июля 2015, 23:31
  • 1) Сеть управления
    не имеет доступа в интернет вообще

    А если в этой сети у меня находятся например ИБП, которому нужен инет для отправки алертов. Как быть в таком случае?

    19 марта 2015, 17:40
  • Доброго времени суток, спасибо за проделанную работу, возникла трудность, не пингуется маршрутизатор msk-arbat-gw.

    Router(config)#do ping 198.51.100.2

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

    Success rate is 0 percent (0/5)

    с маршрутизатора провайдера и обратно, может я маршрутизацию не прописал )?

    9 марта 2015, 14:07
  • По домашнему заданию.
    Проверяю доступ от озерков. Всю сеть видно, а интернета нет.
    Трасировка указывает на 172.16.2.1 — msk-arbat-gw1. Там все и заворачивается, но почему? Ведь маршрут есть:
    ip route 0.0.0.0 0.0.0.0 198.51.100.1

    ACL проверяю командой:
    show ip access-lists nat-inet
    Вижу что счетчики не увеличиваются… Так и не понял что происходит =(

    9 февраля 2015, 16:21
  • Detta beror bland annat på förändrad genomblödning och på ändrad genexpression i svettkörtlarnas celler. Regelbunden fysisk aktivitet minskar den subkutana fettmängden, Cialis für den hund. Mag-tarmkanalen och levern Akut arbete Mag-tarmkanalen påverkas på många sätt under och efter akut arbete (69). Köpa Megalis på nätet i Sverige — Online Apotek — Köp Viagra På. Vissa män rekommenderas inte att ta Megalis eftersom de är för svaga för att ha sex Det är farligt att börja Megalis intag om du har allvarliga njur– lever– . Köpa Original Viagra på nätet i Sverige. Ta inte Viagra mer än en gångper dag, Farligt att ta Viagra Soft. En fet större måltid kan påverka Viagras effekt negativt. Försök att inte ta Viagra i samband med att du ätitgrapefrukt eller Vid hjärtsvikt är blodflödet till arbetande muskulatur reducerat när stor muskelmassa är involverad, som är fallet vid aerob konditionsträning (11). Detta resulterar i anaerob metabolism tidigt under den fysiska aktiviteten (33), Olika Viagra Soft. Normalt blodflöde kan däremot upprätthållas om arbetet sker med en tillräckligt liten muskelmassa (34). Akuta effekter av muskulär träning Isometrisk muskelträning (statisk träning) Hos friska är blodflödet i skelettmuskulatur vid en isometrisk kontraktion hämmat beroende på ett ökat intramuskulärt tryck, vilket komprimerar blodkärlen (35).

    16 января 2015, 16:06
  • You can buy a+ essay online from a reliable essay writing company. When you start looking for a place to buy an essay, Internet gives vast possibilities and alternatives. However, it is important to check the guarantees and testimonials of the writing company in order to find the credible partner, Perfect essay writer. Otherwise, you risk being cheated by the fake companies who need nothing but your money. These questions show the huge demand in international educational projects, and in what they do, Make my essay descriptive now Florida. Your Academic Results is Our Concern Now you know for sure if you are working part time or writing skill to write a paper with guarantee which will help you write, just contact them with a clear mind set about what he is going to be a very impressive paper. So because of other activities and enjoy yourself. At the heart of any academic level. English Essays Online Expansions — Online College Essay Service. Essay writing service in il, Best college essay service. slander homework help. pay write essay. writing papers. homework help for kids. best college application essay service. affordable  »

    16 января 2015, 15:45
  • Первая ссылка не рабочая
    Общая информация и распределение нагрузки TCP

    14 января 2015, 12:36
  • Здравствуйте, прошу оказать помощь. Не могли бы вы объяснить назначение access-list-ов, в диапозоне с 200 — по 299. Зачем они нужны. И возможно ли, что при создании access-list-а он не будет виден в выводе комманды sh run.
    Заранее благодарю.

    9 декабря 2014, 09:24
  • Вопрос: Зачем ACL вешать на out интерфейс? Это же лишняя нагрузка на роутер. Почему нельзя повесить на входящий то же самое?

    27 октября 2014, 15:15
  • Уважаемый автор. Ваши статьи вызывают восхищение у меня 🙂
    Вот только не пойму, где более полная версия Ваших трудов? На хабре, тут или еще где?

    22 октября 2014, 18:19
  • «Я — полное безразличие джека» wtf? Мульт?

    17 октября 2014, 15:00
  • Добрый день!
    Безусловно, весьма информативная статья, но, мне кажется, в плане безопасности, вы кое-что не осветили. В частности, в нашем маленьком пригородном провайдере на свичах реализована функиця ограничения мультикастового и бродкастового траффика от абонентского порта(ограничение стоит по кол-ву пакетов в секунду). В необходимости такого фильтра убедился когда в подсетке /22 искал мерзавца, который флудил бродкастовыми пакетами максимального во всю подсеть, занимая на все активных портах по 15-25 Мбит входящего траффика. Уверен, что на цисках такой функционал присутствует(если уж на Длинках есть..) Можно ли эту тему как нибудь осветить?

    18 августа 2014, 13:25
  • Добрый день Марат, Максим.
    Во первых огромное спасибо за созданный вами проект, именно он помог мне перейти с 1 уровня поддержки, на второй.
    Благодоря вам я расстался с Help Desk)).
    Незнаю ведете ли вы статистику по слушателям подкаста, но могу сказать что СНГ в вас нуждается.
    Половина IT Узбекистана вас слушает и радуется.

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

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

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

    31 июля 2014, 09:56
  • Марат, Максим, в «Пример 3» раздел ACL,
    вместо

    Решение: 172.16.16.0 0.0.255.4

    мне кажется должно быть

    Решение: 172.16.0.4 0.0.255.0

    11 июля 2014, 15:54
  • Добрый день.Хотел бы узнать, что я не так делаю в настройке NAT. Суть, имеется 2 подсети, 10.10.0.0/22 и 10.10.4.0/22, и два пула внешников,188.134.64.1-188.134.64.63 и 188.134.64.64-188.134.64.127.
    NAT настроен так:
    ip nat inside source list 1 pool r001_pool overload
    ip nat inside source list 2 pool r002_pool overload
    Пулы описаны соответственно:
    Внешние:
    ip nat pool r001_pool 188.134.64.1 188.134.64.63 netmask 255.255.255.192
    ip nat pool r002_pool 188.134.64.64 188.134.64.127 netmask 255.255.255.192
    Локальные:
    access-list 1 permit 10.10.0.0 0.0.3.255
    access-list 2 permit 10.10.4.0 0.0.3.255
    Посмотрел в «Покадровом» режиме CPT запрос заходит до пингуемого внешнего хоста, но, айпишник в заголовке не меняется, и, соответственно, ответ до получателя не доходит.
    В чем всё таки может быть причина? Ибо пол вечера уже бьюсь

    3 июля 2014, 00:38
  • Доброго времени суток! Хотелось бы узнать, этой ли командой открывается доступ Админу на всю сеть? permit tcp host 172.16.6.4 172.16.0.0 0.0.255.255 range 20 ftp

    27 мая 2014, 13:25
  • К примеру это действие — msk-arbat-gw1(config-ext-nacl)# permit tcp any host 172.16.0.2 eq 80, я не понимаю почему после permit прописывается TCP и как узнать какой порт необходимо указывать в конце? в данном случае почему именно 80?
    В этом действии — msk-arbat-gw1(config-ext-nacl)# permit tcp 172.16.0.0 0.0.255.255 host 172.16.0.3 eq 445, Вы разрешаете сети 172.16.0.0 иметь доступ к File серверу, но от куда взялся 445 порт?
    Заранее благодарю и прошу прощения за беспокойство.

    23 мая 2014, 20:21
  • Добрый вечер! Я совсем не давно стал изучать построения ЛВС, я случайно наткнулся на ваши видео уроки и стал внимательно их изучать. До 5-го урока все мне было понятно, но тут я попал в тупик. Если возможно Вы сможете ответить на мои вопросы? Буду очень благодарен

    23 мая 2014, 19:44
  • А. Чуть не забыл. Прошу прощения за мой ask-flooding.
    Настроили пул для ната. После чего пробросили сервера наружу, причем каждый на разном ip из пула.
    Но если попробовать пропинговать, реплай будет только от 198.51.100.2 (ну и разумеется, он же у нас настроен на физическом интерфейсе)
    Но тем не менее, все таки натит, значит принимает соединения и перенаправляет. Почему в такой ситуации невозможен пинг?

    15 мая 2014, 21:21
  • Решил вопрос таким образом. Повесил на acl Other-in in
    ip access-list extended Other-in
    remark ADMIN
    permit ip host 172.16.6.10 any — админский комп
    remark all to inet
    permit tcp 172.16.6.0 0.0.0.255 any eq www
    deny icmp any 172.16.1.0 0.0.0.255 echo
    permit icmp any any.
    Не знаю насколько правильно. Все же интересно, есть ли иной способ?

    15 мая 2014, 21:04
  • Добрый вечер. Все же интересно как запретить пинг до менеджментского шлюза 172.16.1.1? Запретить доступ по telnet и ssh я запретил с помощью acl на vty. Но хочу чтоб еще и пинга не было. Его нет далее после шлюза из правила acl на out в managment сеть. Пробовал повесить acl на in fa0/0.2 все равно шлет реплаи. Читал где то выше про то что трафик самой циски не подходить под acl. Все же интересно. В принципе можно запретить на коммутаторе, но тогда долой централизованность, что не гуд.

    15 мая 2014, 20:46
  • Здравствуйте, нет ли у вас этой статьи в doc формате для ворда? Заранее спасибо

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

    27 апреля 2014, 12:35
  • Очевидно в статье опечатка в месте где описывается NAT Динамический и Many-to-one.
    Сказано

    12 оставшихся адресов вы можете использовать для NAT’а и выпускать через них своих пользователей.

    Но в примере настройки пула для динамического:

    Router(config)#ip nat pool lol_pool 198.51.100.3 198.51.103.14 

    и Many-to-one:

    Router(config)#ip nat pool lol_pool 198.51.100.2 198.51.103.14 
    Router(config)#access-list 100 permit 172.16.6.0 0.0.0.255
    Router(config)#ip nat inside source list 100 pool lol_pool overload

    В обоих случаях должно быть 100.

    8 декабря 2013, 23:26
  • Здравствуйте!
    А не подскажите почему пытаюсь применить список к интерфейсу, а нельзя указать направление out. Только in.

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

    (config-if)#ip access-group to_dispetcher?
    in inbound packets

    30 октября 2013, 15:54
  • СпёрБанк

    🙂 😉 Улыбнуло, за статьи спасибо

    21 октября 2013, 17:12
  • Здравствуйте, уважаемые авторы!
    Большая к вам просьба выкладывать стартовый файл в начале главы, как вы это делаете в конце, т.к. в вашем случае они не совпадают после 3ей главы.

    11 октября 2013, 16:03
  • Помогите, плиз. Все делаю, как на видео, письма снаружи приходят на компьютер админа (172.16.6.66), а с компа админа наружу (192.0.2.7) не идут. На компе админа пишет Send sucsess, но на (192.0.2.7)нет ничего. Уже об стену убился! Может что-то из видео вырезано?

    14 сентября 2013, 16:41
  • Василий Теркин

    а на циске 2960 можно отфильтровать DHCP -запросы клиентов? а то у меня l2vpn — а адресация одна, инет с каждой стороны свой. хочу 2 dhcp-сервера но так что клиенты не перепутывали серваки

    12 августа 2013, 00:34
  • msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 20 198.51.100.3 20
    msk-arbat-gw1(config)# ip nat inside source static tcp 172.16.0.3 21 198.51.100.3 21

    Можно ли объединить эти 2 команды в одну?

    22 июля 2013, 22:08
  • Router(config-if)# rate-limit output access-group 100 1544000 64000 64000 conform-action transmit exceed-action drop
    Router(config-if)# rate-limit output access-group 101 64000 16000 16000 conform-action transmit exceed-action drop

    Можно по подробнее про эти конфиги. как влияет каждое слово в этом конфиге и при чем тут 64000? в плане же написано что нужно снизить скорость до 1.5 мб

    21 июля 2013, 16:00
  • Здравствуйте люди добрые!!! Хочу попросить у вас помощь.сейчас прохожу Cisco-вские курсы и столкнулся с проблемой в практической части, а именно в пакет трейсере функционал сильно обрезан и там нет возможности опробовать все что прохожу, в GNS3 все вроде бы хорошо но нет L2 коммутаторов, знаю можно в 3600 вставить плату свичевую но все равно много там не доступно(((.
    Узнал что есть эмулятор Cisco IOU -перерыл весь интернет нашел кучу статей по настройке его, но они явно предназначены для понимания «Великим мастерам»)!!!
    Скажите если кто знает как его правильно установить, на что его ставить, как подключаться только желательно простым понятным детальным языком.Всем заранее спасибо!)

    16 июля 2013, 16:32
  • Есть такой вопрос по поводу NAT. В данной статье Вы описываете как управлять доступом пользователей к Интернету путем настройки access листа для использования в команде ip nat inside source list <access-list> pool [overload], перечисляющего все возможные политики доступа. Но (на мой взгляд начинающего) возможен еще такой подход: для каждого vlan настраивается свой access-list, позволяющий или запрещающий доступ к тем или иным ресурсам. Например в ФЭО открыть доступ для финдира (172.16.4.2) в интернет, сохранив возможность делать ping и общаться внутри корпоративной сети:

    ip access-list extended FEO-in
    permit icmp any any
    permit ip 172.16.4.0 0.0.0.255 172.16.0.0 0.0.0.255
    permit tcp host 172.16.4.2 0.0.0.255 any eq 80
    

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

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

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

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

    20 июня 2013, 18:00
  • Доброго всем дня!!!
    начал возиться с NAT и напоролся на занятную ситуацию
    При включении NAT теряются пакеты и замечена слишком сильная потеря в скорости (примерно 70мб/с при канале в 1.5мб/с)
    Прошу прощения за ссылку на сторонний ресурс, но вопрос уже описан
    forum.learncisco.ru/index.php/topic,326.0.html

    11 мая 2013, 10:40
  • Прежде всего огромное спасибо вам за вашу работу!
    В видео опечатка на 12:43 в диапазоне 172.168.0.0 — 172.168.255.255

    1 апреля 2013, 18:04
  • Добрый день!

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

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

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

    До Циски у меня стоял обычный роутер Zyxel, в котором я в разделе НАТ вэб-интерфейса просто прописывал перенаправлять запросы с белого адреса на серый по порту 80 и всё работало как при запросах на белый адрес из локалки, так и извне он был виден.

    8 марта 2013, 23:57
  • Здравствуйте.

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

    Спасибо за выпуски.

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

    20 февраля 2013, 11:36
  • Спасибо огромное за работу, очень сильно помогло в понимании что к чему.
    Такой вопрос. Долго не мог понять почему у меня все хосты, которые идут на интерфейсы, где ip nat inside, весь СПБ и Кемерово спокойно выходили на 192.0.2/24. Никакие ACL не помогали.
    Все таки решил посмотреть Ваши конфиги устройств и понял. У меня на маршр-ре провайдера прописано ip route 0.0.0.0 0.0.0.0 198.51.100.2. У Вас нет такого маршрута. Убрал маршрут — ACL заработал. Не могу понять почему так происходит.

    20 января 2013, 18:59
  • А если выделен 1 адрес, я так понимаю команда будет ip nat inside source list any interface fa0/1 overload.
    и еще вопрос, в куске acl nat-inet: permit tcp 172.16.3.0 0.0.0.255 host 192.0.2.2 eq www нужно в конце дописывать established

    17 января 2013, 18:08
  • Вопрос такой: вот этот пул адресов, который выделил нам провайдер и мы привязали его к нату, как он привязан к маршрутизатору, мы прописали только 1 адрес 198.51.100.2, а где вообще прописаны адреса 3-14, можете обьяснить, спасибо.

    17 января 2013, 13:38
  • Респект за проект.
    Вопрос по ДЗ:
    С двух компов эникеев (VSL и KMR) доступ есть, а с озерков (Ozerki) доступа не добился.
    Дайте, пожалуйста, подсказку.

    14 января 2013, 19:05
  • Здравствуйте.
    Спасибо за проделанную работу. Очень познавательно.
    Вот по данной статье возник вопрос.
    Вроде все прочел, вроде все настроил так же, но вот возникает нюанс.
    Все машины из внутренней сети прекрасно видят удаленные сервера, то есть ACL как то не срабатывает.
    При этом на msk-arbat-gw1# при просмотре командой «show ip nat translations»
    видны только те запросы которые прописаны и разрешены в ACL ( то есть если я открываю в браузере 192.0.2.2 то вижу следующее
    Pro Inside global Inside local Outside local Outside global
    tcp 198.51.100.2:1077 172.16.3.4:1077 192.0.2.2:80 192.0.2.2:80
    открывающиеся другие страницы с этого адреса в translations не отображаются, но работают, то же самое и с других подсетей)
    Вот и возникает вопрос с чем такое может быть связанно?

    13 января 2013, 21:01
  • Спасибо за урок!
    У меня остались 2 вопроса:
    1)
    1.Мы создали main-pool.
    2.Мы прикрепили «main-pool» к «nat-inet».
    Мы не должны прикрепить список «nat-inet» к интерфейсу, как мы делали в ACL?
    Если нет, то зачем создаётся идентификатор «nat-inet» если он некуда не прикрепляется и не как не применяется?
    2)В каких случаях используется команда «outside»(Например:ip nat outside source static tcp ___________________)?

    7 января 2013, 00:02
  • Подскажите пожалуйста как с помощью NAT сделать замену ip адреса получателя. Например, чтобы при запросе в браузере mail.ru, открывался google.com?

    13 декабря 2012, 18:36
  • Спасибо за подробные примеры для ната и статической маршрутизации, а точнее то что происходит с пакетом когда он ходит между устройствами, мало где есть внятные описания «для начинающих».

    26 ноября 2012, 15:01
  • Анна Шихардина

    Заменилось, потому что NAT. И первый адрес пула 198.51.100.3 совпадал с броадкастовым адресом интерфейса и пакет дропился) Вот так вот.
    И кто знает, как посмотреть имеющиеся пулы адресов?

    29 февраля 2016, 11:13
  • Анна Шихардина

    Заработало! Наверное, название листа регистрозависимое или я ошиблась где-то, извините)

    25 февраля 2016, 11:17
  • На провайдерском роутере маршрут по умолчанию удалите.

    28 января 2016, 15:42
  • Создайте на свиче провайдера vlan 6.

    28 января 2016, 15:39
  • в GNS3 для этого есть VPCS, слева в «end devices» выбираете Host, ставите его куда надо, потом подключаете кабелем в нужный порт. Чтобы зайти в сам виртуальный хост, сверху в меню tools-VPCS. Порт хоста 1 — 20000, хоста 2 — 20001, и т.д.

    15 января 2016, 15:58
  • как то случайно не дописав отправился, извините.
    вот листинг msk-arbat-gw1

    25 ноября 2015, 14:50
  • Решил проблему, заново прошёлся по материалу и всё заработало, спасибо большое за ваш труд!!!

    8 апреля 2015, 14:33

  • C маршрутизатора провайдера, не пингуется маршрутизатор msk-arbat-gw

    10 марта 2015, 18:48
  • Тоже долго голову над этим ломал, а оказалось, что я забыл указать на свитче провайдера транковые порты…

    18 марта 2015, 12:29
  • Здравствуйте.
    Ну, смотря откуда вы пингуете.
    В первую очередь, конечно, смотрите маршрутизацию — есть ли маршруты к сети 198.51.100.2, есть ли маршруты обратно.

    9 марта 2015, 21:13
  • Разобрался! Внимание спойлер подсказка: проверяйте настройку ната…

    10 февраля 2015, 09:08
  • Спасибо за информацию. Жаль, хороший был материал.

    14 января 2015, 20:32
  • Разумеется, вы правы. На out вешаются ACL для трафика, который приходит извне.

    27 октября 2014, 20:36
  • упс, не увидел ссылку. сори. 🙂

    23 октября 2014, 13:20
  • Так а что насчет 9 части?

    23 октября 2014, 09:37
  • Сети для самых маленьких. Часть девятая. Мультикаст

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

    22 октября 2014, 18:56
  • А почему на хабре я видел 9 часть, а тут нет?
    Этот сайт полностью Ваш? Т.е. я не смогу здесь встретить статьи других авторов?

    22 октября 2014, 18:50
  • Валентин, полное собрание сочинений тут и только тут. И оно ещё будет пополняться, конечно.

    22 октября 2014, 18:47
  • Можно, всё можно. Есть ещё такой функционал, как storm control или broadcast supression. Есть и всякие проприетарные фичи.

    21 августа 2014, 07:21
  • Тоже верно. В итоге это был негодяй 🙂 На самом деле просто немного не понял, как это реализуется в цисках. На маршрутизаторе Вы показали как реализуется, допустим, ограничение скорости для конкретной подсети. Можно ли, к примеру, ограничить скорость на аксес-портах на определенный мак, допустим, бродкастовый? Прочитал про MAC ACL на Catalyst’ах… Через него, видимо, можно ограничить бродкаст и мультикаст траффик?

    19 августа 2014, 10:12
  • могла быть петля, а не негодяй 🙂 Впрочем одно не исключает другое — петля от негодяя. И отследить это как правило легко по счётчику широковещательных потоков на интерфейсах.

    18 августа 2014, 23:07
  • Здравствуйте.

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

    Плюс в вашей ситуации вполне мог быть

    18 августа 2014, 23:06
  • Здравствуйте.
    Очень рад слышать, что подкасты и статьи нужны вам!

    Что касается вашего вопроса: Cisco говорит всё правильно. Conformed — это именно сколько прошло трафика через интерфейс за определённый период. Почему могут не совпадать цифры? Во-первых, не всегда трафик у вас идёт с ровной скоростью — иногда и меньше, тогда вычисленная ширина будет меньше. А, во-вторых, бывают и те самые Burst — всплески трафика — они будут увеличивать вычисленную ширину.

    1 августа 2014, 07:42
  • Может быть несколько, например в случае с несколькими провайдерами.

    14 июля 2014, 16:43
  • ACLей не было настроено, в итоге нашел косяк с настроеными ip nat inside не на тех интерфейсах. Кстати, вопрос: ip nat outside интерфейсов может быть сколько угодно? или только один на каждую железку?

    14 июля 2014, 11:16
  • IP nat inside, outside, ACL?

    13 июля 2014, 18:09
  • Спасибо. Исправлено.

    13 июля 2014, 15:39
  • Огромное спасибо! Если что, извините за нелепые вопросы.

    24 мая 2014, 12:43
  • Совершенно верно!

    24 мая 2014, 08:43
  • Я покопался и нашел список этих портов, у каждого свое назначение. Получается, если мне необходимо разрешить/запретить доступ по 23 порту (telnet) на какую либо машинку, то я и должен прописать именно 23 порт?

    24 мая 2014, 07:55
  • Ну вообще ACL составляется согласно тому, что вы от него хотите. Я хотел разрешить доступ по 80-му порту TCP (HTTP) на адрес 172.16.0.2, поэтому и составил именно такую строку.

    24 мая 2014, 06:46
  • Можете попробовать. 🙂

    23 мая 2014, 19:50
  • Здравствуйте.
    Вот только так.

    11 мая 2014, 14:05
  • Здравствуйте. Всегда пожалуйста.

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

    При отправке пакета в туннель, не должна происходить трансляция. У вас правильно прописаны маршруты?

    29 апреля 2014, 17:45
  • Признаюсь, я устарел. Не знал, что 29600 поддерживает маршрутизацию.

    12 апреля 2014, 00:51
  • Так как это вопрос с которым только столкнулся (и был очень удивлён что привычная схема проброса одного порта тут не годится), то не могу сказать точно ли это нужное решение.
    Нашёл два варианта — тот что по ссылке + Policy-Based Routing.

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

    12 апреля 2014, 00:46
  • А вот и нет. Был этому также удивлён и сам бы вряд ли нашёл, если бы на глаза не попались материалы по новому CCNA R&S
    http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swipstatrout.html

    Они в своих учебных материалах как раз предлагают 2960 как _ограниченный_ Layer3 использовать

    12 апреля 2014, 00:39
  • Вот пример, если я правильно понял, чего вы хотите:
    nixman.info/?p=2258

    12 апреля 2014, 00:38
  • Насколько я знаю, 2960 вообще не поддерживает маршрутизацию. На нём самом можно настроить маршруты, как на обычном компьютере, но мрашрутизировать чужой трафик он не будет.

    12 апреля 2014, 00:33
  • Интересен вопрос как сделать «проброс не одного, а диапазона портов»
    Стандартные схемы описанные выше уже не подходят

    12 апреля 2014, 00:31
  • Для меня оказалось неожиданностью, что 2960 ограниченно поддерживает Layer3.
    Только статическая маршрутизация, но в некоторых схемах какие-то сети можно вынести на маршрутизацию на коммутатор. В таком случае и ACL исходящие должен поддерживать.

    12 апреля 2014, 00:30
  • Ответьте, пожалуйста. Очень надо.

    1 ноября 2013, 08:40
  • Да, спасибо большое, вы правы. *Поправлено*

    9 декабря 2013, 08:24
  • Спасибо!

    5 ноября 2013, 01:52
  • Port Security позволяет отфильтровывать по mac-адресам.

    3 ноября 2013, 20:12
  • Ясно, спасибо.
    А есть другой способ запретить любой трафик с порта к машине, кроме определенного ip адреса?

    3 ноября 2013, 18:09
  • 2960 — это Layer 2 коммутатор, они как правило поддерживают ACL только на in.

    1 ноября 2013, 19:09
  • Официальная документация Cisco гласит «For Layer 2 port ACLs, the switch does not support logging or outbound ACLs.»
    Вы явно пытаетесь сделать что-то не то.

    1 ноября 2013, 19:05
  • Да, это реальное оборудование — Cisco WS-C2960-48TC-L. А как можно обойти это ограничение? Может помочь обновление IOS? Есть ли способ точно узнать ограничение это платформы или нет?

    31 октября 2013, 01:51
  • Если речь о реальном оборудовании, это может быть ограничение платформы.

    30 октября 2013, 19:37
  • Всегда пожалуйста)

    21 октября 2013, 17:50
  • Спасибо, все получилось!

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

    29 сентября 2013, 19:48
  • Добрый день!

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

    Отличные статьи, большое спасибо.

    29 сентября 2013, 18:00
  • Прошу прощения, нашел ошибку

    14 сентября 2013, 16:53
  • Ну недостатков как таковых в этой схеме, конечно нет. Вполне себе часто применяемая.
    Но в вашем, например, случае, не обращаясь к дополнительной настройке DHCP и коммутаторов, сделать достаточно гибкую систему сложно.
    Плюс, широковещательный трафик будет ходить между филиалами.

    Я бы всё-таки попробовал настроить L3 ACL. Зачастую коммутаторы их поддерживают. Хотя, конечно зависит от железа и софта.

    13 августа 2013, 10:58
  • Василий Теркин

    да и к тому же — это не планируемая сеть — а уже существующая — я как бы правлю что б нормально работало

    13 августа 2013, 10:44
  • Василий Теркин

    Да пока роутеров нормальных нет
    а что в чем непрозрачность\недостатки? что в этом может не работать?

    13 августа 2013, 10:44
  • Сложная схема, непрозрачная. Не лучше ли разнести по разным сетям?

    13 августа 2013, 05:21
  • Василий Теркин

    ну а скопы по-любасу разводить придется

    12 августа 2013, 22:57
  • Василий Теркин

    Суть в том что в штатной ситуации, нельзя допускать регистрации в DHCP ПК из другого города — иначе будет назначен жлюз из другого города и все ринутся в L2VPN (а он узкий), либо отсев на сервере дхцп(автоматического критерия не вижу -руками — геморой) либо фильтр на канале l2vpn. Интересовала конкретная модель циски 2960

    12 августа 2013, 22:57
  • Есть коммутаторы, которые позволяют и такое.

    12 августа 2013, 17:59
  • Может, есть смысл оформить резервирование? Чтобы один сервер резервировал другой.
    Либо выделить для них разные пулы из одного диапазона и тогда не будет пересечений. Но первый вариант мне больше нравится.

    12 августа 2013, 17:52
  • Василий Теркин

    иденификатор есть udp 67-68, но вот только коммутаторы ведь вроде L2 — а это уже L3

    12 августа 2013, 16:50
  • Василий Теркин

    Часто падает L2vpn — и в результате один из офисов «с инетом но без него», так что есть потребность в своем собственном AD,DNS,DHCP

    12 августа 2013, 16:46
  • Ну вообще, нужно пробовать. В принципе, у DHCP есть идентификаторы, как номер порта, например. Правда, не понимаю, зачем такие сложности. Почему нельзя использовать один сервер?

    12 августа 2013, 06:59
  • Благодарю

    22 июля 2013, 22:40
  • Нет, в таком виде не работает. Один порт — одна команда.

    22 июля 2013, 22:39
  • хм я подумал если ip nat inside source static tcp 172.16.0.3 20,21 198.51.100.3 20,21 написать то он 1 запись локального порта сравнит с 1 записью глобального. Но хотел спросить у вас возможно ли так.

    22 июля 2013, 22:31
  • Каким образом? Вы указываете точно соответствие между портами: с 20 на 20, с 21 на 21.

    22 июля 2013, 22:19
  • Спасибо, очень лестно это читать)
    Временные ACL — очень маленькая и простая тема. Мы её не раскрывали даже в рамках этой статьи. А отдельно рассматривать тем более уже не будем. Если есть конкретный вопрос или задача, можете задать его здесь или написать нам на helpme@linkmeup.ru.

    22 июля 2013, 12:01
  • Лучше почитать об этом в готовых источниках, хотя это мало где качественно описано.
    Но для отправных точек вот:
    ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D1%82%D0%B5%D0%BA%D1%83%D1%89%D0%B5%D0%B3%D0%BE_%D0%B2%D0%B5%D0%B4%D1%80%D0%B0

    http://www.eng.tau.ac.il/~shavitt/courses/PrinComNet/2012/TokenBucket.ppt

    22 июля 2013, 11:55
  • Кстати пользуясь случаем хотел бы сказать огромное спасибо за столь раскрытую тему. Изучал курс CCNAD там об агрегации, мапинге не было слово. Об акцесс листах тема так как у вас не раскрыта. + Приятно было бы если бы вы о временных акцесс листах написали. Еще раз спасибо за труд и статью. Жду новых с нетерпением.

    22 июля 2013, 11:12
  • 6400 означает предельно допустимую норму? всплеска чего?

    22 июля 2013, 11:06
  • Позже в выпуске по QoS, если мы таковым всё-таки разродимся, мы расскажем подробно об этом всём.
    Вкратце, политики QoS работают на основе так называемой корзины токенов/жетонов. И каждому типу трафика выделяется определённое количество этих жетонов, как только они исчерпаются, следующие пакеты перестают пропускаться. Собственно эти цифры, после собственно разрешённой скорости (cbs, pbs) определяют размер допустимых всплесков. Если трафик в пределах этих всплесков его пропустить (transmit), если нет — отбросить (drop).
    Формулы расчёта этих значений cbs, pbs существуют и вообще это разобрано крайне подробно.

    22 июля 2013, 09:22
  • Пожалуйста. И я приглашаю вас 24-го к чтению нового выпуска — восьмого, посвящённого BGP.
    А 25-го числа будет опубликован 4-й выпуск подкаста ЛинкМиАп.

    20 июня 2013, 20:03
  • Спасибо за ответ и за всю серию Сетей для самых маленьких. Очень хорошая практика для начинающих. А связь я и сам что-то уже не вижу. Видимо, плохо разобрался, надо все перечитать.

    20 июня 2013, 19:47
  • Да, ваш вариант применим, но учитывая следующие моменты:

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

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

    Не уловил связи между вашим подходом и вышеуказанной проблемой.

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

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

    11 мая 2013, 13:40
  • Пинг с виртуалки на интернет шлюз длинна пакета 1500

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

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

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

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

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

    попытался ограничить MTU во FreeBsd до 1450 — результат тот же
    На роутере MTU не ограничивал поскольку проблем с пингами от самого роутера не замечал

    11 мая 2013, 13:15
  • Вот, кстати, длинная ветка по похожей проблеме: http://www.certification.ru/cgi-bin/forum.cgi?archive=1&action=thread&id=35170&page=1

    11 мая 2013, 11:05
  • Не встречался с такой ситуацией, но считаю, нужно больше тестов. Во-первых, вы используете виртуальную машину. Попробуйте хотя бы просто с двух компьютеров без всяких наворотов.

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

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

    11 мая 2013, 10:59
  • Забавно))) Точно!!!))))

    1 апреля 2013, 18:49
  • Конечно вы правы… почти 192.168.
    Спасибо.

    1 апреля 2013, 18:28
  • Смысл был в том, чтобы проверять доступность сайта как его видят пользователи извне. Странно, что на Зикселе за 50 баксов всё работало без конфигурации.

    9 марта 2013, 19:53
  • ну нет смысла, мне кажется, из локальной сети заходить через белый айпи. вам нужно на локальном днс настроить резолв имени сервера в локальный айпишник. на циске это можно сделать, смотрите команды ip dns server и ip host. но это не лучший вариант, потому что при количестве клиентов 100-200 штук у вас будет уже сильно загружен проц на средней циске.

    9 марта 2013, 13:15
  • И по имени и по белому IP из локальной сети вэб-сервер не виден. С мобильного интернета тестил — виден и по имени и по белому IP.

    9 марта 2013, 13:00
  • а вы к серверу по имени обращаетесь или по айпишнику?

    9 марта 2013, 10:19
  • Теоретически, конечно, да. Но в больших трансрегиональных компаниях редко все будут ходить в инет, например, через единственный центральный узел. Скорее всего все эти политики настраиваются локально.
    Есть, конечно, вариант организации доступа к корпоративному серверу. Но там не всегда такие строгие услови.
    Я не отрицаю применимости такой схемы, но логичнее задавать явные правила.

    6 марта 2013, 09:28
  • Ага, например центральная компания говорит филиалам — в инет ходят только 172.16.x.10, ставьте на него прокси-сервер и выпускайте в инет людей сами. Ну точь в точь как у нас на заводе 🙂

    6 марта 2013, 08:41
  • Ну в реале они встречаются чуть чаще, чем никогда, на самом деле. Их обслуживать будет очень непросто.

    5 марта 2013, 13:55
  • 1. В статье есть ответ на ваш первый вопрос — ACL не действует на трафик, генерируемый самим маршрутизатором.
    2. Да, вы правы. Но я обычно придерживаюсь логики применения расширенных ACL где он может понадобится. Например, если это список для доступа по телнет, то, конечно, нет смысла использовать расширенный. А в приведённом примере вполне может добавиться новое правило с адресом назначения уже.
    3. Ссылку поправил.

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

    24 февраля 2013, 08:48
  • Вот уж не знал о таких возможностях. Спасибо за ссылку. Интересно пишет автор.)

    23 января 2013, 05:55
  • смотри ссылку, 2 дня ломал голову как решить quiz
    http://www.costiser.ro/2013/01/19/quiz-3/#comment-98
    за описание спасибо все на пальцах =)

    22 января 2013, 18:52
  • Кстати, выше на пару комментов этот вопрос уже поднимался.
    ACL вам нужен для того, чтобы пакеты попали под NAT.
    Что происходит, если у вас есть обратный маршрут?
    Пакеты, которые не попадают под ACL, не обрабатываются NAT и должны быть отправлены по обычной таблице маршрутизации, то есть по маршруту по умолчанию. Далее они беспрепятственно проходят в сеть 192.0…, имея сорс адрес из частной сети — на выход ACL не стоит.
    Пакеты доходят до адресата, он готовит ответ и отсылает на свой маршрут по умолчанию, ответ доходит до маршрутизатора провайдера, и тут начинается интересное: на маршрутизаторе провайдера почему-то настроен дефолт в сторону клиента и пакет отправляется туда.
    Понятно объяснил?

    По-хорошему всё должно было бы закончиться на out-интерфейсе нашей сети и in-интерфейсе маршрутизатора провайдера — там должен быть ACL, который не выпускает приватные сети. Дельное замечание, кстати.

    21 января 2013, 04:25
  • 1) Верно. Только после list имя ACL, а не просто any 🙂
    2) Нет, в этом случае не надо. Establised означает, что будут разрешаться только TCP пакеты, для которых уже установлена сессия. Это подходит для ACL, который будет применяться на Uplink на inbound. То есть хост из приватной сети уже установил сессию (established), тогда ответные TCP будут пропускаться, иначе — нет.

    17 января 2013, 18:52
  • Не, по-другому.
    Провайдер мог выдать нам допустим /24 маску. А из неё мы сами можем сделать 4 пула по 64 адреса. То есть пул в данном случае — это не то, что выдал нам пров, а тот диапазон, который вы вычленили.
    Пулом мы задаём адреса, которые будут использоваться NAT’ом. Он их будет подставлять автоматически.
    Если не настроен overload — то каждый новый NAT-client будет получать новый IP-адрес.
    Если настроен overload, то как только исчерпаются TCP-порты в первом, NAT начнёт выделять порты из второго адреса и т.д.
    Если же вы хотите распоряжаться каждым адресом отдельно, то нужно делать несколько пулов.

    17 января 2013, 13:52
  • Внезапно! Даже не думал о такой возможности.
    Но для атаки, как описано в статье, насколько я понимаю, надо иметь возможность такой пакет (с адресом назначения из приватной сети) доставить до внешнего интерфейса бордера.

    14 января 2013, 19:59
  • Первый шаг траблшутинга в этом случае — трассировка. Проверяем таблицы маршрутизации и ACL на интерфейсах по ходу движения трафика.

    14 января 2013, 19:42
  • Это, кстати, очень любопытный момент! Вот тут статья на этот счет, если я правильно все понял.

    14 января 2013, 07:20
  • Разобрался.
    Оказывается сделал лишний маршрут со стороны провайдера.

    13 января 2013, 21:54
  • Как заметили выше, ip nat outside можно применять для перенаправления запросов на конкретный хост на другой хост.

    7 января 2013, 07:02
  • В статье приведена команда

    msk-arbat-gw1(config)# ip nat inside source list nat-inet pool main_pool overload

    Здесь как раз таки привязывается ACL к пулу NAT, указывается, кому можно, кому нет.

    7 января 2013, 07:00
  • «IP NAT outside? Признаться, не слышал вообще о её применении на практике. Можете более подробно рассказать?»- не заметил)

    7 января 2013, 00:29
  • IP NAT outside? Признаться, не слышал вообще о её применении на практике. Можете более подробно рассказать?

    26 декабря 2012, 07:58
  • Задачу решил при помощи команды ip nat outside source static.

    26 декабря 2012, 07:49
  • Вероятно, на некоторых устройствах это возможно реализовать политиками, но поверьте — это костыли, и вам не следует этого делать.

    14 декабря 2012, 12:14
  • Значит, средствами маршрутизатора эту задачу решить невозможно? (Чтобы хост, запрашивающий один сайт, переадресовывался на другой)

    14 декабря 2012, 10:56
  • У механизма NAT нет таких возможностей. Это организуют различные прокси сервера.

    14 декабря 2012, 09:00
  • Сам очень долго разбирался в своё время с этим. Это было не столько оттого, что нет хорошей документации, сколько оттого, что я вообще не понимал что это)

    26 ноября 2012, 16:37

Ещё статьи

Мысли после Cisco Live US 2019
Подводя итог пятидневному марафону технических инъекций в мозг, хочется сказать, что в обозримом горизонте всё есть код. И это не про скрипты для автоматизации — они уже давно здесь. Речь ...
like 0 7846 2
14 июня 2019
Анонс подкаста. Выпуск 62 \\\\\14.04 11:00 Мск. VMware
В этом месяце linkmeup балует вкусненьким — мало того что мы снова про SDN, так ещё теперь и мастодонтами рынка виртуализации. В гостях у нас VMware. Дата: 14-го апреля. 11:00 ...
like 0 2422 0
10 апреля 2018
Задача №6.5
Маршрутизатор в Москве анонсирует всем остальным маршрутизаторам в сети маршрут по умолчанию. Но на все остальные маршрутизаторы он приходит с одинаковой метрикой равной 1 и метрика не увеличивается по пути ...
like 0 13650 14
29 октября 2012