Сайт о телевидении

Сайт о телевидении

» » Настройка, применение и проверка расширенного именованного ACL-списка. Что такое списки контроля доступа ACL. Настраиваем стандартные и расширенные списки ACL на маршрутизаторах Cisco

Настройка, применение и проверка расширенного именованного ACL-списка. Что такое списки контроля доступа ACL. Настраиваем стандартные и расширенные списки ACL на маршрутизаторах Cisco

Создадим именованный ACL-список и пропишем правила для него:

ip access-list extended HTTP_ONLY – создаемсписок.

permittcp 172.22.34.96 0.0.0.15 host 172.22.34.62 eqwww – настраиваем фильтрацию трафика www.

permiticmp 172.22.34.96 0.0.0.15 host 172.22.34.62 – разрешаем передачу трафика ICMP от PC2 на Сервер.

interfacegigabitEthernet 0/1

ipaccess-groupHTTP_ONLYin – размещениесписканаинтерфейсе.

Для проверки работы примененного списка отправляем эхо-запрос от PC2 на сервер Server (рисунок 4.4).Далее выполняется неуспешноеFTP-подключение от PC2 к серверу Server (рисунок 4.4). Затем необходимо открыть веб-браузер на PC2 и введите IP-адрес сервера Server в виде URL-адреса. Подключение должно быть успешным (рисунок 4.5).

Рисунок 4.4 – Эхо-запрос и FTP-подключение к серверу от РС2

Рисунок 4.5 – Подключение к серверу через веб-браузер


5 Настройка расширенныхACL-списков. Сценарий 2

В этом сценарии устройствам в одной сети LAN разрешается удалённый доступ к устройствам другой LAN через протокол Telnet. За исключением ICMP, весь трафик от других сетей запрещён. Схема сети представлена на рисунке 5.1.

Рисунок 5.1 – Схема сети

Настраиваем расширенный нумерованный ACL-список следующими командами:

accesslist 199 permittcp 10.101.117.32 0.0.0.15 10.101.117.0 0.0.0.31 eqtelnet– трафик по протоколу Telnet в сети 10.101.117.32/28 разрешён для передачи на устройства в сетях 10.100.117.0/27.

access-list 199 permiticmpanyany – трафик ICMP разрешён от любого устройства и в любом направлении.

Остальной трафик запрещён по умолчанию.

interface gigabitethernet0/2

ipaccess-group 199 out – размещениесписканаинтерфейсе.

Для проверки работы расширенного списка сначала необходимо отправить эхо-запросыот компьютера PCB на все остальные IP-адреса в сети (рисунок 5.2). Далее отправляютсяэхо-запросы от компьютера PCA на все остальные IP-адреса в сети (рисунок 5.3).

Рисунок 5.2–Эхо-запрос от РСВ

Рисунок 5.3 – Эхо-запрос от РСА


6 Настройка расширенных ACL-списков. Сценарий 3

В этом сценарии конкретным устройствам сети LAN разрешается доступ к нескольким службам серверов, размещённых в сети Интернет. Используемая сеть представлена на рисунке 6.1.

Рисунок 6.1 – Схема сети

Необходимо использовать один именованный ACL-список для реализации следующих правил:

1 Запретить доступ через протоколы HTTP и HTTPS с PC1 на серверы Server1 и Server2. Эти серверы находятся внутри облака, известны только их IP-адреса.

2Заблокировать FTP-доступ с PC2 к серверам Server1 и Server2.

3Заблокировать ICMP-доступ с PC3 к серверам Server1 и Server2.

Настройка расширенного именованного ACL-списка осуществлялась следующими командами:

ip access-list extended ACL – создаемсписок.

denytcphost 172.31.1.101 host 64.101.255.254 eqwww– правило, запрещающее доступ с PC1 к серверу Server1, только для HTTP.

denytcphost 172.31.1.101 host 64.101.255.254 eq 443 – правило, запрещающее доступ с PC1 к серверу Server1, только для HTTPS.

denytcphost 172.31.1.101 host 64.103.255.254 eqwww– правило, запрещающее доступ с PC1 к серверу Server2, только для HTTP.

denytcphost 172.31.1.101 host 64.103.255.254 eq 443 – правило, запрещающее доступ с PC1 к серверу Server2, только для HTTPS.

denytcphost 172.31.1.102 host 64.101.255.254 eqftp– правило, запрещающее доступ с PC2 к серверу Server1, только для FTP.

denytcphost 172.31.1.102 host 64.103.255.254 eqftp – правило, запрещающее доступ с PC2 к серверу Server2, только для FTP.

denyicmphost 172.31.1.103 host 64.101.255.254 – правило, запрещающее ICMP-доступ с PC3 к серверу Server1.

denyicmphost 172.31.1.103 host 64.103.255.254 – правило, запрещающее ICMP-доступ с PC3 к серверу Server2.

permitipanyany – разрешение остальногоIP-трафика.

interfacegigabitEthernet 0/0

ipaccess-groupACLin – применениеACL-списка на соответствующем интерфейсе и направлении.

Проверка расширенного ACL-списка заключается в следующем: проверяется доступ к веб-сайтам на серверах Server1 и Server2, используя веб-браузер PC1, а также протоколы HTTP и HTTPS (рисунок 6.2), проверяется FTP-доступ к серверам Server1 и Server2 с компьютера PC1 (рисунок 6.3),выполняются эхо-запросы на серверы Server1 и Server2 от PC1 (рисунок 6.4). Аналогично поверяются РС2 и РС3. Удачный доступ к веб-сайтам на серверах от РС2 и РС3 – на рисунке 6.5. Неудачный FTP-доступ к серверам от РС2 – на рисунке 6.6. Неудачные эхо-запросы от РС3 к серверам представлены на рисунке 6.7.

Рисунок 6.2 – Проверка доступа через HTTP и HTTPS

Рисунок 6.3 - FTP-доступ к серверам Server1 и Server2 с PC1

Рисунок 6.4 - Эхо-запросы на серверы Server1 и Server2 от PC1

Рисунок 6.5 - Удачный доступ к веб-сайтам на серверах от РС2 и РС3

Рисунок 6.6 - Неудачный FTP-доступ к серверам от РС2

Рисунок 6.7 - Неудачные эхо-запросы от РС3 к серверам


7 Отработка комплексных практических навыков

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

Рисунок 7.1 – Схема сети

В ходе выполнения лабораторной работы были выполнены следующие требования:

1 Сеть 172.16.128.0/19 разделена на две равные подсети для использования в маршрутизаторе Branch.Последний доступный для использования адрес второй подсети назначен в интерфейс GigabitEthernet 0/0.Последний доступный для использования адрес первой подсети назначен в интерфейс GigabitEthernet 0/1. Задокументированная таблица адресации – в таблице 1.

Таблица 1 – Таблица адресации

Продолжение таблицы 1

