Hold nftables-politikken stabil, mens VPN-interfacet kommer

Tunneler er engangs; politik bør ikke være det. På en Linux-gateway kan en nftables-regel, der matcher tunnelinterfacet på navn, indlæses én gang og blive ved med at gælde, hver gang det interface dukker op. Interfacet har stadig en livscyklus: det oprettes, det forsvinder, og ruterne og oversættelserne omkring det følger deres egen tidsplan. Det er adskillelsen af disse ejere, der holder adgangen stabil under en genopkobling.

Et navnematch lever længere end interfacet

nftables tilbyder numeriske interface-indeksmatch og de dynamiske navnematch iifname og oifname. Regler med disse navne indlæses rent, selv når tunneleenheden endnu ikke er oprettet, hvilket er præcis, hvad et regelsæt ved opstart har brug for. Det holder op med at matche, hvis interfacet omdøbes, og genoptages, når et nyt interface overtager navnet. Et numerisk indeks mangler den egenskab, og derfor er navneformen det sædvanlige valg til en tunnel.

Navnet er en matchningsnøgle, ikke bevis for, hvem der er i den anden ende. Godkendelse af peer forbliver VPN'ens opgave.

Læs kæden, før du tilføjer regler

Se på, hvad regelsættet indeholder nu, og hvor en ny regel ville sidde, fordi rækkefølgen afgør resultatet.

nft list ruleset
nft -c -f /etc/nftables.conf

Oplistningen viser kæder, regler og håndtag, og kontroltilstand validerer en kandidatfil uden at indlæse den. En tilladelse kun for tunnelen, der placeres efter en tidligere accept for det samme flow, ændrer intet, fordi den første matchende regel vinder. Derfor kan en sen regel se rigtig ud og have ingen effekt. Læs kæden i rækkefølge, og bekræft at afvisningen af trafik fra klient til uplink stadig kommer før noget bredere.

Ruter, oversættelse og flows har andre ejere

Interfaceets tilstedeværelse skaber ingen ruter og godkender ikke peeren. Det hører til VPN-manageren, mens oversættelsen har en tredje livscyklus.

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

conntrack-oplistningen viser eksisterende flows med deres oprindelige og oversatte værdier, og ruteoplistningen viser, hvad manageren installerede for interfacet. NAT-regler opretter forbindelsessporingstilstand på den første pakke, så et etableret flow beholder sin oversættelse, selv efter reglen ændres. Derfor er en regel, der opdateres, og et flow, der bruger den nye vej, forskellige udsagn. Beslut, hvilke sessioner der skal genopkobles, og lad uvedkommende flows være.

Accepter kold start, tab og genopretning

Test gatewayen med tunnelen fraværende ved opstart, derefter med den til stede, derefter efter et afbrud og en tilbagevenden. Bekræft, at viderebefordring, der er forbudt, forbliver afvist, mens tunnelen mangler, at et nyt tilladt flow virker, når peeren er godkendt, og at genopretning ikke kræver sletning af uvedkommende tilstand. Ryd ikke hele POSTROUTING-kæden eller hver conntrack-post som en profils stop-handling, fordi andre tjenester deler dem. Noter, hvilken komponent der ændrede interfacet, ruten og politikken, i stedet for kun at en startkrog returnerede nul.

En politik, der overlever en genopkobling, er en, hvis ejere er navngivet, og hvis regler blev testet med tunnelen både nede og oppe. En krog, der rapporterer succes, beviser kun, at krogen kørte.