De ce interfața dvs. VPN tot părăsește zona firewalld

Adăugați tun0 în zona corectă, aplicația începe să funcționeze, iar corectarea se evaporă la următoarea reconectare. Rularea din nou a aceleiași comenzi funcționează, ceea ce face să pară că firewalld a uitat. Nu a uitat; ceva cu o pretenție mai puternică asupra acelei interfețe a reatribuit-o.

Zona supraviețuiește până când interfața este recreată

Atribuirea unei zone firewalld unei interfețe este o legătură, iar legăturile sunt atașate de obiectul interfeței așa cum există acum. Un client VPN care desființează dispozitivul și îl recreează produce un obiect nou, iar cel nou începe de la ce spune componenta care atribuie. De aceea simptomul se repetă la fiecare reconectare și nu la fiecare pachet.

Aceeași logică explică comportamentul la repornire: legăturile de execuție nu supraviețuiesc unei reporniri, iar legăturile permanente se aplică doar dispozitivelor pe care firewalld crede că le deține.

Înainte de a schimba ceva, aflați care componentă atribuie zona.

Citiți trei lucruri înainte de a schimba ceva

Notați zona pe care o are acum interfața, zonele active cu interfețele lor și lista permanentă de interfețe pentru zona pe care o intenționați. Rulați acele interogări înainte de schimbare, după o reconectare și după o repornire. Compararea celor trei rezultate vă spune dacă legătura este înlocuită, ignorată sau doar aplicată târziu. Dacă lista permanentă numește deja dispozitivul, iar zona de execuție nu este de acord, ceva vă suprascrie editarea.

Notați și numele real al dispozitivului la fiecare pas, pentru că un tunel care aterizează azi pe tun0 poate ateriza mâine pe tun1.

O legătură salvată la un nume generic nu este o verificare de identitate, iar două minute de notițe economisesc o oră de presupuneri.

Când NetworkManager deține conexiunea

Dacă NetworkManager administrează conexiunea VPN, profilul ei poartă zona și o transmite la firewalld când conexiunea se activează. O legătură permanentă de interfață în firewalld pentru același dispozitiv poate fi atunci ignorată, pentru că proprietar este NetworkManager. Setați zona pe conexiune și confirmați că editați profilul VPN, nu o conexiune fizică nelegată sau o înregistrare temporară.

Modificarea acelei proprietăți poate afecta imediat o conexiune activă.

Păstrați disponibilă o cale de administrare și citiți politica zonei destinație înainte de a o aplica. Editarea câmpului ZONE dintr-un fișier ifcfg este corectă doar acolo unde acel fișier este încă sursa configurației.

Când firewalld deține legătura

Pentru un tunel de sine stătător cu un nume de interfață intenționat stabil, o schimbare permanentă a interfeței este instrumentul potrivit. Aplicați-o prin reîncărcarea sau ciclul de viață folosit de implementarea dvs., apoi inspectați starea de execuție, pentru că o editare doar permanentă descrie intenția, nu ceea ce este activ. Cele două pot diferi cât durează o reîncărcare.

Dacă numele interfeței este dinamic, mențineți atribuirea pe durata ciclului de viață al conexiunii, în loc să vă întreceți cu tunelul care revendică numele primul.

Nu aruncați interfața în trusted doar ca să funcționeze aplicația.

Testați reîncărcarea, reconectarea și repornirea

O schimbare este terminată doar când supraviețuiește tuturor trei.

Reîncărcați mai întâi, pentru că acolo dispar editările doar de execuție. Apoi reconectați tunelul, pentru că acolo o interfață înlocuită își pierde legătura. Apoi reporniți, pentru că acolo se arată în sfârșit o nepotrivire de proprietar. Notați zona la fiecare etapă și comparați-o cu intenția pe care ați scris-o, și marcați care pas a produs diferența.

Dacă zona este corectă și aplicația tot eșuează, problema este în regulile zonei sau într-o clasificare bazată pe sursă, nu în apartenență. Documentația firewalld despre conexiuni și interfețe este referința pentru modul în care proprietatea ar trebui să funcționeze.

Scrieți proprietarul, valoarea și rezultatul așteptat în runbook, iar următoarea reatribuire va fi explicabilă.