Branch G0/0 172.16.159.254 255.255.240.0 Недоступно
G0/1 172.16.143.254 255.255.240.0 Недоступно
S0/0/0 192.168.0.2 255.255.255.252 Недоступно
HQ1 Сетевой адаптер 172.16.64.1 255.255.192.0 172.16.127.254
HQ2 Сетевой адаптер 172.16.0.2 255.255.192.0 172.16.63.254
HQServer.pka Сетевой адаптер 172.16.0.1 255.255.192.0 172.16.63.254
B1 Сетевой адаптер 172.16.144.1 255.255.240.0 172.16.159.254
B2 Сетевой адаптер 172.16.128.2 255.255.240.0 172.16.143.254
BranchServer.pka Сетевой адаптер 172.16.128.1 255.255.240.0 172.16.143.254

Назначение адресов на интерфейсы осуществляется командамина маршрутизаторе Branch:

interface gigabitEthernet0/0

ip address 172.16.159.254 255.255.240.0

interface gigabitEthernet0/1

ipaddress 172.16.143.254 255.255.240.0

2На B1 настроена соответствующая адресация, был использован первый свободный адрес сети, к которой он подключён. Настройка представлена на рисунке 7.2.

Рисунок 7.2 – Настройка адресации на В1

3 Был настроен маршрутизатор Branch с усовершенствованным протоколом внутренней маршрутизации между шлюзами (EIGRP) в соответствии со следующими критериями:

a) объявлены все три подключённые сети;

b) отключено автоматическое объединение;

c) настроены соответствующие интерфейсы как пассивные;

d) объединены 172.16.128.0/19 на последовательном интерфейсе Serial 0/0/0 с административной дистанцией 5.

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

network 168.0.0.0 0.0.0.3

network 172.16.128.0 0.0.15.255

network 172.16.144.0 0.0.15.255

passive-interface gigabitethernet0/0

passive-interface gigabitethernet0/1

interface serial0/0/0

ipsummary-addresseigrp 1 172.16.128.0 255.255.224.0 5

4 Настроен на маршрутизаторе HQ маршрут по умолчанию, направляющий трафик на интерфейс S0/0/1. Перераспределен маршрут к маршрутизатору Branch. Для этого использовались следующие команды:

ip route 0.0.0.0 0.0.0.0 serial0/0/1

redistributestatic

5 Объединены подсети локальной сети HQ на последовательном интерфейсе Serial 0/0/0 с административной дистанцией 5. Команды:

interfaceserial0/0/0

ipsummaryaddresseigrp 1 172.16.0.0 255.255.128.0 5

6 Создан именованный список доступа HQServer, чтобы запретить для всех компьютеров, подключённых к интерфейсу GigabitEthernet 0/0 маршрутизатора Branch, доступ к HQServer.pka. Весь остальной трафик разрешён. Настроен список доступа на соответствующем маршрутизаторе, назначен подходящему интерфейсу на подходящем направлении. Для этого использовали следующие команды:

ipaccess-listextendedHQServer

denyipanyhost 172.16.0.1

permitip any any

interface gigabitethernet0/0

ip access-group HQServer in

7 Создан именованный список доступа BranchServer, чтобы запретить всем компьютерам, подключённым к интерфейсу GigabitEthernet 0/0 маршрутизатораHQ, доступкслужбамHTTPиHTTPSсервераBranch. Весь остальной трафик разрешён. Настроен список доступа на соответствующем маршрутизаторе, он назначен подходящему интерфейсу на подходящем направлении.

ip access-list extended BranchServer

denytcp any host 172.16.128.1 eq 80

denytcp any host 172.16.128.1 eq 443

permitip any any

interface gigabitethernet0/0

ipaccess-groupBranchServerin

Для проверки отправлялись эхо-запросы от В1 к HQServer.pka (неудачно, рисунок 7.3). Веб-доступ к серверу BranchServer.pka с HQ1 также неудачен (рисунок 7.4).

Рисунок 7.3 - Эхо-запрос от В1 к HQServer.pka

Рисунок 7.4 - Веб-доступ к серверу BranchServer.pka с HQ1


©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-08-20

Теоретическая часть.

Список управления доступом (access control list ACL) это последовательный список правил, которые используются для разрешения или запрета потока пакетов внутри сети на основании информации, приведенной внутри списка. Без списка доступа все пакеты внутри сети разрешаются без ограничений для всех частей сети. Список доступа может быть использован для контроля распространения и получения информации об изменении таблиц маршрутов и, главное, для обеспечения безопасности . Политика безопасности в частности включает защиту от внешних атак, ограничения доступа между отделами организации и распределение загрузки сети.

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

Стандартный ACL

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

Router(config)#access-list № permit | deny source-address source-mask,

где № – целое число – номер списка доступа, source-address обозначает адрес источника пакета, source-mask – маска в инверсной форме, накладываемая на адрес, permit – разрешить прохождение пакета, deny – запретить прохождение пакета. Число № определяет принадлежность элемента списка доступа к определённому списку доступа с номером №. Первая команда access-list определяет первый элемент списка доступа, вторая команда определяет второй элемент списка доступа и т.д. Маршрутизатор обрабатывает каждый определённый в нём список доступа по элементам сверху вниз. То есть, если адрес source-address пакета с учётом маски удовлетворяет условию элемента списка, то дальнейшие элементы списка маршрутизатор не обрабатывает. Следовательно, для избежания лишней обработки, элементы, определяющие более общие условия, следует помещать в начале списка. Внутри маршрутизатора может быть определено несколько списков доступа. Номер стандартного списка должен лежать в диапазоне 1 – 99. Маска в списке доступа задаётся в инверсной форме, например маска 255.255.0.0 выглядит как 0.0.255.255.

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

Router(config)#access-list # deny 0.0.0.0 255.255.255.255

Так, если мы хотим разрешить только трафик от адреса 1.1.1.1 и запретить весь остальной трафик достаточно в список доступа поместить один элемент

Router(config)#access-list 77 permit 1.1.1.1 0.0.0.0.

Здесь предполагается, что мы организовали список доступа с номером 77.

Рассмотрим возможность применения стандартных списков доступа для диапазона адресов. Возьмём к примеру диапазон 10.3.16.0 – 10.3.31.255. Для получения инверсной маски можно вычесть из старшего адреса младший и получить 0.0.15.255. Тогда пример элемента списка можно задать командой

Router(config)#access-list 100 permit 10.3.16.0 0.0.15.255

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

Router(config-if)#ip access-group номер-списка-доступа in либо out

Cписок доступа может быть применён либо как входной (in) либо как выходной (out). Когда вы применяете список доступа как входной, то маршрутизатор получает входной пакет и сверяет его входной адрес с элементами списка. Маршрутизатор разрешает пакету маршрутизироваться на интерфейс назначения, если пакет удовлетворяет разрешающим элементам списка либо отбрасывает пакет, если он соответствует условиям запрещающих элементов списка. Если вы применяете список доступа как выходной, то роутер получает входной пакет, маршрутизирует его на интерфейс назначения и только тогда обрабатывает входной адрес пакета согласно элементам списка доступа этого интерфейса. Далее маршрутизатор либо разрешает пакету покинуть интерфейс либо отбрасывает его согласно разрешающим и запрещающим элементам списка соответственно. Так, созданный ранее список с номером 77 применяется к интерфейсу Ethernet 0 маршрутизатора как входной список командами

