Handshake WireGuardu funguje, ale internet ne: vystopujte paket

Tunel je nahoře, wg show hlásí nedávný handshake, ping na tunelovou adresu serveru projde a nic za ní neodpovídá. První instinkt je přegenerovat klíče nebo znovu nasdílet konfiguraci. Tím se ale mění právě ta část cesty, u které už je prokázáno, že funguje.

Dokončený handshake říká, že se obě strany shodly na klíčích, že UDP dosáhne na koncový bod a že kryptografické směrování paket přijme. Neříká nic o tom, zda paket potom může opustit server.

Sledujte tedy jeden paket místo hádání. Jsou čtyři místa, kde může zemřít, a každé zanechává jinou stopu.

Co handshake skutečně dokazuje

WireGuard je UDP protokol, který naváže relaci pomocí handshake Noise a pak šifruje pakety pro protistranu. Když wg show vypíše handshake starý několik sekund a rostoucí čítač přenosu, koncový bod, klíče i veřejný klíč protistrany jsou v pořádku.

Nedokazuje, že váš klient vůbec posílá internetový provoz do rozhraní, že jej server chce přeposílat nebo že odpověď najde cestu zpět. To jsou rozhodnutí směrování v jádru a firewallu a dělají se mimo tunel.

Proto je ping na tunelovou adresu serveru tak zavádějící test. Ten paket je adresovaný samotnému serveru, takže končí lokálně. Nikdy nepotřebuje forwarding, nikdy nepotřebuje překlad a nikdy nepotřebuje zpáteční trasu z internetu.

AllowedIPs je rozhodnutí o směrování

Na klientovi dělá AllowedIPs dvě věci. Je to kryptoklíčová směrovací tabulka, která rozhoduje, které cílové adresy se posílají do tunelu této protistrany, a je to seznam zdrojových adres, které od vás protistrana přijme. Pokud konfigurace klienta uvádí jen 10.8.0.0/24, veřejné cíle se do rozhraní nikdy nedostanou a vaše běžná výchozí trasa je nese mimo tunel. Tunel pak funguje dokonale a nedělá nic z toho, co jste chtěli.

Podívejte se, co klient skutečně nainstaloval, ne co říká konfigurační soubor:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Druhý příkaz je rozhodující. Pokud odpověď uvádí vaše fyzické rozhraní a běžnou bránu, paket se netuneluje a žádná změna na straně serveru to nespraví. Přidejte 0.0.0.0/0 pro IPv4 a ::/0 pro IPv6 zvlášť; pravidlo, které zachytí vše pro jednu rodinu, nechá druhou na její původní cestě, a to je častá příčina funkčního tunelu IPv4 a zaseknutého vyhledávání IPv6.

Kde paket umírá na bráně

Pokud je trasa správná a paket přesto nikam nejde, dorazí na server a tam se zastaví. Většinu bran pokryjí čtyři kontroly.

Forwarding. sysctl net.ipv4.ip_forward s návratem 0 je klasická odpověď a mnoho distribucí má stále 0 jako výchozí. Musí být 1, a to trvale v souboru sysctl, ne příkazem, který při restartu zmizí. Forwarding IPv6 je samostatný přepínač.

Politika filtrování. Řetěz FORWARD s výchozí politikou dropu zahodí tunelový provoz, zatímco provoz k samotnému hostiteli propustí, což přesně odpovídá symptomu. Čtěte živou sadu pravidel, ne uložený soubor: nft list ruleset nebo iptables -S.

Překlad, nebo směrování. Klienti s privátními tunelovými adresami potřebují buď zdrojový NAT na výstupním rozhraní serveru, nebo směrovaný prefix, který nadřazená síť umí vrátit. Volba mezi nimi vychází z plánu adres. Přidat MASQUERADE do sítě, která váš prefix už směruje zpět, je neškodné, ale zbytečné, a vynechat ho tam, kde žádná trasa neexistuje, nechá odpovědi adresované do nesměrovatelného privátního rozsahu.

Zpáteční cesta. Ve směrovaných návrzích potřebuje nadřazený router trasu ukazující na váš server. Síť poskytovatele to také může blokovat: několik cloudů zapíná na instanci kontrolu zdroje a cíle, která tiše zahazuje pakety, jejichž zdroj není vlastní adresa instance, dokud se tato kontrola nevypne.

DNS selhává jinak než směrování

Paket na známou adresu a vyhledání jména jsou dvě různá selhání a chybové zprávy matou opačnými směry. Pokud ping 1.1.1.1 funguje a prohlížeč nic nenačte, trasa je v pořádku a překlad jmen ne. Pokud selže samotný ping, je DNS irelevantní a vracíte se k předchozí části.

wg-quick umí nastavit resolver z řádku DNS = v konfiguraci a systemd-resolved má své vlastní chování pro každé spojení. VPN, která přepíše resolver adresou dostupnou jen uvnitř tunelu, pokazí každé vyhledání ve chvíli, kdy tunel spadne, což vypadá, jako by tunel rozbíjel internet.

Pořadí, které dává důkazy

Nejprve proveďte kontrolu na straně klienta, protože je to jeden příkaz a vyloučí polovinu možností. Pak ověřte, zda má být server vůbec východem do internetu; brána postavená pro privátní přístup není rozbitá, když veřejné cíle nefungují.

Na serveru sledujte rozhraní, zatímco z klienta posíláte ping: tcpdump -ni wg0 icmp má ukázat požadavek a tcpdump -ni eth0 icmp má ukázat, že odchází, přeložený nebo ne. Pokud se objeví na prvním a nikdy na druhém, zastavení je lokální na serveru. Pokud odejde a nevrátí se žádná odpověď, problém je výš a to je jiná debata.

Nakonec zařiďte, aby oprava přežila restart. Forwarding patří do souboru sysctl, pravidla firewallu do služby, která je načítá, a trasy klienta do konfigurace, která zvedá rozhraní, ne do shellu, který zapomenete. Připojte se znovu, zopakujte stejné dva testy a ověřte, že se čítače hýbou.