Hald nftables-politikken stabil medan VPN-grensesnittet kjem

Tunnelar er eingongs; politikk bør ikkje vere det. På ein Linux-gateway kan ein nftables-regel som matchar tunnelgrensesnittet på namn lastast éin gong og halde fram med å gjelde kvar gong grensesnittet dukkar opp. Grensesnittet har framleis ein livssyklus: det vert oppretta, det forsvinn, og rutene og omsetjingane rundt det følgjer sin eigen tidsplan. Det er å skilje desse eigarane som held tilgangen stabil under ei gjenoppkopling.

Eit namnematch lever lenger enn grensesnittet

nftables tilbyr numeriske grensesnittindeksmatch og dei dynamiske namnematcha iifname og oifname. Reglar som brukar desse namna, vert lasta reint sjølv når tunnelenininga enno ikkje er oppretta, som er nøyaktig det eit regelsett ved oppstart treng. Det sluttar å matche om grensesnittet får nytt namn og tek til att når eit nytt grensesnitt tek namnet. Ein numerisk indeks manglar denne eigenskapen, difor er namneforma det vanlege valet for ein tunnel.

Namnet er ein matchningsnøkkel, ikkje prov for kven som er i den andre enden. Autentisering av peer er framleis oppgåva til VPN.

Les kjeda før du legg til reglar

Sjå på kva regelsettet inneheld no og kvar ein ny regel ville stå, fordi rekkjefølgja avgjer resultatet.

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

Oppføringa viser kjeder, reglar og handtak, og kontrollmodus validerer ei kandidatfil utan å laste henne. Ei løyve berre for tunnelen som vert sett etter ei tidlegare godkjenning for same straum, endrar ingenting, fordi den første matchende regelen vinn. Difor kan ein sein regel sjå rett ut og ikkje ha nokon verknad. Les kjeda i rekkjefølgje og stadfest at forbodet mot trafikk frå klient til oppstraumslenkja framleis kjem før noko breiare.

Ruter, omsetjing og straumar har andre eigarar

Tilstadevera av grensesnittet skaper ingen ruter og autentiserer ikkje peeren. Det høyrer til VPN-handsamaren, medan omsetjinga har ein tredje livssyklus.

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

conntrack-oppføringa viser eksisterande straumar med dei opphavlege og omsette verdiane sine, og ruteoppføringa viser kva handsamaren installerte for grensesnittet. NAT-reglar etablerer tilstand for tilkoplingssporing på den første pakken, så ein etablert straum held på omsetjinga si òg etter at regelen vert endra. Difor er ein regel som vert oppdatert og ein straum som brukar den nye vegen to ulike utsegner. Avgjer kva økter som må koplast til på nytt, og lat uvedkomande straumar vere.

Godta kaldstart, tap og attoppretting

Test gatewayen med tunnelen fråverande ved oppstart, deretter til stades, og deretter etter eit brot og ei tilbakekomst. Stadfest at forbode vidaresending held fram med å verte nekta medan tunnelen manglar, at ein ny tillaten straum verkar når peeren er autentisert, og at attoppretting ikkje krev tømming av uvedkomande tilstand. Ikkje tøm heile POSTROUTING-kjeda eller kvar conntrack-oppføring som ei stopphandling for ein profil, fordi andre tenester deler dei. Noter kva komponent som endra grensesnittet, ruta og politikken, i staden for berre at ein startkrok avslutta med null.

Ein politikk som overlever ei gjenoppkopling, er ein der eigarane er namngjevne og reglane er testa med tunnelen både nede og oppe. Ein krok som rapporterer suksess, beviser berre at kroken køyrde.