Обмежте правило SNAT для OpenVPN, перш ніж воно зламає nginx

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

Переконайтеся, що контейнер може створити пристрій tun

Ніщо інше не має значення, якщо тунельний інтерфейс не може існувати. Перевірте, що /dev/net/tun присутній і що створення тестового пристрою вдається, бо багато провайдерів типово вимикають tun у контейнерах. Жодна робота з firewall не компенсує пристрій, який так і не було створено.

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

Вирішіть, що MASQUERADE робить на цьому інтерфейсі

На звичайній віртуальній машині звичайне правило виходу — це POSTROUTING MASQUERADE з основного інтерфейсу. У контейнері OpenVZ видимий пристрій часто venet0, віртуальний інтерфейс під керуванням хоста, а не маршрутизована мережева карта, і MASQUERADE там поводиться не завжди так, як припускають посібники.

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Без правил пересилання трансляція все одно відбувається, а ядро все одно відмовляється пересилати. Це поєднання створює заплутаний стан, коли лічильники на правилі NAT зростають, а клієнт нічого не отримує. Два рядки FORWARD теж мають стояти перед будь-яким широким правилом drop у тому самому ланцюжку. Порядок — частина конфігурації, а не деталь реалізації.

Обмежте правило одним пулом і одним інтерфейсом

Другий симптом має іншу причину: правило POSTROUTING без обмеження джерела й без обмеження виходу. Таке правило переписує кожен пакет, що залишає хост.

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

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

Зробіть правила постійними й з’ясуйте, хто ще ними володіє

Правила, додані вручну, зникають під час перезавантаження, тому збережіть їх за допомогою iptables-save або керуйте ними через netfilter-persistent там, де він встановлений. Підтвердьте, що відновлення виконується до запуску OpenVPN. Потім один раз навмисно перезавантажтеся, замість того щоб виявити прогалину під час інциденту.

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

Перевірте лічильниками й одним перехопленим потоком

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

На сервері прочитайте лічильники пакетів на правилах NAT і FORWARD за допомогою iptables -t nat -L -v -n і поспостерігайте за одним потоком у перехопленні. Якщо адреса клієнта з’являється в перехопленні й відповіді немає, прогалина на зворотному шляху або у фільтрації провайдера, а не в профілі клієнта. Порівняйте перехоплене джерело з адресою, на яку транслює правило, бо розбіжність означає, що раніше збіглося інше правило. Один спостережений потік вирішує більше, ніж сторінка читання конфігурації.

Тримайте пул, трансльовану адресу й назву інтерфейсу разом у журналі змін. Правило, правильне для одного пулу, неправильно транслює наступний.