Peer WireGuardu je nedostupný, zatímco jiný funguje: kontrolní seznam

Jeden peer WireGuardu přenáší provoz a druhý dokončí handshake, ale nikdy se nedostane k ničemu za tunelem. Fungující peer vám říká, že rozhraní, UDP port a klíč serveru jsou pravděpodobně v pořádku. O AllowedIPs druhého peeru, jeho vnitřní zdrojové adrese ani o pravidlech předávání mezi nimi neříká nic. Projděte seznam popořadě a zastavte se u prvního kroku, jehož podmínka selže.

Krok 1: Zapište cestu, kterou má paket projít

Dva klienti na stejném hubu se k sobě automaticky nedostanou. V uspořádání hub a paprsky server přijme paket na wg0 a musí ho předat zpět z wg0 druhému peeru, což vyžaduje IP forwarding a pravidlo předávání. V přímém uspořádání peer proti peeru každá strana potřebuje endpoint té druhé a adresu jejího tunelu uvnitř AllowedIPs. Rozhodněte, které uspořádání ladíte, než začnete číst jakoukoli konfiguraci.

Očekávaná cesta vám také řekne, kam se dívat. Pokud má paket projít hubem, selhávajícím skokem jsou buď AllowedIPs odesílatele, nebo předávání na hubu, nebo AllowedIPs příjemce. Pokud má jít přímo, hub nehraje roli a záleží na polích endpointu u obou peerů.

Krok 2: Porovnejte AllowedIPs na obou stranách, ne jen na jedné

WireGuard používá AllowedIPs zároveň jako směrovací tabulku a jako přístupový seznam. Při odesílání se cílová adresa hledá v AllowedIPs peeru, aby se vybral tunel; při příjmu musí vnitřní zdrojová adresa spadat do AllowedIPs odesílajícího peeru, jinak se paket zahodí. Chybějící rozsah na kterékoli straně dává stejný příznak: transport funguje, užitečné zatížení mizí.

Čtěte živý stav, ne soubor, protože opětovné načtení mohlo tiše selhat: sudo wg show wg0 allowed-ips. Na serveru musí záznam selhávajícího peeru obsahovat adresu jeho tunelu, například 10.90.0.3/32. Na klientu musí záznam peeru serveru obsahovat cíl, který testujete, ať už je to adresa tunelu hubu, nebo vzdálená podsíť. Překrývající se rozsahy činí vyhledávání nejednoznačným a mohou vybrat peer, který jste nezamýšleli, proto je držte oddělené.

Krok 3: Zkontrolujte vnitřní zdrojovou adresu

Klient, který směruje 10.90.0.3 přes wg0, ale posílá pakety ze své Wi-Fi adresy, bude příjemcem odmítnut, protože zdroj neodpovídá AllowedIPs peeru. Ověřte, co jádro skutečně vybírá, pomocí ip route get 10.90.0.3 from 10.90.0.2, a ověřte adresu přiřazenou rozhraní tunelu pomocí ip -brief addr show wg0.

Na přijímajícím hostiteli s Linuxem je filtrování zpětné cesty druhou branou. Striktní rp_filter na rozhraní, které vlastní zpětnou trasu, může zahodit tunelový provoz, jehož zpětná cesta neodpovídá rozhraní, kterým dorazil. Před vypnutím zkontrolujte efektivní hodnotu; v mnoha topologiích je správnou opravou trasa, ne uvolněný filtr.

Krok 4: Prověřte předávání na hubu a zpětnou cestu

Pokud má hub předávat mezi peery, jádro potřebuje net.ipv4.ip_forward=1 a firewall musí přijmout předávaný tok: vstup na wg0, výstup na wg0, od adresy tunelu odesílatele k adrese příjemce. Častou závadou je vstupní pravidlo, které přijímá UDP 51820, ale chybí pravidlo předávání], takže handshake uspěje a užitečné zatížení umře. Vypište platná pravidla pomocí sudo nft list ruleset nebo ekvivalentu pro váš správce firewallu.

Potom zkontrolujte odpověď. Cílový hostitel musí mít trasu zpět k odesílateli, buď přes hub, nebo přes svou vlastní bránu. Pokud hub také provádí NAT pro podsíť tunelu, ověřte, že se překlad vztahuje na předávaný tok a že odpověď dorazí k hubu dřív, než vyprší stav. Jednosměrná závada, která vypadá jako problém s klíčem, je často právě tato zpětná trasa.

Nakonec oddělte handshake od dat. Peer, který dokončí handshake, ale zasekne se u velkých přenosů, má obvykle problém s MTU nebo MSS na právě této cestě, ne problém s AllowedIPs. Testujte nejprve malým pingem, potom pingem plné velikosti a oba peery porovnejte.

Krok 5: Změňte jednu věc a udržte fungující peer netknutý

Proveďte jedinou změnu na selhávající cestě a oba peery znovu otestujte. Nahradit AllowedIPs každého peeru hodnotou 0.0.0.0/0 je nejrychlejší způsob, jak rozbít peer, který už fungoval, protože to mění rozhodnutí o směrování pro veškerý provoz na daném rozhraní. Upravte jeden záznam, znovu načtěte a přečtěte živý stav.

Zaznamenejte, která cesta uspěla, která selhala, a přesný výstup příkazu pro každou z nich. Takové srovnání má větší cenu než obecná zpráva, že je VPN rozbitá, a je to první, na co se příští člověk zeptá.