nftables: sett inn VPN-tillatelsesregelen før drop-håndtaket

Plasser en tillatelsesregel på feil sted, og den oppfører seg som om det ikke fantes noen tillatelsesregel. I nftables avgjør valget mellom insert og add hvilken side av en referert regel den nye setningen lander på, og et håndtak navngir regelen i det levende regelsettet fremfor radnummeret. Tar du feil av plasseringen, når pakken drop først.

Sammenligningen nedenfor bruker én fast peer og én ytre lytterutveksling. Den er bevisst smal; å erstatte en hel kjede er en annen endring med en annen risikoprofil.

To plasseringer, to forskjellige utfall

insert plasserer en regel før den refererte regelen. add plasserer den etter. Hvis den refererte regelen er det terminale droppet for flyten, gir de to kommandoene motsatte resultater selv om regelteksten er identisk.

Å utelate en plassering har sin egen standardatferd, som er nok en grunn til ikke å kopiere en kommando fra et forum uten å lese hva den er forankret i. Forankringen er hele beslutningen. Skriv ned den tiltenkte siden før du skriver kommandoen. insert og add skiller seg med ett ord i filen.

Plasseringen er relativ til en regel i en bestemt kjede. Å flytte den samme setningen til en annen kjede eller en annen hook-prioritet endrer hvilke pakker den ser, selv når regelens syntaks ser riktig ut.

Et håndtak identifiserer en regel, ikke et linjenummer

Et håndtak som 42 er en identifikator i den gjeldende tilstanden til regelsettet. Det er ikke den førtiandre regelen, og det er ikke stabilt på tvers av verter, gjenoppbygginger eller en behandler som laster konfigurasjonen sin på nytt.

Finn kjeden og det faktiske terminale droppet før du velger forankringen. Bekreft deretter håndtaket på den regelen i samme opplisting som viser droppet, slik at nummeret og regelen leses sammen. Et håndtak lest fra en gammel opplisting kan allerede tilhøre en annen regel. Les det på nytt i økten som skal bruke endringen.

iptables --version
nft -a list ruleset

iptables-versjonen rapporterer hvilken backend som brukes. Et iptables-nft-regelsett og en uavhengig administrert innebygd tabell kan eksistere side om side, så en opplisting fra én frontend er ikke automatisk det fullstendige filtreringsbildet. Kontroller begge visningene før du velger en kjede.

Finn kjeden og regelen som faktisk dropper

Les input-hooken, kjede prioriteten og regelen som avviser denne lytterflyten. En inet-tabell kan bære begge adressefamiliene, men en enkelt regel kan fortsatt bare matche IPv4.

Ta én godkjent peer, med 198.51.100.25 fra dokumentasjonsområdet som eksempel. En gjennomgått innebygd fil kan plassere en ytre tillatelse før håndtak 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Erstatt familie, tabell, kjede, håndtak, inngangsgrensesnitt og peer etter inspeksjon. Eksempelet bruker håndtak-plasseringsformen som er dokumentert for nft 1.0.9, og den hører i en inndatafil; sitat av krøllparenteser er en egen sak når kommandoen skrives interaktivt.

Hold konfigurasjonseieren tydelig. En behandler som bygger opp reglene sine på nytt kan overskrive en kjøretidsendring, og et oppstartsskript som hardkoder et utdatert håndtak vil enten feile eller feste seg til feil regel.

Tillatelse er avgrenset, et drop er terminalt

En tillatelsesdom avslutter evalueringen på sin nåværende vei, men en senere anvendelig basiskjede kan fortsatt droppe pakken. En dropdom er terminal. Derfor er en økende tillatelsesteller ikke bevis på at flyten lyktes.

Undersøk alle relevante hook-prioriteter i stedet for én kjede isolert. En pakke kan passere et input-filter og likevel bli avvist av en annen tabells hook ved en annen prioritet. List opp hver basiskjede som kan se flyten.

Den regelen dekker bare den ytre lytterutvekslingen. Transportinnkapslet ESP, innebygd ESP, IPv6-peers og den dekrypterte trafikken inne i tunnelen trenger alle egne policyer. Det er ikke en fullstendig nettsteds-VPN-brannmur.

Kontroller filen, og verifiser deretter det levende resultatet

Kjør en syntaks- og transaksjonskontroll på den gjennomgåtte filen før du bruker den. Kontrollmodus rapporterer om nft kan parse og klargjøre endringen; den bruker den ikke og beviser ikke at en annen hook vil tillate pakken. Filen forblir et forslag til eieren bruker den:

nft -c -f reviewed-vpn-rule.nft

Bruk den gjennom eierens kontrollerte prosess og behold gjenopprettingstilgang. Hvis regelen er feil, kan droppet du prøvde å komme foran også kutte veien du bruker for å rette den.

Etter endringen, observer et nytt tillatt peer-forsøk og kontroller at kilder utenfor den godkjente peeren fortsatt avvises. Flytt den varige regelen inn i den behandleren som eier regelsettet, fordi håndtak i kjøretid lokaliserer gjeldende objekter i stedet for å identifisere dem på tvers av oppstarter.