Prievado persiuntimas į WireGuard peer už NAT: DNAT ir SNAT
DNAT pristato užklausą, bet atsakymas išeina iš neteisingo adreso. Pridėkite atitinkamą SNAT taisyklę ir abi įdėkite po tunelio konfigūravimo.
Naršyklė prašo https://203.0.113.10:8443, tarpinis serveris priima ryšį, o paslauga WireGuard peer niekada neatsako. DNAT taisyklė atlieka savo darbą; nepavyksta atsakymo dalis. Sekite paketą per abi transformacijas ir trūkstama taisyklė tampa akivaizdi. Pataisa – dar vienas NAT teiginys tinkamame hook, o ne naujas tunelis.
Sekite vieną užklausą nuo pradžios iki pabaigos
Užklausa patenka į viešą tarpinio serverio sąsają, šaltinis – viešas kliento adresas, paskirtis – tarpinio serverio adresas. nat PREROUTING DNAT taisyklė perrašo paskirtį į peer tunelio adresą, 10.90.0.2. Tada maršrutizavimo sprendimas išsiunčia paketą per wg0, ir persiuntimo kelias baigtas.
Peer paketas dabar neša pradinį viešą šaltinio adresą, nes niekas jo neperrašė. Paslauga priima ryšį ir siunčia atsakymą į savo numatytąją šliuzą, kuri yra namų maršrutizatorius prieš peer. Tas maršrutizatorius neturi būsenos srautui, kurio niekada nematė, todėl arba meta paketą, arba išverčia jį į savo viešą adresą, ko klientas nepriims.
Asimetrija yra visa problema: užklausa eina per tarpinį serverį, o atsakymas bando eiti tiesiai. Tarpinio serverio ryšių sekimas padeda tik tada, kai atsakymas grįžta per tarpinį serverį, o grįžti ten negali, kol šaltinio adresas vis dar rodo į pradinį klientą.
Pridėkite grįžtamąją transformaciją
Perrašykite persiunčiamo srauto šaltinį į tarpinio serverio tunelio adresą, kol jis neišvyko pas peer. Tada paslauga atsako į 10.90.0.1, tarpinis serveris tai priima, o ryšių sekimas apverčia abi transformacijas, prieš paketui grįžtant klientui.
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.1POSTROUTING taisyklė sąmoningai siaura: ji atitinka išverstą paskirtį ir tunelio sąsają, todėl neperrašo nesusijusio srauto, kuris atsitiktinai išeina per wg0. Plati masquerade taisyklė taip pat paslėptų kliento adresą, bet tai darytų kiekvienam srautui ir apsunkintų NAT lentelės auditą.
Įdėkite taisykles ten, kur egzistuoja tunelis
Taisyklės, kurios nurodo tunelio adresą ar sąsają, turi veikti po to, kai wg-quick jį sukonfigūruoja. Sąsaja sukuriama prieš PreUp, bet adresai, MTU, DNS ir maršrutai taikomi vėliau, o PostUp paleidžiamas, kai visa tai yra vietoje. Papildymus dėkite į PostUp, o šalinimus – į 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Šalinimai turi atitikti papildymus po vieną žymą, įskaitant multiport ir sąsajos atitikimus. Šalinimas, kuris skiriasi vienu atitikimu, nieko nepašalina, o kitas prisijungimas prideda antrą taisyklės kopiją. Po kelių prisijungimų lentelėje lieka dublikatų, kuriuos sunku priskirti konfigūracijos eilutei.
Patikrinkite rezultatą su iptables -t nat -S po prisijungimo iš naujo. Jei ta pati taisyklė pasirodo du kartus, PreDown eilutė neatitinka ir valymas tyliai nepavyksta.
Persiuntimas, filtravimas ir kitas NAT
Įjunkite IPv4 persiuntimą visam laikui, tada leiskite persiunčiamą srautą filtro lentelėje. DNAT vyksta prieš FORWARD grandinę, todėl filtro taisyklė atitinka išverstą paskirtį, o ne viešą adresą. Jei UFW valdo ugniasienę, išreikškite leidimą kaip maršruto taisyklę; paprasta host taisyklė neapima persiunčiamo srauto.
Dar du NAT sluoksniai vis tiek gali sulaužyti kelią net kai tarpinio serverio taisyklės teisingos. Namų ryšyje viešas adresas priklauso maršrutizatoriui, o prievado atidarymas jo ugniasienėje nėra tas pats, kas prievado persiuntimo įrašo, siunčiančio tą prievadą tarpiniam serveriui, sukūrimas. Prievadas, kuris iš išorės atrodo atidarytas, nors niekas neatsako, dažnai neturi būtent to susiejimo.
NAT VPS teikėjas susieja viešą prievadą su privačiu adresu. Susiejimas turi atitikti skelbiamą prievadą, o neatitikimas atrodo identiškai kaip sugedęs tunelis. Patvirtinkite teikėjo susiejimą prieš keisdami WireGuard konfigūraciją.
Patikrinkite grįžimo kelią ir priimkite kainą
Prisijunkite iš tinklo, kuris nėra tarpinio serverio LAN, tada patikrinkite transformacijų porą, kol ryšys atidarytas:
conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080conntrack įrašas turėtų rodyti pradinį tuple, išverstą tuple ir atsakymo kryptį. Jei atsakymo nėra, peer nesiunčia per tunelį, o tai paprastai reiškia, kad SNAT taisyklė nebuvo pritaikyta arba peer ugniasienė numetė srautą.
Paleiskite iš naujo vieną kartą, kad įrodytumėte, jog PostUp vėl pritaiko taisykles, tada sustabdykite tunelį ir patvirtinkite, kad PreDown jas pašalino. Mirusios taisyklės, išgyvenančios atsijungimą, yra priežastis, kodėl vėlesnis pakeitimas elgiasi nenuspėjamai.
Galiausiai priimkite, kiek kainuoja SNAT. Paslauga kiekvieną užklausą mato kaip ateinančią iš tarpinio serverio, todėl prieigos žurnalai, greičio limitai vienam klientui ir leidžiamų adresų sąrašai nebeatskiria vartotojų. Hairpin atvejis reikalauja savo šaltinio transformacijos klientams tarpinio serverio LAN. Jei peer reikia tikrų kliento adresų, alternatyva yra grįžimo maršrutas į kliento tinklą, tai daugiau darbo, bet išsaugo informaciją.