NetLab Academy

Сетевые лаборатории в браузере

Войти Начать бесплатно

Теория: ACL — списки контроля доступа

Фильтрация трафика по правилам: standard/extended ACL, порядок обработки, wildcard-маски. Прочитайте материал, а затем пройдите тест — следующий пункт курса откроется после верных ответов.

Зачем нужны ACL

ACL (Access Control List) — набор правил, по которым роутер или файрвол решает, пропустить пакет дальше или отбросить. Правило обычно матчит по «пятёрке» признаков (5-tuple): IP-адрес источника, IP-адрес назначения, протокол (TCP/UDP/ICMP/...), порт источника, порт назначения. Применяют ACL по двум разным причинам, которые легко перепутать: для безопасности (заблокировать нежелательный трафик, например доступ к серверу управления только с определённых адресов) и просто для управления потоками трафика (например, отметить определённый трафик для QoS или маршрутизации по политике — даже без намерения что-то заблокировать). Сам механизм один и тот же, цели использования разные.

Standard и Extended ACL

Standard ACL — самый простой вид, матчит только по IP-адресу источника, без учёта назначения, протокола или портов. Грубый инструмент, но иногда достаточный — например, «разрешить telnet-доступ к роутеру только с этой управляющей подсети», где неважно, какой именно протокол используется. Extended ACL матчит и источник, и назначение, и протокол, и порты — гораздо более гибкий и точный инструмент, поэтому в реальной практике почти всегда используется именно extended, а standard остался скорее исторической опцией.

Есть и разделение по способу идентификации: numbered ACL (идентифицируется числом, например access-list 101) и named ACL (идентифицируется именем, например ip access-list extended BLOCK-GUESTS). У именованных ACL практическое преимущество — можно вставить или удалить отдельную строку по номеру правила без необходимости полностью пересоздавать весь список заново, что у numbered ACL на старых платформах часто было невозможно сделать без удаления всего списка целиком.

Порядок обработки и неявный deny

Правила ACL проверяются по порядку сверху вниз, и применяется первое же совпавшее правило — все правила после него для этого конкретного пакета уже не имеют значения, даже если они тоже бы совпали. В конце каждого ACL есть невидимый, никогда явно не прописываемый implicit deny all — если пакет не совпал ни с одним явным правилом из списка, он будет отброшен молча, без уведомления отправителя. Отсюда прямое следствие: порядок правил критичен — узкое (специфичное) правило обязательно должно стоять выше более широкого, иначе широкое правило «съест» трафик первым, и узкое правило просто никогда не получит шанс сработать, оставшись мёртвым кодом в конфигурации.
Пакет идёт по списку сверху вниз и останавливается на первом совпадении
Правило-тень — не ошибка синтаксиса: конфигурация принимается, ничего не мигает, в логах пусто. Именно на этом построен инцидент rule-shadow в лабе acl01.

Где и в какую сторону применяется ACL

ACL сам по себе — просто список правил, который ничего не делает, пока его не привязали к конкретному интерфейсу и направлению — inbound (проверка трафика, входящего в роутер через этот интерфейс, до принятия решения о маршрутизации) или outbound (проверка трафика, выходящего из роутера через этот интерфейс, уже после решения о маршрутизации). Один и тот же набор правил может вести себя совершенно по-разному в зависимости от того, на каком интерфейсе и в каком направлении он применён — классическая ошибка новичков: написать правильные правила, но повесить их на неверный интерфейс или неверное направление, и потом долго недоумевать, почему трафик блокируется (или, наоборот, не блокируется) не там, где ожидалось.

Wildcard-маска — инвертированная логика

В отличие от обычной маски подсети, ACL (в Cisco-style синтаксисе) использует wildcard mask, где логика буквально обратная: бит 0 означает «этот бит должен совпадать», а 1 — «этот бит не важен, игнорируем». Технически wildcard-маска получается простой побитовой инверсией обычной маски подсети. Например, маска подсети /24 — 255.255.255.0, а соответствующая wildcard — 0.0.0.255 (последний октет полностью игнорируется при сравнении). Для подсети /26 (маска 255.255.255.192) wildcard будет 0.0.0.63.

Есть и удобные сокращения: host 10.0.0.5 — это ровно то же самое, что 10.0.0.5 0.0.0.0 (wildcard из сплошных нулей — должны совпасть все биты, то есть конкретно один-единственный адрес), а any — сокращение для 0.0.0.0 255.255.255.255 (wildcard из сплошных единиц — все биты не важны, подходит абсолютно любой адрес).

