Waar VPN-NAT in UFW's before.rules hoort en hoe je het test

Een NAT-regel die werkt als je hem in een shell typt, faalt als je hem in before.rules plakt, omdat dat bestand geen script is. Het is een document in herstelformaat met tabelsecties, kettingdeclaraties en een COMMIT-marker per tabel. Een regel op de verkeerde plek breekt ofwel de hele herstel af of gooit stil regels weg waarvan je dacht dat ze er stonden. De procedure hieronder zet het fragment waar het raamwerk het verwacht en bewijst het resultaat vóór de volgende herlaadbeurt.

Een shellcommando is geen herstelbestand

Een regel die begint met iptables -t nat is een instructie aan het iptables-binary, terwijl het bestand dat UFW leest een beschrijving van een complete regelset is. Het verschil is niet cosmetisch: het herstelformaat moet weten in welke tabel het zit, welke ketens bestaan en waar de tabel eindigt. Een commando dat in dat document wordt geplakt is ofwel een syntaxisfout of, erger, een regel die aan de verkeerde tabel hangt. Het raamwerk laadt deze bestanden via herstelgereedschap juist omdat ze declaratief zijn en niet sequentieel.

Het document wordt ook als geheel geladen, dus één misvormde sectie kan verhinderen dat de rest van het bestand wordt toegepast. Een kleine fout in een NAT-fragment sleurt daarom de filterregels mee naar beneden, en zo wordt een firewallwijziging een storing.

Zet het fragment in de bestaande tabelsectie

Een NAT-fragment heeft een vorm, en de vorm is belangrijker dan de regeltekst erin. De tabelkop opent de sectie, kettingdeclaraties zetten de tellers op, de regels volgen en een COMMIT sluit de sectie.

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

De pool en interface hierboven zijn plaatsaanduidingen voor je eigen waarden; de structuur is het deel dat het kopiëren waard is. Als het bestand al een *nat-sectie bevat, voeg de regel dan binnen die sectie toe in plaats van een tweede te openen, omdat het formaat één COMMIT per tabel verwacht en twee secties voor dezelfde tabel een reparatie zijn die staat te wachten. Houd de kettingdefinities van de distributie intact, inclusief degene die de leverancier voor zijn eigen integratie heeft toegevoegd. De UFW-raamwerkhandleiding documenteert de bestanden before, user en after samen met de eis van een bijpassende COMMIT.

Als het bestand leeg blijkt te zijn, vul het dan niet vanuit een tutorial. Bevestig welk pakket het bezit en wat het actieve beleid werkelijk is, want een leeg persistent bestand bewijst niet dat de kernel geen regels heeft, en een geladen regelset bewijst niet dat de volgende herlaadbeurt een compleet bestand heeft om te lezen. Herstel eerst de ondersteunde basislijn en pas daarna de sitewijzigingen daarop opnieuw toe.

Test de kandidaat zonder hem toe te passen

Het herstelgereedschap kan een regelset parsen en opbouwen zonder hem toe te passen, en dat is de goedkoopste beschikbare test. Voer het uit tegen een beschermde kopie in plaats van het live bestand, en lees de fouttekst in plaats van alleen de exitstatus. Een parsefout noemt een regel en meestal een tabel, wat meer is dan een mislukte herlaadbeurt je vertelt.

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

Die controle doorstaan bewijst dat het document wordt geparsed en niets anders. Het bewijst niet dat de kandidaat nog elke keten bevat waarvan UFW afhankelijk is, dat hij alleen de bedoelde bronnen toestaat, of dat beheer op afstand bereikbaar blijft. Dat zijn afzonderlijke beoordelingen, en de laatste verdient een tweede sessie die vóór de start wordt geopend.

Kies het gereedschap dat past bij de geïnstalleerde backend en de adresfamilie. Een host die de nft-backend via de compatibiliteitslaag draait, heeft het bijbehorende commando nodig, en IPv6-regels leven in een heel ander bestand.

Houd doorsturen, NAT en toegangsbeleid gescheiden

Bronvertaling lost een adresseringsprobleem op en geeft niets. Doorsturen is een aparte toestemming die door een sysctl en door de filtertabel wordt beheerd, en dat is degene die mensen vergeten wanneer een tunnel routeert maar geen verkeer doorlaat. Toegangsbeleid is een derde beslissing over welke bronnen welke diensten mogen bereiken, en geen enkele NAT-regel drukt dat uit. Juist het gescheiden houden van de drie maakt een storing diagnoseerbaar in plaats van één vaag symptoom.

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

Lees die drie uitvoer samen in plaats van één voor één. Een masquerade-regel met doorsturen uitgeschakeld levert een client op die verbindt en niets bereikt, wat er vanaf de clientkant precies als een routeringsfout uitziet en mensen naar het verkeerde bestand stuurt. De filtertabel is ook de plek waar een te brede accept zich verstopt, dus controleer daar het standaardbeleid terwijl je er bent.

Controleer een herlaadbeurt, een weigering en een VPN-verlies

Drie observaties vormen een complete acceptatietest: de herlaadbeurt slaagt, een toegestane clientbewerking werkt en een verzoek dat geweigerd zou moeten worden, wordt daadwerkelijk geweigerd. De derde is degene die wordt overgeslagen, en het is het enige bewijs dat het beleid helemaal iets doet.

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

Test daarna de storing waarvoor je hebt ontworpen. Laat de tunnel vallen en kijk wat de host doet, want een beleid dat alleen werkt zolang de VPN aan staat, is een beleid met een onuitgesproken afhankelijkheid. Herlaad daarna nog één keer om te bewijzen dat het bestand, en niet een achtergebleven actieve toestand, het werkende resultaat oplevert.

IPv4-NAT zegt niets over IPv6, dus vermeld de bedoelde dekking voor beide families in dezelfde notitie als de regel. Het doel is een samenhangend beheerd beleid, en een fragment dat toevallig werd geparsed is daar geen bewijs van.