Hvorfor VPN-grensesnittet ditt stadig forlater firewalld-sonen sin

Du legger tun0 til riktig sone, applikasjonen begynner å virke, og rettelsen fordamper ved neste gjenoppkobling. Å kjøre samme kommando på nytt virker, noe som får det til å se ut som firewalld har glemt det. Den har ikke glemt det; noe med et sterkere krav på grensesnittet tildelte det på nytt.

Sonen holder til grensesnittet gjenskapes

En firewalld-sonetildeling til et grensesnitt er en binding, og bindinger er knyttet til grensesnittobjektet slik det finnes nå. En VPN-klient som river ned enheten og gjenskaper den, produserer et nytt objekt, og det nye starter med det den tildelende komponenten sier. Derfor gjentar symptomet seg ved hver gjenoppkobling og ikke ved hver pakke.

Den samme logikken forklarer oppførselen ved omstart: kjøretidsbindinger overlever ikke en omstart, og permanente bindinger gjelder bare for enheter som firewalld mener å eie.

Før du endrer noe, finn ut hvilken komponent som tildeler sonen.

Les tre ting før du endrer noe

Noter sonen grensesnittet har nå, de aktive sonene med grensesnittene sine, og den permanente grensesnittlisten for sonen du har tenkt på. Kjør disse spørringene før endringen, etter en gjenoppkobling og etter en omstart. Å sammenligne de tre resultatene forteller deg om bindingen blir erstattet, ignorert eller bare brukt sent. Hvis den permanente listen allerede nevner enheten mens kjøretidssonen er uenig, er det noe som overstyrer endringen din.

Noter også det faktiske enhetsnavnet ved hvert trinn, fordi en tunnel som lander på tun0 i dag kan lande på tun1 i morgen.

En lagret binding til et generisk navn er ikke en identitetskontroll, og to minutters notater sparer en times gjetting.

Når NetworkManager eier tilkoblingen

Hvis NetworkManager administrerer VPN-tilkoblingen, bærer profilen sonen og sender den videre til firewalld når tilkoblingen aktiveres. En permanent firewalld-grensesnittbinding for samme enhet kan da bli ignorert, fordi NetworkManager er eieren. Sett sonen på tilkoblingen, og bekreft at du redigerer VPN-profilen og ikke en urelatert fysisk tilkobling eller en midlertidig oppføring.

Å endre denne egenskapen kan påvirke en aktiv tilkobling umiddelbart.

Hold en administrasjonsvei tilgjengelig og les policyen for målsonen før du bruker den. Å redigere ZONE-feltet i en ifcfg-fil er bare riktig der filen fortsatt er konfigurasjonskilden.

Når firewalld eier bindingen

For en frittstående tunnel med et bevisst stabilt grensesnittnavn er en permanent grensesnittendring det riktige verktøyet. Bruk den gjennom omlastingen eller livssyklusen distribusjonen din bruker, og undersøk deretter kjøretidstilstanden, fordi en bare-permanent endring beskriver intensjonen og ikke det som er aktivt. De to kan være uenige så lenge omlastingen varer.

Hvis grensesnittnavnet er dynamisk, vedlikehold tildelingen gjennom tilkoblingens livssyklus i stedet for å kappes med hvilken tunnel som krever navnet først.

Ikke slipp grensesnittet inn i trusted bare for å få applikasjonen til å virke.

Test omlastingen, gjenoppkoblingen og omstarten

En endring er først ferdig når den overlever alle tre.

Last om først, fordi det er der endringer bare i kjøretid forsvinner. Koble deretter tunnelen til på nytt, fordi det er der et erstattet grensesnitt mister bindingen sin. Start deretter på nytt, fordi det er der en eierkonflikt endelig viser seg. Noter sonen ved hvert trinn og sammenlign den med intensjonen du skrev ned, og noter hvilket trinn som skapte forskjellen.

Hvis sonen er riktig og applikasjonen fortsatt feiler, er problemet sonens regler eller en kildebasert klassifisering, ikke medlemskapet. firewalld-dokumentasjonen om tilkoblinger og grensesnitt er referansen for hvordan eierskap er ment å fungere.

Skriv eieren, verdien og forventet resultat i runbooken, og neste tildeling vil være forklarbar.