Router(config)#int Ethernet 0

Router(config-if)#ip access-group 77 in

Этот же список применяется к интерфейсу Ethernet 0 маршрутизатора как выходной список с помощью команд

Router(config-if)#ip access-group 77 out

Отменяется список на интерфейсе с помощью команды no

Router(config-if)# no ip access-group 77 out

Приступим к созданию более сложных списков доступа. Рассмотрим сеть на рисунке 1. Разрешим все пакеты, исходящие из сети 10.1.1.0 /25 (10.1.1.0 255.255.255.128) , но запретим все пакеты, исходящие из сети 10.1.1.128 /25 (10.1.1.128 255.255.255.128). Мы также хотим запретить все пакеты, исходящие из сети 15.1.1.0 /24 (15.1.1.0 255.255.255.0), за исключением пакетов от единственного хоста с адресом 15.1.1.5. Все остальные пакеты мы разрешаем. Списку дадим номер 2. Последовательность команд для выполнения поставленной задачи будет следующая

Router(config)#

Router(config)#access-list 2 permit 15.1.1.5 0.0.0.0

Router(config)#

Router(config)#

Отметим отсутсвие разрешающего элемента для сети 10.1.1.0 255.255.255.128. Его роль выполняет последний элемент access-list 2 permit 0.0.0.0 255.255.255.255.

Удостоверимся, что мы выполнили поставленную задачу.

1. Разрешить все пакеты, исходящие из сети 10.1.1.0 255.255.255.128.

Последняя строка в списке доступа удовлетворяет этому критерию. Нет необходимости в явном виде разрешать эту сеть в нашем списке доступа так, как в списке нет строк, соответствующей этой сети за исключением последней разрешающей строки permit 0.0.0.0 255.255.255.255.

Первая строка в списке выполняет этот критерий. Важно отметить вид инверсной маски 0.0.0.127 для этой сети. Эта маска указывает, что мы не должны брать в рассмотрение последние семь бит четвертого октета адреса, которые назначены для адресации в данной подсети. Маска для этой сети 255.255.255.128, которая говорит, что последние семь бит четвертого октета определяют адресацию в данной сети.

3. Запретить все пакеты, исходящие из сети 15.1.1.0 255.255.255.0, за исключением пакетов от единственного хоста с адресом 15.1.1.5

Рисунок 9.1.

Это требование удовлетворяется второй и третьей строкой нашего списка доступа. Важно отметить, что список доступа осуществляет это требование не в том порядке как оно определено. Обязательно следует помнить, что список доступа обрабатывается сверху вниз и при первом совпадении обработка пакетов прекращается. Мы вначале требуем запретить все пакеты, исходящие из сети 15.1.1.0 255.255.255.0 и лишь затем разрешить пакеты с адресом 15.1.1.5. Если в командах, определяющих список доступа мы, переставим вторую и третью команды, то вся сеть 15.1.1.0 будет запрещена до разрешения хоста 15.1.1.5. То есть, адрес 15.1.1.5 сразу же в начале будет запрещён более общим критерием deny 15.1.1.0 0.0.0.255.

4. Разрешить все остальные пакеты

Последняя команда разрешает все адреса, которые не соответствуют первым трем командам.

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

1. Определить критерии и ограничения для доступа.

2. Воплотить их с помощью команд аccess-list, создав список доступа с определённым номером.

3. Применить список к определённому интерфейсу либо как входящий, либо как исходящий.

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

Конкретизируем политику безопасности для сети на рисунке 1. Наша цель создать политику для компьютера А (адрес 1.1.1.2 сеть 1.1.1.0/24), которая изо всех устройств локальной сети 15.1.1.0 /24 в которую входит компьютер С (15.1.1.5) разрешит доступ к компьютеру А лишь самого компьютера С. Мы также хотим создать политику, запрещающую удалённый доступ к компьютеру А из любого устройства локальной сети 10.1.1.128 / 25 компьютера D (10.1.1.133). Весь остальной трафик мы разрешаем. На рисунке 1 компьютер PC5 (15.1.1.5) играет роль произвольного отличного от компьютера С представителя локальной сети 15.1.1.0/24.

Размещение списка критично для воплощения такой политики. Возьмём созданный ранее список с номером 2. Если список сделать выходным на последовательном интерфейсе маршрутизатора 2, то задача для компьютера А будет выполнена, однако возникнут ограничения на трафик между другими локальными сетями. Аналогичную ситуацию получим, если сделаем этот список входным на последовательном интерфейсе маршрутизатора 1. Если мы поместим этот список как выходной на Ethernet A интерфейс маршрутизатора 1, то задача будет выполнена безо всяких побочных эффектов.

Расширенные ACL

Со стандартным ACL вы можете указывать только адрес источника, а маска не обязательна. В расширенных ACL вы должны указать и адрес приёмника и адрес источника с масками. Можете добавить дополнительную протокольную информацию для источника и назначения. Например, для TCP и UDP разрешено указывать номер порта, а для ICMP разрешено указывать тип сообщения. Как и для стандартных ACL, можно с помощью опции log осуществлять лог.

Общая форма команды для формирования строки списка расширенного доступа

access-list access-list-number {permit | deny} protocol source source-wildcard destination destination-wildcard ,

где access-list-number -100-199|2000-2699, protocol - ip, icmp, tcp, gre, udp, igrp, eigrp, igmp, ipinip, nos и ospf. Для порта source-port или destination-port можно использовать номер порта или его обозначение bgp, chargen, daytime, discard, domain, echo, finger, ftp, ftp-data, gopher, hostname, irc, klogin, kshell, lpd, nntp, pop2, pop3, smtp, sunrpc, syslog, tacacs-ds, talk, telnet, time, uucp, whois и www. Operator это eq (равно), neq (не равно), gt (больше чем), lt (меньше чем), range (указывается два порта для определения диапазона).

Как и для стандартных ACL расширенный ACL следует привязать к интерфейсу либо для входящего на интерфейс трафика

Router(config-if)# ip access-group №ACL in

либо для выходящего из интерфейса трафика

Router(config-if)# ip access-group №ACL оut

здесь №ACL - номер списка.

Примеры элементов расширенного ACL

Разрешить SMTP отовсюду на хост

Router(config)# access-list 111 permit tcp any host 172.17.11.19 eq 25

Разрешить телнет отовсюду на хост

Router(config)# access-list 111 permit tcp any host 172.17.11.19 eq 23

Расширенный ACL позволяет очень тонко настроить права доступа.

Именованные ACL

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

Router(config)# ip access-list extended ACL_name

