Waar VPN-NAT in UFW se before.rules hoort en hoe om dit te toets

'n NAT-reël wat werk wanneer dit in 'n dop ingetik word, misluk wanneer dit in before.rules geplak word, want daardie lêer is nie 'n script nie. Dit is 'n dokument in herstelformaat met tabelafdelings, kettingverklarings en 'n commit-merker vir elke tabel. 'n Reël op die verkeerde plek breek óf die hele herstel af óf laat reëls stilweg val wat jy geglo het daar was. Die runbook hieronder plaas die fragment waar die raamwerk dit verwag en bewys die resultaat voor die volgende herlaai.

'n Dopopdrag is nie 'n herstellêer nie

'n Reël wat met iptables -t nat begin, is 'n opdrag aan die iptables-program, terwyl die lêer wat UFW lees 'n beskrywing van 'n volledige reëlstel is. Die verskil is nie kosmeties nie: die herstelformaat moet weet in watter tabel dit is, watter kettings bestaan en waar die tabel eindig. 'n Opdrag wat in daardie dokument geplak word, is óf 'n sintaksfout óf, erger, 'n reël wat aan die verkeerde tabel geheg word. Die raamwerk laai hierdie lêers juis deur herstelgereedskap omdat hulle verklarend eerder as opeenvolgend is.

Die dokument word ook as 'n geheel gelaai, so een kwaadwillige afdeling kan verhoed dat die res van die lêer toegepas word. 'n Klein fout in 'n NAT-fragment neem dus die filterreëls saam met hom, en dit is hoe 'n firewall-verandering 'n onderbreking word.

Plaas die fragment binne die bestaande tabelafdeling

'n NAT-fragment het 'n vorm, en die vorm is belangriker as die reëlteks daarin. Die tabelopskrif open die afdeling, kettingverklarings vestig die tellers, die reëls volg, en 'n commit sluit die afdeling.

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

Die poel en koppelvlak hierbo is plekhouers vir jou eie; die struktuur is die deel wat werd is om te kopieer. As die lêer reeds 'n *nat-afdeling bevat, voeg die reël binne daardie afdeling by eerder as om 'n tweede een te open, want die formaat verwag een commit per tabel en twee afdelings vir dieselfde tabel is 'n herstelling wat wag om te gebeur. Hou die kettingdefinisies van die verspreiding ongeskonde, insluitend enige wat die verskaffer vir sy eie integrasie bygevoeg het. Die UFW-raamwerkhandleiding dokumenteer die before-, user- en after-lêers saam met die vereiste vir 'n ooreenstemmende commit.

As die lêer leeg blyk te wees, moenie dit uit 'n tutoriaal vul nie. Bevestig watter pakket dit besit en wat die lewendige beleid werklik is, want 'n leë blywende lêer bewys nie dat die kernel geen reëls het nie, en 'n gelaaide reëlstel bewys nie dat die volgende herlaai 'n volledige lêer het om te lees nie. Herstel eers die ondersteunde basislyn en pas dan werfveranderinge daarop toe.

Toets die kandidaat sonder om dit te commit

Die herstelgereedskap kan 'n reëlstel ontleed en opbou sonder om dit toe te pas, wat die goedkoopste toets is wat beskikbaar is. Laat dit op 'n beskermde kopie loop eerder as op die lewendige lêer, en lees die foutteks eerder as net die uittredestatus. 'n Ontledingsfout noem 'n reël en gewoonlik 'n tabel, wat meer is as wat 'n mislukte herlaai jou sal vertel.

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

Om daardie toets te slaag bewys dat die dokument ontleed word en niks anders nie. Dit bewys nie dat die kandidaat nog elke ketting bevat waarvan UFW afhanklik is nie, dat dit net die bronne toelaat wat jy bedoel het nie, of dat afstandadministrasie bereikbaar bly nie. Dit is afsonderlike hersienings, en die laaste een verdien 'n tweede sessie wat oopgemaak word voordat jy begin.

Kies die gereedskap wat by die geïnstalleerde backend en adresfamilie pas. 'n Gasheer wat die nft-backend deur die versoenbaarheidslaag laat loop, het die ooreenstemmende opdrag nodig, en IPv6-reëls woon in 'n heeltemal ander lêer.

Hou aanstuur, NAT en toegangsbeleid apart

Bronvertaling los 'n adresseringsprobleem op en gee niks nie. Aanstuur is 'n aparte toestemming wat deur 'n sysctl en deur die filtertabel beheer word, en dit is die een wat mense vergeet wanneer 'n tonnel roeteer maar geen verkeer deurlaat nie. Toegangsbeleid is 'n derde besluit oor watter bronne watter dienste mag bereik, en geen NAT-reël druk dit uit nie. Om die drie apart te hou, is wat 'n fout diagnoseerbaar maak in plaas van 'n enkele vae simptoom.

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

Lees daardie drie uitsette saam eerder as een op 'n keer. 'n Masquerade-reël met aanstuur gedeaktiveer lewer 'n kliënt wat verbind en niks bereik, wat presies soos 'n roeteringsfout van die kliënt se kant lyk en mense na die verkeerde lêer stuur. Die filtertabel is ook waar 'n te breë accept wegkruip, so kyk terselfdertyd na sy standaardbeleid.

Verifieer 'n herlaai, 'n weiering en 'n VPN-verlies

Drie waarnemings maak 'n volledige aanvaardingstoets: die herlaai slaag, 'n toegelate kliëntbewerking werk, en 'n versoek wat geweier moet word, word werklik geweier. Die derde een is die een wat oorgeslaan word, en dit is die enigste bewys dat die beleid enigiets doen.

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

Toets dan die mislukking waarvoor jy ontwerp het. Laat die tonnel val en kyk wat die gasheer doen, want 'n beleid wat net werk terwyl die VPN op is, is 'n beleid met 'n onuitgesproke afhanklikheid. Herlaai daarna nog eens om te bewys dat dit die lêer is, eerder as een of ander oorblywende lopende toestand, wat die werkende resultaat lewer.

IPv4-NAT sê niks oor IPv6 nie, so vermeld die beoogde dekking vir beide families in dieselfde nota as die reël. 'n Samehangende bestuurde beleid is die doel, en 'n fragment wat toevallig ontleed het, is nie 'n bewys daarvan nie.