Hvor VPN-NAT hører hjemme i UFWs before.rules, og hvordan du tester det

En NAT-regel som fungerer når den skrives i et skall, feiler når den limes inn i before.rules, fordi filen ikke er et skript. Den er et dokument i gjenopprettingsformat med tabellseksjoner, kjedeklæringer og en COMMIT-markør for hver tabell. En linje på feil sted avbryter enten hele gjenopprettingen eller slipper stille regler du trodde var der. Runbooken nedenfor plasserer fragmentet der rammeverket forventer det, og beviser resultatet før neste omlasting.

En skallkommando er ikke en gjenopprettingsfil

En linje som begynner med iptables -t nat, er en instruks til iptables-binæren, mens filen UFW leser, er en beskrivelse av et komplett regelsett. Forskjellen er ikke kosmetisk: gjenopprettingsformatet må vite hvilken tabell det er i, hvilke kjeder som finnes, og hvor tabellen slutter. En kommando som limes inn i det dokumentet, er enten en syntaksfeil eller, verre, en regel festet til feil tabell. Rammeverket laster disse filene via gjenopprettingsverktøy nettopp fordi de er deklarative og ikke sekvensielle.

Dokumentet lastes også som en helhet, så én feilaktig seksjon kan stoppe resten av filen fra å bli brukt. En liten feil i et NAT-fragment tar derfor med seg filterreglene ned, og slik blir en brannmur-endring et avbrudd.

Sett fragmentet inn i den eksisterende tabellseksjonen

Et NAT-fragment har en form, og formen betyr mer enn regelteksten inni det. Tabelloverskriften åpner seksjonen, kjedeklæringene setter opp tellerne, reglene følger, og en COMMIT lukker seksjonen.

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

Bassenget og grensesnittet ovenfor er plassholdere for dine egne; strukturen er den delen som er verdt å kopiere. Hvis filen allerede inneholder en *nat-seksjon, legger du regelen inn i den seksjonen i stedet for å åpne en ny, fordi formatet forventer én COMMIT per tabell, og to seksjoner for samme tabell er en reparasjon som venter på å skje. Hold distribusjonens kjedefinisjoner intakte, inkludert dem leverandøren har lagt til for sin egen integrasjon. UFW-rammeverkets håndbok dokumenterer filene before, user og after sammen med kravet om en samsvarende COMMIT.

Hvis filen viser seg å være tom, må du ikke fylle den fra en veiledning. Bekreft hvilken pakke som eier den, og hva den aktive politikken faktisk er, fordi en tom vedvarende fil ikke beviser at kjernen ikke har regler, og et lastet regelsett beviser ikke at neste omlasting har en komplett fil å lese. Gjenopprett den støttede grunnlinjen først, og bruk deretter nettstedendringene oppå den.

Test kandidaten uten å bruke den

Gjenopprettingsverktøyet kan parse og bygge et regelsett uten å bruke det, og det er den billigste tilgjengelige testen. Kjør det mot en beskyttet kopi i stedet for den aktive filen, og les feilteksten i stedet for bare utgangsstatusen. En parsefeil angir en linje og vanligvis en tabell, noe som er mer enn en mislykket omlasting vil fortelle deg.

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

Å bestå den kontrollen beviser at dokumentet parses, og ingenting annet. Det beviser ikke at kandidaten fortsatt inneholder hver kjede UFW er avhengig av, at den bare tillater kildene du mente, eller at fjernadministrasjon forblir tilgjengelig. Dette er separate gjennomganger, og den siste fortjener en ekstra økt som åpnes før du begynner.

Velg verktøyet som passer til den installerte backenden og adressefamilien. En vert som kjører nft-backenden gjennom kompatibilitetslaget, trenger den tilsvarende kommandoen, og IPv6-regler bor i en helt annen fil.

Hold videresending, NAT og tilgangspolicy atskilt

Kildeoversettelse løser et adresseringsproblem og gir ingenting. Videresending er en egen tillatelse styrt av en sysctl og av filtertabellen, og det er den folk glemmer når en tunnel ruter men ikke slipper trafikk gjennom. Tilgangspolicy er en tredje beslutning om hvilke kilder som kan nå hvilke tjenester, og ingen NAT-regel uttrykker den. Å holde de tre atskilt er det som gjør en feil diagnostiserbar i stedet for ett vagt symptom.

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

Les disse tre utdataene sammen i stedet for ett om gangen. En masquerade-regel med videresending deaktivert gir en klient som kobler til og ikke når noe, noe som fra klientsiden ser nøyaktig ut som en rutingfeil og sender folk til feil fil. Filtertabellen er også der et for bredt accept skjuler seg, så sjekk standardpolicyen mens du er der.

Bekreft en omlasting, en avvisning og et VPN-tap

Tre observasjoner utgjør en komplett akseptansetest: omlastingen lykkes, en tillatt klientoperasjon virker, og en forespørsel som skal avvises, blir faktisk avvist. Den tredje er den som hoppes over, og den er det eneste beviset på at policyen gjør noe i det hele tatt.

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

Test deretter feilen du designet for. Slipp tunnelen og se hva verten gjør, fordi en policy som bare virker mens VPN-et er oppe, er en policy med en usagt avhengighet. Last inn én gang til etterpå for å bevise at det er filen, og ikke en gjenværende kjørende tilstand, som gir det fungerende resultatet.

IPv4-NAT sier ingenting om IPv6, så oppgi den tiltenkte dekningen for begge familiene i samme notat som regelen. Målet er en sammenhengende administrert policy, og et fragment som tilfeldigvis ble parset, er ikke bevis for en.