Dlaczego interfejs VPN wciąż opuszcza swoją strefę firewalld

Dodajesz tun0 do właściwej strefy, aplikacja zaczyna działać, a poprawka ulatnia się przy następnym ponownym połączeniu. Ponowne uruchomienie tego samego polecenia działa, co sprawia, że wygląda to, jakby firewalld zapomniał. Nie zapomniał; coś z silniejszym prawem do tego interfejsu przydzieliło go ponownie.

Strefa przetrwa, dopóki interfejs nie zostanie utworzony od nowa

Przydzielenie strefy firewalld do interfejsu jest powiązaniem, a powiązania są przywiązane do obiektu interfejsu w takiej postaci, w jakiej istnieje teraz. Klient VPN, który rozbiera urządzenie i tworzy je od nowa, wytwarza nowy obiekt, a nowy zaczyna od tego, co mówi komponent przydzielający. Dlatego objaw powtarza się przy każdym ponownym połączeniu, a nie przy każdym pakiecie.

Ta sama logika wyjaśnia zachowanie przy restarcie: powiązania czasu wykonania nie przeżywają restartu, a powiązania trwałe dotyczą tylko urządzeń, które firewalld uważa za swoje.

Zanim cokolwiek zmienisz, ustal, który komponent przydziela strefę.

Przeczytaj trzy rzeczy, zanim cokolwiek zmienisz

Zapisz strefę, którą interfejs ma teraz, aktywne strefy wraz z ich interfejsami i trwałą listę interfejsów dla strefy, którą zamierzasz. Uruchom te zapytania przed zmianą, po ponownym połączeniu i po restarcie. Porównanie trzech wyników mówi, czy powiązanie jest zastępowane, ignorowane, czy tylko stosowane z opóźnieniem. Jeśli trwała lista już wymienia urządzenie, a strefa czasu wykonania się nie zgadza, coś nadpisuje twoją zmianę.

Zapisuj też rzeczywistą nazwę urządzenia na każdym etapie, bo tunel, który dziś ląduje na tun0, jutro może wylądować na tun1.

Zapisane powiązanie z ogólną nazwą nie jest kontrolą tożsamości, a dwie minuty notowania oszczędzają godzinę zgadywania.

Gdy połączenie należy do NetworkManagera

Jeśli NetworkManager zarządza połączeniem VPN, jego profil niesie strefę i przekazuje ją do firewalld, gdy połączenie się aktywuje. Trwałe powiązanie interfejsu w firewalld dla tego samego urządzenia może wtedy zostać zignorowane, bo właścicielem jest NetworkManager. Ustaw strefę na połączeniu i potwierdź, że edytujesz profil VPN, a nie niepowiązane połączenie fizyczne czy tymczasowy zapis.

Zmiana tej właściwości może natychmiast wpłynąć na aktywne połączenie.

Utrzymuj dostępną ścieżkę zarządzania i przeczytaj politykę strefy docelowej przed jej zastosowaniem. Edytowanie pola ZONE w pliku ifcfg jest poprawne tylko tam, gdzie ten plik nadal jest źródłem konfiguracji.

Gdy powiązanie należy do firewalld

Dla samodzielnego tunelu z celowo stabilną nazwą interfejsu trwała zmiana interfejsu jest właściwym narzędziem. Zastosuj ją przez przeładowanie lub cykl życia, którego używa twoje wdrożenie, a potem sprawdź stan czasu wykonania, bo zmiana tylko trwała opisuje intencję, a nie to, co jest aktywne. Oba mogą się różnić tak długo, jak trwa przeładowanie.

Jeśli nazwa interfejsu jest dynamiczna, utrzymuj przydział przez cały cykl życia połączenia, zamiast ścigać się z tunelem, który zażąda nazwy pierwszy.

Nie wrzucaj interfejsu do trusted tylko po to, żeby aplikacja działała.

Sprawdź przeładowanie, ponowne połączenie i restart

Zmiana jest skończona dopiero wtedy, gdy przetrwa wszystkie trzy.

Najpierw przeładuj, bo tam znikają zmiany tylko w czasie wykonania. Potem połącz tunel ponownie, bo tam zastąpiony interfejs traci swoje powiązanie. Potem zrestartuj, bo tam w końcu ujawnia się niezgodność właściciela. Zapisuj strefę na każdym etapie i porównuj ją z zapisaną intencją, i zaznacz, który krok wytworzył różnicę.

Jeśli strefa jest poprawna, a aplikacja nadal zawodzi, problem jest w regułach strefy lub w klasyfikacji opartej na źródle, a nie w członkostwie. Dokumentacja firewalld dotycząca połączeń i interfejsów jest odniesieniem do tego, jak własność powinna działać.

Zapisz właściciela, wartość i oczekiwany wynik w runbooku, a następne przydzielenie będzie wyjaśnialne.