nftables: indsæt VPN-tilladelsesreglen før drop-håndtaget
I nftables placerer insert og add en regel på hver sin side af et håndtag. Find drop, vælg siden, og kontroller derefter filen, før regelsættet ændres.
Placer en tilladelsesregel på det forkerte sted, og den opfører sig som ingen tilladelsesregel. I nftables afgør valget mellem insert og add, hvilken side af en refereret regel den nye sætning lander på, og et håndtag navngiver reglen i det levende regelsæt frem for dens rækkenummer. Tager du fejl af placeringen, når pakken først drop.
Sammenligningen nedenfor bruger én fast peer og én ydre lytterudveksling. Den er bevidst smal; at erstatte en hel kæde er en anden ændring med en anden risikoprofil.
To placeringer, to forskellige udfald
insert placerer en regel før den refererede regel. add placerer den efter. Hvis den refererede regel er det terminale drop for flowet, giver de to kommandoer modsatte resultater, selv om regelteksten er identisk.
At udelade en placering har sin egen standardadfærd, hvilket er endnu en grund til ikke at kopiere en kommando fra et forum uden at læse, hvad den er forankret i. Forankringen er hele beslutningen. Skriv den tilsigtede side ned, før du skriver kommandoen. insert og add adskiller sig med ét ord i filen.
Placeringen er relativ til en regel i en bestemt kæde. Flytter du den samme sætning til en anden kæde eller en anden hook-prioritet, ændrer det, hvilke pakker den ser, selv når regelens syntaks ser korrekt ud.
Et håndtag identificerer en regel, ikke et linjenummer
Et håndtag som 42 er en identifikator i den aktuelle regelsætstilstand. Det er ikke den toogfyrretyvende regel, og det er ikke stabilt på tværs af værter, genopbygninger eller en manager, der genindlæser sin konfiguration.
Find kæden og det faktiske terminale drop, før du vælger forankringen. Bekræft derefter håndtaget på den regel i samme visning, der viser droppet, så nummeret og reglen læses sammen. Et håndtag læst fra en gammel visning kan allerede tilhøre en anden regel. Læs det igen i den session, der anvender ændringen.
iptables --version
nft -a list ruleset
iptables-versionen angiver, hvilken backend der bruges. Et iptables-nft-regelsæt og en uafhængigt administreret indbygget tabel kan eksistere side om side, så en visning fra én frontend er ikke automatisk det komplette filtreringsbillede. Kontroller begge visninger, før du vælger en kæde.
Find kæden og den regel, der faktisk dropper
Læs input-hooken, kædeprioriteten og den regel, der afviser dette lytterflow. En inet-tabel kan bære begge adressefamilier, men en enkelt regel kan stadig kun matche IPv4.
Tag én godkendt peer, idet du bruger 198.51.100.25 fra dokumentationsområdet som eksempel. En gennemgået indbygget fil kan placere en ydre tilladelse før håndtag 42:
insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept
Erstat familie, tabel, kæde, håndtag, indgangsgrænseflade og peer efter inspektion. Eksemplet bruger håndtagsplaceringsformen, der er dokumenteret for nft 1.0.9, og den hører i en inputfil; citat af krøllede parenteser er en særskilt sag, når kommandoen skrives interaktivt.
Hold konfigurationsejeren klar. En manager, der genopbygger sine regler, kan overskrive en redigering under kørsel, og et opstartsscript, der hardcoder et forældet håndtag, vil enten fejle eller knytte sig til den forkerte regel.
Tilladelse er afgrænset, et drop er terminalt
En tilladelsesdom afslutter evalueringen på sin nuværende vej, men en senere anvendelig basiskæde kan stadig droppe pakken. En drop-dom er terminal. Derfor er en stigende tilladelsestæller ikke bevis på, at flowet lykkedes.
Undersøg alle relevante hook-prioriteter i stedet for én kæde isoleret. En pakke kan passere et inputfilter og stadig blive afvist af en anden tabels hook ved en anden prioritet. List hver basiskæde, der kan se flowet.
Den regel dækker kun den ydre lytterudveksling. Transportindkapslet ESP, indbygget ESP, IPv6-peers og den dekrypterede trafik inde i tunnelen har alle brug for deres egne politikker. Det er ikke en komplet site-VPN-firewall.
Kontroller filen, og verificér derefter det levende resultat
Kør en syntaks- og transaktionskontrol på den gennemgåede fil, før du anvender den. Kontroltilstand rapporterer, om nft kan parse og klargøre ændringen; den anvender den ikke og beviser ikke, at en anden hook vil tillade pakken. Filen forbliver et forslag, indtil ejeren anvender den:
nft -c -f reviewed-vpn-rule.nft
Anvend gennem ejerens kontrollerede proces, og bevar gendannelsesadgang. Hvis reglen er forkert, kan det drop, du forsøgte at komme foran, også skære den vej over, du bruger til at rette det.
Efter ændringen skal du observere et nyt tilladt peer-forsøg og kontrollere, at kilder uden for den godkendte peer stadig afvises. Flyt den varige regel ind i den manager, der ejer regelsættet, fordi håndtag under kørsel lokaliserer aktuelle objekter i stedet for at identificere dem på tværs af opstarter.