Hold nftables-policyen stabil mens VPN-grensesnittet kommer

Tunneler er engangs; policy bør ikke være det. På en Linux-gateway kan en nftables-regel som matcher tunnelgrensesnittet på navn, lastes én gang og fortsette å gjelde hver gang grensesnittet dukker opp. Grensesnittet har fortsatt en livssyklus: det opprettes, det forsvinner, og rutene og oversettelsene rundt det følger sin egen tidsplan. Det er å skille disse eierne som holder tilgangen stabil under en gjenoppkobling.

Et navnematch lever lenger enn grensesnittet

nftables tilbyr numeriske grensesnittindeksmatch og de dynamiske navnematchiene iifname og oifname. Regler som bruker disse navnene, lastes rent selv når tunnelenheten ennå ikke er opprettet, som er nøyaktig det et regelsett ved oppstart trenger. Det slutter å matche hvis grensesnittet får nytt navn og gjenopptas når et nytt grensesnitt tar navnet. En numerisk indeks mangler denne egenskapen, derfor er navneformen det vanlige valget for en tunnel.

Navnet er en matchningsnøkkel, ikke bevis for hvem som er i den andre enden. Autentisering av peer er fortsatt VPN sin oppgave.

Les kjeden før du legger til regler

Se på hva regelsettet inneholder nå og hvor en ny regel ville stå, fordi rekkefølgen avgjør resultatet.

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

Oppføringen viser kjeder, regler og håndtak, og kontrollmodus validerer en kandidatfil uten å laste den. En tillatelse kun for tunnelen som settes etter en tidligere godkjenning for samme flyt, endrer ingenting, fordi den første matchende regelen vinner. Derfor kan en sen regel se riktig ut og ikke ha noen virkning. Les kjeden i rekkefølge og bekreft at forbudet mot trafikk fra klient til oppstrømslenken fortsatt kommer før noe bredere.

Ruter, oversettelse og flyter har andre eiere

Tilstedeværelsen av grensesnittet skaper ingen ruter og autentiserer ikke peeren. Det hører til VPN-behandleren, mens oversettelsen har en tredje livssyklus.

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

conntrack-oppføringen viser eksisterende flyter med deres opprinnelige og oversatte verdier, og ruteoppføringen viser hva behandleren installerte for grensesnittet. NAT-regler etablerer tilstand for tilkoblingssporing på den første pakken, så en etablert flyt beholder oversettelsen sin også etter at regelen endres. Derfor er en regel som oppdateres og en flyt som bruker den nye veien to forskjellige utsagn. Bestem hvilke økter som må kobles til på nytt, og la uvedkommende flyter være.

Aksepter kaldstart, tap og gjenoppretting

Test gatewayen med tunnelen fraværende ved oppstart, deretter til stede, og deretter etter et brudd og en retur. Bekreft at forbudt videresending forblir nektet mens tunnelen mangler, at en ny tillatt flyt virker når peeren er autentisert, og at gjenoppretting ikke krever tømming av uvedkommende tilstand. Ikke tøm hele POSTROUTING-kjeden eller hver conntrack-oppføring som en profils stopphandling, fordi andre tjenester deler dem. Noter hvilken komponent som endret grensesnittet, ruten og policyen, i stedet for bare at en startkrok avsluttet med null.

En policy som overlever en gjenoppkobling, er en der eierne er navngitt og reglene er testet med tunnelen både nede og oppe. En krok som rapporterer suksess, beviser bare at kroken kjørte.