Kvifor VPN-grensesnittet ditt stadig forlèt firewalld-sona si

Du legg tun0 til rett sone, applikasjonen byrjar å verke, og rettinga fordampar ved neste attoppkopling. Å køyre same kommando på nytt verkar, noko som får det til å sjå ut som firewalld har gløymt det. Ho har ikkje gløymt det; noko med eit sterkare krav på grensesnittet tildelte det på nytt.

Sona held til grensesnittet blir skapt på nytt

Ei firewalld-sonetildeling til eit grensesnitt er ei binding, og bindingar er knytte til grensesnittobjektet slik det finst no. Ein VPN-klient som riv ned eininga og skapar ho på nytt, produserer eit nytt objekt, og det nye byrjar med det den tildelande komponenten seier. Difor kjem symptomet att ved kvar attoppkopling og ikkje ved kvar pakke.

Den same logikken forklarar åtferda ved omstart: køyretidsbindingar overlever ikkje ein omstart, og permanente bindingar gjeld berre for einingar som firewalld meiner å eige.

Før du endrar noko, finn ut kva komponent som tildeler sona.

Les tre ting før du endrar noko

Noter sona grensesnittet har no, dei aktive sonene med grensesnitta sine, og den permanente grensesnittlista for sona du har tenkt på. Køyr desse spørjefrågårsmålene før endringa, etter ei attoppkopling og etter ein omstart. Å samanlikne dei tre resultata fortel deg om bindinga blir erstatta, ignorert eller berre brukt seint. Viss den permanente lista alt nemner eininga medan køyretidssona er usamd, er det noko som overstyrer endringa di.

Noter også det faktiske namnet på eininga ved kvart steg, fordi ein tunnel som landar på tun0 i dag kan lande på tun1 i morgon.

Ei lagra binding til eit generisk namn er ikkje ein identitetskontroll, og to minutt med notat sparer ein time med gissing.

Når NetworkManager eig tilkoplinga

Viss NetworkManager styrer VPN-tilkoplinga, ber profilen sona og sender ho vidare til firewalld når tilkoplinga blir aktivert. Ei permanent firewalld-grensesnittbinding for same eininga kan då bli ignorert, fordi NetworkManager er eigaren. Set sona på tilkoplinga, og stadfest at du redigerer VPN-profilen og ikkje ei urelatert fysisk tilkopling eller ei mellombels oppføring.

Å endre denne eigenskapen kan påverke ei aktiv tilkopling med det same.

Hald ein administrasjonsveg tilgjengeleg og les policyen for målsona før du brukar han. Å redigere ZONE-feltet i ei ifcfg-fil er berre rett der fila framleis er konfigurasjonskjelda.

Når firewalld eig bindinga

For ein frittståande tunnel med eit medvite stabilt grensesnittnamn er ei permanent grensesnittendring det rette verktøyet. Bruk ho gjennom omlastinga eller livssyklusen distribusjonen din brukar, og undersøk deretter køyretidstilstanden, fordi ei berre-permanent endring skildrar intensjonen og ikkje det som er aktivt. Dei to kan vere usamde så lenge omlastinga varer.

Viss grensesnittnamnet er dynamisk, vedlikehald tildelinga gjennom livssyklusen til tilkoplinga i staden for å kappast med kva tunnel som krev namnet først.

Ikkje slepp grensesnittet inn i trusted berre for å få applikasjonen til å verke.

Test omlastinga, attoppkoplinga og omstarten

Ei endring er først ferdig når ho overlever alle tre.

Last om først, fordi det er der endringar berre i køyretid forsvinn. Kopla deretter tunnelen til på nytt, fordi det er der eit erstatta grensesnitt mistar bindinga si. Start deretter på nytt, fordi det er der ein eigarkonflikt endeleg viser seg. Noter sona ved kvart steg og samanlikne ho med intensjonen du skreiv ned, og noter kva steg som skapte skilnaden.

Viss sona er rett og applikasjonen framleis feilar, er problemet reglane til sona eller ei kjeldebasert klassifisering, ikkje medlemskapen. firewalld-dokumentasjonen om tilkoplingar og grensesnitt er referansen for korleis eigarskap er meint å fungere.

Skriv eigaren, verdien og venta resultat i runbooken, og neste tildeling vil vere forklarleg.