Dva peerové WireGuardu sdílejí rozsah: kdo dostane paket
Překrývající se rozsahy se řeší nejkonkrétnějším prefixem, ne pořadím. Nejdřív zkontrolujte trasu, potom seznam peerů, než cokoli rozšíříte.
Dva peerové uvádějí rozsahy, které se dotýkají, a provoz dorazí k tomu špatnému. Nic není poškozeno: WireGuard vybírá peer porovnáním cíle s nakonfigurovanými rozsahy a vyhrává nejkonkrétnější shoda. Než cokoli rozšíříte, rozhodněte, který peer má vlastnit který prefix.
Nejdelší prefix vyhrává uvnitř WireGuardu
Každý záznam peeru nese sadu cílových prefixů. Když je paket směrován do rozhraní, implementace hledá záznam s nejkonkrétnějším odpovídajícím prefixem — stejné pravidlo, jaké uplatňuje směrovací tabulka. Proto /24 poráží /16, který ho obsahuje, a užší peer dostane provoz.
Sestavy road-warrior to používají záměrně. Jeden peer vlastní široký rozsah pro lokalitu a jednotliví hostitelé se vyčleňují záznamy /32, které patří jiným peerům. Vzor funguje proto, že vyčlenění jsou konkrétnější, ne kvůli pořadí.
Zapište vlastnictví jako tabulku prefixu a peeru. Pokud dva záznamy popisují stejný prefix, konfigurace už nevyjadřuje záměr, ale závod.
Operační systém vybírá nejdřív rozhraní
WireGuard vybírá pouze mezi peery na jednom rozhraní. Které rozhraní paket dostane, se rozhoduje dřív, směrovací tabulkou hostitele, a druhá výchozí trasa nebo zastaralá trasa může poslat provoz někam, kde ho seznam peerů nikdy nevidí. Proto může být diagnóza na úrovni peeru správná a přesto nevysvětlovat selhání. Zkontrolujte trasu k cíli dřív, než začnete číst konfiguraci peeru, protože trasa ukazující na fyzické rozhraní celou otázku obchází.
Nástroj obvykle instaluje tyto trasy z rozsahů peerů, což znamená, že změna v seznamu jednoho peeru může tiše přesměrovat provoz, který dřív patřil jinému. Úprava peeru je tedy změna směrování v převleku. Prohlédněte obojí najednou, jinak jedno opravíte a druhé rozbijete.
Příchozí pakety se kontrolují podle zdroje
Seznam rozsahů plní dvojí úlohu. Pro odchozí provoz vybírá peer podle cíle a pro příchozí provoz autorizuje zdrojovou adresu. Paket přicházející z adresy mimo rozsahy daného peeru se zahodí dřív, než ho uvidí jakýkoli firewall.
Tuto asymetrii snadno přehlédnete, když čtete jednu stranu konfigurace. Peer, který dosáhne na podsíť, tím není oprávněn odesílat z této podsítě, a oba směry vynucují různé kontroly.
Úzké vlastnictví zdroje z toho dělá výhodu. Dejte každému peeru /32 pro jeho vlastní adresu a firewall níže má spolehlivý zdroj k porovnání, místo rozsahu pro celou skupinu, který by si mohl nárokovat kterýkoli člen.
Duplicitní rozsahy nejsou failover
Přiřazení stejného prefixu dvěma peerům nevytváří vyrovnávání zátěže ani záložní cestu. Neexistuje kontrola stavu ani afinita relace: vítězný záznam určuje vnitřní pořadí implementace, což není smlouva, na kterou byste měli navrhovat. Pokud potřebujete alternativní východy, vyjádřete je tam, kde je definován výběr. Směrovací politika, metrika nebo dvojice odlišných prefixů s dokumentovaným vlastníkem každého z nich dávají chování, které můžete předvídat a testovat.
Rozšíření rozsahu kvůli opravě nesouvisející poruchy je druhá častá chyba. Odvede provoz od peeru, který fungoval, a nový symptom přichází dřív, než je starý pochopen.
Před úpravou ověřte výběr
Tři příkazy odpovídají na tři otázky v pořadí. První vypíše rozsahy, které každý peer nárokuje. Druhý ukáže, které rozhraní by hostitel použil pro cíl. Třetí ukáže živý stav peerů poté, co provoz protekl.
wg show wg0 allowed-ips ip route get 10.66.8.20 wg show wg0 ip rule show
Spusťte je před změnou a po ní a porovnejte. Pokud se výstup trasy změnil, ale provoz stále dorazí ke špatnému peeru, seznamy prefixů se překrývají způsobem, který jste ještě nezapsali. Pokud se výstup trasy nezměnil, konfigurace peeru nebyla to, na co se dotazovalo.
Zaznamenejte do tiketu cíl, zvolené rozhraní a zvolený peer. Právě tato trojice činí překryv později přezkoumatelným a je mnohem užitečnější než snímek obrazovky konfigurace.