Wêr't VPN-NAT yn UFW syn before.rules heart en hoe jo it teste

In NAT-regel dy't wurket as er yn in shell typt wurdt, mislearret as er yn before.rules plakt wurdt, om't dat bestân gjin skript is. It is in dokumint yn restauraasjeformaat mei tabele-ûnderdielen, keatlingferklearringen en in COMMIT-markearring foar elke tabel. In rigel op it ferkearde plak briek de hiele restauraasje ôf of smyt stil regels weilitten dy't jo tochten dat der wiene. It runbook hjirûnder set it fragmint dêr't it ramt it ferwachtet en bewiist it resultaat foar de folgjende opnij laden.

In shellopdracht is gjin restauraasjebestân

In rigel dy't begjint mei iptables -t nat is in opdracht oan it iptables-binêre bestân, wylst it bestân dat UFW lêst in beskriuwing is fan in folsleine regelset. It ferskil is net kosmetysk: it restauraasjeformaat moat witte yn hokker tabel it is, hokker keatlingen besteane en wêr't de tabel einiget. In opdracht dy't yn dat dokumint plakt wurdt is of in syntaksflater of, slimmer, in regel dy't oan de ferkearde tabel ferbûn is. It ramt laadt dizze bestannen fia restauraasje-ark, krekt om't se deklaratyf binne en net sekwinsjeel.

It dokumint wurdt ek as gehiel laden, dus ien ferkeard ûnderdiel kin de rest fan it bestân stoppe om tapast te wurden. In lytse flater yn in NAT-fragmint nimt dêrom de filterregels mei nei ûnderen, en sa wurdt in firewallwiziging in útfal.

Set it fragmint binnen it besteande tabele-ûnderdiel

In NAT-fragmint hat in foarm, en de foarm is wichtiger as de regeltekst der yn. De tabelekop iepenet it ûnderdiel, keatlingferklearringen fêstigje de tellers, de regels folgje, en in COMMIT slút it ûnderdiel.

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

De pool en ynterface hjirboppe binne plakhâlders foar jo eigen; de struktuer is it part dat it kopiearjen wurdich is. As it bestân al in *nat-ûnderdiel befettet, foegje de regel dan binnen dat ûnderdiel ta ynstee fan in twadde te iepenjen, om't it formaat ien COMMIT per tabel ferwachtet en twa ûnderdielen foar deselde tabel in reparaasje binne dy't op it barren wachtet. Hâld de keatlingdefinysjes fan de distribúsje yntakt, ynklusyf dy't de leveransier tafoege hat foar syn eigen yntegraasje. De UFW-ramthantlieding dokumintearret de bestannen before, user en after tegearre mei de eask fan in passende COMMIT.

As it bestân leech blykt te wêzen, folje it dan net út in tutorial. Befêstigje hokker pakket it besit en wat it libbene belied eins is, om't in leech persistent bestân net bewissiget dat de kernel gjin regels hat, en in laden regelset net bewissiget dat de folgjende opnij laden in folslein bestân hat om te lêzen. Restorearje earst de stipe basisline en pas dêrnei de sidewizigingen dêrop opnij ta.

Test de kandidaat sûnder it ta te passen

It restauraasje-ark kin in regelset parse en bouwe sûnder it ta te passen, wat de goedkeapste beskikbere test is. Rin it tsjin in beskerme kopy ynstee fan it libbene bestân, en lês de flatertekst ynstee fan allinnich de útgongstatus. In parseflater neamt in rigel en meastentiids in tabel, wat mear is as in mislearre opnij laden jo fertelle sil.

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

It slagjen fan dy kontrôle bewissiget dat it dokumint parset wurdt en neat oars. It bewissiget net dat de kandidaat noch elke keatling befettet dêr't UFW fan ôfhinklik is, dat it allinnich de boarnen tastiet dy't jo bedoelden, of dat op ôfstân behear berikber bliuwt. Dat binne aparte beoardielingen, en de lêste fertsjinnet in twadde sesje dy't iepene wurdt foardat jo begjinne.

Kies it ark dat past by it ynstallearre backend en de adresfamylje. In host dy't it nft-backend fia de kompatibiliteitslaach rint, hat it oerienkommende kommando nedich, en IPv6-regels libje yn in hiel oar bestân.

Hâld trochstjoering, NAT en tagongsbelied apart

Boarnfertaling lost in adressearringsprobleem op en jout neat. Trochstjoering is in aparte tastimming dy't regele wurdt troch in sysctl en troch de filtertabel, en it is dy't minsken ferjitte as in tunnel rûtelet mar gjin ferkear trochlit. Tagongsbelied is in tredde beslút oer hokker boarnen hokker tsjinsten berikke meie, en gjin NAT-regel sprekt it út. Krekt it apart hâlden fan de trije makket in flater diagnostisearber ynstee fan ien ûndúdlik symptoom.

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

Lês dy trije útgongen tegearre ynstee fan ien foar ien. In masquerade-regel mei trochstjoering útskeakele produsearret in kliïnt dy't ferbynt en neat berikt, wat fan 'e kliïntkant krekt op in routingflater liket en minsken nei it ferkearde bestân stjoert. De filtertabel is ek it plak dêr't in te breed accept him ferskûlet, dus kontrolearje it standertbelied wylst jo der binne.

Ferifiearje in opnij laden, in wegering en in VPN-ferlies

Trije observaasjes meitsje in folsleine akseptaasjetest: it opnij laden slagget, in tastiene kliïntbewurking wurket, en in fersyk dat wegere wurde moat wurdt echt wegere. De tredde is dejinge dy't oerslein wurdt, en it is it iennige bewiis dat it belied hielendal wat docht.

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

Test dan de flater dêr't jo foar ûntwurpen hawwe. Lit de tunnel falle en sjoch wat de host docht, om't in belied dat allinnich wurket wylst de VPN oan is in belied is mei in ûnútspritsen ôfhinklikens. Laad dêrnei noch ien kear opnij om te bewizen dat it bestân, en net in oerbleaune rinnende tastân, it wurkjende resultaat produsearret.

IPv4-NAT seit neat oer IPv6, dus neam de bedoelde dekking foar beide famyljes yn deselde notysje as de regel. In gearhingjend beheard belied is it doel, en in fragmint dat tafallich parset waard is dêr gjin bewiis foar.