Router(config-ext-nacl)# permit|deny IP_protocol source_IP_address wildcard_mask destination_IP_address wildcard_mask

Для завершения создания списка следует дать команду exit.

Имя именованного списка чувствительно к регистру. Команды для создания неименованного списка аналогичные командам для создания элементов нумерованного списка, но сам процесс создания отличен. Вы должны использовать ключевое слово ip перед главным ACL оператором и тем самым войти в режим конфигурации именно для этого именованного списка. В этом режиме вы начинаете с ключевых слов permit или deny и не должны вводить access-list в начале каждой строки.

Привязка именованных ACL к интерфейсу осуществляется командой

Router(config)# interface type port_№

Router(config-if)# ip access-group ACL_name in|out

ACL обрабатываются сверху вниз. Наиболее часто повторяющийся трафик должен быть обработан в начале списка. Как только обрабатываемый списком пакет удовлетворяет элементу списка, обработка этого пакета прекращается. Стандартные ACLs следует помещать ближе к точке назначения, где трафик должен фильтроваться. Выходные (out) расширенные ACLs следует помещать как можно ближе к источнику фильтруемых пакетов, а входные следует помещать ближе к точке назначения, где трафик должен фильтроваться.

Именованный ACLs разрешает вам себя редактировать. Для этого надо набрать команду, которая была использована для его создания

Router(config)# ip access-list extended ACL_name

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

Для редактирования числовых ACLs следует его уничтожить и создать заново или изменить список офлайн и загрузить в устройство с помощью.

Практическая часть.

1. Загрузим в симулятор топологию, изображённую на рисунке 2.

Рисунок 9.2.

Назначим адреса интерфейсам (маска 255.255.255.240) согласно таблице. Не забудьте на DCE устройстве последовательного соединения задать синхронизацию.

Router2 Router1 Router4
Ethernet 24.17.2.2 24.17.2.1
Serial 24.17.2.17 24.17.2.18

Осуществим конфигурацию RIP маршрутизации

Router1(config)#router rip

Router1(config- router)#version 2

Router1(config- router)#network 24.0.0.0

Router2(config)#router rip

Router1(config- router)#version 2

Router2(config- router)#network 24.0.0.0

Router4(config)#router rip

Router1(config- router)#version 2

Router4(config- router)#network 24.0.0.0

Проверьте свою сеть с помощью команды ping и, в частности, что вы можете пинговать интерфейс Ethernet0 (24.17.2.2) маршрутизатора 2 из маршрутизатора 4

Router4#ping 24.17.2.2

Создадим стандартный список доступа, который не позволит пинговать маршрутизатор 2 из маршрутизатора 4. Для этого блокируем единственный адресс 24.17.2.18 маршрутизатора 4 и разрешим остальной трафик. Список создадим на маршрутизаторе 2 командами

Router2(config)#access-list 1 deny 24.17.2.18 0.0.0.0

Router2(config)#access-list 1 permit 0.0.0.0 255.255.255.255

Router2(config)#interface FastEthernet0/0

Router2(config-if)#ip access-group 1 in

Проверим, что список доступа запущен. Для этого просмотрим работающую конфигурацию

Router2#show running-config

Мы также можем видеть, что список применён к интерфейсу, используя команду “show ip interface”. Найдите в выводимой информации с строку “Innbound access list is 1”.

Router2#show ip interface

Команда “show access-lists” покажет нам содержимое созданного списка доступа.

Router2#show access-lists

Отметим, что host 24.17.2.18 равносильно 24.17.2.18 0.0.0.0. Теперь при попытке пинговать интерфейс Ethernet0 (24.17.2.2) роутера 2 из роутера 4

Router4#ping 24.17.2.2

Получим строку “UUUUU”, которая означает, что список доступа работает корректно.

  1. Создадим и загрузим в симулятор топологию на рисунке 2,

Рисунок 9.3.

Назначим адреса интерфейсам (маска 255.255.255.0) согласно таблице

Router2 Router1 Router3 Router4
Ethernet 0 160.10.1.2 160.10.1.1 175.10.1.2 180.10.1.2
Ethernet 1 175.10.1.1 180.10.1.1

Осуществим конфигурацию OSPF маршрутизации

Router1(config)#router ospf 1

Router1(config- router)#

Router1(config- router)#

Router2(config)#router ospf 1

Router2(config- router)#network 160.10.1.0 0.0.0.255 area 0

Router3(config) #router ospf 1

Router3(config- router)#network 175.10.1.0 0.0.0.255 area 0

Router3(config- router)#

Router4(config)#router ospf 1

Router4(config- router)#network 180.10.1.0 0.0.0.255 area 0

Для проверки пропингуйте крайние точки

router2#ping 180.10.1.2

router4#ping 160.10.1.2

Создадим стандартный список доступа для фильтрации трафика, приходящего на интерфейс ethernet0 1-го маршрутизатора router1 и разрешает трафик от подсети 175.10.1.0 (router3) и блокирует трафик от других устройств.

router1(config)#access-list 1 permit 175.10.1.0 0.0.0.255

Проверьте, что он создался

router1#show access-list

router1(config)#interface FastEthernet1/0

router1(config-if)#ip access-group 1 in

router1#show running-config

Проверьте связь между 3 и 2 маршрутизаторами и между 4 и 2 .

router3# ping 160.10.1.2

router4# ping 160.10.1.2

Связь между 3 и 2-м роутерами должна быть, а между 4 и 2 - нет.

Изменим список доступа и разрешим трафик от подсети 180.10.1.0 (router4) и блокируем трафик от других устройств.

router1(config)# no access-list 2

router1(config)# access-list 2 permit 180.10.1.0 0.0.0.255

Проверьте, что он изменился

router1#show access-list

Присоедините список как входной к интерфейсу Ethernet 1

router1(config)#interface FastEthernet1/0

router1(config-if)#ip access-group 1 in

Проверьте присоединение командой

router1#show running-config

Проверьте связь между 3 и 2 маршрутизаторами и между 4 и 2.

router3# ping 160.10.1.2

router4# ping 160.10.1.2

Связь между 4 и 2-м роутерами должна быть, а между 3 и 2 - нет.

3. Осуществите и проверьте конфигурацию IP для сети на рисунке 1 и примените OSPF для организации динамической маршрутизации.

Для маршрутизатора router 1

router1(config)#router ospf 1

router1(config-router)#

router1(config-router)#network 1.1.1.0 0.0.0.255 area 0

router1(config-router)#network 10.1.1.0 0.0.0.127 area 0

Для маршрутизатора router 2

Router2(config)#router ospf 1

Router2(config-router)#network 10.1.1.128 0.0.0.127 area 0

Router2(config-router)#network 15.1.1.0 0.0.0.255 area 0

Router2(config-router)#network 2.2.2.0 0.0.0.255 area 0

Проверте работоспособность сети: вы должны из любого устройства пинговать любой интерфейс. Или проще: все компьютеры A, B, C, D, PC5 должны взаимно попарно пинговаться.

