Брандмауер дистрибутива Linux може блокувати ваш трафік VPN

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

Знайдіть менеджер і бекенд

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

Бекенд такий самий важливий, як фронтенд. Інсталяція firewalld може керувати nftables або старим бекендом iptables залежно від версії та конфігурації, і обидва дають різний вивід перевірки. Запишіть дистрибутив, версію та бекенд у заявку, перш ніж порівнювати систему з будь-яким посібником.

Узгодьте напрямок та інтерфейс

Вихідний запит клієнта, вхідний слухач і пересланий пакет проходять через різні хуки, і правило для одного не покриває інших. Зона, яка дозволяє локальну LAN, часто не включає інтерфейс тунелю або пул адрес VPN. Інтерфейс тунелю зазвичай потрапляє в зону за замовчуванням, яка нерідко суворіша за зону фізичного адаптера. Ця невідповідність пояснює, чому перегляд працює в LAN і припиняється в момент підняття тунелю.

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

Тримайте власників правил у згоді

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

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

Перевірте виправлення, не втративши блокування

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

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

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

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