Hvorfor din VPN-grænseflade hele tiden forlader sin firewalld-zone

Du føjer tun0 til den rigtige zone, programmet begynder at virke, og rettelsen fordamper ved næste genopkobling. At køre den samme kommando igen virker, hvilket får det til at se ud, som om firewalld har glemt det. Det har ikke glemt det; noget med et stærkere krav på den grænseflade tildelte den igen.

Zonen holder, indtil grænsefladen genskabes

En firewalld-zonetildeling til en grænseflade er en binding, og bindinger er knyttet til grænsefladeobjektet, som det ser ud nu. En VPN-klient, der river enheden ned og genskaber den, producerer et nyt objekt, og det nye starter med det, den tildelende komponent siger. Derfor gentager symptomet sig ved hver genopkobling og ikke ved hver pakke.

Den samme logik forklarer adfærden ved genstart: runtime-bindinger overlever ikke en genstart, og permanente bindinger gælder kun for enheder, som firewalld mener at eje.

Før du ændrer noget, skal du finde ud af, hvilken komponent der tildeler zonen.

Læs tre ting, før du ændrer noget

Notér den zone, grænsefladen har nu, de aktive zoner med deres grænseflader og den permanente grænsefladeliste for den zone, du sigter mod. Kør de forespørgsler før ændringen, efter en genopkobling og efter en genstart. At sammenligne de tre resultater fortæller dig, om bindingen bliver erstattet, ignoreret eller blot anvendt sent. Hvis den permanente liste allerede nævner enheden, mens runtime-zonen er uenig, er der noget, der overtrumfer din redigering.

Notér også det faktiske enhedsnavn ved hvert trin, fordi en tunnel, der lander på tun0 i dag, kan lande på tun1 i morgen.

En gemt binding til et generisk navn er ikke en identitetskontrol, og to minutters notering sparer en times gætteri.

Når NetworkManager ejer forbindelsen

Hvis NetworkManager styrer VPN-forbindelsen, bærer dens profil zonen og giver den videre til firewalld, når forbindelsen aktiveres. En permanent firewalld-grænsefladebinding til den samme enhed kan så blive ignoreret, fordi NetworkManager er ejeren. Sæt zonen på forbindelsen, og bekræft, at du redigerer VPN-profilen og ikke en urelateret fysisk forbindelse eller en midlertidig post.

Ændring af den egenskab kan påvirke en aktiv forbindelse med det samme.

Hold en administrationsvej tilgængelig, og læs målzonens politik, før du anvender den. Redigering af ZONE-feltet i en ifcfg-fil er kun korrekt der, hvor den fil stadig er konfigurationskilden.

Når firewalld ejer bindingen

For en enkeltstående tunnel med et bevidst stabilt grænsefladenavn er en permanent grænsefladeændring det rigtige værktøj. Anvend den gennem den genindlæsning eller livscyklus, din udrulning bruger, og undersøg derefter runtime-tilstanden, fordi en kun-permanent redigering beskriver hensigten snarere end det, der er aktivt. De to kan være uenige så længe, det tager at genindlæse.

Hvis grænsefladenavnet er dynamisk, skal du vedligeholde tildelingen gennem forbindelsens livscyklus i stedet for at kapløbe med den tunnel, der først kræver navnet.

Læg ikke grænsefladen i trusted blot for at få programmet til at virke.

Test genindlæsningen, genopkoblingen og genstarten

En ændring er først færdig, når den overlever alle tre.

Genindlæs først, for det er der, redigeringer kun i runtime forsvinder. Genopkobl derefter tunnelen, for det er der, en erstattet grænseflade mister sin binding. Genstart derefter, for det er der, en uoverensstemmelse i ejerskab endelig viser sig. Notér zonen på hvert trin, og sammenlign den med den hensigt, du skrev ned, og notér, hvilket trin der skabte forskellen.

Hvis zonen er korrekt, og programmet stadig fejler, er problemet zonens regler eller en kildebaseret klassificering og ikke medlemskabet. firewalld-dokumentationen om forbindelser og grænseflader er referencen for, hvordan ejerskab er ment at skulle virke.

Skriv ejeren, værdien og det forventede resultat i runbooken, og den næste gentildeling vil være forklarlig.