Handshake WireGuardu funguje, ale kancelářská podsíť neodpovídá

Handshake se dokončí, wg show hlásí nedávný přenos a tunelová adresa serveru odpovídá na ping. Host v LAN serveru však ne. Tři podmínky musí platit současně: klient musí směrovat prefix LAN do tunelu, server musí přeposílat pakety a odpověď potřebuje cestu zpět. Když jedna ze tří chybí, příznak je stejný.

AllowedIPs je seznam přístupu i směrovací tabulka

Na klientovi seznam AllowedIPs rozhoduje jak o tom, co se smí poslat tomuto peeru, tak o tom, které trasy WireGuard nainstaluje. Záznam peeru, který uvádí jen tunelovou adresu serveru, nainstaluje jednu trasu k hostu, takže cíle v LAN se do tunelu nikdy nedostanou. Přidání prefixu LAN je první věc k ověření a také změna, která po zkopírované konfiguraci nejčastěji chybí. Peer rozšířený na výchozí trasu je jiný návrh a přesune i internetový provoz klienta.

Držte trasu k hostu a prefix LAN jako samostatné záznamy. Pokud má kancelář dvě podsítě, obě patří do seznamu, a chybějící druhý prefix vytváří selhání, které vypadá selektivně, nikoli úplně.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Přesměrování a překlad patří na server

Server potřebuje zapnuté přesměrování IP, pravidlo přesměrování, které přijímá provoz přicházející z tunelu, a pravidlo překladu směrem k jeho rozhraní LAN. Právě překlad umožňuje, aby návrh fungoval bez zásahu do každého hostu v kancelářské síti. Odpovědi se pak vracejí na server, nikoli na adresu, o které LAN nikdy neslyšela. Bez toho každý host potřebuje trasu do podsítě tunelu a pravidlo firewallu, které ji povolí, což je v síti, kterou spravuje někdo jiný, málokdy přijatelné.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Pravidla přidaná ručně po restartu zmizí, proto je přivažte k rozhraní pomocí hook příkazů v konfiguraci serveru. Sada pravidel, která přežije své rozhraní, je způsob, jak stroj skončí překládáním provozu pro tunel, který už neexistuje.

Když se LAN přestěhovala a pravidlo ne

Výměna routeru, která přečísluje kancelářskou podsíť, je klasickou verzí tohoto selhání. Tunel zůstává zapnutý, handshake zůstává čerstvý a nic za serverem neodpovídá, protože pravidlo překladu stále uvádí starou adresu. Instalační skripty často zapekají adresu LAN serveru do pravidla POSTROUTING a po přečíslování tato adresa neexistuje na žádném rozhraní. Pakety se pak přepisují na cíl, který nemůže odpovědět.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Porovnejte oba výstupy. Cíl překladu, který se v seznamu rozhraní neobjevuje, je chyba, a její oprava je změna na jeden řádek, jakmile ji uvidíte. Pravidlo může žít ve vygenerované unitě, nikoli v konfiguraci WireGuardu, proto po úpravě tuto unitu znovu načtěte a ověřte, že příští start vaši změnu nepřepíše.

Dvě lokality za NAT potřebují místo, kde se setkat

Když ani jedna strana nepřijímá příchozí spojení, praktickou odpovědí je malý host s veřejnou adresou a dvěma rozhraními WireGuardu. Každá lokalita se připojuje ven, prostřední host uvádí LAN každého peeru ve svém AllowedIPs, a přesměrování přenáší pakety mezi oběma tunely. Na firewallu žádné z lokalit se nic měnit nemusí, a proto se tento návrh snadno šíří.

Směrování mezi lokalitami zachovává původní zdrojové adresy, a tím zachovává smysl protokolování po hostech. Překlad na prostředním hostu je jednodušší, když se obě LAN překrývají, ale za cenu ztráty identity zdroje v záznamech. Rozhodněte, která vlastnost je důležitá, než si vyberete.

Oddělte vrstvy čtyřmi kontrolami

Provádějte jednu kontrolu na vrstvu, místo abyste měnili tři věci a doufali. První ukazuje stáří handshake a počítadla pro každý peer. Druhá ukazuje, zda klient skutečně směruje tento cíl do tunelu. Třetí a čtvrtá říkají, zda požadavek dorazil a zda ho nějaká politika po doručení zahodila.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

Požadavek, který dorazí a nevyvolá odpověď, ukazuje na cestu odpovědi nebo na host v LAN. Požadavek, který nedorazí vůbec, ukazuje na AllowedIPs nebo na trasu klienta. Tyto dva výsledky vyžadují různé opravy a zachycení je to, co je rozliší.