Porta plusendado al WireGuard-peer malantaŭ NAT: DNAT kaj SNAT

Retumilo petas https://203.0.113.10:8443, la prokurilo akceptas la konekton, kaj la servo sur la WireGuard-peer neniam respondas. La regulo DNAT faras sian taskon; la respondo estas la parto, kiu malsukcesas. Sekvu la paketon tra ambaŭ tradukoj kaj la mankanta regulo fariĝas evidenta. La ripeto estas unu plia NAT-deklaro en la ĝusta hoko, ne nova tunelo.

Sekvu unu peton de la komenco ĝis la fino

La peto alvenas sur la publikan interfacon de la prokurilo kun la publika adreso de la kliento kiel fonto kaj la adreso de la prokurilo kiel celo. En nat PREROUTING la regulo DNAT reskribas la celon al la tunela adreso de la peer, 10.90.0.2. Poste la enkursiga decido sendas la paketon eksteren tra wg0, kaj la plusenda vojo kompletiĝas.

Sur la peer la paketo nun portas la originan publikan fontadreson, ĉar nenio reskribis ĝin. La servo akceptas la konekton kaj sendas sian respondon al sia propra implicita enirejo, kiu estas la hejma enkursigilo antaŭ la peer. Tiu enkursigilo havas neniun staton por fluo, kiun ĝi neniam vidis, kaj ĝi aŭ forĵetas la paketon aŭ tradukas ĝin al sia propra publika adreso, kion la kliento ne akceptos.

La nesimetrio estas la tuta problemo: la peto iras tra la prokurilo, kaj la respondo provas iri rekte. La konekta spurado de la prokurilo helpas nur se la respondo revenas tra la prokurilo, kaj ĝi ne povas reveni tien dum la fontadreso ankoraŭ montras al la origina kliento.

Aldonu la returnan tradukon

Reskribu la fonton de la plusendata fluo al la tunela adreso de la prokurilo antaŭ ol ĝi foriros al la peer. La servo tiam respondas al 10.90.0.1, la prokurilo ricevas ĝin, kaj la konekta spurado inversigas ambaŭ tradukojn antaŭ ol la paketo revenos al la kliento.

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

La regulo POSTROUTING estas intence mallarĝa: ĝi kongruas kun la tradukita celo kaj la tunela interfaco, do ĝi ne reskribas senrilatan trafikon, kiu hazarde eliras tra wg0. Vasta masquerade-regulo ankaŭ kaŝus la klientan adreson, sed ĝi farus tion por ĉiu fluo kaj malfaciligus la revizion de la NAT-tabelo.

Metu la regulojn tie, kie la tunelo ekzistas

Reguloj, kiuj referencas la tunelan adreson aŭ interfacon, devas ruliĝi post kiam wg-quick agordis ĝin. La interfaco kreiĝas antaŭ PreUp, sed adresoj, MTU, DNS kaj enkursigoj aplikiĝas poste, kaj PostUp ruliĝas kiam ĉio tio estas en loko. Metu la aldonojn en PostUp kaj la forigojn en 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

La forigoj devas kongrui kun la aldonoj po unu ĵetono, inkluzive de la multiport- kaj interfacaj kongruoj. Forigo, kiu diferencas per unu kongruo, forigas nenion, kaj la sekva rekonekto aldonas duan kopion de la regulo. Post kelkaj rekonektoj la tabelo enhavas duplikatojn, kiujn oni malfacile atribuas al agorda linio.

Kontrolu la rezulton per iptables -t nat -S post rekonekto. Se la sama regulo aperas dufoje, la linio PreDown ne kongruas kaj la purigado silente malsukcesas.

Plusendado, filtrado kaj la alia NAT

Ŝaltu IPv4-plusendadon permanente, poste permesu la plusendatan fluon en la filtra tabelo. DNAT okazas antaŭ la ĉeno FORWARD, do la filtra regulo kongruas kun la tradukita celo anstataŭ kun la publika adreso. Se UFW administras la fajroŝirmilon, esprimu la permeson kiel enkursigan regulon; ordinara gastiga regulo ne kovras plusendatan trafikon.

Du aliaj NAT-tavoloj ankoraŭ povas rompi la vojon eĉ kiam la reguloj de la prokurilo estas ĝustaj. En hejma konekto la publika adreso apartenas al la enkursigilo, kaj malfermi la pordon en ĝia fajroŝirmilo ne samas kiel krei pordplusendan enskribon, kiu sendas tiun pordon al la prokurilo. Pordo, kiu ŝajnas malfermita de ekstere dum nenio respondas, ofte mankas ĝuste tiun mapadon.

Sur NAT-VPS la provizanto mapas publikan pordon al privata adreso. La mapado devas kongrui kun la pordo, kiun vi anoncas, kaj malkongruo aspektas identa al rompita tunelo. Konfirmu la mapadon de la provizanto antaŭ ol ŝanĝi la agordon de WireGuard.

Kontrolu la returnan vojon kaj akceptu la koston

Konektiĝu el reto, kiu ne estas la LAN de la prokurilo, poste ekzamenu la tradukan paron dum la konekto estas malfermita:

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

La conntrack-enskribo devus montri la originan opon, la tradukitan opon kaj la respondon direkton. Se la respondo mankas, la peer ne sendas tra la tunelo, kio kutime signifas, ke la regulo SNAT ne aplikiĝis aŭ ke la propra fajroŝirmilo de la peer forĵetis la fluon.

Restartigu unufoje por pruvi, ke PostUp reaplikas la regulojn, poste haltigu la tunnelon kaj konfirmu, ke PreDown forigis ilin. Mortaj reguloj, kiuj postvivas malkonekton, estas la kialo, ke posta ŝanĝo kondutas neantaŭvideble.

Fine, akceptu, kion kostas SNAT. La servo vidas ĉiun peton kiel venantan de la prokurilo, do alirprotokoloj, rapidlimoj po kliento kaj adresaj permeslistoj ne plu distingas uzantojn. La hairpin-okazo bezonas sian propran fonttradukon por klientoj en la LAN de la prokurilo. Se la peer bezonas verajn klientajn adresojn, la alternativo estas returna enkursigo al la klienta reto, kio estas pli da laboro sed konservas la informon.