Правило слухача firewalld і політика пересилання: що робить кожне

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

Дві політики, один тунель

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

Практичний наслідок: робочий тунель нічого не каже про другу політику, а правильна друга політика не робить першу непотрібною.

Пропустіть справжній зовнішній слухач

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

Авторизуйте розшифроване призначення окремо

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

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

Чому довіра до інтерфейсу — неправильний короткий шлях

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

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

Перевірте три речі, включно з однією відмовою

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

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