Kial via VPN-interfaco daŭre forlasas sian firewalld-zonon

Vi aldonas tun0 al la ĝusta zono, la aplikaĵo ekfunkcias, kaj la riparo vaporiĝas ĉe la sekva rekonekto. Relanĉi la saman komandon funkcias, kio igas ĝin aspekti kvazaŭ firewalld forgesis. Ĝi ne forgesis; io kun pli forta pretendo al tiu interfaco realjuĝis ĝin.

La zono restas ĝis la interfaco estas rekreata

firewalld-zona atribuo por interfaco estas ligo, kaj ligoj estas ligitaj al la interfaca objekto tia, kia ĝi nun ekzistas. VPN-kliento, kiu malkonstruas la aparaton kaj rekreis ĝin, produktas novan objekton, kaj la nova komenciĝas de tio, kion diras la atribuanta komponanto. Tial la simptomo ripetiĝas ĉe ĉiu rekonekto kaj ne ĉe ĉiu pakaĵo.

La sama logiko klarigas la konduton ĉe restartigo: rultempaj ligoj ne postvivas restartigon, kaj permanentaj ligoj validas nur por aparatoj, kiujn firewalld kredas posedi.

Antaŭ ol ŝanĝi ion, eltrovu, kiu komponanto atribuas la zonon.

Legu tri aferojn antaŭ ol ŝanĝi ion

Notu la zonon, kiun la interfaco nun havas, la aktivajn zonojn kun iliaj interfacoj, kaj la permanentan interfacan liston por la zono, kiun vi celas. Rulu tiujn demandojn antaŭ la ŝanĝo, post rekonekto kaj post restartigo. Kompari la tri rezultojn diras al vi, ĉu la ligo estas anstataŭigata, ignorata aŭ nur malfrue aplikata. Se la permanenta listo jam nomas la aparaton dum la rultempa zono malkonsentas, io anstataŭas vian redakton.

Notu ankaŭ la faktan aparatonomon ĉe ĉiu paŝo, ĉar tunelo, kiu hodiaŭ surteriĝas sur tun0, povas morgaŭ surteriĝi sur tun1.

Konservita ligo al ĝenerala nomo ne estas identeca kontrolo, kaj du minutoj da notado ŝparas horon da divenado.

Kiam NetworkManager posedas la konekton

Se NetworkManager administras la VPN-konekton, ĝia profilo portas la zonon kaj transdonas ĝin al firewalld, kiam la konekto aktiviĝas. Permanenta firewalld-interfaca ligo por la sama aparato tiam povas esti ignorata, ĉar NetworkManager estas la posedanto. Agordu la zonon sur la konekto, kaj konfirmu, ke vi redaktas la VPN-profilo kaj ne rilatan fizikan konekton aŭ provizoran rikordon.

Ŝanĝi tiun proprecon povas tuj efiki al aktiva konekto.

Tenu administran vojon disponebla kaj legu la politikon de la cela zono antaŭ ol apliki ĝin. Redakti la kampon ZONE de ifcfg-dosiero estas ĝuste nur tie, kie tiu dosiero ankoraŭ estas la agorda fonto.

Kiam firewalld posedas la ligon

Por memstara tunelo kun intence stabila interfaca nomo, permanenta interfaca ŝanĝo estas la ĝusta ilo. Apliku ĝin tra la reŝarĝo aŭ vivciklo, kiun uzas via deplojo, poste inspektu la rultempan staton, ĉar nur-permanenta redakto priskribas intencon kaj ne tion, kio estas aktiva. La du povas malkonsenti tiom longe, kiom daŭras reŝarĝo.

Se la interfaca nomo estas dinamika, konservu la atribuon tra la vivciklo de la konekto anstataŭ konkurri kun tiu tunelo, kiu unue reklamas la nomon.

Ne ĵetu la interfacon en trusted nur por igi la aplikaĵon funkcii.

Testu la reŝarĝon, la rekonekton kaj la restartigon

Ŝanĝo estas finita nur kiam ĝi postvivas ĉiujn tri.

Unue reŝarĝu, ĉar tie malaperas redaktoj nur rultempaj. Poste rekonektu la tunelon, ĉar tie anstataŭigita interfaco perdas sian ligon. Poste restartigu, ĉar tie finfine montriĝas posedanta miskongruo. Notu la zonon ĉe ĉiu etapo kaj komparu ĝin kun la intenco, kiun vi skribis, kaj notu, kiu paŝo produktis la diferencon.

Se la zono estas ĝusta kaj la aplikaĵo tamen malsukcesas, la problemo estas la reguloj de la zono aŭ fontbazita klasifiko, ne la membreco. La firewalld-dokumentaro pri konektoj kaj interfacoj estas la referenco por tio, kiel posedado devus funkcii.

Skribu la posedanton, la valoron kaj la atendatan rezulton en la runbook, kaj la sekva realjuĝo estos klarigebla.