Prefix hostitele ve WireGuardu: proč jedna adresa funguje a ostatní ne

Tunel je nahoře, handshake probíhá každé dvě minuty a přesně jedna adresa na druhé straně odpovídá. Pingy na tunelovou adresu peera fungují; nic za ní ne. Někdo si přečte konfiguraci rozhraní, uvidí prefix hostitele a usoudí, že maska je špatná. Rozšíření na /24 ping na chvíli opraví a pak rozbije něco jiného. Prefix nikdy nebyl příčinou a chybějící trasa není ta, kterou maska ovládá.

Co prefix rozhraní skutečně vytváří

V Linuxu přiřazení adresy rozhraní vytvoří připojenou trasu pro tento prefix. Přiřadíte-li prefix hostitele, připojená trasa pokrývá jednu adresu. Přiřadíte-li /24, pokrývá 256 a každá z nich je nyní považována za dosažitelnou přes toto spojení.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Prefix hostitele je pro tunel typu bod-bod zcela normální volba, protože na druhém konci je přesně jeden peer. Třetí příkaz je ten, který odpovídá na uživatelovu otázku: říká, které rozhraní by jádro pro tento cíl použilo, a neukáže nic užitečného, pokud neodpovídá žádná trasa.

To je celé vysvětlení symptomu. Jedna adresa odpovídá proto, že pro ni existuje připojená trasa, nebo proto, že seznam povolených peera ji náhodou obsahuje. Vše ostatní nemá trasu a je zahozeno dřív, než se WireGuard vůbec zapojí. Tunel je po celou dobu zdravý, a proto počítadlo handshake vypadá dál uklidňujícím dojmem.

AllowedIPs jsou dvě pravidla pod jedním jménem

Seznam povolených pro každého peera ve WireGuardu dělá dvě věci najednou a syntaxe konfigurace je nechává vypadat jako jednu. Na vstupu povoluje, které zdrojové adresy smí peer předložit. Na výstupu vybírá, kterému peerovi se paket pošle, a to nalezením nejkonkrétnější shody.

Ani jedna z těch věcí není routing. Jádro stále musí rozhodnout, že paket patří na tunelové rozhraní, dřív než se na něj WireGuard podívá, a toto rozhodnutí pochází z routovací tabulky. Záznam peera se širokým seznamem povolených sám o sobě trasu nenainstaluje.

Proto může konfigurace vypadat úplně a chovat se asymetricky. Klient posílá na druhou stranu, protože existuje trasa, a odpovědi nikdy nedorazí, protože seznam povolených druhé strany nepovoluje zdroj klienta, nebo protože druhá strana nemá zpáteční cestu. Oba směry jsou samostatná rozhodnutí se samostatnými režimy selhání. Zapsat, který z nich testujete, je polovina diagnózy.

Odkud trasa pochází

Pokud používáte wg-quick, trasy se za vás generují ze seznamu povolených každého peera, pokud jste nenastavili Table = off a nepřevzali kontrolu sami. To je chování, které nástroj dokumentuje, a je to důvod, proč konfigurace bez explicitních direktiv tras přesto funguje.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Porovnejte seznam povolených s trasami, které skutečně existují. Peer, který povoluje celou podsíť, ale vytvořil jen trasu hostitele, znamená, že pomocník nikdy neběžel, nebo že rozhraní spravujete přímo pomocí wg a ip, a v tom případě vám nic trasy negeneruje.

Když ho spravujete ručně, trasa je jeden řádek a její tvar je explicitní: cíl přes rozhraní, bez brány, protože spojení je bod-bod. Přidat ji není berlička za špatný prefix; je to chybějící polovina návrhu, který se rozhodl routing řídit sám.

Širší prefix záznam peera nepřidá

Lákavá oprava je změnit adresu na /24, aby připojená trasa pokryla LAN serveru. Vypadá to, že to funguje, a důvod, proč to vypadá, že funguje, je ten, že připojená trasa teď odpovídá, nikoli že by se WireGuard něco nového naučil.

Co jste také udělali, je nárokování celého rozsahu jako přímo dosažitelného přes toto spojení, včetně adres, které patří jiným peerům nebo LAN, která je ve skutečnosti za serverem. Provoz na tyto adresy teď vstupuje do tunelu, a zda vyjde na druhé straně, závisí na routingu a seznamech povolených samotného serveru.

Kryptografická stránka není nijak dotčena. WireGuard stále potřebuje záznam v seznamu povolených, který pokrývá cíl, aby vybral peera, a druhá strana stále potřebuje záznam, který pokrývá váš zdroj, aby ho přijala. Širší prefix rozhraní nemůže dodat ani jedno.

Potvrďte oba směry, než cokoli změníte

Zpracujte oba konce odděleně a zapište, co každý říká. Na klientovi trasa a záznam peera; na serveru zrcadlový obraz plus jeho vlastní zpáteční cesta:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Zachycení je to, co rozhoduje spory o směr. Pokud se odchozí pakety objeví na tunelovém rozhraní a server nic neloguje, vzdálený konec je odmítá, obvykle proto, že váš zdroj je mimo jeho seznam povolených. Pokud se neobjeví vůbec nic, trasa chybí nebo ukazuje jinam.

Pak opravte užší konec. Záznam v seznamu povolených na straně serveru pro adresu vašeho klienta a záznam na straně klienta pro cílovou podsíť je normální tvar a ponechává prefix rozhraní na pokoji. Prefix rozšiřujte jen tehdy, pokud adresní plán opravdu chce sdílenou podsíť na tomto spojení, a udělejte to jako změnu plánu, ne jako krok ladění.