Per què la vostra interfície VPN no para de sortir de la seva zona de firewalld

Afegiu tun0 a la zona correcta, l’aplicació comença a funcionar i la correcció s’esfuma a la següent reconnexió. Tornar a executar la mateixa ordre funciona, cosa que fa semblar que firewalld s’ha oblidat. No s’ha oblidat; alguna cosa amb un dret més fort sobre aquesta interfície l’ha reassignada.

La zona aguanta fins que la interfície es torna a crear

L’assignació d’una zona de firewalld a una interfície és una vinculació, i les vinculacions van lligades a l’objecte d’interfície tal com existeix ara. Un client VPN que destrueix el dispositiu i el torna a crear produeix un objecte nou, i el nou comença pel que diu el component que assigna. Per això el símptoma es repeteix a cada reconnexió i no a cada paquet.

La mateixa lògica explica el comportament en reiniciar: les vinculacions d’execució no sobreviuen a un reinici, i les vinculacions permanents només s’apliquen als dispositius que firewalld creu que posseeix.

Abans de canviar res, esbrineu quin component assigna la zona.

Llegiu tres coses abans de canviar res

Anoteu la zona que té ara la interfície, les zones actives amb les seves interfícies i la llista permanent d’interfícies de la zona que voleu. Executeu aquestes consultes abans del canvi, després d’una reconnexió i després d’un reinici. Comparar els tres resultats us diu si la vinculació es substitueix, s’ignora o només s’aplica tard. Si la llista permanent ja anomena el dispositiu mentre la zona d’execució no hi coincideix, alguna cosa està passant per sobre de la vostra edició.

Anoteu també el nom real del dispositiu a cada pas, perquè un túnel que avui cau a tun0 demà pot caure a tun1.

Una vinculació desada a un nom genèric no és una comprovació d’identitat, i dos minuts d’anotacions estalvien una hora d’endevinalles.

Quan NetworkManager és l’amo de la connexió

Si NetworkManager gestiona la connexió VPN, el seu perfil porta la zona i la passa a firewalld quan la connexió s’activa. Llavors es pot ignorar una vinculació permanent d’interfície de firewalld per al mateix dispositiu, perquè NetworkManager és l’amo. Definiu la zona a la connexió, i confirmeu que editeu el perfil VPN i no una connexió física no relacionada o un registre temporal.

Canviar aquesta propietat pot afectar immediatament una connexió activa.

Mantingueu un camí de gestió disponible i llegiu la política de la zona de destinació abans d’aplicar-la. Editar el camp ZONE d’un fitxer ifcfg només és correcte allà on aquest fitxer encara és la font de configuració.

Quan firewalld és l’amo de la vinculació

Per a un túnel autònom amb un nom d’interfície deliberadament estable, un canvi permanent d’interfície és l’eina adequada. Apliqueu-lo mitjançant la recàrrega o el cicle de vida que fa servir el vostre desplegament, i després inspeccioneu l’estat d’execució, perquè una edició només permanent descriu la intenció i no el que és actiu. Les dues coses poden discrepar tant com trigui una recàrrega.

Si el nom d’interfície és dinàmic, manteniu l’assignació durant el cicle de vida de la connexió en lloc de competir amb el túnel que reclami el nom primer.

No llanceu la interfície a trusted només perquè l’aplicació funcioni.

Proveu la recàrrega, la reconnexió i el reinici

Un canvi només està acabat quan sobreviu a les tres proves.

Primer recarregueu, perquè és on desapareixen les edicions només d’execució. Després torneu a connectar el túnel, perquè és on una interfície substituïda perd la seva vinculació. Després reinicieu, perquè és on finalment es manifesta un desajust d’amo. Anoteu la zona a cada etapa i compareu-la amb la intenció que vau escriure, i indiqueu quina etapa va produir la diferència.

Si la zona és correcta i l’aplicació encara falla, el problema és a les regles de la zona o en una classificació per origen, no en la pertinença. La documentació de firewalld sobre connexions i interfícies és la referència de com ha de funcionar la propietat.

Escriviu l’amo, el valor i el resultat esperat al runbook, i la propera reassignació serà explicable.