Miks teie VPN-liides lahkub pidevalt oma firewalld-tsoonist

Lisate tun0 õigesse tsooni, rakendus hakkab tööle ja parandus aurustub järgmisel taasühendamisel. Sama käsu uuesti käivitamine töötab, mis jätab mulje, nagu oleks firewalld unustanud. Ta ei ole unustanud; miski, millel on tugevam nõue sellele liidesele, määras selle uuesti.

Tsoon püsib, kuni liides luuakse uuesti

firewalld-tsooni määramine liidesele on sidumine ja sidumised on seotud liidese objektiga sellisena, nagu see praegu eksisteerib. VPN-klient, mis seadme lammutab ja uuesti loob, tekitab uue objekti, ja uus algab sellest, mida ütleb määrav komponent. Seetõttu kordub sümptom igal taasühendamisel, mitte iga paketi juures.

Sama loogika selgitab käitumist taaskäivitamisel: tööajalised sidumised ei ela taaskäivitamist üle ja püsivad sidumised kehtivad ainult seadmetele, mida firewalld peab enda omaks.

Enne millegi muutmist tehke kindlaks, milline komponent tsooni määrab.

Lugege kolme asja enne millegi muutmist

Kirjutage üles tsoon, mis liidesel praegu on, aktiivsed tsoonid koos nende liidestega ja püsiv liideste loend tsooni jaoks, mida kavatsete. Käivitage need päringud enne muudatust, pärast taasühendamist ja pärast taaskäivitamist. Kolme tulemuse võrdlemine ütleb teile, kas sidumine asendatakse, jäetakse tähelepanuta või rakendatakse lihtsalt hilja. Kui püsiv loend juba nimetab seadet, samal ajal kui tööaja tsoon on vastuolus, kirjutab miski teie muudatuse üle.

Kirjutage igal etapil üles ka tegelik seadme nimi, sest tunnel, mis täna maandub tun0-le, võib homme maanduda tun1-le.

Üldnimele salvestatud sidumine ei ole identiteedikontroll ja kaks minutit üleskirjutamist säästab tunni oletusi.

Kui ühendust omab NetworkManager

Kui NetworkManager haldab VPN-ühendust, kannab selle profiil tsooni ja annab selle firewalldile üle, kui ühendus aktiveerub. Püsiv firewalld-liidese sidumine sama seadme jaoks võidakse siis tähelepanuta jätta, sest omanik on NetworkManager. Määrake tsoon ühendusele ja kinnitage, et muudate VPN-profiili, mitte seostamatut füüsilist ühendust või ajutist kirjet.

Selle omaduse muutmine võib mõjutada aktiivset ühendust kohe.

Hoidke haldustee saadaval ja lugege sihttsooni poliitikat enne selle rakendamist. ifcfg-faili ZONE-välja muutmine on õige ainult seal, kus see fail on endiselt konfiguratsiooni allikas.

Kui sidumist omab firewalld

Eraldiseisva tunneli jaoks, mille liidese nimi on teadlikult püsiv, on püsiv liidese muudatus õige tööriist. Rakendage seda läbi uuestilaadimise või elutsükli, mida teie juurutus kasutab, seejärel kontrollige tööaja olekut, sest ainult püsiv muudatus kirjeldab kavatsust, mitte seda, mis on aktiivne. Need kaks võivad erineda nii kaua, kui uuestilaadimine aega võtab.

Kui liidese nimi on dünaamiline, hoidke määramine ühenduse elutsükli jooksul, selle asemel et võistelda tunneliga, mis nime esimesena nõuab.

Ärge visake liidest trusted-tsooni ainult selleks, et rakendus tööle hakkaks.

Testige uuestilaadimist, taasühendamist ja taaskäivitamist

Muudatus on valmis alles siis, kui see elab üle kõik kolm.

Laadige esmalt uuesti, sest seal kaovad ainult tööaja muudatused. Seejärel ühendage tunnel uuesti, sest seal kaotab asendatud liides oma sidumise. Seejärel taaskäivitage, sest seal ilmneb lõpuks omaniku lahknevus. Kirjutage tsoon igas etapis üles ja võrrelge seda kavatsusega, mille kirja panite, ja märkige, milline samm erinevuse tekitas.

Kui tsoon on õige ja rakendus siiski ebaõnnestub, on probleem tsooni reeglites või allikapõhises klassifikatsioonis, mitte liikmelisuses. firewalld dokumentatsioon ühenduste ja liideste kohta on viide sellele, kuidas omand peaks toimima.

Kirjutage omanik, väärtus ja oodatav tulemus runbooki, ja järgmine ümbermääramine on seletatav.