Списки доступа (access-lists) используются в целом ряде случаев и являются механизмом задания условий, которые роутер проверяет перед выполнением каких-либо действий. Маршрутизатор проверяет каждый пакет и на основании вышеперечисленных критериев, указанных в ACL определяет, что нужно сделать с пакетом, пропустить или отбросить. Типичными критериями являются адреса отправителя и получателя пакета, тип протокола. Каждый критерий в списке доступа записывается отдельной строкой. Список доступа в целом представляет собой набор строк с критериями, имеющих один и тот же номер (или имя). Порядок задания критериев в списке существенен. Проверка пакета на соответствие списку производится последовательным применением критериев из данного списка (в том порядке, в котором они были введены). Пакет, который не соответствует ни одному из введенных критериев будет отвергнут. Для каждого протокола на интерфейс может быть назначен только один список доступа. Как пример ниже приведена таблица списка управления доступом по умолчанию:
Без ACL - по умолчанию при создании конечной точки ей все разрешено.
Разрешить - при добавлении одного или нескольких диапазонов "разрешения" все остальные диапазоны по умолчанию запрещаются. Только пакеты из разрешенного диапазона IP -адресов смогут достичь конечной точки виртуальной машины.
Запретить - при добавлении одного или нескольких диапазонов "запретить" все другие диапазоны трафика по умолчанию разрешаются.
Сочетание разрешения и запрета - можно использовать сочетание правил "разрешить" и "запретить", чтобы указать вложенный разрешенный или запрещенный диапазон IP -адресов.
Рассмотрим два примера стандартных списков:
# access-list 1 permithost 10.0.0.10 - разрешаем прохождение трафика от узла 10.0.0.10.
# access-list 2 deny 10.0.1.0 0.0.0.255 - запрещаем прохождение пакетов из подсети 10.0.1.0/24.
Списки доступа бывают нескольких видов: стандартные, расширенные, динамические и другие. В стандартных ACL есть возможность задать только IP адрес источника пакетов для их запретов или разрешений.
Соберем данную схему и настроим ее. Настройку PC0 и PC1 выполните самостоятельно.
Интерфейс 0/0 маршрутизатора1841 настроим на адрес 192.168.0.1 и включим следующими командами:
Router>en Router#conf t Router (config)#int fa0/0 Router (config-if)#ip addr 192.168.0.1 255.255.255.0 Router (config-if)#no shut Router (config-if)#exit
Второй интерфейс маршрутизатора (порт 0/1) настроим на адресом 10.0.0.1 и так же включим:
Router (config)#intfa0/1 Router (config-if)#ip addr 10.0.0.1 255.255.255.0 Router (config-if)#no shut
Настройки сервера приведены на рис. 9.3 .
Проверяем связь ПК из разных сетей ( рис. 9.4).
Правило запрета и разрешения доступа будем составлять с использованием стандартных списков доступа (ACL). Пока не задан список доступа на интерфейсе всё разрешено (permit ). Но, стоит создать список, сразу действует механизм "Всё, что не разрешено, то запрещено". Поэтому нет необходимости что-то запрещать (deny ) – указываем что разрешено, а "остальным – запретить" подразумевается автоматически. По условиям задачи нам нужно на R0 пропустить пакеты с узла 192.168.0.12 на сервер ( рис. 9.5).
Применяется данное правило на интерфейс в зависимости от направления (PC1 расположен со стороны порта Fa0/0) – рис. 9.6 . Эта настройка означает, что список доступа (правило с номером 1) будет действовать на интерфейсе fa0/0 на входящем (in) от PC1 направлении.
Примечание
Входящий трафик (in) - этот тот, который приходит на интерфейс извне. Исходящий (out) - тот, который отправляется с интерфейса вовне. Список доступа вы можете применить либо на входящий трафик, тогда неугодные пакеты не будут даже попадать на маршрутизатор и соответственно, дальше в сеть, либо на исходящий, тогда пакеты приходят на маршрутизатор, обрабатываются им, доходят до целевого интерфейса и только на нём обрабатываются. Как правило, списки применяют на входящий трафик (in).
Продолжаем развитие нашей маленькой уютной сети Лифт ми Ап. Мы уже обсудили вопросы маршрутизации и стабильности, и теперь, наконец, выросли для подключения к Интернету. Довольно заточения в рамках нашей корпоративной среды!
Но с развитием появляются и новые проблемы.
Сначала вирус парализовал веб-сервер, потом кто-то притаранил червя, который распространился в сети, заняв часть полосы пропускания. А ещё какой-то злодей повадился подбирать пароли на ssh к серверу.
А представляете, что начнётся, когда мы подключимся к Интернету?!
Итак, сегодня:
1) учимся настраивать различные списки контроля доступа (Access Control List)
2) пытаемся понять разницу между ограничением входящего и исходящего трафика
3) разбираемся с тем, как работает NAT, его плюсы, минусы и возможности
4) на практике организуем подключение к Интернету через NAT и увеличим безопасность сети, используя списки доступа.
Каково предназначение списков доступа? Казалось бы, совершенно очевидный ответ - для ограничения доступа: кому-то что-то запретить, например. Вообще - это верно, но понимать нужно в более широком смысле: речь не только о безопасности. То есть, изначально, вероятно, так оно и было, отсюда 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):
В конце статьи пример настройки и .
Стандартный список доступа проверяет только адрес отправителя. Расширенный- адрес отправителя, адрес получателя, а также порт. Стандартные ACL рекомендуется ставить как можно ближе к получателю (чтобы не порезать больше, чем нужно), а расширенные- ближе к отправителю (чтобы как можно раньше дропнуть нежелательный трафик).
Правила в списке доступа проверяются по порядку сверху вниз до первого совпадения. Как только одно из правил сработало, независимо от того 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-ext-nacl)# remark WEB
any host 172.16.0.2 eq 80
Разрешаем (permit
) TCP-трафик от любого узла (any
) на хост (host
- именно один адрес) 172.16.0.2, адресованный на 80-й порт.
Пробуем повесить этот список доступа на интерфейс FE0/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)#
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 и отбрасывается.
0.0.255.255 - обратная маска (wildcard mask). О том, что это такое, поговорим чуточку позже
Первой строкой мы удаляем существующий список, далее создаём его заново и перечисляем все новые правила в нужном нам порядке. Командой в третьей строке мы разрешили проход всех 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
Сейчас наш админ имеет доступ только на WEB-сервер. Откройте ему полный доступ на всю сеть. Это первое домашнее задание.
Обычная сеть на 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-адрес. Десятичная запись | 172 | 16 | 2 | 4 |
IP-адрес. Двоичная запись | 10101100 | 00010000 | 00000010 | 00000100 |
Маска подсети. Двоичная запись | 11111111 | 11111111 | 11111111 | 11111100 |
Маска подсети. Десятичная запись | 255 | 255 | 255 | 252 |
То есть теперь вам должно быть чуть-чуть понятно, что маска подсети - это последовательность 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 |
Но на самом деле обратная маска - это несколько более богатый инструмент, здесь вы можете объединять адреса внутри одной подсети или даже объединять подсети, но самое главное отличие, вы можете чередовать нули и единицы. Это позволяет вам, например, отфильтровать определённый узел (или группу) в нескольких подсетях одной строкой.
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
2) C ACL надо быть аккуратнее. При небольшой ошибке в правиле, неправильном порядке настройки или вообще плохо продуманном списке вы можете остаться без доступа к устройству.
Например, вы хотите закрыть доступ куда угодно для сети 172.16.6.0/24, кроме своего адреса 172.16.6.61 и задаёте правила так:
deny ip 172.16.6.0 0.0.0.255 any
Как только вы примените ACL на интерфейс, вы сразу потеряете доступ к маршрутизатору, потому что вы попадаете под первое правило и второе даже не проверяется.
Вторая неприятная ситуация, которая может с вами приключиться: под ACL попадёт трафик, который не должен был попасть.
Вообразите такую ситуацию: у нас в серверной есть FTP-сервер в пассивном режиме. Для доступа к нему вы открыли 21-й порт в ACL Servers-out
. После первичного установления соединения FTP-сервер сообщает клиенту порт, по которому он готов передавать/принимать файлы, например, 1523-й. Клиент пытается установить TCP-соединение на этот порт, но натыкается на ACL Servers-out, где такого разрешения нету - так и кончается сказка про успешный трансфер. В нашем примере выше, где мы настраивали доступ на файловый сервер, мы открыли доступ только по 20 и 21-му, потому что для примера этого достаточно. В реальной жизни придётся повозиться. Немного примеров конфигурации ACL для распространенных случаев.
3) Из 2-го пункта вытекает очень похожая и интересная проблема.
Вздумалось вам, например повесить на интерфейс в интернет такие вот ACL:
access-list out permit tcp host 1.1.1.1 host 2.2.2.2 eq 80
access-list in permit tcp host 2.2.2.2 any eq 80
Казалось бы: хосту с адресом 1.1.1.1 разрешён доступ по 80-му порту на сервер 2.2.2.2 (первое правило). И обратно от сервера 2.2.2.2 разрешены соединения внутрь.
Но нюанс тут в том, что компьютер 1.1.1.1 устанавливает соединение НА 80-й порт, но С какого-то другого, например, 1054, то есть ответный пакет от сервера приходит на сокет 1.1.1.1:1054, не подпадает под правило в ACL на IN и отбрасывается ввиду неявного deny ip any any.
Чтобы избежать такой ситуации, и не открывать всем пучком порты, можно прибегнуть к такой хитрости в ACL на in:
permit tcp host 2.2.2.2 any established.
Подробности такого решения в одной из следующих статей.
4) Говоря про современный мир, нельзя обойти такой инструмент, как объектные группы (Object-group).
Допустим, надо составить ACL, выпускающий три определенных адреса в интернет по трем одинаковым портам c перспективой расширения количества адресов и портов. Как это выглядит без знания объектных групп:
ip access-list extended TO-INTERNET
permit tcp host 172.16.6.66 any eq 80
permit tcp host 172.16.6.66 any eq 8080
permit tcp host 172.16.6.66 any eq 443
permit tcp host 172.16.6.67 any eq 80
permit tcp host 172.16.6.67 any eq 8080
permit tcp host 172.16.6.67 any eq 443
permit tcp host 172.16.6.68 any eq 80
permit tcp host 172.16.6.68 any eq 8080
permit tcp host 172.16.6.68 any eq 443
При увеличении количества параметров сопровождать такой ACL становится всё труднее и труднее, легко ошибиться при настройке.
Зато, если обратиться к объектным группам, то это приобретает следующий вид:
object-group service INET-PORTS
description Ports allowed for some hosts
tcp eq www
tcp eq 8080
tcp eq 443
Object-group network HOSTS-TO-INET
description Hosts allowed to browse the net
host 172.16.6.66
host 172.16.6.67
host 172.16.6.68
Ip access-list extended INET-OUT
permit object-group INET-PORTS object-group HOSTS-TO-INET any
на первый взгляд несколько угрожающе выглядит, но если разобраться, то это очень удобно.
4) Очень полезную для траблшутинга информацию можно получить из вывода команды show ip access-lists %имя ACL% . Кроме собственно списка правил указанного ACL, эта команда показывает количество совпадений по каждому правилу.
Msk-arbat-gw1#sh ip access-lists nat-inet
Extended IP access list nat-inet
permit ip host 172.16.6.61 any
(4 match(es))
А дописав в конце любого правила log , мы сможем получать сообщения о каждом совпадении в консоль. (последнее не работает в PT)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
Их вы свободно можете использовать в своей частной сети, и поэтому, разумеется, они будут повторяться. Как же быть с уникальностью? Кому будет отвечать WEB-сервер, которому пришёл запрос с обратным адресом 192.168.1.1? Ростелекому? Компании Татнефть? Или вашему комнатному Длинку? В большом интернете никто ничего не знает о приватных сетях - они не маршрутизируются.
Тут и выходит на сцену NAT. По большому счёту, это обман, подстава. На натирующем устройстве ваш приватный адрес, грубо говоря, просто подменяется на белый адрес, который и будет фигурировать далее в пакете, пока он путешествует до WEB-сервера. А вот белые адреса очень даже хорошо маршрутизируются, и пакет точно вернётся обратно на натирующее устройство.
Но как оно в свою очередь поймёт, что с ним делать дальше? Вот с этим и разберёмся.
Настраивается следующей командой:
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-адреса, но тем не менее он бывает полезен.
Этот вариант тоже не универсальный, своих 300 пользователей вы так же не сможете выпустить всех в Интернет, если у вас нет 300 внешних адресов. Как только белые адреса исчерпаются, никто новый уже не сможет получить доступ в Интернет. При этом те пользователи, что уже успели отхватить себе внешний адрес, будут работать. Скинуть все текущие трансляции и освободить внешний адреса вам поможет команда clear ip nat translation *
Помимо динамического выделения внешних адресов, этот динамически NAT отличается от статического тем, что без отдельной настройки проброса портов уже невозможно внешнее соединение на один из адресов пула.
Маршрутизатор расчехляет IP-пакет от первого хоста, извлекает из него TCP-сегмент, распечатывает его и узнаёт, с какого порта устанавливается соединение. У него есть внешний адрес 198.51.100.2, на который будет меняться адрес из внутренней сети.
Далее он выбирает свободный порт, например, 11874. И что он делает дальше? Все данные уровня приложений он упаковывает в новый TCP сегмент, где в качестве порта назначения по-прежнему остаётся 80 (именно на него ждёт коннектов WEB-сервер), а порт отправителя меняется с 23761 на 11874. Этот TCP-сегмент инкапсулируется в новый IP-пакет, где меняется IP-адрес отправителя с 172.16.6.5 на 198.51.100.2.
То же самое происходит для пакета от второго хоста, только выбирается следующий свободный порт, например 11875. “Свободный” означает, что он ещё не занят другими такими соединениями.
Данные, которые отправляются в интернет, теперь буду выглядеть так.
В свою NAT-таблицу он заносит данные отправителей и получателей
Для WEB-сервера - это два совершенно разных запроса, которые он должен обработать каждый индивидуально. После этого он отсылает ответ, который выглядит так:
Когда один из этих пакетов доходит до нашего маршрутизатора, тот сопоставляет данные в этом пакете со своими записями в NAT-таблице. Если совпадение найдено, происходит обратная процедура - пакету и TCP сегменту возвращаются его изначальные параметры только в качестве назначения:
И теперь пакеты доставляется по внутренней сети компьютерам-инициаторам, которым и невдомёк даже, что где-то с их данными так жёстко обошлись на границе.
Каждое ваше обращение - это отдельное соединение. То есть попытались вы открыть 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
Кстати, эта команда - частный случай самой первой: ip nat inside source static 172.16.6.66 198.51.100.2. Только в этом случае речь идёт о пробросе всего трафика, а в наших примерах - конкретных портов протокола TCP.
Вот так в общих чертах фунциклирует NAT. Про его особенности, плюсы/минусы написано куча статей, но не отметить их нельзя.
- В-третьих , NAT скрывает от посторонних глаз внутреннюю структуру вашей сети - при трассировке маршрута извне вы не увидите ничего далее натирующего устройства.
Что ещё нужно знать?
- 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 и есть ещё море нюансов, не утонуть в котором вам поможет самообразование.
Сначала подготовим тестовую площадку:
Подключение к Интернету будет организовано через существующий линк, который предоставляет провайдер.
Он уходит в сеть провайдера. Напоминаем, что всё в этом облаке - это абстрактная сеть, которая на деле может состоять из десятков маршрутизаторов и сотен коммутаторов. Но нам нужно нечто управляемое и предсказуемое, поэтому водружаем сюда ещё маршрутизатор. С одной стороны в него линк из коммутатора, с другой сервера в Интернете.
Сервера нам понадобятся следующие:
1. Два клиент-банка для бухгалтеров (sperbank.ru, mmm-bank.ru)
2. сайт для ПТОшников
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
Вот так выглядит сейчас 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)# 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!
С компьютера админа доступно всё:
Из сети ПТО есть доступ только на сайт сайт по 80-му порту (HTTP):
В сети ФЭО в мир выходит только 4.123 (финдиректор)
В бухгалтерии работают только сайты клиент-банков. Но, поскольку разрешение дано полностью на протокол IP, то их можно и пинговать:
Далее вносим домен в DNS. Этот шаг необязательный - можно к серверу обращаться и по IP, но почему бы и нет?
Настраиваем компьютер из нашей сети:
Из внешней:
Готовим письмо:
На локальном хосте нажимаем Receive:
На этом первое знакомство с технологией NAT можно считать законченным.
В качестве ещё одного ДЗ ответьте на вопрос, почему нет доступа в Интернет с компьютеров эникиев в Питере и в Кемерово. Ведь мы их добавили уже в список доступа.
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.
Рассмотрим создание и использование списков доступа (access lists ) на примере схемы подключения малого офиса к сети Интернет с помощью маршрутизатора Cisco 881 . Команды для настройки маршрутизаторов других серий (1841, 2800, 3825…) или коммутаторов 3 уровня (серии 3500, 4800…) будут аналогичными. Различия могут быть лишь в настройках интерфейсов.
В распоряжении имеем:
Задача: ограничить соединения, проходящие через маршрутизатор.
Списки доступа (access lists ) сами по себе не являются какими-то правилами, ограничивающими доступ. Эти строки лишь указывают определенный трафик. Эффект от них появляется тогда, когда в настройках определенной функции маршрутизатора указывается ссылка на соответствующий список доступа.
Логика устройства такова, что сначала мы показываем маршрутизатору трафик, который нам интересен, а затем указываем что маршрутизатор должен с ним сделать. Например, в одном случае список доступа будет указывать адрес, с которого возможен удаленный доступ к маршрутизатору по протоколу SSH , а в другом будет указывать маршрут, который будет распространен с помощью протокола динамической маршрутизации.
Пример access list
, который используется для ограничения удаленного доступа к консоли маршрутизатора только с определенных ip
адресов. В нашем случае – адрес рабочей станции администратора.
Создаем список доступа ACL_REMOTE_ACCESS
R-DELTACONFIG(config)#
ip access-list standard ACL_REMOTE_ACCESS
permit ip host 192.168.0.100
Привязываем access list
для ограничения доступа к удаленному управлению маршрутизатором только с адреса 192.168.0.100
R-DELTACONFIG(config)#
line vty 0 4
access-class ACL_REMOTE_ACCESS
in
Важно!
Будьте осторожны и внимательно все проверьте перед применением. Ошибку можно будет исправить только
подключившись или сбросив настройки маршрутизатора до заводских.
Для ограничения доступа из локальной сети офиса в Интернет необходим соответствующий список доступа, а также привязка его к одному из интерфейсов маршрутизатора.
Допустим, что нужно ограничить выход пользователей в сеть Интернет следующим образом:
Создаем следующий список доступа ACL_INSIDE_IN
и последовательно вводим правила доступа:
R-DELTACONFIG(config)#
ip access-list extended ACL_INSIDE_IN
доступ DNS
сервера в Интернет
permit udp host 192.168.0.201 any
eq 53
permit tcp host 192.168.0.201 any
eq 53
доступ Прокси
сервера в Интернет
permit tcp
host 192.168.0.202 any
eq 80
permit tcp host 192.168.0.202 any
eq 443
полный доступ администратора
permit ip
host 192.168.0.100 any
разрешение Ping
для всей локальной сети
permit icmp
192.168.0.0 0.0.0.255 any
запрет иных подключений
deny ip
any any
log
Важно!
Обратите внимание на то, как записана строчка правила для протокола ICMP
(Ping
). В списках доступа на маршрутизаторах Cisco
маска подсети пишется в обратном виде: не 255.255.255.0, а 0.0.0.255
После привязываем список доступа ко внутреннему интерфейсу Vlan 1
в направлении «внутрь маршрутизатора» (параметр in
). Собственно, направление привязки всегда считается относительно устройства Cisco
. Для удобства интерфейс и направление трафика указано в названии самого списка доступа: ACL_INSIDE_IN
— фильтр трафика, входящего
во внутренний
интерфейс.
R-DELTACONFIG(config)#
interface Vlan 1
ip access-group ACL_INSIDE_IN in
С этого момента доступ наружу будет осуществляться в соответствии с примененным access list при условии, что корректно настроена трансляция адресов (NAT
). Как это делается описано в про настройку доступа в интернет с помощью маршрутизатора Cisco.
Проверить работу списка доступа можно посмотрев статистику срабатываний правил. После привязки списка доступа ACL_INSIDE_IN
к интерфейсу Vlan 1
запустите Ping
с любой из рабочих станций сети до любого адреса в Интернет (например до www.yandex.ru
), а затем выполните из привилегированного режима (знак #
рядом с названием устройства) команду show access-lists
. Результат должен показывать количество срабатываний каждой из строк списка доступа:
sh access-lists
Extended IP access list ACL_INSIDE_IN
…
60 permit icmp any any (4 estimate matches)
70 deny ip any any log
Важные аспекты использования списков доступа (access list
)
- Список доступа состоит из строк – правил, показывающих определенный трафик
- Список доступа, привязанный к интерфейсу, ограничивает проходящие через этот интерфейс пакеты.
- Список доступа может быть привязан к интерфейсу в одном из направлений: входящем или исходящем.
- В списках доступа может быть указан или только источник соединения (standard, пример ограничения доступа по SSH ) или источник и назначение соединения(extended, пример ограничения доступа в Интернет).
- Не может быть привязано более одного списка доступа к одному интерфейсу в одном направлении. Все необходимые правила должны быть указаны только в одном привязанном списке доступа.
Создаем список доступа ACL_OUTSIDE_IN
для внешнего
интерфейса. В нем указываем лишь то, что внешний интерфейс должен отвечать на ping
, а все остальные запросы отклонять.
R-DELTACONFIG(config)#
permit icmp any interface
//разрешение Ping
deny
ip any any log //запрет иных подключений
Привязываем список доступа ко внешнему интерфейсу.
R-DELTACONFIG(config)#
interface FastEthernet 4
ip access-group ACL_OUTSIDE_IN in
Важно!
Все новые правила, которые потребуются для доступа изнутри или снаружи, следует добавлять в соответствующие списки доступа ДО
строчки
deny ip any any log
Если какая-то строчка с разрешением окажется в списке после запрещающей, то она не будет хоть как-то влиять на трафик, так как маршрутизатор обрабатывает строки access list
последовательно
до первого совпадения.
Для изменения access list
удобно зайти в сам список доступа, добавить все нужные разрешения, а после этого удалить последнюю строку (deny ip any any log
) и тут же ее добавить. Выполняя это нехитрое правило запрещающая строка всегда будет в самом конце списка, а все правила будут идти в порядке добавления снизу вверх. Для наглядности разрешим доступ к маршрутизатору извне по протоколу http (TCP порт 80)
R-DELTACONFIG(config)#
ip access-list extended ACL_OUTSIDE_IN
permit tcp any interface eq 80
no deny ip any any log
deny ip any any log
После привязки списка доступа ACL_OUTSIDE_IN
пропадает весь доступ из локальной сети ко всем ресурсам по любым протоколам кроме Ping
. Это происходит из-за того, что фильтрующие трафик правила применяются и на внутреннем (ACL_INSIDE_IN
) и на внешнем (ACL_OUTSIDE_IN
) интерфейсах.
Для того, чтобы проходили все обратные
пакеты на запросы из локальной сети указываем протоколы для функции Inspect
.
R-DELTACONFIG(config)#
ip inspect name Internet http
ip inspect name Internet https
ip inspect name Internet dns
ip inspect name Internet icmp
Привязываем правило инспектирования ко внешнему
интерфейсу.
R-DELTACONFIG(config)#
interface FastEthernet 4
ip inspect Internet out
Список разрешенных для инспекции служб можно расширить в будущем.
Надеюсь, что статья поможет Вам лучше понять принцип работы списков доступа. К сожалению эту достаточно простую тему очень сложно описать простым языком. Если у Вас возникли вопросы или какой-то момент остался неясным, напишите мне на адрес [email protected] или оставьте свой вопрос в комментариях.
Access-lists, Access-control-lists (ACL) – списки контроля доступа. Существует несколько разновидностей аксесс-листов, применяемых на маршрутизаторах и коммутаторах Cisco. Аксесс-листы используются для фильтрации трафика или для определения классов трафика при применении политик. Список доступа представляет собой набор строк вида условие-действие. Строка аксесс-листа называется access-control-entry (ACE). Условием может быть соответствие пакета определенному протоколу или набору параметров. Действием может быть разрешение пакета (permit), либо запрещение (deny). Для списков доступа справедливы следующие правила:
По способу создания списки доступа делятся на стандартные, расширенные, и именованные. Удобнее всего работать с именованными.
Фильтрует только по ip адресу источника. Должен иметь номер в диапазоне 1-99. Пример:
Access-list 10 deny host 172.16.30.2 – запретить ip источника access-list 10 permit any - разрешить всё
Фильтрует по адресам источника и получателя, по протоколам 3, 4 уровня. Должен иметь номер в диапазоне 100-199. Пример:
Acсess-list 110 deny tcp any host 172.16.30.2 eq 22 - запретить tcp от всех на хост с портом 22 access-list 110 deny ip 192.168.160.0 0.0.31.255 any - запретить ip от сети по шаблону на всех access-list 110 permit ip any any - разрешить всё
Фильтрует по адресам источника и получателя, по протоколам 3, 4 уровня. Должен иметь имя. Возможно удалять отдельные строки. Пример:
Ip access-list extended INET - создать список с именем INET deny tcp any host 172.16.30.2 eq 22 - запретить tcp от всех на хост с портом 22 deny ip 192.168.160.0 0.0.31.255 any - запретить ip от сети по шаблону на всех permit ip any any - разрешить всё
Строки доступа нумеруются с шагом 10 по-умолчанию. Можно перенумеровать аксесс-лист с другим шагом. Можно добавить строку пронумеровав – она попадет в указанное место, по нумерации.
Просмотр расширенного аксесс-листа:
Router# sh access-list INET Extended IP access list INET 10 deny tcp any host 172.16.30.2 eq 22 (150 matches) 20 deny ip 192.168.160.0 0.0.31.255 any (4 matches) 30 permit ip any any (1556 matches)
Как видим - строки пронумерованы с шагом 10. Можно вставить новую строку в произвольное место листа, используя номер:
Router(conf)# ip access-list extended INET router(config-ext-nacl)# 5 permit ip host 10.10.10.10 any router(config-ext-nacl)# 223 deny ip host 1.1.1.1 any router(config-ext-nacl)# end router# sh access-list INET Extended IP access list INET 5 permit ip host 10.10.10.10 any 10 deny tcp any host 172.16.30.2 eq 22 (150 matches) 20 deny ip 192.168.160.0 0.0.31.255 any (4 matches) 30 permit ip any any (1556 matches) 223 deny ip host 1.1.1.1 any
Удалить отдельную строчку из листа можно по номеру, или по полному указанию строки с префиксом "no". Например так:
Router(conf)# ip access-list extended INET router(config-ext-nacl)# no permit ip host 10.10.10.10 any
Router(config-ext-nacl)# no 223
Полностью удалить список доступа можно указав соответствующую команду и "no":
Router(conf)# no ip access-list extended INET
permit icmp vs. permit ip
Deny ACEs that check Layer 4 information never match a fragment unless the fragment contains Layer 4 information.
VLAN map применяется для всех отбриджованных пакетов. Router ACL только для маршрутизированных. Если
1. VLAN map for input VLAN10
2. Input router ACL / int VLAN10
3. routing VLAN10 to VLAN 20
4. Output router ACL / int VLAN20
5. VLAN map for output VLAN20
ip access-list extended WIFIHOSTEL permit ip 10.12.0.0 0.0.255.255 host 212.192.64.2 permit ip host 212.192.64.2 10.12.0.0 0.0.255.255 deny ip any any ! vlan access-map WIFIHOSTEL 10 match ip address WIFIHOSTEL action forward ! vlan filter WIFIHOSTEL vlan-list 534