Почему правило блокировки клиента OpenVPN никогда не попадает в FORWARD

Два клиента на одном сервере OpenVPN могут достигать друг друга даже после того, как вы добавили правило DROP для их пула. Правило находится в цепочке FORWARD, трафик явно идёт, а счётчик этого правила остаётся на нуле. Естественный вывод — межсетевой экран сломан. Чаще пакет вообще не входил в цепочку.

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

Два пути, по которым может пройти пакет партнёра

Когда параметр внутренней пересылки отключён, пакет от клиента A приходит на туннельный интерфейс с пунктом назначения внутри выделенного адреса клиента B. Таблица маршрутизации сервера отправляет его обратно через тот же туннельный интерфейс, потому что маршрут к адресу B принадлежит серверу. Это поток внутрь и наружу через хост, и его оценивает путь пересылки IPv4.

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

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

Когда счётчик никогда не сдвигается

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

Третья — позиция. Правило выше в цепочке может принять поток раньше, чем будет оценено ваше DROP, а правило ниже может быть тем, что действительно решает исход. Прочитайте цепочку по порядку с видимыми счётчиками, затем проверьте, у какого правила растёт счётчик при повторе теста.

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

Выбор границы, которая может фильтровать

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

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

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

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

Проверка изоляции вместо доверия правилу

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

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

Изоляция — это наблюдаемый результат на границе, которая действительно несёт поток. Правило DROP где-то в хосте не является доказательством; неудачное соединение плюс сдвинувшийся счётчик правила, которое его вызвало, — является.