Kvar VPN-NAT høyrer heime i before.rules til UFW, og korleis du testar det

Ein NAT-regel som fungerer når han blir skriven i eit skal, feilar når han blir limt inn i before.rules, fordi fila ikkje er eit skript. Ho er eit dokument i gjenopprettingsformat med tabellseksjonar, kjedeklæringar og ein COMMIT-markør for kvar tabell. Ei linje på feil stad avbryt anten heile gjenopprettinga eller slepp stille reglar du trudde var der. Runboka nedanfor plasserer fragmentet der rammeverket ventar det, og beviser resultatet før neste omlasting.

Ein skalkommando er ikkje ei gjenopprettingsfil

Ei linje som byrjar med iptables -t nat, er ein instruks til iptables-binæren, medan fila UFW les, er ei skildring av eit komplett regelsett. Skilnaden er ikkje kosmetisk: gjenopprettingsformatet må vite kva tabell det er i, kva kjeder som finst, og kvar tabellen sluttar. Ein kommando som blir limt inn i det dokumentet, er anten ein syntaksfeil eller, verre, ein regel festa til feil tabell. Rammeverket lastar desse filene via gjenopprettingsverktøy nettopp fordi dei er deklarative og ikkje sekvensielle.

Dokumentet blir òg lasta som ei heilheit, så ein einaste feil seksjon kan stoppe resten av fila frå å bli brukt. Ein liten feil i eit NAT-fragment tek derfor med seg filterreglane ned, og slik blir ei brannmur-endring eit avbrot.

Set fragmentet inn i den eksisterande tabellseksjonen

Eit NAT-fragment har ei form, og forma betyr meir enn regelteksten inni det. Tabelloverskrifta opnar seksjonen, kjedeklæringane set opp teljarane, reglane følgjer, og ein COMMIT lukkar seksjonen.

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

Bassenget og grensesnittet ovanfor er plasshaldarar for dine eigne; strukturen er den delen som er verdt å kopiere. Viss fila allereie inneheld ein *nat-seksjon, legg regelen inn i den seksjonen i staden for å opne ein ny, fordi formatet ventar ein COMMIT per tabell, og to seksjonar for same tabell er ein reparasjon som ventar på å skje. Hald kjedefinisjonane til distribusjonen intakte, inkludert dei leverandøren har lagt til for si eiga integrering. Handboka til UFW-rammeverket dokumenterer filene before, user og after saman med kravet om ein samsvarande COMMIT.

Viss fila viser seg å vere tom, må du ikkje fylle henne frå ei rettleiing. Stadfest kva pakke som eig henne, og kva den aktive politikken faktisk er, fordi ei tom varig fil ikkje beviser at kjernen ikkje har reglar, og eit lasta regelsett beviser ikkje at neste omlasting har ei komplett fil å lese. Gjenopprett den støtta grunnlinja først, og bruk deretter nettstadendringane oppå henne.

Test kandidaten utan å bruke han

Gjenopprettingsverktøyet kan parse og byggje eit regelsett utan å bruke det, og det er den billegaste tilgjengelege testen. Køyr det mot ein verna kopi i staden for den aktive fila, og les feilteksten i staden for berre utgangsstatusen. Ein parsefeil nemner ei linje og vanlegvis ein tabell, noko som er meir enn ei mislukka omlasting vil fortelje 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 blir parsa, og ingenting anna. Det beviser ikkje at kandidaten framleis inneheld kvar kjede UFW er avhengig av, at han berre tillèt kjeldene du meinte, eller at fjernadministrasjon blir verande tilgjengeleg. Dette er separate gjennomgangar, og den siste fortener ei ekstra økt som blir opna før du byrjar.

Vel verktøyet som passar til den installerte backenden og adressefamilien. Ein vert som køyrer nft-backenden gjennom kompatibilitetslaget, treng den tilsvarande kommandoen, og IPv6-reglar bur i ei heilt anna fil.

Hald videresending, NAT og tilgangspolitikk atskilde

Kjeldeomsetjing løyser eit adresseringsproblem og gir ingenting. Videresending er ei eiga tillating styrt av ein sysctl og av filtertabellen, og det er den folk gløymer når ein tunnel rutar men ikkje slepp trafikk gjennom. Tilgangspolitikk er eit tredje vedtak om kva kjelder som kan nå kva tenester, og ingen NAT-regel uttrykkjer den. Å halde dei tre atskilde er det som gjer ein feil diagnostiserbar i staden for eitt vagt symptom.

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

Les desse tre utdataa saman i staden for eitt om gongen. Ein masquerade-regel med videresending deaktivert gir ein klient som koplar til og ikkje når noko, noko som frå klientsida ser nøyaktig ut som ein rutefeil og sender folk til feil fil. Filtertabellen er òg der eit for breitt accept skjuler seg, så sjekk standardpolitikken medan du er der.

Stadfest ei omlasting, ei avvising og eit VPN-tap

Tre observasjonar utgjer ein komplett akseptansetest: omlastinga lukkast, ein tillaten klientoperasjon verkar, og ein førespurnad som skal avvisast, blir faktisk avvist. Den tredje er den som blir hoppa over, og den er det einaste beviset på at politikken gjer noko i det heile.

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

Test deretter feilen du designa for. Slepp tunnelen og sjå kva verten gjer, fordi ein politikk som berre verkar medan VPN-et er oppe, er ein politikk med ei usagd avhengigheit. Last inn ein gong til etterpå for å bevisa at det er fila, og ikkje ein attverande køyrande tilstand, som gir det fungerande resultatet.

IPv4-NAT seier ingenting om IPv6, så oppgi den tiltenkte deknaden for begge familiane i same notat som regelen. Målet er ein samanhengande administrert politikk, og eit fragment som tilfeldigvis vart parsa, er ikkje bevis for ein.