Sådan bygger du en WireGuard-test med to peers, der beviser én vej

En WireGuard-test, der bærer en standardrute, et LAN-præfiks, DNS og en undtagelse i firewallen, kan ikke fortælle dig, hvilken af dem der gik i stykker. Skær den ned til to peers, ét adressepar og én tilladt tjeneste, så har fejlen ingen steder at skjule sig. Den kedelige baseline er diagnosen. Byg den først; det tager femten minutter og sparer den eftermiddag, du ellers ville bruge på at gætte.

Det, baselinen beviser, er snævrere, end de fleste forventer. Den beviser, at to identiteter er enige, at UDP når den lyttende port, og at én tilladt destination bærer en anmodning. Videresendelse, NAT, LAN-ruter og DNS er separate funktioner, der tilføjes bagefter, én ad gangen.

Nøgler, adresser og det ene endpoint

Generér et nøglepar på hvert system, og flyt kun de offentlige halvdele mellem dem. wg genkey | tee privatekey | wg pubkey > publickey er den dokumenterede énlinjekommando, og den efterlader den private nøgle i en fil, du derefter kan beskytte. Vælg tunneladresser fra et interval, der ikke optræder i nogen anden konfiguration, du ejer, såsom 10.99.0.1/24 og 10.99.0.2/24. Skriv ned, hvilken adresse der hører til hvilken maskine, fordi hver senere kontrol afhænger af den kobling.

Private nøgler rejser aldrig. Hvis en test har brug for at kopiere en til den anden side, er testen allerede gået galt. Hvor de to systemer sidder bag NAT, har mindst ét brug for en tilgængelig UDP-port, mens det andet bærer et Endpoint, der peger på den, og den offentlige adresse og port hører i dine noter frem for i dine antagelser om 51820.

En portvideresendelse, der mapper en anden ekstern port, fungerer fint, så længe Endpoint matcher den. Uoverensstemmelser her giver stilhed frem for fejl, og derfor er de værd at kontrollere på papiret, før du fejlretter på ledningen.

Felterne, der hører til wg, og dem, der ikke gør

Det grundlæggende feltsæt er lille: PrivateKey og ListenPort under Interface, PublicKey, AllowedIPs og Endpoint under Peer. Address og DNS hører til wg-quick frem for wg selv, og den forskel bider i det øjeblik, den samme konfiguration flytter til et andet værktøj.

[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 to job på én gang. Det vælger, hvilke destinationer der går ind i tunnelen, og det autoriserer peeren til at bruge disse kildeadresser ved ankomst. Derfor skal spejlopføringen på den anden side navngive din tunneladresse præcist; en /32 til den forkerte peer læses som et routingproblem og opfører sig som et autorisationsproblem. WireGuard-hurtigstart viser samme topunktsform med den kanoniske formulering, hvis du vil sammenligne feltnavne.

Læs håndtrykket i stedet for ikonet

Bring grænsefladen op gennem det, der ejer den, og læs derefter tilstand i stedet for en statuslampe. wg show udskriver det seneste håndtryk per peer sammen med byttetællere, og et håndtryk inden for de sidste par minutter betyder, at nøgler, endpoint og UDP-vej alle virker. En tæller, der kun stiger i én retning, er sit eget svar, og det er ikke den samme fejl som et håndtryk, der aldrig sker.

De to fejl kræver forskellige undersøgelser. Intet håndtryk overhovedet peger på uenighed om nøgler, et forkert Endpoint, blokeret UDP eller en firewall, der dropper selve håndtrykket. Et håndtryk, der lykkes, mens data ikke kommer nogen steder, peger på AllowedIPs, en tjeneste, der ikke lytter på tunneladressen, eller en værtsfirewall, der accepterer porten for LAN, men ikke for tunnelgrænsefladen. Det er forskellige halvdele af systemet, og baselinen adskiller dem, før du begynder at ændre regler.

Bevis én tilladt tjeneste, derefter det modsatte

Send en anmodning til den anden peers tunneladresse på en tjeneste, der skal svare, og vælg noget bedre end ping. Et manglende ICMP-svar kan være værtsfiltrering frem for en tunnelfejl, så et tavst ping beviser ingen af retningerne. En TCP-forbindelse til en port, du ved er åben, eller en anmodning, der returnerer data, giver dig et svar, du kan fortolke.

Kør den modsatte retning som en separat test med sit eget resultat, fordi de to retninger har separate firewall- og AllowedIPs-opføringer og kan fejle uafhængigt. Hvis håndtrykket virker, og anmodningen ikke gør, sidder problemet i datastien frem for i tunnelen: AllowedIPs, den lyttende tjeneste eller en værtsfirewall. Ret det, før du tilføjer videresendelse, NAT eller DNS, ellers bruger du eftermiddagen på at fejlrette en funktion, der aldrig var skyld i det.

At holde baselinen som reference

Gem den fungerende topologi og profilkilden et sted, du kan gendanne fra, og hold dem ude af enhver mappe, der synkroniserer til en offentlig tjeneste. Tilføj derefter én funktion ad gangen, og gentag den oprindelige anmodning efter hver: videresendelse, NAT, en LAN-rute og først derefter DNS. Hver tilføjelse, der bryder testen, er nu identificerbar, fordi intet andet flyttede sig.

En baseline, der kun gør et ikon grønt, har ikke fortalt dig noget om, hvilken tilføjelse der forårsagede den næste fejl. Hold den ene tilladte vej kørende som reference, og enhver senere ændring måles imod den.