Создадим список доступа из теоретической части

3.1 На маршрутизаторе router 1 создадим список доступа

router1(config)#access-list 2 deny 10.1.1.128 0.0.0.127

router1(config)#access-list 2 permit host 15.1.1.5

router1(config)#access-list 2 deny 15.1.1.0 0.0.0.255

router1(config)#access-list 2 permit 0.0.0.0 255.255.255.255

и применим его к интерфейсу Ethernet0 как выходной

router1(config)#interface FastEthernet0/0

router1(config-if)#ip access-group 2 out

Создать скриншот результата выполнения команды

router1#show access-list

Из\В A B C E D
A + + + - -
B + + + + +
C + + + + +
E - + + + +
D - + + + +

Таблица 1

Видим, что политика безопасности из теоретической части полностью реализована.

3.2 Удалим ACL c интерфейса е0 и применим как входной к интерфейсу s0

router1(config)#interface fa0/0

router1(config-if)#no ip access-group 2 out

router1(config-if)#int s2/0

router1(config-if)#ip access-group 2 in

Попарно пропингуем A, B, C, PC5, D. В результате должна получиться следующая матрица доступа

Из\В A B C E D
A + + + - -
B + + + - -
C + + + + +
E - - + + +
D - - + + +

Таблица 2

Видим, что теперь трафик между сетями 10.1.1.0/25 и 10.1.1.128/25 запрещен. Невозможен также трафик между сетью 10.1.1.0/25 и сетью 15.1.1.0/24 за исключением компьютера С с адресом 15.1.1.5.

4. Используем топологию и конфигурацию пункта 1 этой лабораторной работы

Отменим конфигурацию доступа, сделанную в пункте 1

Router2(config)#no access-list 1 deny 24.17.2.18 0.0.0.0

Router2(config)#no access-list 1 permit 0.0.0.0 255.255.255.255

Применим список к интерфейсу Ethernet маршрутизаторе 2

Router2(config)#interface fa0/0

Router2(config-if)#no ip access-group 1 in

Разрешим заходить на router1 телнетом на его два интерфейса с паролем router1

Router1(config)#line vty 0 4

Router1(config-line)#login

Router1(config-line)#password router1

Наши EACL будут делать пару различных вещей. Первое мы разрешим только телнет из подсети последовательного соединения 24.17.2.16/240 для входа на router1

router1(conf)#access-list 101 permit tcp 24.17.2.16 0.0.0.15 any eq telnet log

Опция log заставит маршрутизатор показывать выход при срабатывании списка доступа.

Разрешим на маршрутизаторе router1 весь трафик из Ethernet 0 подсети 24.17.2.0/240

router1(conf)#access-list 102 permit ip 24.17.2.0 0.0.0.15 any

Проверим установку списков

router1#show access-list

Теперь применим списки к интерфейсам для входящих пакетов

router1(conf)# interface Serial2/0

router1(conf-if)# ip access-group 101 in

router1(conf-if)# interface fa0/0

router1(conf-if)# ip access-group 102 in

Для проверки, что EACL присутствуют на интерфейсах, используйте команду

router1#show running-config

router1#show ip interface

Проверим функционирования EACL. Присоединимся к router4 и попытаемся безуспешно пропинговать интерфейс Serial2/0 на router1

router4#ping 24.17.2.17

EACL номер 101 блокировал ping. Но должен разрешить telnet

router4#telnet 24.17.2.17

Успешно. Введём пароль router1. Промпт router4# изменился на router1>. Нажав одновременно ctrl-shift-6 и затем 6, вернёмся на router4. О срабатывании EACL 101 на router1 нам укажет лог

Посмотрим номер сессии и убьём телнет соединение

router4#show sess

router4# disconnect 1

Присоединимся к router2 и посмотрим, можем ли мы пропинговать интерфейс Serial0 на router4.

Router2# ping 24.17.2.18

Почему неудачно? Пакет стартует в Router2, идёт через Router1 (о срабатывании EACL 102 на router1 нам укажет лог

) и приходит на Router4. На Router4 он переформируется и отсылается обратно к Router1. Когда Router4 переформирует пакет, адрес источника становится адресом приёмника и адрес приёмника становится адресом источника. Когда пакет приходит на интерфейс Serial0 на router1 он отвергается, так как его адрес источника равен IP адресу интерфейса Serial0 на router4 24.17.2.17, а здесь разрешён лишь tcp.

Присоединимся к router2 и посмотрим, можем ли мы пропинговать интерфейс Ethernet0 на router1.

router2#ping 24.17.2.1

Успешно. Аналогично и для телнета

router2#telnet 24.17.2.1

EACL работают успешно. О срабатывании EACL 102 на router1 нам укажет лог.

Заметим, что лог так же постоянно показывает RIP обновления

5. Именованные ACL

Отменим на router1 привязку EACL к интерфейсам

router1(conf)# interface Serial0

router1(conf-if)# no ip access-group 101 in

router1(conf-if)# interface Ethernet0

router1(conf-if)#no ip access-group 102 in

и отменим на router1 EACL

router1(conf)#no access-list 101

router1(conf)#no access-list 102

Поставим задачу запретить по всей сети лишь пинги от router4 на router2. Список доступа можно расположить и на router1 и на router2. Хотя рекомендуют располагать ACL ближе к источнику (для сокоащения трафика), в этом примере расположим именованный список с именем deny_ping на router2.

router2(config)#ip access-list extended deny_ping

router2(config-ext-nacl)#deny icmp 24.17.2.18 0.0.0.0 24.17.2.2 0.0.0.0 log

router2(config- ext-nacl)# permit ip any any log

Первая команда указывает, что мы создаём именованный расширенный список доступа с именем deny_ping. Вторая команда указывает на запрещение ICMP трафика с адресом источника строго 24.17.2.18 и адресом приёмника строго 24.17.2.2. Третья команда разрешает остальной IP трафик.

Проверим создание списка

router2#show access-list

Всё правильно, мы видим в первой строке просто другую форму представления команды deny icmp 24.17.2.18 0.0.0.0 24.17.2.2 0.0.0.0 log.

Применим список для входного трафика интерфейса Ethernet0 на router2

Router2(conf)#interface Ethernet0

Router2(conf-if)#ip access-group deny_ping in

Присоединимся к router4 и пропингуем роутер2

router4#ping 24.17.2.2

Неудача. Присоединимся к router1 и пропингуем роутер2

Router1#ping 24.17.2.2

Успех. Присоединимся к router2 и посмотрим на два отдельных лог-сообщения: первое о запрещении пинга от router4 и второе о разрешении пинга от router1

6. Рассмотрим более сложные вопросы расширенных списков доступа. Создадим топологию

.

Рисунок 9.4.

Используйте коммутаторы модели 1912. Маршрутизатор Router1 - модели 805. Маршрутизатор Router2 - модели 1605.

Назначим IP адреса маршрутизаторам

