Hvor VPN-NAT hører til i UFW's before.rules, og hvordan du tester det

En NAT-regel, der virker, når den skrives i en shell, fejler, når den indsættes i before.rules, fordi filen ikke er et script. Den er et dokument i gendannelsesformat med tabelsektioner, kædedeklarationer og en COMMIT-markør for hver tabel. En linje på det forkerte sted afbryder enten hele gendannelsen eller dropper lydløst regler, du troede var der. Runbooken nedenfor placerer fragmentet, hvor rammen forventer det, og beviser resultatet før den næste genindlæsning.

En shellkommando er ikke en gendannelsesfil

En linje, der begynder med iptables -t nat, er en instruktion til iptables-binæren, mens filen, som UFW læser, er en beskrivelse af et komplet regelsæt. Forskellen er ikke kosmetisk: gendannelsesformatet skal vide, hvilken tabel det er i, hvilke kæder der findes, og hvor tabellen slutter. En kommando, der indsættes i det dokument, er enten en syntaksfejl eller, værre, en regel knyttet til den forkerte tabel. Rammen indlæser disse filer via gendannelsesværktøjer netop, fordi de er deklarative og ikke sekventielle.

Dokumentet indlæses også som helhed, så én fejlbehæftet sektion kan stoppe resten af filen i at blive anvendt. En lille fejl i et NAT-fragment tager derfor filterreglerne med ned, og det er sådan en firewallændring bliver et nedbrud.

Sæt fragmentet inde i den eksisterende tabelsektion

Et NAT-fragment har en form, og formen betyder mere end reglens tekst indeni. Tabelhovedet åbner sektionen, kædedeklarationer etablerer tællerne, reglerne følger, og en COMMIT lukker sektionen.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Puljen og interfacet ovenfor er pladsholdere for dine egne; strukturen er den del, der er værd at kopiere. Hvis filen allerede indeholder en *nat-sektion, skal du tilføje reglen inde i den sektion i stedet for at åbne en anden, fordi formatet forventer én COMMIT per tabel, og to sektioner til den samme tabel er en reparation, der venter på at ske. Bevar distributionens kædedefinitioner intakte, inklusive dem leverandøren har tilføjet til sin egen integration. UFW-rammemanualen dokumenterer before-, user- og after-filerne sammen med kravet om en matchende COMMIT.

Hvis filen viser sig at være tom, må du ikke udfylde den fra en tutorial. Bekræft, hvilken pakke der ejer den, og hvad den aktive politik faktisk er, fordi en tom vedvarende fil ikke beviser, at kernen ikke har regler, og et indlæst regelsæt beviser ikke, at den næste genindlæsning har en komplet fil at læse. Gendan den understøttede basislinje først, og anvend derefter webstedsændringerne oven på den.

Test kandidaten uden at anvende den

Gendannelsesværktøjet kan parse og konstruere et regelsæt uden at anvende det, hvilket er den billigste tilgængelige test. Kør det mod en beskyttet kopi i stedet for den live fil, og læs fejlteksten i stedet for kun exitstatus. En parsefejl angiver en linje og normalt en tabel, hvilket er mere, end en mislykket genindlæsning vil fortælle dig.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

At bestå den kontrol beviser, at dokumentet parses, og intet andet. Det beviser ikke, at kandidaten stadig indeholder hver kæde, UFW afhænger af, at den kun tillader de kilder, du havde tænkt på, eller at fjernadministration forbliver tilgængelig. Det er separate gennemgange, og den sidste fortjener en ekstra session åbnet, før du begynder.

Vælg det værktøj, der passer til den installerede backend og adressefamilie. En vært, der kører nft-backenden gennem kompatibilitetslaget, har brug for den tilsvarende kommando, og IPv6-regler bor i en helt anden fil.

Hold videresendelse, NAT og adgangspolitik adskilt

Kildetranslation løser et adresseringsproblem og giver intet. Videresendelse er en separat tilladelse styret af en sysctl og af filtertabellen, og det er den, folk glemmer, når en tunnel router, men ikke sender trafik. Adgangspolitik er en tredje beslutning om, hvilke kilder der må nå hvilke tjenester, og ingen NAT-regel udtrykker den. At holde de tre adskilt er det, der gør en fejl diagnosticerbar i stedet for et enkelt vagt symptom.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Læs de tre output sammen i stedet for et ad gangen. En masquerade-regel med videresendelse deaktiveret giver en klient, der forbinder og ikke når noget, hvilket fra klientsiden ser ud præcis som en routingfejl og sender folk til den forkerte fil. Filtertabellen er også der, hvor et for bredt accept skjuler sig, så kontroller dens standardpolitik, mens du er der.

Bekræft en genindlæsning, en afvisning og et VPN-tab

Tre observationer udgør en komplet accepttest: genindlæsningen lykkes, en tilladt klienthandling virker, og en anmodning, der bør afvises, bliver faktisk afvist. Den tredje er den, der springes over, og den er det eneste bevis for, at politikken overhovedet gør noget.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Test derefter den fejl, du designede til. Drop tunnelen og se, hvad værten gør, fordi en politik, der kun virker, mens VPN'et er oppe, er en politik med en usagt afhængighed. Genindlæs én gang mere bagefter for at bevise, at det er filen, og ikke en resterende kørende tilstand, der giver det fungerende resultat.

IPv4-NAT siger intet om IPv6, så angiv den tilsigtede dækning for begge familier i samme note som reglen. Målet er en sammenhængende administreret politik, og et fragment, der tilfældigvis blev parset, er ikke bevis for en.