Përcjellje porti drejt një peer WireGuard pas NAT: DNAT plus SNAT

Një shfletues kërkon https://203.0.113.10:8443, proxy-ja e pranon lidhjen dhe shërbimi në peer-in WireGuard nuk përgjigjet kurrë. Rregulli DNAT bën punën e vet; pjesa që dështon është përgjigjja. Ndiqni paketën nëpër të dy përkthimet dhe rregulli që mungon bëhet i qartë. Rregullimi është një deklaratë tjetër NAT në hook-un e duhur, jo një tunel i ri.

Ndiqni një kërkesë nga fillimi në fund

Kërkesa arrin në ndërfaqen publike të proxy-s, me adresën publike të klientit si burim dhe adresën e proxy-s si destinacion. Në nat PREROUTING rregulli DNAT rishkruan destinacionin në adresën e tunelit të peer-it, 10.90.0.2. Më pas vendimi i rrugëtimit e dërgon paketën jashtë përmes wg0 dhe rruga e përcjelljes plotësohet.

Në peer paketa tani mbart adresën publike origjinale të burimit, sepse asgjë nuk e ka rishkruar atë. Shërbimi e pranon lidhjen dhe e dërgon përgjigjjen te porta e vet e parazgjedhur, që është ruteri i shtëpisë përpara peer-it. Ai ruter nuk ka gjendje për një rrjedhë që nuk e ka parë kurrë dhe ose e hedh paketën ose e përkthen në adresën e vet publike, gjë që klienti nuk do ta pranojë.

Asimetria është e gjithë problemi: kërkesa kalon përmes proxy-s dhe përgjigjja përpiqet të shkojë drejtpërdrejt. Ndjekja e lidhjeve e proxy-s ndihmon vetëm nëse përgjigjja kthehet përmes proxy-s, dhe nuk mund të kthehet atje sa kohë adresa e burimit vazhdon të tregojë klientin origjinal.

Shtoni përkthimin e kthimit

Rishkruani burimin e rrjedhës së përcjellë në adresën e tunelit të proxy-s përpara se të niset drejt peer-it. Më pas shërbimi përgjigjet në 10.90.0.1, proxy-ja e merr atë dhe ndjekja e lidhjeve i kthen të dy përkthimet përpara se paketa të kthehet te klienti.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Rregulli POSTROUTING është qëllimisht i ngushtë: përputhet me destinacionin e përkthyer dhe me ndërfaqen e tunelit, kështu që nuk rishkruan trafik të palidhur që ndodh të dalë përmes wg0. Një rregull masquerade i gjerë do të fshihte gjithashtu adresën e klientit, por do ta bënte për çdo rrjedhë dhe do ta vështirësonte auditimin e tabelës NAT.

Vendosni rregullat atje ku ekziston tuneli

Rregullat që i referohen adresës ose ndërfaqes së tunelit duhet të ekzekutohen pasi wg-quick ta ketë konfiguruar atë. Ndërfaqja krijohet përpara PreUp, por adresat, MTU, DNS dhe rrugët zbatohen më pas, dhe PostUp ekzekutohet kur të gjitha këto janë në vend. Shtesat i vendosni në PostUp dhe fshirjet në PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Fshirjet duhet të përputhen me shtesat token për token, duke përfshirë përputhjet multiport dhe të ndërfaqes. Një fshirje që ndryshon në një përputhje nuk heq asgjë, dhe rilidhja tjetër shton një kopje të dytë të rregullit. Pas disa rilidhjeve tabela përmban dublikata që është e vështirë t'u atribuohen një rreshti konfigurimi.

Kontrolloni rezultatin me iptables -t nat -S pas një rilidhjeje. Nëse i njëjti rregull shfaqet dy herë, rreshti PreDown nuk përputhet dhe pastrimi dështon në heshtje.

Përcjellje, filtrim dhe NAT-i tjetër

Aktivizoni përcjelljen IPv4 përgjithmonë, më pas lejoni rrjedhën e përcjellë në tabelën e filtrit. DNAT ndodh përpara zinxhirit FORWARD, kështu që rregulli i filtrit përputhet me destinacionin e përkthyer dhe jo me adresën publike. Nëse UFW e administron firewall-in, shprehni lejen si rregull rrugëtimi; një rregull i thjeshtë hosti nuk e mbulon trafikun e përcjellë.

Dy shtresa të tjera NAT mund ta prishin rrugën edhe kur rregullat e proxy-s janë të sakta. Në një lidhje shtëpie adresa publike i përket ruterit, dhe hapja e portës në firewall-in e tij nuk është e njëjtë me krijimin e një zëri përcjelljeje porti që e dërgon atë portë te proxy-ja. Një portë që duket e hapur nga jashtë ndërsa asgjë nuk përgjigjet shpesh i mungon pikërisht ajo hartëzim.

Në një VPS me NAT ofruesi harton një portë publike në një adresë private. Hartëzimi duhet të përputhet me portën që njoftoni, dhe një mospërputhje duket njësoj si një tunel i prishur. Konfirmoni hartëzimin e ofruesit përpara se të ndryshoni konfigurimin e WireGuard.

Verifikoni rrugën e kthimit dhe pranoni koston

Lidhuni nga një rrjet që nuk është LAN-i i proxy-s, më pas inspektoni çiftin e përkthimeve ndërsa lidhja është e hapur:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Zëri conntrack duhet të tregojë tuple-in origjinal, tuple-in e përkthyer dhe drejtimin e përgjigjjes. Nëse përgjigjja mungon, peer-i nuk dërgon përmes tunelit, që zakonisht do të thotë se rregulli SNAT nuk u zbatua ose firewall-i i vetë peer-it e hodhi rrjedhën.

Rinisni një herë për të provuar që PostUp i zbaton përsëri rregullat, më pas ndaloni tunelin dhe konfirmoni që PreDown i hoqi ato. Rregullat e vdekura që mbijetojnë një shkëputje janë arsyeja pse një ndryshim i mëvonshëm sillet në mënyrë të paparashikueshme.

Më në fund, pranoni sa kushton SNAT. Shërbimi e sheh çdo kërkesë si që vjen nga proxy-ja, kështu që regjistrat e aksesit, kufijtë e shpejtësisë për klient dhe listat e adresave të lejuara nuk i dallojnë më përdoruesit. Rasti hairpin ka nevojë për përkthimin e vet të burimit për klientët në LAN-in e proxy-s. Nëse peer-it i duhen adresat reale të klientëve, alternativa është një rrugë kthimi drejt rrjetit të klientit, që kërkon më shumë punë por ruan informacionin.