Waarom jou VPN-koppelvlak voortdurend sy firewalld-sone verlaat

Jy voeg tun0 by die regte sone, die toepassing begin werk, en die regstelling verdamp by die volgende herkoppeling. As jy dieselfde opdrag weer uitvoer, werk dit, wat dit laat lyk of firewalld dit vergeet het. Dit het nie vergeet nie; iets met 'n sterker aanspraak op daardie koppelvlak het dit hertoegewys.

Die sone bly staan tot die koppelvlak herskep word

'n firewalld-soneopdrag vir 'n koppelvlak is 'n binding, en bindings is gekoppel aan die koppelvlakobjek soos dit nou bestaan. 'n VPN-kliënt wat die toestel afbreek en weer skep, lewer 'n nuwe objek, en die nuwe een begin by wat die toewysende komponent sê. Dit is waarom die simptoom by elke herkoppeling herhaal en nie by elke pakkie nie.

Dieselfde logika verduidelik herbeginning: runtime-bindings oorleef nie 'n herbegin nie, en permanente bindings geld net vir toestelle wat firewalld glo hy besit.

Voordat jy enigiets verander, vind uit watter komponent die sone toewys.

Lees drie dinge voordat jy enigiets verander

Teken die sone aan wat die koppelvlak tans het, die aktiewe sones met hul koppelvlakke, en die permanente koppelvlaklys vir die sone wat jy beoog. Voer daardie navrae voor die verandering, na 'n herkoppeling en na 'n herbegin uit. Om die drie resultate te vergelyk, sê vir jou of die binding vervang, geïgnoreer of net laat toegepas word. As die permanente lys die toestel al noem terwyl die runtime-sone verskil, is iets besig om jou wysiging te oorheers.

Teken ook die werklike toestelnaam by elke stap aan, want 'n tonnel wat vandag op tun0 land, kan môre op tun1 land.

'n Gestoor binding aan 'n generiese naam is nie 'n identiteitstoets nie, en twee minute se aantekeninge spaar 'n uur se raai.

Wanneer NetworkManager die verbinding besit

As NetworkManager die VPN-verbinding bestuur, dra sy profiel die sone en gee dit aan firewalld wanneer die verbinding aktiveer. 'n Permanente firewalld-koppelvlakbinding vir dieselfde toestel kan dan geïgnoreer word, want NetworkManager is die eienaar. Stel die sone op die verbinding, en bevestig dat jy die VPN-profiel wysig eerder as 'n onverwante fisiese verbinding of 'n tydelike rekord.

Om daardie eienskap te verander, kan 'n aktiewe verbinding onmiddellik raak.

Hou 'n bestuurspad beskikbaar en lees die bestemmingsone se beleid voordat jy dit toepas. Om 'n ifcfg-lêer se ZONE-veld te wysig, is net korrek waar daardie lêer steeds die konfigurasiebron is.

Wanneer firewalld die binding besit

Vir 'n alleenstaande tonnel met 'n doelbewus stabiele koppelvlaknaam is 'n permanente koppelvlakverandering die regte instrument. Pas dit toe deur die herlaai of lewensiklus wat jou ontplooiing gebruik, en ondersoek dan die runtime-toestand, want 'n slegs-permanente wysiging beskryf bedoeling eerder as wat aktief is. Die twee kan verskil vir so lank as wat dit neem om te herlaai.

As die koppelvlaknaam dinamies is, onderhou die toewysing deur die verbindingslewensiklus eerder as om te jaag teen watter tonnel die naam eerste opeis.

Moenie die koppelvlak in trusted gooi net om die toepassing te laat werk nie.

Toets die herlaai, die herkoppeling en die herbegin

'n Verandering is eers klaar wanneer dit al drie oorleef.

Herlaai eerste, want daar verdwyn wysigings wat net in runtime bestaan. Koppel dan die tonnel weer, want daar verloor 'n vervangde koppelvlak sy binding. Herbegin dan, want daar duik 'n eienaarmismatch uiteindelik op. Teken die sone by elke stadium aan en vergelyk dit met die bedoeling wat jy neergeskryf het, en let op watter stap die verskil veroorsaak het.

As die sone korrek is en die toepassing steeds misluk, is die probleem die sone se reëls of 'n brongebaseerde klassifikasie eerder as die lidmaatskap. Die firewalld-dokumentasie oor verbindings en koppelvlakke is die verwysing vir hoe eienaarskap bedoel is om te werk.

Skryf die eienaar, die waarde en die verwagte resultaat in die runbook, en die volgende hertoewysing sal verklaarbaar wees.