Saan napupunta ang NAT ng VPN sa before.rules ng UFW at paano ito subukan

Ang tuntuning NAT na gumagana kapag itina-type sa shell ay nabigo kapag ipinaste sa before.rules, dahil ang file na iyon ay hindi script. Ito ay dokumento sa format ng pag-restore na may mga seksyon ng talahanayan, mga deklarasyon ng chain at markang COMMIT para sa bawat talahanayan. Ang linyang nasa maling lugar ay alinman sa inaabort ang buong pag-restore o tahimik na itinatapon ang mga tuntuning inaakala mong nandoon. Inilalagay ng pamamaraan sa ibaba ang fragment kung saan ito inaasahan ng framework at pinatutunayan ang resulta bago ang susunod na reload.

Ang utos sa shell ay hindi file sa pag-restore

Ang linyang nagsisimula sa iptables -t nat ay utos sa binary ng iptables, samantalang ang file na binabasa ng UFW ay paglalarawan ng kumpletong set ng mga tuntunin. Hindi kosmetiko ang pagkakaiba: kailangang malaman ng format ng pag-restore kung aling talahanayan ito naroroon, aling mga chain ang umiiral at saan nagtatapos ang talahanayan. Ang utos na ipinaste sa dokumentong iyon ay alinman sa syntax error o, mas malala, tuntuning nakakabit sa maling talahanayan. Inilo-load ng framework ang mga file na ito sa pamamagitan ng mga tool sa pag-restore dahil eksaktong deklaratibo ang mga ito at hindi sunud-sunod.

Ang dokumento ay ini-load din bilang isang buo, kaya ang isang sirang seksyon ay maaaring pumigil sa pag-apply ng natitirang bahagi ng file. Kaya't ang maliit na pagkakamali sa isang fragment ng NAT ay naghihila rin ng mga tuntunin sa pag-filter, at ganoon nagiging outage ang pagbabago sa firewall.

Ilagay ang fragment sa loob ng umiiral na seksyon ng talahanayan

May hugis ang fragment ng NAT, at ang hugis ay mas mahalaga kaysa sa teksto ng tuntunin sa loob nito. Binubuksan ng header ng talahanayan ang seksyon, itinatag ng mga deklarasyon ng chain ang mga counter, sumusunod ang mga tuntunin, at isinasara ng COMMIT ang seksyon.

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

Ang pool at interface sa itaas ay mga placeholder para sa iyong sariling mga halaga; ang istruktura ang bahaging sulit kopyahin. Kung mayroon nang seksyong *nat ang file, idagdag ang tuntunin sa loob ng seksyong iyon sa halip na magbukas ng pangalawa, dahil isang COMMIT bawat talahanayan ang inaasahan ng format at ang dalawang seksyon para sa parehong talahanayan ay pag-aayos na naghihintay mangyari. Panatilihing buo ang mga depinisyon ng chain ng distribution, kasama ang idinagdag ng vendor para sa sarili nitong integrasyon. Dinodokumento ng manwal ng framework ng UFW ang mga file na before, user at after kasama ang pangangailangan ng tugmang COMMIT.

Kung ang file ay lumabas na walang laman, huwag itong punuin mula sa tutorial. Tiyakin kung aling package ang nagmamay-ari nito at ano talaga ang aktibong patakaran, dahil ang walang lamang persistenteng file ay hindi nagpapatunay na walang tuntunin ang kernel, at ang na-load na set ng tuntunin ay hindi nagpapatunay na ang susunod na reload ay may kumpletong file na babasahin. Ibalik muna ang sinusuportahang baseline at pagkatapos ay muling i-apply ang mga pagbabago sa site sa ibabaw nito.

Subukan ang kandidato nang hindi ito ina-apply

Maaaring i-parse at buuin ng tool sa pag-restore ang isang set ng tuntunin nang hindi ito ina-apply, at ito ang pinakamurang test na magagamit. Patakbuhin ito laban sa protektadong kopya sa halip na sa live na file, at basahin ang teksto ng error hindi lamang ang exit status. Ang kabiguan sa pag-parse ay nagpapangalan ng linya at karaniwang talahanayan, na higit pa sa sasabihin sa iyo ng nabigong reload.

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

Ang pagpasa sa pagsusuring iyon ay nagpapatunay na ang dokumento ay na-parse at wala nang iba. Hindi nito pinatutunayan na ang kandidato ay naglalaman pa rin ng bawat chain na umaasa ang UFW, na pinapayagan lamang ang mga source na nilayon mo, o na ang remote administration ay nananatiling maabot. Ito ay magkakahiwalay na pagsusuri, at ang huli ay karapat-dapat sa pangalawang session na bubuksan bago ka magsimula.

Piliin ang tool na tumutugma sa naka-install na backend at sa pamilya ng address. Ang host na nagpapatakbo ng nft backend sa pamamagitan ng compatibility layer ay nangangailangan ng katumbas na utos, at ang mga tuntunin sa IPv6 ay naninirahan sa ganap na ibang file.

Ihiwalay ang forwarding, NAT at access policy

Ang pagsasalin ng source ay lumulutas ng problema sa addressing at wala itong ibinibigay na anuman. Ang forwarding ay hiwalay na pahintulot na kontrolado ng sysctl at ng filter table, at ito ang nakakalimutan ng mga tao kapag nag-route ang tunnel pero walang trafikong dumadaan. Ang access policy ay ikatlong desisyon tungkol sa kung aling mga source ang makakaabot sa aling mga serbisyo, at walang tuntuning NAT ang nagpapahayag nito. Ang paghihiwalay ng tatlo ang siyang gumagawa sa kabiguan na ma-diagnose sa halip na isang malabong sintomas.

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

Basahin ang tatlong output na iyon nang sabay, hindi isa-isa. Ang tuntuning masquerade na patay ang forwarding ay gumagawa ng client na kumokonekta at walang naaabot, na mula sa panig ng client ay mukhang eksaktong fault sa routing at nagpapadala ng mga tao sa maling file. Ang filter table din ang lugar kung saan nagtatago ang masyadong malawak na accept, kaya tingnan ang default na patakaran nito habang nandoon ka.

I-verify ang reload, pagtanggi at pagkawala ng VPN

Tatlong obserbasyon ang bumubuo ng kumpletong acceptance test: nagtagumpay ang reload, gumagana ang pinahintulutang operasyon ng client, at ang kahilingang dapat tanggihan ay talagang tinatanggihan. Ang pangatlo ang madalas laktawan, at ito ang tanging ebidensiyang may ginagawa ang patakaran.

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

Pagkatapos subukan ang kabiguang dinisenyo mo. Ibagsak ang tunnel at obserbahan ang ginagawa ng host, dahil ang patakarang gumagana lamang habang bukas ang VPN ay patakarang may hindi sinasabing dependency. Mag-reload muli pagkatapos upang patunayang ang file, at hindi ang natirang running state, ang gumagawa ng gumaganang resulta.

Walang sinasabi ang NAT ng IPv4 tungkol sa IPv6, kaya sabihin ang inilaan na saklaw para sa parehong pamilya sa parehong tala ng tuntunin. Ang layunin ay isang magkakaugnay na pinamamahalaang patakaran, at ang fragment na nagkataong na-parse ay hindi ebidensiya nito.