Kie VPN-NAT iras en before.rules de UFW kaj kiel testi ĝin

NAT-regulo kiu funkcias kiam entajpita en ŝelon malsukcesas kiam algluita en before.rules, ĉar tiu dosiero ne estas skripto. Ĝi estas dokumento en restaŭra formato kun tabelaj sekcioj, ĉendeklaroj kaj COMMIT-markilo por ĉiu tabelo. Linio en malĝusta loko aŭ abortigas la tutan restaŭron aŭ silentas pri forĵeto de reguloj kiujn vi kredis ekzistantaj. La gvidilo sube metas la fragmenton tien, kie la kadro atendas ĝin, kaj pruvas la rezulton antaŭ la sekva reŝargo.

Ŝela komando ne estas restaŭra dosiero

Linio komenciĝanta per iptables -t nat estas instrukcio al la iptables-binaraĵo, dum la dosiero, kiun UFW legas, estas priskribo de kompleta regularo. La diferenco ne estas kosmetika: la restaŭra formato devas scii, en kiu tabelo ĝi estas, kiuj ĉenoj ekzistas kaj kie la tabelo finiĝas. Komando algluita en tiun dokumenton estas aŭ sintaksa eraro aŭ, pli malbone, regulo alkroĉita al la malĝusta tabelo. La kadro ŝargas tiujn dosierojn per restaŭraj iloj ĝuste ĉar ili estas deklarivaj, ne sinsekvaj.

La dokumento ankaŭ ŝargiĝas kiel tuto, do unu misformita sekcio povas haltigi la aplikadon de la resto de la dosiero. Malgranda eraro en NAT-fragmento do trenas kun si ankaŭ la filtrajn regulojn, kaj tiel fajroŝirmila ŝanĝo fariĝas efektiviga interrompo.

Metu la fragmenton ene de la ekzistanta tabela sekcio

NAT-fragmento havas formon, kaj la formo gravas pli ol la regulteksto ene de ĝi. La tabela kapo malfermas la sekcion, ĉendeklaroj starigas la nombrilojn, la reguloj sekvas, kaj COMMIT fermas la sekcion.

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

La naĝejo kaj interfaco supre estas anstataŭigiloj por viaj propraj; la strukturo estas la parto inda je kopiado. Se la dosiero jam enhavas sekcion *nat, aldonu la regulon ene de tiu sekcio anstataŭ malfermi duan, ĉar la formato atendas unu COMMIT por tabelo kaj du sekcioj por la sama tabelo estas riparo atendanta okazi. Konservu la ĉendefinojn de la distribuo sendifekte, inkluzive de tiuj, kiujn la vendisto aldonis por sia propra integriĝo. La manlibro pri la kadro UFW dokumentas la dosierojn before, user kaj after kune kun la postulo de kongrua COMMIT.

Se la dosiero montriĝos malplena, ne plenigu ĝin el lernilo. Konfirmu, kiu pakaĵo posedas ĝin kaj kia estas la aktiva politiko fakte, ĉar malplena persista dosiero ne pruvas, ke la kerno tenas neniujn regulojn, kaj ŝargita regularo ne pruvas, ke la sekva reŝargo havos kompletan dosieron por legi. Unue restarigu la subtenatan bazlinion, poste reaplikigu la retejajn ŝanĝojn sur ĝin.

Testu la kandidaton sen apliki ĝin

La restaŭra ilo povas analizi kaj konstrui regularon sen apliki ĝin, kio estas la plej malmultekosta disponebla testado. Rulu ĝin sur protektita kopio anstataŭ la aktiva dosiero, kaj legu la erartekston anstataŭ nur la elirstaton. Analiza malsukceso nomas linion kaj kutime tabelon, kio estas pli ol malsukcesa reŝargo diros al vi.

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

Pasi tiun kontrolon pruvas, ke la dokumento analiziĝas kaj nenion alian. Ĝi ne pruvas, ke la kandidato ankoraŭ enhavas ĉiun ĉenon, de kiu UFW dependas, ke ĝi permesas nur la fontojn, kiujn vi celis, aŭ ke fora administrado restas atingebla. Tiuj estas apartaj revizioj, kaj la lasta meritas duan seancon malfermitan antaŭ ol vi komencos.

Elektu la ilon kongruan al la instalita malantaŭaĵo kaj adresa familio. Gastiganto, kiu rulas la nft-malantaŭaĵon tra la kongrueca tavolo, bezonas la respondan komandon, kaj IPv6-reguloj loĝas en tute alia dosiero.

Tenu plusendadon, NAT kaj alirpolitikon aparte

Fonta tradukado solvas adresan problemon kaj donas nenion. Plusendado estas aparta permeso regata de sysctl kaj de la filtra tabelo, kaj ĝi estas tiu, kiun homoj forgesas kiam tunelo enkursigas sed pasigas neniun trafikon. Alirpolitiko estas tria decido pri tio, kiuj fontoj povas atingi kiujn servojn, kaj neniu NAT-regulo esprimas ĝin. Tenu la tri aparte — tio igas fiaskon diagnozebla anstataŭ unu malpreciza simptomo.

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

Legu tiujn tri eligojn kune anstataŭ unu post unu. Masquerade-regulo kun malŝaltita plusendado produktas klienton, kiu konektiĝas kaj atingas nenion, kio de la klienta flanko aspektas ĝuste kiel enkursiga fuŝo kaj sendas homojn al la malĝusta dosiero. La filtra tabelo ankaŭ estas kie tro larĝa accept kaŝiĝas, do kontrolu ĝian defaŭltan politikon dum vi tie estas.

Kontrolu reŝargon, rifuzon kaj perdon de VPN

Tri observoj faras kompletan akceptan testadon: la reŝargo sukcesas, permesita klienta operacio funkcias, kaj peto, kiu devus esti rifuzita, efektive rifuziĝas. La tria estas tiu, kiu preteratentiĝas, kaj ĝi estas la sola pruvo, ke la politiko faras ion ajn.

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

Poste testu la fiaskon, por kiu vi dizajnis. Faligu la tunelon kaj observu, kion faras la gastiganto, ĉar politiko, kiu funkcias nur dum la VPN estas ŝaltita, estas politiko kun nedeklarita dependeco. Reŝargu ankoraŭfoje poste por pruvi, ke la dosiero, ne ia restanta rulstato, produktas la funkciantan rezulton.

IPv4-NAT diras nenion pri IPv6, do deklaru la celatan kovradon por ambaŭ familioj en la sama noto kiel la regulo. Kohera administrata politiko estas la celo, kaj fragmento, kiu hazarde analiziĝis, ne estas pruvo pri ĝi.