Ku vendoset NAT-i i VPN-së te before.rules i UFW dhe si ta testosh

Një rregull NAT që funksionon kur shkruhet në një shell dështon kur ngjitet në before.rules, sepse ai skedar nuk është skript. Është një dokument në format rikuperimi me seksione tabelash, deklarata zinxhirësh dhe një shenjë COMMIT për çdo tabelë. Një rresht në vendin e gabuar ose ndërpret të gjithë rikuperimin ose hedh në heshtje rregulla që besonit se ishin aty. Procedura më poshtë e vendos fragmentin aty ku e pret korniza dhe e provon rezultatin përpara ringarkimit të radhës.

Një komandë shell nuk është skedar rikuperimi

Një rresht që fillon me iptables -t nat është udhëzim për binarin iptables, ndërsa skedari që lexon UFW është përshkrimi i një grupi të plotë rregullash. Dallimi nuk është kozmetik: formati i rikuperimit duhet të dijë në cilin tabelë është, cilët zinxhirë ekzistojnë dhe ku mbaron tabela. Një komandë e ngjitur në atë dokument është ose gabim sintakse ose, më keq, një rregull i lidhur me tabelën e gabuar. Korniza i ngarkon këto skedarë përmes mjeteve të rikuperimit pikërisht sepse janë deklarative dhe jo sekuenciale.

Dokumenti ngarkohet edhe si tërësi, kështu që një seksion i deformuar mund të ndalojë zbatimin e pjesës tjetër të skedarit. Prandaj një gabim i vogël në një fragment NAT tërheq poshtë edhe rregullat e filtrimit, dhe kështu një ndryshim firewalls bëhet ndërprerje.

Vendos fragmentin brenda seksionit ekzistues të tabelës

Një fragment NAT ka formë, dhe forma ka më shumë rëndësi se teksti i rregullit brenda tij. Koka e tabelës hap seksionin, deklaratat e zinxhirëve vendosin numëruesit, rregullat vazhdojnë dhe një COMMIT mbyll seksionin.

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

Grupi dhe ndërfaqja më sipër janë vendmbajtëse për vlerat e tua; struktura është pjesa që ia vlen të kopjohet. Nëse skedari tashmë përmban një seksion *nat, shto rregullin brenda atij seksioni në vend që të hapësh një të dytë, sepse formati pret një COMMIT për tabelë dhe dy seksione për të njëjtën tabelë janë një riparim që pret të ndodhë. Mbaj të paprekura përkufizimet e zinxhirëve të shpërndarjes, përfshirë ato që furnizuesi ka shtuar për integrimin e vet. Manuali i kornizës UFW dokumenton skedarët before, user dhe after bashkë me kërkesën për një COMMIT përputhës.

Nëse skedari rezulton bosh, mos e mbush nga një tutorial. Konfirmo cili paketë e zotëron dhe cila është në të vërtetë politika aktive, sepse një skedar i përhershëm bosh nuk provon që kerneli nuk mban rregulla, dhe një grup rregullash i ngarkuar nuk provon që ringarkimi i radhës do të ketë një skedar të plotë për të lexuar. Rikthe fillimisht bazën e mbështetur dhe më pas rizbato ndryshimet e faqes mbi të.

Testo kandidatin pa e zbatuar

Mjeti i rikuperimit mund të analizojë dhe ndërtojë një grup rregullash pa e zbatuar, dhe ky është testi më i lirë i disponueshëm. Ekzekutoje mbi një kopje të mbrojtur dhe jo mbi skedarin aktiv, dhe lexo tekstin e gabimit, jo vetëm statusin e daljes. Një dështim analize emërton një rresht dhe zakonisht një tabelë, që është më shumë sesa të thotë një ringarkim i dështuar.

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

Kalimi i asaj kontrolli provon që dokumenti analizohet dhe asgjë tjetër. Nuk provon që kandidati ende përmban çdo zinxhir nga i cili varet UFW, që lejon vetëm burimet e synuara, ose që administrimi në distancë mbetet i arritshëm. Këto janë rishikime të veçanta, dhe i fundit meriton një sesion të dytë të hapur përpara se të fillosh.

Zgjidh mjetin që i përshtatet backend-it të instaluar dhe familjes së adresave. Një host që ekzekuton backend-in nft përmes shtresës së përputhshmërisë ka nevojë për komandën përkatëse, dhe rregullat IPv6 jetojnë në një skedar krejt tjetër.

Mbaj të ndara përcjelljen, NAT-in dhe politikën e aksesit

Përkthimi i burimit zgjidh një problem adresimi dhe nuk jep asgjë. Përcjellja është një leje e veçantë e kontrolluar nga një sysctl dhe nga tabela e filtrimit, dhe është pikërisht ajo që njerëzit harrojnë kur një tunel rrugëton por nuk kalon trafik. Politika e aksesit është vendimi i tretë për cilat burime mund të arrijnë cilat shërbime, dhe asnjë rregull NAT nuk e shpreh atë. Pikërisht mbajtja e këtyre treve të ndara e bën një dështim të diagnostikueshëm në vend të një simptome të vetme të paqartë.

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

Lexo këto tre dalje së bashku, jo një nga një. Një rregull masquerade me përcjelljen e çaktivizuar prodhon një klient që lidhet dhe nuk arrin askund, që nga ana e klientit duket saktësisht si një defekt rrugëtimi dhe i dërgon njerëzit te skedari i gabuar. Tabela e filtrimit është gjithashtu vendi ku fshihet një accept shumë i gjerë, prandaj kontrollo politikën e tij të paracaktuar ndërsa je atje.

Verifiko një ringarkim, një refuzim dhe një humbje VPN

Tre vëzhgime përbëjnë një test të plotë pranimi: ringarkimi ka sukses, një operacion i lejuar i klientit funksionon dhe një kërkesë që duhet të refuzohet refuzohet vërtet. E treta është ajo që anashkalohet, dhe është prova e vetme që politika po bën diçka.

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

Më pas testo dështimin për të cilin ke projektuar. Lësho tunelin dhe vëzhgo çfarë bën hosti, sepse një politikë që funksionon vetëm sa kohë VPN-i është i ndezur është një politikë me një varësi të padeklaruar. Ringarko edhe një herë pas kësaj për të provuar se është skedari, dhe jo ndonjë gjendje ekzekutimi e mbetur, që prodhon rezultatin funksional.

NAT-i i IPv4 nuk thotë asgjë për IPv6, prandaj deklaro mbulimin e synuar për të dyja familjet në të njëjtën shënim si rregulli. Objektivi është një politikë koherente e menaxhuar, dhe një fragment që rastësisht u analizua nuk është provë për të.