Perché la vostra interfaccia VPN continua a lasciare la sua zona firewalld

Aggiungete tun0 alla zona giusta, l’applicazione inizia a funzionare e la correzione evapora alla riconnessione successiva. Eseguire di nuovo lo stesso comando funziona, il che fa sembrare che firewalld abbia dimenticato. Non ha dimenticato; qualcosa con un diritto più forte su quell’interfaccia l’ha riassegnata.

La zona sopravvive finché l’interfaccia non viene ricreata

L’assegnazione di una zona firewalld a un’interfaccia è un binding, e i binding sono legati all’oggetto interfaccia così come esiste ora. Un client VPN che distrugge il dispositivo e lo ricrea produce un nuovo oggetto, e quello nuovo parte da ciò che dice il componente che assegna. Per questo il sintomo si ripete a ogni riconnessione e non a ogni pacchetto.

La stessa logica spiega il comportamento al riavvio: i binding di runtime non sopravvivono a un riavvio, e i binding permanenti valgono solo per i dispositivi che firewalld ritiene suoi.

Prima di cambiare qualcosa, scoprite quale componente assegna la zona.

Leggete tre cose prima di cambiare qualcosa

Annotate la zona che l’interfaccia ha ora, le zone attive con le loro interfacce e l’elenco permanente di interfacce della zona che intendete. Eseguite quelle interrogazioni prima della modifica, dopo una riconnessione e dopo un riavvio. Confrontare i tre risultati vi dice se il binding viene sostituito, ignorato o solo applicato in ritardo. Se l’elenco permanente nomina già il dispositivo mentre la zona di runtime non è d’accordo, qualcosa sta scavalcando la vostra modifica.

Annotate anche il nome reale del dispositivo a ogni passo, perché un tunnel che oggi atterra su tun0 domani può atterrare su tun1.

Un binding salvato su un nome generico non è un controllo d’identità, e due minuti di annotazioni risparmiano un’ora di congetture.

Quando NetworkManager possiede la connessione

Se NetworkManager gestisce la connessione VPN, il suo profilo porta la zona e la passa a firewalld quando la connessione si attiva. Un binding permanente di interfaccia in firewalld per lo stesso dispositivo può quindi essere ignorato, perché il proprietario è NetworkManager. Impostate la zona sulla connessione, e confermate che state modificando il profilo VPN e non una connessione fisica non correlata o un record temporaneo.

Modificare quella proprietà può influire immediatamente su una connessione attiva.

Tenete disponibile un percorso di gestione e leggete la politica della zona di destinazione prima di applicarla. Modificare il campo ZONE di un file ifcfg è corretto solo dove quel file è ancora la fonte di configurazione.

Quando firewalld possiede il binding

Per un tunnel autonomo con un nome di interfaccia volutamente stabile, una modifica permanente dell’interfaccia è lo strumento giusto. Applicatela tramite il ricaricamento o il ciclo di vita usato dal vostro deployment, poi ispezionate lo stato di runtime, perché una modifica solo permanente descrive l’intenzione e non ciò che è attivo. I due possono divergere per tutto il tempo che richiede un ricaricamento.

Se il nome dell’interfaccia è dinamico, mantenete l’assegnazione lungo il ciclo di vita della connessione invece di gareggiare con il tunnel che rivendica il nome per primo.

Non buttate l’interfaccia in trusted solo per far funzionare l’applicazione.

Provate il ricaricamento, la riconnessione e il riavvio

Una modifica è finita solo quando sopravvive a tutte e tre.

Ricaricate prima, perché è lì che spariscono le modifiche solo di runtime. Poi ricollegate il tunnel, perché è lì che un’interfaccia sostituita perde il suo binding. Poi riavviate, perché è lì che un disallineamento di proprietario emerge finalmente. Annotate la zona a ogni fase e confrontatela con l’intenzione che avete scritto, e indicate quale passo ha prodotto la differenza.

Se la zona è corretta e l’applicazione fallisce ancora, il problema sono le regole della zona o una classificazione basata sulla sorgente, non l’appartenenza. La documentazione firewalld su connessioni e interfacce è il riferimento per come dovrebbe funzionare la proprietà.

Scrivete il proprietario, il valore e il risultato atteso nel runbook, e la prossima riassegnazione sarà spiegabile.