На Router1 и Router2 конфигурируем RIP

Router(config)#router rip

Router(config-router)#network 1.0.0.0

Интерфейсы всех устойств должны пинговаться со всех устройств.

6.1. Список доступа сеть-сеть.

Создадим список, который разрешает трафик от локальной сети компьютеров PC4 и PC5 в локальную сеть компьютера PC1 и запрещает трафик от локальной сети компьютеров PC2 и PC3 в локальную сеть компьютера PC1. Так как трафик приходит от router2 к router1 , то следует поместить список доступа на интерфейс serial2/0 router1 для входного трафика

Router1(conf)#access-list 100 permit ip 1.1.1.0 0.0.0.127 1.1.3.0 0.0.0.255 log

Router1(conf)#access-list 100 permit ip 1.1.2.0 0.0.0.255 any log

Первая команда непосредственно решает поставленную задачу, а вторая разрешает широковещание RIP протоколов. Проверим создание

Router1#show access-list

Применим список доступа к интерфейсу.

Router1(conf)# interface Serial2/0

Router1(conf-if)# ip access-group 100 in

Для тестирования списка доступа, попытайтесь пропинговать PC1 от PC2, PC3, PC4 и PC5.

PC#Ping 1.1.3.2

Для PC2 и PC3 пинги не пойдут. Для PC4 и PC5 пинги пойдут. Список доступа работает. Посмотрите логи на router1

6.2. Список доступа хост-хост.

Создадим на router2 список доступа, который блокирует доступ к PC5 только с PC2. Контролировать попытки доступа можно по логам на router2.

Router2(conf)#access-list 101 deny ip 1.1.1.130 0.0.0.0 1.1.1.3 0.0.0.0 log

Router2(conf)# access-list 101 permit ip any any

Проверим создание

Router2#show access-list

Применим список доступа к fast Ethernet интерфейсу router2

Router2(conf)#interface FastEthernet0/0

Router2(conf-if)#ip access-group 101 in

Присоединитесь к PC2 и проверьте, что вы не можете пиновать PC5

PC2# Ping 1.1.1.3

На router2 появится лог

Присоединитесь к PC3 и проверьте, что вы можете пиновать PC5.

PC3# Ping 1.1.1.3

На router2 появится лог

6.3. Список доступа сеть-хост.

Вначале удалим предыдущие списки доступа с интерфейсов Router1 и Router2.

Router1(conf)#interface Serial2/0

Router1(conf-if)#no ip access-group 100 in

Router2(conf)#interface FastEthernet0/0

Router2(conf-if)#no ip access-group 101 in

Создадим расширенный список доступа, который блокирует весь трафик к PC1 из локальной сети компьютеров PC2 и PC3. Так как мы блокируем весь трафик, то будем использовать IP протокол.

Router2(conf)#access-list 102 deny ip 1.1.1.128 0.0.0.127 1.1.3.2 0.0.0.0 log

Router2(conf)#access-list 102 permit ip any any

Проверим создание

Router2#show access-list

Применим список к исходящему трафику на интерфейсе Serial2/0 Router2

Router2(conf)#interface Serial2/0

Router2(conf-if)#ip access-group 102 out

Для проверки списка попытайтесь пропинговать PC1 (1.1.3.2) из PC2 и PC3. Пинги не пройдут. Симулятор почему-то не даёт лог на консоли Router2. Но эффект выможете увидеть так

Вы видите после каждого неудачного пинга количество отслеженных (matches) пакетов возрастает.

Контрольные вопросы

1. Что такое ACL?

2. Какой адрес является критерием для разрешения/запрещения пакета?

3. Где применяются ACL?

4. Как задать элемент ACL и что такое инверсная маска?

5. Как роутер обрабатывает элементы ACL?

6. Какой элемент всегда неявно присутствует в ACL?

7. Как ACL применить к интерфейсу и затем его отменить?

8. Чем отличается входной ACL от выходного?

10. Какими тремя командами можно проверить содержимое ACL и привязку к интерфейсу.

11. Что фильтруют расширенные ACL?

12. Какую дополнительную функциональность имеютрасширенные ACL по сравнению со стандартными?

13. Можно ли, используя расширенные ACL, наложить ограничения на трафик к определённой TCP/IP службе?

14. Опишите процедуру создания именованного ACL.

15. Как отредактировать конкретную строку в числовом ACL?

16. Как отредактировать конкретную строку в именованном ACL?

17. Чем отличается форматы команд для ввода элементов числового и именованного ACL?


Похожая информация.


ACL - списки контроля доступа.

Можно назначить по одному списку на:
- каждый протокол
- каждый интерфейс
- входящий и исходящий трафик

ACL не оказывает никакого влияния на трафик, генерируемый самим маршрутизатором.

Бывают:
Стандартные ACL - фильтруют пакеты только по IP адресу источника
Расширенные ACL - фильтруют по:
- IP адресу источника
- IP адресу назначения
- TCP или UDP портам источника
- TCP или UDP портам назначения
- типу протокола (названию или номеру)

А также:
1. Нумерованные ACL:
- от 1 до 99 и от 1300 до 2000 - стандартные IP ACL
- от 100 до 199 и от 2000 до 2699 - расширенные IP ACL
2. Именованные - их более удобно применять, т.к. можно указать их назначение. Требования к именам:
- могут содержать буквы и цифры
- предполагается, что имена будут писаться заглавными буквами
- имена не могут содержать пробелы и знаки пунктуации
В именованные ACL можно добавлять и удалять записи.

Как применяются ACL
1. Создать ACL, указав номер или имя и указать условия.
2. Назначить ACL на интерфейс или терминальную линию.

Как работает стандартный ACL
1. На интерфейс поступает пакет
2. Проверяется, есть ли на входе интерфейса ACL.
3. Проверяется, стандартный ли ACL.
4. Сравнивается адрес источника с первой записью.
5. Если не совпадает, сравнивается со следующей записью.
6. Если не совпадает ни с одной записью, то отбрасывается.
7. Если совпадает с какой-то записью, пропускает или отбрасывает согласно правилу.
8. Если пропускает, ищет адрес назначения в таблице маршрутизации.
9. Если есть, отправляет на нужный интерфейс.
10. Если нет - отбрасывает.

Правила размещения ACL:
- Стандартные ACL надо располагать ближе к сети назначения
- Расширенные ACL- ближе к сети источника.

Создание нумерованного стандартного ACL
Router(config)#access-list access-list-number source
Например:
R1(config)# access-list 10 remark Permit for 192.168.0.0 LAN - описываем ACL или каждую запись в ACL
R1(config)# access-list 10 permit 192.168.0.0 - для классовой сети
R1(config)# access-list 10 permit 192.168.5.0 0.0.0.128 - для бесклассовой сети
Удаление ACL
R1(config)# no access-list 10

wildcard маска образуется путе вычитания маски необходимой сети из маски 255.255.255.0, например
255.255.255.255
-
255.255.15.0
=
0.0.240.255

