Jak postavit test WireGuardu se dvěma peery, který prokáže jednu cestu

Test WireGuardu, který nese výchozí trasu, prefix LAN, DNS a výjimku ve firewallu, vám neřekne, která z toho se rozbila. Zredukujte ho na dva peery, jednu dvojici adres a jednu povolenou službu a porucha se nemá kam schovat. Nudný základ je diagnostika. Postavte ho první; zabere patnáct minut a ušetří odpoledne, které byste jinak strávili hádáním.

Co základ prokazuje, je užší, než většina lidí čeká. Prokazuje, že se dvě identity shodují, že UDP dorazí na naslouchající port a že jedna povolená destinace nese požadavek. Forwarding, NAT, trasy LAN a DNS jsou samostatné funkce, které se přidávají později, jedna po druhé.

Klíče, adresy a jediný endpoint

Vygenerujte pár klíčů na každém systému a přeneste mezi nimi jen veřejné poloviny. wg genkey | tee privatekey | wg pubkey > publickey je dokumentovaný jednořádkový příkaz a nechává soukromý klíč v souboru, který pak můžete chránit. Vyberte adresy tunelu z rozsahu, který se nevyskytuje v žádné jiné vaší konfiguraci, například 10.99.0.1/24 a 10.99.0.2/24. Zapište, která adresa patří kterému stroji, protože každá další kontrola závisí na tomto mapování.

Soukromé klíče nikdy necestují. Pokud test potřebuje jeden zkopírovat na druhou stranu, test už šel špatně. Když jsou oba systémy za NAT, alespoň jeden potřebuje dostupný UDP port, zatímco druhý nese Endpoint, který na něj ukazuje, a veřejná adresa a port patří do vašich poznámek, ne do vašich předpokladů o 51820.

Přesměrování portu, které mapuje jiný externí port, funguje dobře, dokud mu Endpoint odpovídá. Neshody zde vytvářejí ticho místo chyb, a proto je stojí za to zkontrolovat na papíře, než začnete ladit na drátě.

Pole, která patří wg, a ta, která ne

Základní sada polí je malá: PrivateKey a ListenPort pod Interface, PublicKey, AllowedIPs a Endpoint pod Peer. Address a DNS patří wg-quick, ne samotnému wg, a ten rozdíl kousne ve chvíli, kdy se stejná konfigurace přesune do jiného nástroje.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs nese dva úkoly najednou. Vyberá, které destinace jdou do tunelu, a autorizuje peerovi použít tyto zdrojové adresy při příchodu. Proto musí zrcadlový záznam na druhé straně přesně pojmenovat adresu vašeho tunelu; /32 pro špatný peer se čte jako problém směrování a chová se jako problém autorizace. Rychlý start WireGuardu ukazuje stejný tvar se dvěma peery s kanonickou formulací, pokud si chcete porovnat názvy polí.

Čtení handshake místo ikony

Zvedněte rozhraní přes to, co ho vlastní, a potom čtěte stav, ne kontrolku. wg show vypíše poslední handshake pro každý peer spolu s počítači bajtů, a handshake v posledních několika minutách znamená, že klíče, endpoint i UDP cesta fungují. Počítač, který roste jen jedním směrem, je sám svou odpovědí a není to stejná porucha jako handshake, který nikdy nenastane.

Dvě poruchy implikují různá vyšetřování. Úplná absence handshake ukazuje na neshodu klíčů, špatný Endpoint, blokovaný UDP nebo firewall, který zahazuje samotný handshake. Handshake, který uspěje, ale data nikam nejdou, ukazuje na AllowedIPs, službu, která nenaslouchá na adrese tunelu, nebo firewall hostitele, který přijímá port pro LAN, ale ne pro rozhraní tunelu. To jsou různé poloviny systému a základ je odděluje dřív, než začnete měnit pravidla.

Prokázání jedné povolené služby, pak opačný směr

Pošlete požadavek na adresu tunelu druhého peeru na službu, která má odpovídat, a vyberte něco lepšího než ping. Chybějící odpověď ICMP může být filtrování hostitele, ne porucha tunelu, takže tichý ping neprokazuje ani jeden směr. TCP spojení na port, o kterém víte, že je otevřený, nebo požadavek, který vrací data, vám dá odpověď, kterou lze interpretovat.

Spusťte opačný směr jako samostatný test s vlastním výsledkem, protože oba směry mají samostatné záznamy firewallu a AllowedIPs a mohou selhat nezávisle. Pokud handshake funguje a požadavek ne, problém je v datové cestě, ne v tunelu: AllowedIPs, naslouchající služba nebo firewall hostitele. Opravte to dřív, než přidáte forwarding, NAT nebo DNS, jinak strávíte odpoledne laděním funkce, která nikdy nebyla vinna.

Udržení základu jako reference

Uložte fungující topologii a zdroj profilu na místo, odkud je můžete obnovit, a držte je mimo každý adresář, který se synchronizuje s veřejnou službou. Pak přidávejte jednu funkci po druhé a po každé zopakujte původní požadavek: forwarding, NAT, trasu LAN a teprve pak DNS. Každý přírůstek, který test rozbije, je nyní identifikovatelný, protože se nic jiného nepohnulo.

Základ, který jen rozsvítí ikonu zeleně, vám neřekl nic o tom, který přírůstek způsobil další poruchu. Držte jedinou povolenou cestu funkční jako referenci a každá další změna se měří proti ní.