Что это такое
ACL — это упорядоченный список правил, по которому устройство решает, пропускать пакет или отбросить. Список применяется к интерфейсу и разбирается строго сверху вниз: как только нашлось первое совпадение, решение принято, остальные строки не смотрятся.
Идея та же, что у фаервола на сервере, только ближе к сети: фильтрация происходит на маршрутизаторе или коммутаторе, до того как трафик дошёл до конечных устройств. На небольшой сети это часто и есть основной инструмент разграничения — особенно если VLAN уже настроены и нужно решить, кому между ними можно ходить.
Кроме фильтрации списками доступа пользуются и для других задач: пометить трафик для приоритизации, выбрать, что заворачивать в туннель, ограничить доступ к управлению самим устройством. Синтаксис один, применение разное.
Стандартные и расширенные
Стандартные (standard) | Расширенные (extended) | |
|---|---|---|
Смотрят на | Только адрес отправителя | Отправителя, получателя, протокол, порты |
Где применять | Ближе к получателю | Ближе к источнику |
Типичная задача | Ограничить доступ к управлению | Разграничить доступ между сегментами |
Стандартные списки — грубый инструмент: «из этой сети можно, из той нельзя». Их применяют как можно ближе к получателю, потому что иначе можно случайно отрезать отправителю доступ и ко всему остальному.
Расширенные позволяют сформулировать правило вроде «из офисной сети к серверу баз данных только на порт 5432, остальное запретить». Их, наоборот, вешают ближе к источнику: чем раньше отсечь ненужный трафик, тем меньше он занимает ресурсов по пути. На практике почти всегда нужны именно расширенные.
Порядок важнее содержания
Самая частая ошибка выглядит так. Первой строкой написали «запретить всей сети 192.168.10.0/24 доступ к серверам», второй — «разрешить бухгалтеру 192.168.10.15 доступ к серверу 1С». Бухгалтер доступа не получит никогда: его пакет совпадёт с первым правилом, и до второго разбор не дойдёт.
Отсюда правило, которое стоит просто запомнить: частные разрешения идут выше общих запретов. Сначала исключения, потом широкие правила. Проверять себя удобно вопросом «какое правило сработает первым для конкретного пакета» — а не «есть ли где-то нужное разрешение».
Как править списки, не ломая порядок
На многих платформах новые строки добавляются в конец — а именно там они чаще всего бесполезны. Поэтому правилам принято присваивать номера с шагом, например 10, 20, 30: тогда между 10 и 20 всегда можно вставить строку 15, не переписывая весь список. Если нумерации нет, списки редактируют целиком: составляют новый, проверяют, потом подменяют старый.
Неявный запрет в конце (Implicit Deny)
В конце любого ACL стоит невидимая строка «запретить всё остальное». Её не видно в конфигурации, но она есть и работает. Из этого следует неприятный сюрприз: применили список из одного разрешающего правила — и всё, кроме этого правила, отвалилось.
Практический приём: если нужно запретить что-то конкретное, а остальное оставить как было, не забудьте последней строкой явно разрешить всё. И привыкайте писать эту строку сознательно — тогда список читается однозначно и через полгода, когда причина его появления забудется.
Про страховку
Применять ACL стоит к устройству, к которому у вас есть физический доступ или запасной канал. Отрезать себе управление одной командой — дело нескольких секунд, и ошибка эта совершенно не зависит от опыта. На оборудовании, где есть отложенное применение конфигурации с автоматическим откатом, им нужно пользоваться не задумываясь: сохранили, проверили доступ, подтвердили. Не подтвердили — устройство само вернулось к рабочей конфигурации через заданное время.
Направление: in или out
Список применяется к интерфейсу в конкретном направлении — на входящий трафик или на исходящий. Разница принципиальная: правило, повешенное не туда, либо не сработает вовсе, либо отфильтрует совсем не то, что ожидалось.
Направление считается относительно устройства, а не относительно вашего представления о «наружу». Трафик, который приходит в этот интерфейс, — входящий, даже если по смыслу он идёт из интернета в локальную сеть. Именно на этой путанице чаще всего и ошибаются.
Про ответный трафик
Правило, разрешающее запрос, само по себе не разрешает ответ. Если оборудование не отслеживает состояние соединений, придётся писать встречное правило — и здесь снова легко открыть больше, чем хотелось: разрешение «всё с порта 80» пропускает и то, что никто не запрашивал.
Поэтому, если устройство умеет работать с состоянием соединений (на маршрутизаторах это обычно называется reflexive ACL, на фаерволах — stateful-режим), пользоваться нужно именно этим. Тогда ответ на разрешённый запрос пропускается автоматически, а всё незапрошенное остаётся снаружи.
Как отлаживать списки доступа
Главный вопрос при разборе «почему не работает» — какое правило сработало. Угадывать не нужно: оборудование считает совпадения по каждой строке, и эти счётчики видно в выводе команды просмотра ACL.
Метод простой. Обнулите счётчики, воспроизведите проблему, посмотрите список снова. Строка, у которой счётчик вырос, и есть та, что приняла решение. Если выросло у запрещающего правила, которое вы считали неприменимым к этому трафику, — значит порядок строк не тот, что вы держали в голове.
Хуже, когда не выросло вообще ничего. Это означает, что трафик до списка не доходит: либо он повешен не на тот интерфейс, либо не в том направлении, либо пакеты идут другим путём. Полезная привычка на такой случай — добавить в конец явное правило «запретить всё» с включённым логированием: тогда всё, что отбрасывается неявным запретом, станет видно в журнале вместе с адресами и портами.
Логирование, правда, стоит ресурсов, и на нагруженном интерфейсе его включают точечно и ненадолго. Оставленное на месяц правило с логом само по себе способно положить маршрутизатор — не самый удачный способ узнать, что диагностика удалась.