Практический пример

Задача: разрешить SSH (TCP/22) только с хоста 10.0.0.5 к серверу 192.168.1.10, всё остальное к этому серверу запретить, а остальной трафик в сети не трогать вообще. Правильный порядок правил:
1. permit tcp host 10.0.0.5 host 192.168.1.10 eq 22
2. deny ip any host 192.168.1.10
3. permit ip any any

Третья строка обязательна: неявного «разрешить всё остальное» не существует — implicit deny в конце списка заблокирует вообще весь трафик, для которого нет ни одного явного permit, если не добавить финальный permit ip any any самостоятельно. Поменяйте местами строки 1 и 2 — и SSH с разрешённого хоста тоже перестанет работать, потому что deny-правило перехватит его раньше, чем очередь дойдёт до permit.

Established и возвратный трафик

ACL по умолчанию работают без сохранения состояния (stateless) — каждый пакет проверяется независимо от остальных, в отличие от современных файрволов с stateful-инспекцией. Это создаёт практическую проблему: если разрешить TCP только в одну сторону, ответные пакеты (например, ACK на установленное соединение) могут не пройти через ACL в обратном направлении. Ключевое слово established — частичное решение: оно матчит TCP-пакеты, у которых выставлен флаг ACK или RST, то есть пакеты, которые похожи на часть уже идущей сессии, а не на попытку начать новую (TCP SYN без ACK). Это не настоящая stateful-проверка — established просто смотрит на флаги конкретного пакета, не помня предыдущих, но на практике этого достаточно для большинства простых сценариев разрешения возвратного трафика.

Как проверять / частые ошибки

show access-lists — посмотреть сами правила и счётчики совпадений по каждой строке отдельно — отличный способ понять, какое правило реально срабатывает на практике, а какое мёртвым грузом висит в конфигурации, потому что более общее правило выше перехватывает весь трафик первым. Частые ошибки: забыли про implicit deny, и весь незапланированный трафик внезапно блокируется; перепутали wildcard-маску с обычной маской подсети (по привычке написали 255.255.255.0 вместо нужной 0.0.0.255 — и правило либо не сработает вообще, либо сработает совсем не так, как задумывалось); более общее правило стоит выше специфичного и перехватывает трафик раньше, чем дело доходит до нужного узкого правила.

Команды настройки — шпаргалка

# создать список правил
ip access-list extended BLOCK-GUESTS
                              # extended — вид списка: умеет проверять
                              #   отправителя, получателя, протокол и порт
                              #   (у standard есть только отправитель).
                              #   Последнее слово — имя, придумываете сами

# сами правила, по порядку сверху вниз
 permit tcp host 10.0.0.5 host 192.168.1.10 eq 22
                              # permit разрешить (есть deny); tcp — протокол;
                              #   host 10.0.0.5 — отправитель, слово host значит
                              #   «ровно один адрес»; затем получатель;
                              #   eq 22 — порт получателя равен 22.
                              #   Бывают также gt, lt, range
 deny ip any host 192.168.1.10
                              # ip — любой протокол поверх IP; any — любой адрес.
                              #   То есть: всем и всё к этому одному узлу — нельзя
 permit ip any any            # два any — отправитель и получатель. Без этой
                              #   строки сработает implicit deny, невидимое
                              #   правило в конце любого ACL, и всё неописанное
                              #   будет отброшено
 permit tcp any any established
                              # established пропускает только пакеты с флагами
                              #   ACK или RST — ответы внутри уже установленных
                              #   сессий. Начать соединение снаружи так нельзя

# применить на порт — без этого список не делает НИЧЕГО
interface GigabitEthernet0/1
 ip access-group BLOCK-GUESTS in
                              # имя списка и направление: in — проверять
                              #   входящий в интерфейс трафик, out — исходящий

# проверка
show access-lists             # все списки со счётчиками совпадений по строкам
Контрольные вопросы

Дальше — лабораторная работа «ACL: закрой доступ»

Для неё нужен аккаунт: стенд поднимается персонально под вас — свои роутеры, свои конфиги, никто в них не мешает. Регистрация — почта и пароль.

Теория прочитана. Дальше — руками.

Личный стенд из настоящих роутеров разворачивается за секунды. Платформа проверяет не ответы на тесты, а состояние вашей сети: поднялись ли соседства, сошлись ли маршруты, ходит ли ping. Рядом — AI-наставник, который видит ваши конфиги и ведёт к решению, не выдавая готовое.

Начать бесплатно → бета открыта, доступ бесплатный