Varför ditt VPN-gränssnitt ständigt lämnar sin firewalld-zon

Du lägger till tun0 i rätt zon, programmet börjar fungera, och rättelsen avdunstar vid nästa återanslutning. Att köra samma kommando igen fungerar, vilket får det att se ut som om firewalld har glömt. Den har inte glömt; något med ett starkare anspråk på gränssnittet tilldelade det på nytt.

Zonen håller tills gränssnittet skapas på nytt

En firewalld-zontilldelning till ett gränssnitt är en bindning, och bindningar är knutna till gränssnittsobjektet sådant det finns nu. En VPN-klient som river ner enheten och skapar den på nytt producerar ett nytt objekt, och det nya börjar med vad den tilldelande komponenten säger. Därför upprepas symtomet vid varje återanslutning och inte vid varje paket.

Samma logik förklarar beteendet vid omstart: runtime-bindningar överlever inte en omstart, och permanenta bindningar gäller bara enheter som firewalld anser sig äga.

Innan du ändrar något, ta reda på vilken komponent som tilldelar zonen.

Läs tre saker innan du ändrar något

Notera zonen gränssnittet har nu, de aktiva zonerna med sina gränssnitt, och den permanenta gränssnittslistan för zonen du avser. Kör de frågorna före ändringen, efter en återanslutning och efter en omstart. Att jämföra de tre resultaten säger om bindningen ersätts, ignoreras eller bara tillämpas sent. Om den permanenta listan redan namnger enheten medan runtime-zonen inte håller med, är det något som åsidosätter din ändring.

Notera också det faktiska enhetsnamnet vid varje steg, eftersom en tunnel som landar på tun0 i dag kan landa på tun1 i morgon.

En sparad bindning till ett generiskt namn är inte en identitetskontroll, och två minuters anteckningar sparar en timmes gissande.

När NetworkManager äger anslutningen

Om NetworkManager hanterar VPN-anslutningen bär dess profil zonen och skickar den vidare till firewalld när anslutningen aktiveras. En permanent firewalld-gränssnittsbindning för samma enhet kan då ignoreras, eftersom NetworkManager är ägaren. Sätt zonen på anslutningen, och bekräfta att du redigerar VPN-profilen och inte en orelaterad fysisk anslutning eller en tillfällig post.

Att ändra den egenskapen kan påverka en aktiv anslutning omedelbart.

Håll en administrationsväg tillgänglig och läs policyn för målzonen innan du tillämpar den. Att redigera ZONE-fältet i en ifcfg-fil är bara korrekt där filen fortfarande är konfigurationskällan.

När firewalld äger bindningen

För en fristående tunnel med ett medvetet stabilt gränssnittsnamn är en permanent gränssnittsändring rätt verktyg. Tillämpa den via omladdningen eller livscykeln som din distribution använder, och inspektera sedan runtime-tillståndet, eftersom en bara-permanent ändring beskriver avsikten och inte det som är aktivt. De två kan vara oeniga så länge omladdningen varar.

Om gränssnittsnamnet är dynamiskt, underhåll tilldelningen genom anslutningens livscykel i stället för att tävla med vilken tunnel som begär namnet först.

Kasta inte in gränssnittet i trusted bara för att få programmet att fungera.

Testa omladdningen, återanslutningen och omstarten

En ändring är först klar när den överlever alla tre.

Ladda om först, eftersom det är där ändringar bara i runtime försvinner. Anslut sedan tunneln på nytt, eftersom det är där ett ersatt gränssnitt förlorar sin bindning. Starta sedan om, eftersom det är där en ägaravvikelse äntligen visar sig. Notera zonen i varje steg och jämför den med avsikten du skrev ner, och anteckna vilket steg som skapade skillnaden.

Om zonen är korrekt och programmet fortfarande misslyckas, ligger problemet i zonens regler eller i en källbaserad klassificering, inte i medlemskapet. firewalld-dokumentationen om anslutningar och gränssnitt är referensen för hur ägande är tänkt att fungera.

Skriv ägaren, värdet och det förväntade resultatet i runbooken, och nästa tilldelning kommer att vara förklarlig.