Две группы клиентов, один сервер: где применять политику

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

Подсеть — это метка, а не правило

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

Именно владение адресом делает префикс пригодным в качестве селектора группы. Каждая аутентифицированная личность должна соответствовать предсказуемому адресу или диапазону, а это сопоставление ломается, как только несколько устройств делят одни учётные данные и одно назначение. Решите вопросы личности и одновременности, прежде чем полагаться на префикс источника, потому что политика, которая угадывает, какая машина звонит, в худший момент авторизует не ту.

Выберите путь, по которому идёт трафик между узлами

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

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

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

Напишите матрицу до правил

Короткая матрица проще для обзора, чем набор правил, и это контракт, который реализация должна выполнить: узлы одной группы разрешены, узлы между группами запрещены, обеим группам разрешён доступ к одному именованному общему сервису, всё остальное запрещено. Запишите эти четыре строки, прежде чем открыть редактор межсетевого экрана. Рецензент, который не читает синтаксис правил, всё равно может проверить матрицу. Реализации остаётся только соответствовать строкам.

Держите три класса назначения раздельно, пока пишете. Сервис на хосте VPN — это локальный ввод, другой клиент — транзит между узлами, а машина за шлюзом — другой путь пересылки. Одно щедрое правило может случайно разрешить все три, и так групповая политика превращается в плоскую сеть с лишними шагами. Запишите класс рядом с каждой строкой, чтобы намерение пережило следующую правку.

Разместите правила там, где они выживут

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

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

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

Докажите это с обеих сторон

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

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