Portu-birbidalketa NAT atzean dagoen WireGuard peer batera: DNAT gehi SNAT

Nabigatzaile batek https://203.0.113.10:8443 eskatzen du, proxyak konexioa onartzen du eta WireGuard peer-eko zerbitzuak ez du inoiz erantzuten. DNAT arauak bere lana egiten du; erantzuna da huts egiten duen zatia. Jarraitu paketea bi itzulpenetan zehar eta falta den araua begibistakoa bihurtzen da. Konponketa hook egokian NAT adierazpen bat gehiago da, ez tunel berri bat.

Jarraitu eskaera bat hasieratik amaierara

Eskaera proxyaren interfaze publikora iristen da, iturburuan bezeroaren helbide publikoa eta helmugan proxyaren helbidea dituela. nat PREROUTING-en DNAT arauak helmuga peer-aren tunel helbidera berridazten du, 10.90.0.2. Gero bideratze-erabakiak paketea wg0 bidez bidaltzen du eta birbidaltze-bidea osatuta geratzen da.

Peer-ean paketeak jatorrizko iturburu-helbide publikoa darama orain, ezerk berridatzi ez duelako. Zerbitzuak konexioa onartzen du eta bere erantzuna bere gateway lehenetsira bidaltzen du, hau da, peer-aren aurrean dagoen etxeko routerra. Router horrek inoiz ikusi ez duen fluxu baterako egoerarik ez du eta paketea bota edo bere helbide publikora itzultzen du, bezeroak onartuko ez duena.

Asimetria da arazo osoa: eskaera proxyaren bidez doa eta erantzuna zuzenean joaten saiatzen da. Proxyaren konexio-jarraipenak bakarrik laguntzen du erantzuna proxyaren bidez itzultzen bada, eta ezin da hara itzuli iturburu-helbideak jatorrizko bezeroa seinalatzen duen bitartean.

Gehitu itzulera-itzulpena

Berridatzi birbidalitako fluxuaren iturburua proxyaren tunel helbidera, peer-era joan aurretik. Orduan zerbitzuak 10.90.0.1-era erantzuten du, proxyak jasotzen du eta konexio-jarraipenak bi itzulpenak alderantzikatzen ditu paketea bezerora itzuli aurretik.

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

POSTROUTING araua nahita estu da: itzulitako helmugarekin eta tunelaren interfazearekin bat dator, beraz ez du wg0 bidez kasualitatez irteten den erlaziorik gabeko trafikoa berridazten. Masquerade arau zabal batek bezeroaren helbidea ere ezkutatuko luke, baina fluxu bakoitzerako egingo luke eta NAT taula ikuskatzea zailagoa litzateke.

Jarri arauak tunela dagoen tokian

Tunelaren helbideari edo interfazeari erreferentzia egiten dioten arauek wg-quick-ek konfiguratu ondoren exekutatu behar dute. Interfazea PreUp aurretik sortzen da, baina helbideak, MTU, DNS eta ibilbideak geroago aplikatzen dira, eta PostUp dena hor egon ondoren exekutatzen da. Jarri gehikuntzak PostUp-en eta ezabaketak PreDown-en.

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

Ezabaketek gehikuntzekin tokenz token bat etorri behar dute, multiport eta interfazearen bat-etortzeak barne. Bat-etortze batean desberdintzen den ezabaketa batek ez du ezer kentzen, eta hurrengo berrerakusketak arauaren bigarren kopia gehitzen du. Berrerakusketa batzuen ondoren taulak konfigurazio-lerro bati egotzi zailak diren bikoiztuak ditu.

Egiaztatu emaitza iptables -t nat -S erabiliz berrerakusketaren ondoren. Arau bera birritan agertzen bada, PreDown lerroa ez dator bat eta garbiketa isilki huts egiten du.

Birbidalketa, iragazketa eta beste NAT

Gaitu IPv4 birbidalketa modu iraunkorrean, eta gero baimendu birbidalitako fluxua iragazki-taulan. DNAT FORWARD katearen aurretik gertatzen da, beraz iragazki-araua itzulitako helmugarekin bat dator, ez helbide publikoarekin. UFW-k firewall-a kudeatzen badu, adierazi baimena ibilbide-arau gisa; host arau soil batek ez du birbidalitako trafikoa estaltzen.

Beste bi NAT geruzak bidea hautsi dezakete proxyaren arauak zuzenak izan arren. Etxeko konexioan helbide publikoa routerrarena da, eta haren firewall-ean portua irekitzea ez da berdin portu-birbidalketa sarrera bat sortzea, portu hori proxyari bidaltzen diona. Kanpotik irekita dirudien baina ezerk erantzuten ez duen portu batek askotan ez du mapaketa hori hain zuzen.

NAT VPS batean hornitzaileak portu publiko bat helbide pribatu batera mapatzen du. Mapaketak iragartzen duzun portuarekin bat etorri behar du, eta desadostasunak tunel hautsia bezalakoa dirudi. Berretsi hornitzailearen mapaketa WireGuard konfigurazioa aldatu aurretik.

Egiaztatu itzulera-bidea eta onartu kostua

Konektatu proxyaren LAN-a ez den sare batetik, eta gero aztertu itzulpen-parea konexioa irekita dagoen bitartean:

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

conntrack sarrerak jatorrizko tuplea, itzulitako tuplea eta erantzunaren norabidea erakutsi beharko lituzke. Erantzuna falta bada, peer-a ez da tunelaren bidez bidaltzen ari, eta horrek normalean esan nahi du SNAT araua ez zela aplikatu edo peer-aren firewall propioak fluxua baztertu zuela.

Berrabiarazi behin PostUp-ek arauak berriro aplikatzen dituela frogatzeko, gero gelditu tunela eta berretsi PreDown-ek kendu zituela. Deskonexio bat gainditzen duten arau hilak dira geroagoko aldaketa bat modu aurreikusezinean joka dezan arrazoia.

Azkenik, onartu SNAT-ek duen kostua. Zerbitzuak eskaera bakoitza proxyatik datorrela ikusten du, beraz sarbide-erregistroek, bezero bakoitzeko tasa-mugek eta baimendutako helbide-zerrendek ez dituzte erabiltzaileak bereizten jada. Hairpin kasuak bere iturburu-itzulpena behar du proxyaren LAN-ean dauden bezeroentzat. Peer-ak benetako bezero-helbideak behar baditu, alternatiba bezero-sarearekiko itzulera-ibilbidea da, lan gehiago baina informazioa gordetzen duena.