Přesměrování portu na peer WireGuard za NAT: DNAT plus SNAT

DNAT doručí požadavek, ale odpověď vychází ze špatné adresy. Přidejte odpovídající pravidlo SNAT a obě umístěte po konfiguraci tunelu.

Prohlížeč žádá https://203.0.113.10:8443, proxy připojení přijme a služba na peeru WireGuard nikdy neodpoví. Pravidlo DNAT dělá svou práci; selhává část s odpovědí. Projděte paket oběma překlady a chybějící pravidlo bude zřejmé. Oprava je jeden další příkaz NAT ve správném hooku, ne nový tunel.

Sledujte jeden požadavek od začátku do konce

Požadavek dorazí na veřejné rozhraní proxy, se zdrojovou veřejnou adresou klienta a cílovou adresou proxy. V nat PREROUTING pravidlo DNAT přepíše cíl na adresu tunelu peeru, 10.90.0.2. Směrovací rozhodnutí pak pošle paket ven přes wg0 a cesta přesměrování je hotová.

Na peeru paket nyní nese původní veřejnou zdrojovou adresu, protože ji nic nepřepsalo. Služba připojení přijme a odešle odpověď na svou výchozí bránu, kterou je domácí router před peerem. Ten router nemá stav pro tok, který nikdy neviděl, a buď paket zahodí, nebo ho přeloží na svou vlastní veřejnou adresu, což klient nepřijme.

Asymetrie je celý problém: požadavek jde přes proxy a odpověď se snaží jít přímo. Sledování spojení na proxy pomůže jen tehdy, když se odpověď vrací přes proxy, a tam se vrátit nemůže, dokud zdrojová adresa stále ukazuje na původního klienta.

Přidejte zpětný překlad

Přepište zdroj přesměrovaného toku na adresu tunelu proxy, než odejde k peeru. Služba pak odpoví na 10.90.0.1, proxy to přijme a sledování spojení obrátí oba překlady, než se paket vrátí klientovi.

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

Pravidlo POSTROUTING je záměrně úzké: odpovídá přeloženému cíli a rozhraní tunelu, takže nepřepisuje nesouvisející provoz, který náhodou odchází přes wg0. Široké pravidlo masquerade by také skrylo adresu klienta, ale udělalo by to pro každý tok a ztížilo audit tabulky NAT.

Umístěte pravidla tam, kde tunel existuje

Pravidla odkazující na adresu nebo rozhraní tunelu musí běžet poté, co ho wg-quick nakonfiguruje. Rozhraní se vytvoří před PreUp, ale adresy, MTU, DNS a trasy se aplikují až potom a PostUp běží, když je vše na místě. Přidání dejte do PostUp a mazání do 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

Mazání musí odpovídat přidáním token po tokenu, včetně shod multiport a rozhraní. Mazání, které se liší v jedné shodě, nic neodstraní a další opětovné připojení přidá druhou kopii pravidla. Po několika opětovných připojeních obsahuje tabulka duplikáty, které lze jen těžko připsat řádku konfigurace.

Výsledek zkontrolujte pomocí iptables -t nat -S po opětovném připojení. Pokud se stejné pravidlo objeví dvakrát, řádek PreDown neodpovídá a úklid tiše selhává.

Přesměrování, filtrování a ten druhý NAT

Trvale zapněte přesměrování IPv4 a poté povolte přesměrovaný tok v tabulce filtru. DNAT probíhá před řetězcem FORWARD, takže pravidlo filtru odpovídá přeloženému cíli, nikoli veřejné adrese. Pokud firewall spravuje UFW, vyjádřete povolení jako pravidlo trasy; běžné pravidlo hostitele přesměrovaný provoz nepokryje.

Dvě další vrstvy NAT mohou cestu stále zlomit, i když jsou pravidla proxy správná. U domácího připojení patří veřejná adresa routeru a otevření portu v jeho firewallu není totéž jako vytvoření záznamu přesměrování portu, který ten port pošle na proxy. Port, který zvenku vypadá otevřeně, zatímco nic neodpovídá, často přesně toto mapování postrádá.

Na NAT VPS poskytovatel mapuje veřejný port na privátní adresu. Mapování musí odpovídat portu, který inzerujete, a nesoulad vypadá stejně jako rozbitý tunel. Před změnou konfigurace WireGuard potvrďte mapování u poskytovatele.

Ověřte zpětnou cestu a přijměte cenu

Připojte se ze sítě, která není LAN proxy, a poté prozkoumejte dvojici překladů, dokud je spojení otevřené:

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

Záznam conntrack by měl ukazovat původní tuple, přeložený tuple a směr odpovědi. Pokud odpověď chybí, peer neposílá přes tunel, což obvykle znamená, že se pravidlo SNAT neuplatnilo nebo že vlastní firewall peeru tok zahodil.

Jednou restartujte, abyste dokázali, že PostUp znovu aplikuje pravidla, poté tunel zastavte a potvrďte, že je PreDown odstranil. Mrtvá pravidla, která přežijí odpojení, jsou důvodem, proč se pozdější změna chová nepředvídatelně.

Nakonec přijměte, co SNAT stojí. Služba vidí každý požadavek jako přicházející z proxy, takže přístupové logy, limity rychlosti na klienta a seznamy povolených adres už uživatele nerozlišují. Případ hairpin potřebuje vlastní překlad zdroje pro klienty v LAN proxy. Pokud peer potřebuje skutečné adresy klientů, alternativou je zpětná trasa do klientské sítě, což je více práce, ale zachovává informaci.

Související články