Slik bygger du en WireGuard-test med to peers som beviser én vei

En WireGuard-test som bærer en standardrute, et LAN-prefiks, DNS og et unntak i brannmuren kan ikke fortelle deg hvilken av dem som ble ødelagt. Skrell den ned til to peers, ett adressepar og én tillatt tjeneste, og feilen har ingen steder å gjemme seg. Den kjedelige baseline er diagnosen. Bygg den først; den tar femten minutter og sparer ettermiddagen du ellers ville brukt på gjetting.

Det baseline beviser er smalere enn folk flest forventer. Den beviser at to identiteter er enige, at UDP når den lyttende porten, og at én tillatt destinasjon bærer en forespørsel. Videresending, NAT, LAN-ruter og DNS er separate funksjoner som legges til etterpå, én om gangen.

Nøkler, adresser og det ene endepunktet

Generer et nøkkelpar på hvert system og flytt bare de offentlige halvdelene mellom dem. wg genkey | tee privatekey | wg pubkey > publickey er den dokumenterte énlinjeren, og den lar den private nøkkelen ligge i en fil du deretter kan beskytte. Velg tunneladresser fra et område som ikke forekommer i noen annen konfigurasjon du eier, for eksempel 10.99.0.1/24 og 10.99.0.2/24. Skriv ned hvilken adresse som hører til hvilken maskin, fordi hver senere sjekk avhenger av den koblingen.

Private nøkler reiser aldri. Hvis en test trenger en kopiert til den andre siden, har testen allerede gått galt. Der de to systemene sitter bak NAT, trenger minst ett en tilgjengelig UDP-port mens det andre bærer et Endpoint som peker på den, og den offentlige adressen og porten hører hjemme i notatene dine, ikke i antakelsene dine om 51820.

En portvideresending som mapper en annen ekstern port fungerer fint så lenge Endpoint samsvarer med den. Uoverensstemmelser her gir stillhet i stedet for feil, og derfor er de verdt å sjekke på papiret før du feilsøker på ledningen.

Feltene som hører til wg, og de som ikke gjør det

Kjernesettet med felt er lite: PrivateKey og ListenPort under Interface, PublicKey, AllowedIPs og Endpoint under Peer. Address og DNS hører til wg-quick og ikke til wg selv, og den forskjellen biter i det øyeblikket den samme konfigurasjonen flyttes til et annet verktøy.

[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 jobber samtidig. Det velger hvilke destinasjoner som går inn i tunnelen, og det autoriserer peeren til å bruke disse kildeadressene ved ankomst. Derfor må speiloppføringen på den andre siden navngi tunneladressen din nøyaktig; en /32 for feil peer leses som et ruteproblem og oppfører seg som et autorisasjonsproblem. WireGuard-hurtigstart viser samme topunktsform med den kanoniske ordlyden hvis du vil sammenligne feltnavn.

Les håndtrykket i stedet for ikonet

Ta grensesnittet opp gjennom det som eier det, og les deretter tilstand i stedet for en statuslampe. wg show skriver ut det siste håndtrykket per peer sammen med byttetellere, og et håndtrykk i løpet av de siste minuttene betyr at nøkler, endepunkt og UDP-vei alle virker. En teller som bare stiger i én retning er sitt eget svar, og det er ikke samme feil som et håndtrykk som aldri skjer.

De to feilene krever ulike undersøkelser. Intet håndtrykk i det hele tatt peker på nøkkelavvik, et feil Endpoint, blokkert UDP eller en brannmur som dropper selve håndtrykket. Et håndtrykk som lykkes mens data ikke kommer noe sted, peker på AllowedIPs, en tjeneste som ikke lytter på tunneladressen, eller en vertsbrannmur som godtar porten for LAN, men ikke for tunellgrensesnittet. Det er ulike halvdeler av systemet, og baseline skiller dem før du begynner å endre regler.

Bevis én tillatt tjeneste, deretter det motsatte

Send en forespørsel til den andre peerens tunneladresse på en tjeneste som skal svare, og velg noe bedre enn ping. Et manglende ICMP-svar kan være vertsfiltrering og ikke en tunnelfeil, så en stille ping beviser ingen av retningene. En TCP-forbindelse til en port du vet er åpen, eller en forespørsel som returnerer data, gir deg et svar du kan tolke.

Kjør den motsatte retningen som en egen test med sitt eget resultat, fordi de to retningene har separate brannmur- og AllowedIPs-oppføringer og kan feile uavhengig. Hvis håndtrykket virker og forespørselen ikke, ligger problemet i datastien og ikke i tunnelen: AllowedIPs, den lyttende tjenesten eller en vertsbrannmur. Fiks det før du legger til videresending, NAT eller DNS, ellers bruker du ettermiddagen på å feilsøke en funksjon som aldri var skylden.

Å holde baseline som referanse

Lagre den fungerende topologien og profilkilden et sted du kan gjenopprette fra, og hold dem utenfor enhver mappe som synkroniseres til en offentlig tjeneste. Legg deretter til én funksjon om gangen, og gjenta den opprinnelige forespørselen etter hver: videresending, NAT, en LAN-rute og først deretter DNS. Hver tilføyelse som bryter testen er nå identifiserbar, fordi ingenting annet flyttet seg.

En baseline som bare gjør et ikon grønt har ikke fortalt deg noe om hvilken tilføyelse som forårsaket neste feil. Hold den ene tillatte veien i drift som referanse, og hver senere endring måles mot den.