В ACL вместо адреса источника можно указывать:
- вместо 0.0.0.0 255.255.255.255 - any
- вместо конкретного адреса хоста типа 192.168.5.12 0.0.0.0 - host 192.168.5.12

Применение нумерованного стандартного ACL на интерфейс
Router(config-if)#ip access-group {access-list-number | access-list-name} {in | out}
Например, ACL 10:
R1(config)# access-list 10 permit 192.168.0.0
R1(config)# access-list 10 permit 192.168.5.0 0.0.0.128
применяем на входе интерфейса Fastethernet 0/1
R1(config)# interface f0/1
R1(config-if)# ip access-group 10 in

Hастройка ACL для виртуальных терминальных линий (вместо параметра access-group используется access-class ):
R1(config-line)# access-class access-list-number {in | out}
Например
R1(config)# access-list 22 permit 192.168.1.0
R1(config)# access-list 22 permit 192.168.2.0
R1(config)# line vty 0 4 - надо назначать на все vty, т.к. пользователь может подключиться к любому из них
R1(config-line)# login local
R1(config-line)# transport input telnet
R1(config-line)# ip access-class 22 in

Редактирование нумерованных ACL
При редактировании нумерованных ACL записи вставляются в порядке ввода. Нельзя вставить новую запись между двумя уже введенными. Если это все-таки надо сделать, то:
- Копируем все правила из конфигурации в блокнот.
- Вставляем необходимые записи.
- Удаляем весь AC
- Копируем все записи из блокнота
- Вставляем в конфигурацию.

Именованные стандартные ACL
R1(config)# ip access-list standard NAME - объявляем именованный стандартный ACL
R1(config-std-nacl)# remark Deny for host 192.168.0.13 - описываем ACL
R1(config-std-nacl)# deny 192.168.0.13 - создаем правила
R1(config-std-nacl)# permit 192.168.0.0 0.0.0.255
R1(config-std-nacl)# interface Fa0/0
R1(config-if)# ip access-group NAME out - привязываем ACL к интерфейсу
Называть ACL заглавными буквами не обязательно. Это делается для удобства.

Просмотр и проверка ACL
Используется команда:
Router# show access-lists {access-list-mumber | name}
Например,
R1# show access-lists - выводит все ACL
R1# show access-lists 10 - выводит ACL с номером 10
R1# show access-lists NAM - выводит ACL с именем NAM

Редактирование именованных ACL
У именованных ACL есть преимущество перед нумерованными. Их проще редактировать. Все записи правил в именованных ACL имеют порядковый номер с шагом 10. Т.е. первое правило имеет номер 10, второе - 20 и т.д.
Поэтому у именованных ACL можно удалять конкретные запис, а также добавлять записи между имеющимися правилами с присвоением им номера между номерами правил, между которыми добавляется новое правило.
Например, у нас есть ACL с темя записями:
R1# show access-lists

10 permit 192.168.10.10

Нам надо добавить еще одно правило:
R1(config)# access-list standard WEBSERVER
R1(config-std-nacl)# 15 permit 192.168.10.13

Вот, что получилось:
R1# show access-lists
Standard IP access-list WEBSERVER
10 permit 192.168.10.10
15 permit 192.168.10.13
20 deny 192.168.10.0, wildcard bits 0.0.0.255
30 deny 192.168.12.0, wildcard bits 0.0.0.255

Расшр\иренные ACL
Расширенные списки доступа дают возможность более точно фильтровать трафик, поэтому и используются они чаще. Помимо адреса источника они еще проверяют:
- протокол (IP, ICMP, TCP, UDP и др)
- адрес назначения
- номер порта (не интерфейса)

Синтаксис команды расширенного нумерованного ACL
Router(config)#access-list access-list-number protocol source destination
где:
access-list-number - номер ACL (100-199 и 2000-2699)
deny - запретить трафик
permit - разрешить трафик
remark - описание правила или ACL
protocol - имя или номер протокола. В основном это - IP, ICMP, TCP, UDP.
source - адрес источника
source-wildcard - обратная маска источника
destination - адрес назначения
destination-wildcard - обратная маска назначения
operator - сравнивает номера портов. Может быть: lt-меньше чем, gt-больше чем, eq-равно, neq-не равно, range -включает диапазон.
port - номер порта
established - только для TCP - указывает установленное соединение.

Пример
R1(config)#access-list 103 permit tcp 192.168.10.0 0.0.0.255 any eq 80 - резрешаем доступ по 80 порту от сети 192.168.10.0
R1(config)#access-list 103 permit tcp 192.168.10.0 0.0.0.255 any eq 443 - резрешаем доступ по 443 порту от сети 192.168.10.0
R1(config)#access-list 104 permit tcp any 192.168.10.0 0.0.0.255 established - разрешаем установленные tcp соединения к сети 192.168.10.0.

Расширенные ACL назначаются на интерфейсы так же, как и стандартные. Например:
R1(config)# interface f0/1
R1(config-if)# ip access-group 103 out
R1(config-if)# ip access-group 104 in

Создание именованного расширенного ACL
R1(config)# ip access-list extended SURFING - объявляем именованный расширенный ACL для исходящего трафика
R1(config-ext-nacl)# pernit tcp 192.168.10.0 0.0.0.255 any eq 80 - создаем правила
R1(config-ext-nacl)# pernit tcp 192.168.10.0 0.0.0.255 any eq 443
R1(config)# access-list extended BROWSING - объявляем именованный расширенный ACL для входящего трафика
R1(config-ext-nacl)# pernit tcp any 192.168.10.0 0.0.0.255 established - создаем правила

Комплексные ACL
Стандартные и расширенные ACL могут быть основой для комплексных ACL для улучшения функциональности. Бывают:
- Динамические
- Рефлексивные
- С ограничением по времени

Динамические ACL - если пользователю необходимо получить доступ к какому-либо устройству, находящемуся за маршрутизатором, он сначала должен аутентифицироваться на маршрутизаторе через Telnet. После этого маршрутизатор на определенное время дает доступ, по истечении которого опять надо будет аутентифицироваться.
R1(config)#username Student password 0 cisco — создаем пользователей для подключения через Telnet без привелегий.
R3(config)#access-list 101 permit tcp any host 10.2.2.2 eq telnet - разрешаем отовсюду подключаться к маршрутизатору
R3(config)#access-list 101 dynamic testlist timeout 15 permit ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255 - добавляем динамическую запись с именем testlist, которая будет работать только после установления связи через Telnet в течении 15 минут, а затем будет отключаться. Это правило открывает доступ из сети 192.168.10.0 в сеть 192.168.30.0.
R3(config)#interface serial 0/0/1
R3(config-if)#ip access-group 101 in
— закрепляем ACL 101 за интерфейсом во входящем направлении.
R3(config)#line vty 0 4
R3(config-line)#login local
R3(config-line)#autocommand access-enable host timeout 5
— как только пользователь залогинится на маршрутизатор, выолнится автокоманда, которая даст доступ к сети 192.168.30.0. Сессия Telnet после этого закроется. Доступ к сети сохраниться и будет закрыт после 5 минут ожидания.

