Чому правило блокування клієнта OpenVPN ніколи не потрапляє у FORWARD

Два клієнти на одному сервері OpenVPN можуть діставати один одного навіть після того, як ви додали правило DROP для їхнього пулу. Правило стоїть у ланцюгу FORWARD, трафік очевидно йде, а лічильник цього правила залишається на нулі. Природний висновок — міжмережевий екран зламаний. Частіше пакет узагалі не входив у ланцюг.

Є два шляхи, якими пакет партнера може пройти через сервер OpenVPN, і їх визначає конфігурація, а не міжмережевий екран. Знання того, який шлях використовується, підказує, чи правило хоста взагалі на правильному місці.

Два шляхи, якими може пройти пакет партнера

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

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

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

Коли лічильник ніколи не зрушується

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

Третя — позиція. Правило вище в ланцюгу може прийняти потік раніше, ніж буде оцінено ваше DROP, а правило нижче може бути тим, що насправді вирішує результат. Читайте ланцюг по порядку з видимими лічильниками, потім перевірте, у якого правила зростає лічильник, коли ви повторюєте тест.

Проведіть один контрольований обмін між двома клієнтами, справжні адреси яких ви підтвердили з власного стану сервера, а не з оренди, яку пам'ятаєте. Якщо відповідний лічильник досі не рухається, запідозріть шлях, перш ніж переписувати зіставлення. Якщо він рухається, але з'єднання все одно вдається, скидання перекривається пізніше, і проблема в порядку. Ця відповідь визначає, чи є виправлення зміною правила або зміною топології, тож отримайте її перед будь-яким редагуванням.

Вибір межі, яка може фільтрувати

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

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

Багатьом розгортанням краще служить фільтрація на рівні клієнта або групи, де ідентичність відома й політика йде за користувачем, а не за адресою, що змінюється під час повторного підключення. Це інший механізм порівняно з ланцюгом хоста, і їх не слід змішувати без ясної причини.

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

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

Перевірте заборонений випадок і дозволений випадок в одному запуску. Запустіть нове з'єднання від одного клієнта до іншого й підтвердьте, що воно не вдається, потім підтвердьте, що з'єднання, яке має бути дозволене, усе ще працює. Якщо перевіряти лише перше, екран, що блокує все, виглядає як успіх.

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

Ізоляція — це спостережуваний результат на межі, яка справді несе потік. Правило DROP десь у хості не є доказом; невдале з'єднання плюс зрушений лічильник правила, що його спричинило, — є.