Så bygger du ett WireGuard-test med två peers som bevisar en enda väg

Ett WireGuard-test som bär en standardrutt, ett LAN-prefix, DNS och ett brandväggsundantag kan inte säga vilken av dem som gick sönder. Skala ner det till två peers, ett adresspar och en tillåten tjänst, och felet har ingenstans att gömma sig. Den tråkiga baslinjen är diagnosen. Bygg den först; den tar femton minuter och sparar eftermiddagen du annars skulle lägga på att gissa.

Det baslinjen bevisar är snävare än de flesta förväntar sig. Den bevisar att två identiteter är överens, att UDP når den lyssnande porten och att en tillåten destination bär en begäran. Vidarebefordran, NAT, LAN-rutter och DNS är separata funktioner som läggs till efteråt, en i taget.

Nycklar, adresser och den enda endpointen

Generera ett nyckelpar på varje system och flytta bara de offentliga halvorna mellan dem. wg genkey | tee privatekey | wg pubkey > publickey är den dokumenterade enradaren, och den lämnar den privata nyckeln i en fil som du sedan kan skydda. Välj tunneladresser från ett intervall som inte förekommer i någon annan konfiguration du äger, till exempel 10.99.0.1/24 och 10.99.0.2/24. Skriv ner vilken adress som hör till vilken maskin, eftersom varje senare kontroll beror på den kopplingen.

Privata nycklar reser aldrig. Om ett test behöver en kopierad till andra sidan har testet redan gått fel. När de två systemen sitter bakom NAT behöver minst en en nåbar UDP-port medan den andra bär en Endpoint som pekar på den, och den offentliga adressen och porten hör hemma i dina anteckningar, inte i dina antaganden om 51820.

En portvidarebefordran som mappar en annan extern port fungerar bra så länge Endpoint stämmer med den. Avvikelser här ger tystnad i stället för fel, och därför är det värt att kontrollera dem på papper innan du felsöker på kabeln.

Fälten som hör till wg och de som inte gör det

Kärnfälten är få: PrivateKey och ListenPort under Interface, PublicKey, AllowedIPs och Endpoint under Peer. Address och DNS hör till wg-quick och inte till wg självt, och den skillnaden biter i samma stund som samma konfiguration flyttas till ett annat verktyg.

[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 har två jobb samtidigt. Det väljer vilka destinationer som går in i tunneln, och det auktoriserar peeren att använda de källadresserna vid ankomst. Därför måste spegelposten på andra sidan namnge din tunneladress exakt; en /32 för fel peer läses som ett routingproblem och beter sig som ett auktorisationsproblem. WireGuard-snabbstart visar samma tvåpeersform med den kanoniska formuleringen om du vill jämföra fältnamn.

Läsa handskakningen i stället för ikonen

Ta upp gränssnittet genom det som äger det och läs sedan tillstånd i stället för en statuslampa. wg show skriver ut den senaste handskakningen per peer tillsammans med byträknare, och en handskakning inom de senaste minuterna betyder att nycklar, endpoint och UDP-väg alla fungerar. En räknare som bara stiger i en riktning är sitt eget svar, och det är inte samma fel som en handskakning som aldrig sker.

De två felen kräver olika undersökningar. Ingen handskakning alls pekar på nyckelavvikelse, fel Endpoint, blockerad UDP eller en brandvägg som släpper själva handskakningen. En handskakning som lyckas medan data inte kommer någonstans pekar på AllowedIPs, en tjänst som inte lyssnar på tunneladressen eller en värdbrandvägg som accepterar porten för LAN men inte för tunnelgränssnittet. Det är olika halvor av systemet, och baslinjen skiljer dem innan du börjar ändra regler.

Bevisa en tillåten tjänst, sedan det motsatta

Skicka en begäran till den andra peerns tunneladress på en tjänst som ska svara, och välj något bättre än ping. Ett saknat ICMP-svar kan vara värdsk filtrering och inte ett tunnelfel, så en tyst ping bevisar ingen av riktningarna. En TCP-anslutning till en port du vet är öppen, eller en begäran som returnerar data, ger dig ett svar du kan tolka.

Kör den motsatta riktningen som ett eget test med eget resultat, eftersom de två riktningarna har separata brandväggs- och AllowedIPs-poster och kan misslyckas oberoende av varandra. Om handskakningen fungerar och begäran inte gör det, sitter problemet i datavägen och inte i tunneln: AllowedIPs, den lyssnande tjänsten eller en värdbrandvägg. Fixa det innan du lägger till vidarebefordran, NAT eller DNS, annars lägger du eftermiddagen på att felsöka en funktion som aldrig var skyldig.

Att hålla baslinjen som referens

Spara den fungerande topologin och profilkällan på en plats du kan återställa från, och håll dem utanför varje katalog som synkroniseras till en offentlig tjänst. Lägg sedan till en funktion i taget och upprepa den ursprungliga begäran efter varje: vidarebefordran, NAT, en LAN-rutt och först därefter DNS. Varje tillägg som bryter testet är nu identifierbart, eftersom ingenting annat rörde sig.

En baslinje som bara gör en ikon grön har inte sagt dig något om vilket tillägg som orsakade nästa fel. Håll den enda tillåtna vägen igång som referens, och varje senare ändring mäts mot den.