Рефлексивные ACL - разрешают трафик извне сети только в случае, если он был инициирован изнутри. Изначально весть трафик извне закрыт. Список доступа запоминает параметры пользовательских сессий, которые дают запрос наружу. Ответ на эти запросы проверяется на соответствие параметрам пользовательской сессии. Рефлексивные ACL имеют только временные записи, которые создаются автоматически с каждой сессией. Рефлексивные ACL не применяются непосредственно на интерфейс, но вкладываются в расширенный ACL , который применяется на интерфейс. Рефлексивные ACL могут быть определены только в расширенных именованных ACL, а использоваться могут с любими ACL.
R2(config)#ip access-list extended OUTBOUNDFILTERS - объявляем именованный расширенный ACL для исходящего трафика.
R2(config-ext-nacl)#permit tcp 192.168.0.0 0.0.255.255 any reflect TCPTRAFFIC - заставляем маршрутизатор отслеживать tcp трафик, который инициировался изнутри, и сохранять в переменной TCPTRAFFIC.
R2(config-ext-nacl)#permit icmp 192.168.0.0 0.0.255.255 any reflect ICMPTRAFFIC — заставляем маршрутизатор отслеживать icmp трафик, который инициировался изнутри, и сохранять в переменной ICMPTRAFFIC .
R2(config)#ip access-list extended INBOUNDFILTERS - объявляем именованный расширенный ACL для входящего трафика.
R2(config-ext-nacl)#evaluate TCPTRAFFIC - заставляем маршрутизатор сравнивать параметры входящего tcp трафика с переменной TCPTRAFFIC, созданной правилом OUTBOUNDFILTERS.
R2(config-ext-nacl)#evaluate ICMPTRAFFIC — заставляем маршрутизатор сравнивать параметры входящего icmp трафика с переменной ICMPTRAFFIC, созданной правилом OUTBOUNDFILTERS.
R2(config)#interface serial 0/1/0
R2(config-if)#ip access-group INBOUNDFILTERS in - применяем ACL для входящего трафика на интерфейс.
R2(config-if)#ip access-group OUTBOUNDFILTERS out - применяем ACL для исходящего трафика на интерфейс.

ACL с ограничением по времени - определяет время, когда в расширенном ACL работает конкретная запись.
R1(config)#time-range EVERYOTHERDAY - обьявляем переменную времени EVERYOTHERDAY.
R1(config-time-range)#periodic Monday Wednesday Friday 8:00 to 17:00 — присваиваем список времени для этой переменной, в котором добавляем дни недели и время.
R1(config)#access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq telnet time-range EVERYOTHERDAY — применяем переменную к правилу.
R1(config)#interface s0/0/0
R1(config-if)#ip access-group 101 out — закрепляем ACL за интерфейсом.

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

Access Control List

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

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

В конце статьи пример настройки и .

Виды 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-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 и отбрасывается.

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



remark FILE


remark MAIL


remark DNS

Первой строкой мы удаляем существующий список, далее создаём его заново и перечисляем все новые правила в нужном нам порядке. Командой в третьей строке мы разрешили проход всех 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)# permit ip host 172.16.6.61 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
Работа 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


Как только вы примените 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)

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.
Данные от хостов выглядят так:

Маршрутизатор расчехляет 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

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

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

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

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

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

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

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

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

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

10.1.10.255-10.2.10.255

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

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

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

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

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

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

Сервера нам понадобятся следующие:
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

1) Сеть управления
не имеет доступа в интернет вообще
Готово
2) Хосты из сети ПТО
Имеют доступ только к профильным сайтам, например, сайт
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)# 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, то их можно и пинговать:



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 можно считать законченным.
В качестве ещё одного ДЗ ответьте на вопрос, почему нет доступа в Интернет с компьютеров эникиев в Питере и в Кемерово. Ведь мы их добавили уже в список доступа.

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

access-list 101 permit ip 192.168.2.0 0.0.0.255 any

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

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

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

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

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

Авторы:

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

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

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

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

Введение

Итак представим, что наша небольшая локальная сеть создана, и в ней в качестве активного оборудования используется маршрутизатор Cisco. Через него проходит большое количество самого разного трафика. И сетевому инженеру необходимо его фильтровать. Здесь и начинается знакомство со списками управления доступом.

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

ACL разделяют на стандартные и расширенные.

Основные особенности

  • Фильтрация трафика возможно как на входе, так и на выходе трафика из выбранного интерфейса
  • Для данных, которые должны быть допущены, применяется атрибут permit . Для тех, которые следует отбросить - deny
  • Списки управления доступом настраиваются таким образом, что если трафик не попадает не под одно правило, указанное в списке, он автоматически будет запрещен

На рисунке ниже указана логика фильтрации пакетов, относительно расположения ACL на маршрутизаторе.

Таким образом, когда трафик начинает свое движение, маршрутизатор проверяет поля пакета, на соответствие списку правил из ACL. Если они будут найдены, то применится действие, настроенное для такого типа пакета - разрешить или запретить. Если соответствие не будет найдено - трафик автоматически заблокируется.

Стандартные списки ACL

Команда для настройки на маршрутизаторах Cisco имеет следующий синтаксис.

access-list номер-списка {deny | permit} отправитель [инвертированная маска отправителя ]

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

Обратите внимание . Нумерация стандартных списков ACL доступна в диапазоне 1-99 и 1300-1999.

Таким образом, алгоритм настройки можно описать следующим образом:

  1. Определяем место расположения списка ACL - интерфейс и направленность данных
  2. В режиме глобальной конфигурации указываем правила, используя команду access-list . Используйте справку "? ", для просмотра доступных параметров.
  3. В режиме конфигурацирования интерфейса назначаем для него соответствующий список - ip access-group number {in | out}

Расширенные ACL

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

Настройка

Общий принцип не изменился. Вам нужно определить интерфейс и направление трафика, затем задать список параметров фильтрации. Сам список создается и настраивается следующим образом:

IP access-list access-list-number ] {deny | permit} protocol source source-wildcard destination destination-wildcard ICMP access-list access-list-number ] {deny | permit} icmp source source-wildcard destination destination-wildcard | ] TCP access-list access-list-number ] {deny | permit} tcp source source-wildcard ] destination destination-wildcard ] UDP access-list access-list-number ] {deny | permit} udp source source-wildcard ] destination destination-wildcard ] cisco.com

Видео к статье :

Заключение

Списки контроля доступа ACL Cisco - мощное средство обеспечения безопасности в сети. Используйте его, чтобы фильтровать ваш трафик. Но помните про особенности. Если вы некорректно укажите параметры фильтрации, "правильный" трафик может не попасть к адресату.

Зачем искать информацию на других сайтах, если все собрано у нас?