Kur VPN NAT priklauso UFW before.rules faile ir kaip jį išbandyti

NAT taisyklė, kuri veikia įvedus ją į shell, nepavyksta įklijavus ją į before.rules, nes tas failas nėra scenarijus. Tai atkūrimo formato dokumentas su lentelių dalimis, grandinių deklaracijomis ir COMMIT žymekliu kiekvienai lentelei. Eilutė netinkamoje vietoje arba nutraukia visą atkūrimą, arba tyliai išmeta taisykles, kurias manėte esant. Toliau pateikta instrukcija įdeda fragmentą ten, kur jo tikisi sistema, ir įrodo rezultatą prieš kitą įkėlimą.

Shell komanda nėra atkūrimo failas

iptables -t nat prasidedanti eilutė yra nurodymas iptables dvejetainiam failui, o failas, kurį skaito UFW, yra viso taisyklių rinkinio aprašymas. Skirtumas ne kosmetinis: atkūrimo formatas turi žinoti, kurioje lentelėje jis yra, kokios grandinės egzistuoja ir kur lentelė baigiasi. Į tą dokumentą įklijuota komanda yra arba sintaksės klaida, arba, dar blogiau, taisyklė, prikabinta prie netinkamos lentelės. Sistema įkelia šiuos failus atkūrimo įrankiais būtent todėl, kad jie deklaratyvūs, o ne nuoseklūs.

Dokumentas taip pat įkeliamas kaip visuma, todėl viena sugadinta dalis gali sustabdyti likusio failo taikymą. Todėl maža klaida NAT fragmente nutempia žemyn ir filtro taisykles, ir taip ugniasienės pakeitimas tampa trikdžiu.

Įdėkite fragmentą į esamą lentelės dalį

NAT fragmentas turi formą, ir forma svarbesnė už jame esantį taisyklės tekstą. Lentelės antraštė atveria dalį, grandinių deklaracijos nustato skaitiklius, taisyklės seka, o COMMIT uždaro dalį.

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

Aukščiau esantis telkinys ir sąsaja yra jūsų reikšmių vietos žymekliai; struktūra yra dalis, kurią verta kopijuoti. Jei faile jau yra *nat dalis, pridėkite taisyklę į tą dalį, o ne atidarykite antrą, nes formatas tikisi vieno COMMIT lentelei, o dvi dalys tai pačiai lentelei yra taisymas, laukiantis įvykio. Išsaugokite platinimo grandinių apibrėžimus nepaliestus, įskaitant tuos, kuriuos tiekėjas pridėjo savo integracijai. UFW sistemos vadove aprašomi failai before, user ir after kartu su atitinkamo COMMIT reikalavimu.

Jei failas pasirodo tuščias, nepildykite jo iš mokymo. Patvirtinkite, kuris paketas jį valdo ir kokia iš tikrųjų yra veikianti politika, nes tuščias nuolatinis failas neįrodo, kad branduolyje nėra taisyklių, o įkeltas taisyklių rinkinys neįrodo, kad kitą kartą įkeliant bus pilnas failas skaitymui. Pirmiausia atkurkite palaikomą bazinę liniją, tada iš naujo pritaikykite svetainės pakeitimus.

Išbandykite kandidatą jo netaikydami

Atkūrimo įrankis gali išanalizuoti ir sukonstruoti taisyklių rinkinį jo netaikydamas, ir tai pigiausias galimas testas. Paleiskite jį apsaugotoje kopijoje, o ne veikiančiame faile, ir skaitykite klaidos tekstą, o ne vien išėjimo būseną. Analizės klaida nurodo eilutę ir dažniausiai lentelę, o tai daugiau, nei pasakys nepavykęs įkėlimas.

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

Šio patikrinimo praėjimas įrodo, kad dokumentas analizuojamas, ir nieko daugiau. Jis neįrodo, kad kandidatas vis dar turi kiekvieną grandinę, nuo kurios priklauso UFW, kad leidžia tik numatytus šaltinius arba kad nuotolinis administravimas lieka pasiekiamas. Tai atskiri vertinimai, o paskutinis nusipelno antros sesijos, atidaromos prieš pradedant.

Pasirinkite įrankį, atitinkantį įdiegtą backend ir adresų šeimą. Hostas, paleidžiantis nft backend per suderinamumo sluoksnį, turi atitinkamą komandą, o IPv6 taisyklės gyvena visiškai kitame faile.

Laikykite persiuntimą, NAT ir prieigos politiką atskirai

Šaltinio vertimas išsprendžia adresavimo problemą ir nieko neduoda. Persiuntimas yra atskiras leidimas, valdomas sysctl ir filtro lentelės, ir būtent jį žmonės pamiršta, kai tunelis maršrutizuoja, bet nepraleidžia srauto. Prieigos politika yra trečias sprendimas apie tai, kurie šaltiniai gali pasiekti kurias paslaugas, ir jokia NAT taisyklė to neišreiškia. Būtent šių trijų atskyrimas daro gedimą diagnozuojamą, o ne vieną neaiškų simptomą.

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

Skaitykite šiuos tris išvestis kartu, o ne po vieną. Masquerade taisyklė su išjungtu persiuntimu sukuria klientą, kuris prisijungia ir nieko nepasiekia, o tai iš kliento pusės atrodo lygiai kaip maršrutizavimo gedimas ir nukreipia žmones į netinkamą failą. Filtro lentelė taip pat yra vieta, kur slepiasi per platus accept, todėl ten būdami patikrinkite jos numatytąją politiką.

Patikrinkite įkėlimą, atmetimą ir VPN praradimą

Trys stebėjimai sudaro išsamų priėmimo testą: įkėlimas pavyksta, leidžiama kliento operacija veikia, o užklausa, kuri turėtų būti atmesta, iš tikrųjų atmetama. Trečiasis yra tas, kuris praleidžiamas, ir tai vienintelis įrodymas, kad politika apskritai ką nors daro.

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

Tada išbandykite gedimą, kuriam projektavote. Numeskite tunelį ir stebėkite, ką daro hostas, nes politika, kuri veikia tik kol VPN įjungtas, yra politika su neįvardyta priklausomybe. Po to įkelkite dar kartą, kad įrodytumėte, jog veikiantį rezultatą duoda failas, o ne kokia likusi veikimo būsena.

IPv4 NAT nieko nesako apie IPv6, todėl nurodykite numatomą aprėptį abiem šeimoms tame pačiame įraše kaip ir taisyklę. Tikslas yra nuosekli valdoma politika, o fragmentas, kuris atsitiktinai išanalizuotas, nėra to įrodymas.