Păstrați stabilă politica nftables cât timp apare interfața VPN
Regulile nftables bazate pe nume supraviețuiesc unui tunel care apare și dispare, dar rutele și fluxurile existente nu urmează automat. Separați proprietarii.
Tunelurile sunt de unică folosință; politica nu ar trebui să fie. Pe un gateway Linux, o regulă nftables care potrivește interfața tunelului după nume poate fi încărcată o dată și continuă să se aplice de fiecare dată când acea interfață apare. Interfața are totuși un ciclu de viață: este creată, dispare, iar rutele și traducerile din jurul ei urmează propriul calendar. Tocmai separarea acestor proprietari menține accesul stabil în timpul unei reconectări.
O potrivire după nume supraviețuiește interfeței
nftables oferă potriviri numerice după indicele interfeței și potrivirile dinamice după nume iifname și oifname. Regulile care folosesc aceste nume se încarcă curat chiar și când dispozitivul tunelului nu a fost încă creat, ceea ce este exact ce are nevoie un set de reguli la pornire. Potrivirea încetează dacă interfața este redenumită și reîncepe când o interfață nouă preia acel nume. Un indice numeric nu are această proprietate, de aceea forma cu nume este alegerea obișnuită pentru un tunel.
Numele este o cheie de potrivire, nu o dovadă despre cine se află la celălalt capăt. Autentificarea partenerului rămâne sarcina VPN-ului.
Citiți lanțul înainte de a adăuga reguli
Uitați-vă ce conține acum setul de reguli și unde s-ar așeza o regulă nouă, pentru că ordinea decide rezultatul.
nft list ruleset
nft -c -f /etc/nftables.confListarea arată lanțuri, reguli și mânere, iar modul de verificare validează un fișier candidat fără a-l încărca. O permisiune doar pentru tunel plasată după o acceptare anterioară pentru același flux nu schimbă nimic, pentru că câștigă prima regulă care se potrivește. De aceea o regulă târzie poate părea corectă și nu poate avea niciun efect. Citiți lanțul în ordine și confirmați că interdicția pentru traficul de la client către legătura superioară precedă în continuare orice lucru mai larg.
Rutele, traducerea și fluxurile au alți proprietari
Prezența interfeței nu creează rute și nu autentifică partenerul. Acestea aparțin managerului VPN, în timp ce traducerea are un al treilea ciclu de viață.
conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0Listarea conntrack arată fluxurile existente cu valorile lor originale și traduse, iar listarea rutelor arată ce a instalat managerul pentru interfață. Regulile NAT stabilesc starea de urmărire a conexiunii la primul pachet, așa că un flux stabilit își păstrează traducerea chiar și după ce regula se schimbă. De aceea o regulă actualizată și un flux care folosește noua cale sunt două afirmații diferite. Decideți ce sesiuni trebuie să se reconecteze și lăsați în pace fluxurile nelegate.
Acceptați pornirea la rece, pierderea și recuperarea
Testați gateway-ul cu tunelul absent la pornire, apoi prezent, apoi după o cădere și o revenire. Confirmați că redirecționarea interzisă rămâne refuzată cât timp lipsește tunelul, că un flux nou permis funcționează după autentificarea partenerului și că recuperarea nu cere ștergerea stării nelegate. Nu ștergeți tot lanțul POSTROUTING sau fiecare intrare conntrack ca acțiune de oprire a unui profil, pentru că alte servicii le împart. Notați ce componentă a schimbat interfața, ruta și politica, în loc de doar că un hook de pornire s-a încheiat cu zero.
O politică ce supraviețuiește unei reconectări este aceea ai cărei proprietari sunt numiți și ale cărei reguli au fost testate cu tunelul atât coborât, cât și ridicat. Un hook care raportează succes dovedește doar că hook-ul a rulat.