Ako postaviť test WireGuardu s dvoma peermi, ktorý preukáže jednu cestu

Test WireGuardu, ktorý nesie predvolenú trasu, prefix LAN, DNS a výnimku vo firewalle, vám nepovie, ktorá z toho sa pokazila. Zredukujte ho na dva peery, jednu dvojicu adries a jednu povolenú službu a porucha sa nemá kam schovať. Nudný základ je diagnostika. Postavte ho prvý; zaberie pätnásť minút a ušetrí popoludnie, ktoré by ste inak strávili hádaním.

Čo základ preukazuje, je užšie, než väčšina ľudí čaká. Preukazuje, že sa dve identity zhodujú, že UDP dorazí na naslúchajúci port a že jedna povolená destinácia nesie požiadavku. Forwarding, NAT, trasy LAN a DNS sú samostatné funkcie, ktoré sa pridávajú neskôr, jedna po druhej.

Kľúče, adresy a jediný endpoint

Vygenerujte pár kľúčov na každom systéme a preneste medzi nimi len verejné polovice. wg genkey | tee privatekey | wg pubkey > publickey je dokumentovaný jednořádkový príkaz a necháva súkromný kľúč v súbore, ktorý potom môžete chrániť. Vyberte adresy tunela z rozsahu, ktorý sa nevyskytuje v žiadnej inej vašej konfigurácii, napríklad 10.99.0.1/24 a 10.99.0.2/24. Zapíšte, ktorá adresa patrí ktorému stroju, pretože každá ďalšia kontrola závisí od tohto mapovania.

Súkromné kľúče nikdy necestujú. Ak test potrebuje jeden skopírovať na druhú stranu, test už išiel zle. Keď sú oba systémy za NAT, aspoň jeden potrebuje dostupný UDP port, zatiaľ čo druhý nesie Endpoint, ktorý naň ukazuje, a verejná adresa a port patria do vašich poznámok, nie do vašich predpokladov o 51820.

Presmerovanie portu, ktoré mapuje iný externý port, funguje dobre, kým mu Endpoint zodpovedá. Nezhody tu vytvárajú ticho namiesto chýb, a preto je stojí za to skontrolovať ich na papieri, než začnete ladiť na drôte.

Polia, ktoré patria wg, a tie, ktoré nie

Základná sada polí je malá: PrivateKey a ListenPort pod Interface, PublicKey, AllowedIPs a Endpoint pod Peer. Address a DNS patria wg-quick, nie samotnému wg, a ten rozdiel zahryzne v okamihu, keď sa tá istá konfigurácia presunie do iného nástroja.

[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 plní dve úlohy naraz. Vyberá, ktoré destinácie idú do tunela, a autorizuje peera používať tieto zdrojové adresy pri príchode. Preto musí zrkadlový záznam na druhej strane presne pomenovať adresu vášho tunela; /32 pre nesprávny peer sa číta ako problém smerovania a správa sa ako problém autorizácie. Rýchly štart WireGuardu ukazuje rovnaký tvar s dvoma peermi s kanonickou formuláciou, ak si chcete porovnať názvy polí.

Čítanie handshake namiesto ikony

Zdvihnite rozhranie cez to, čo ho vlastní, potom čítajte stav, nie kontrolku. wg show vypíše posledný handshake pre každý peer spolu s počítadlami bajtov, a handshake v posledných minútach znamená, že kľúče, endpoint aj cesta UDP fungujú. Počítadlo, ktoré rastie len jedným smerom, je samo svojou odpoveďou a nie je rovnakou poruchou ako handshake, ktorý nikdy nenastane.

Dve poruchy naznačujú rôzne vyšetrovania. Úplná absencia handshake ukazuje na nezhodu kľúčov, nesprávny Endpoint, blokovaný UDP alebo firewall, ktorý zahadzuje samotný handshake. Handshake, ktorý uspeje, ale dáta nikam nejdú, ukazuje na AllowedIPs, službu, ktorá nepočúva na adrese tunela, alebo firewall hostiteľa, ktorý prijíma port pre LAN, ale nie pre rozhranie tunela. To sú rôzne polovice systému a základ ich oddeľuje skôr, než začnete meniť pravidlá.

Preukázanie jednej povolenej služby, potom opačný smer

Pošlite požiadavku na adresu tunela druhého peera na službu, ktorá má odpovedať, a vyberte niečo lepšie ako ping. Chýbajúca odpoveď ICMP môže byť filtrovanie hostiteľa, nie porucha tunela, takže tichý ping nepreukazuje ani jeden smer. TCP spojenie na port, o ktorom viete, že je otvorený, alebo požiadavka, ktorá vracia dáta, vám dá odpoveď, ktorú možno interpretovať.

Spustite opačný smer ako samostatný test s vlastným výsledkom, pretože oba smery majú samostatné záznamy firewallu a AllowedIPs a môžu zlyhať nezávisle. Ak handshake funguje a požiadavka nie, problém je v dátovej ceste, nie v tuneli: AllowedIPs, naslúchajúca služba alebo firewall hostiteľa. Opravte to predtým, než pridáte forwarding, NAT alebo DNS, inak strávite popoludnie ladením funkcie, ktorá nikdy nebola vinná.

Udržanie základu ako referencie

Uložte fungujúcu topológiu a zdroj profilu na miesto, odkiaľ ju môžete obnoviť, a držte ich mimo každého adresára, ktorý sa synchronizuje s verejnou službou. Potom pridávajte jednu funkciu po druhej, po každej zopakujte pôvodnú požiadavku: forwarding, NAT, trasu LAN a až potom DNS. Každý prírastok, ktorý test pokazí, je teraz identifikovateľný, pretože sa nič iné nepohlo.

Základ, ktorý len rozsvieti ikonu zeleno, vám nepovedal nič o tom, ktorý prírastok spôsobil ďalšiu poruchu. Držte jedinú povolenú cestu funkčnú ako referenciu a každá ďalšia zmena sa meria proti nej.