Чому ваш інтерфейс VPN постійно залишає свою зону firewalld

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

Зона тримається, доки інтерфейс не буде створено заново

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

Та сама логіка пояснює поведінку під час перезавантаження: прив'язки часу виконання не переживають перезапуск, а постійні прив'язки діють лише для пристроїв, які firewalld вважає своїми.

Перш ніж щось змінювати, з'ясуйте, який компонент призначає зону.

Прочитайте три речі, перш ніж щось змінювати

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

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

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

Коли з'єднанням володіє NetworkManager

Якщо NetworkManager керує з'єднанням VPN, його профіль несе зону й передає її firewalld, коли з'єднання активується. Постійна прив'язка інтерфейсу у firewalld для того самого пристрою тоді може ігноруватися, бо власник — NetworkManager. Задайте зону на з'єднанні й переконайтеся, що ви редагуєте профіль VPN, а не стороннє фізичне з'єднання чи тимчасовий запис.

Зміна цієї властивості може негайно вплинути на активне з'єднання.

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

Коли прив'язкою володіє firewalld

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

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

Не кидайте інтерфейс у trusted лише для того, щоб застосунок запрацював.

Перевірте перезавантаження, перепідключення й перезапуск

Зміна завершена лише тоді, коли вона переживає всі три.

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

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

Запишіть власника, значення й очікуваний результат у runbook, і наступне перепризначення буде пояснюваним.