Slik byggjer du ein WireGuard-test med to peers som beviser éin veg

Ein WireGuard-test som ber ei standardrute, eit LAN-prefiks, DNS og eit unntak i brannmuren kan ikkje fortelje deg kva av dei som vart øydelagd. Skrell han ned til to peers, eitt adressepar og éin tillaten teneste, og feilen har ingen stad å gøyme seg. Den keisame basisen er diagnosen. Bygg han fyrst; han tek femten minutt og sparar ettermiddagen du elles ville brukt på gjetting.

Det basisen beviser er smalare enn folk flest ventar. Han beviser at to identitetar er samde, at UDP når den lyttande porten, og at éin tillaten destinasjon ber ein førespurnad. Videresending, NAT, LAN-ruter og DNS er separate funksjonar som vert lagde til etterpå, éin om gongen.

Nøklar, adresser og det eine endepunktet

Generer eit nøkkelpar på kvart system og flytt berre dei offentlege halvdelane mellom dei. wg genkey | tee privatekey | wg pubkey > publickey er den dokumenterte éinlinjaren, og han let den private nøkkelen liggje i ei fil du deretter kan verne. Vel tunneladresser frå eit område som ikkje førekjem i nokon annan konfigurasjon du eig, til dømes 10.99.0.1/24 og 10.99.0.2/24. Skriv ned kva adresse som høyrer til kva maskin, fordi kvar seinare sjekk avheng av den koplinga.

Private nøklar reiser aldri. Treng ein test ein kopi til den andre sida, har testen allereie gått gale. Der dei to systema sit bak NAT, treng minst eitt ein tilgjengeleg UDP-port medan det andre ber ein Endpoint som peikar på han, og den offentlege adressa og porten høyrer heime i notata dine, ikkje i antakingane dine om 51820.

Ei portvideresending som mappar ein annan ekstern port fungerer fint så lenge Endpoint samsvarar med han. Uoverensstemmingar her gir stille i staden for feil, og difor er det verdt å sjekke dei på papiret før du feilsøkjer på leidningen.

Felta som høyrer til wg, og dei som ikkje gjer det

Kjernesettet med felt er lite: PrivateKey og ListenPort under Interface, PublicKey, AllowedIPs og Endpoint under Peer. Address og DNS høyrer til wg-quick og ikkje til wg sjølv, og den skilnaden bit i det augneblinken den same konfigurasjonen flyttar til eit anna 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 jobbar samstundes. Det vel kva destinasjonar som går inn i tunnelen, og det autoriserer peeren til å bruke desse kjeldeadressene ved ankomst. Difor må spegeloppføringa på den andre sida nemne tunneladressa di nøyaktig; ein /32 for feil peer vert lesen som eit ruteproblem og oppfører seg som eit autorisasjonsproblem. WireGuard-snøggstart viser same topunktsform med den kanoniske ordlyden om du vil samanlikne feltnamn.

Les handtrykket i staden for ikonet

Ta grensesnittet opp gjennom det som eig det, og les deretter tilstand i staden for ei statuslampe. wg show skriv ut det siste handtrykket per peer saman med bytteteljarar, og eit handtrykk i løpet av dei siste minutta tyder at nøklar, endepunkt og UDP-veg alle verkar. Ein teljar som berre stig i éi retning er sitt eige svar, og det er ikkje same feil som eit handtrykk som aldri skjer.

Dei to feila krev ulike undersøkingar. Ikkje noko handtrykk i det heile peikar på nøkkelavvik, ein feil Endpoint, blokkert UDP eller ein brannmur som droppar sjølve handtrykket. Eit handtrykk som lukkast medan data ikkje kjem nokon stad, peikar på AllowedIPs, ei teneste som ikkje lyttar på tunneladressa, eller ein vertsbrannmur som godtek porten for LAN, men ikkje for tunellgrensesnittet. Det er ulike halvdelar av systemet, og basisen skil dei før du byrjar å endre reglar.

Bevis éi tillaten teneste, deretter det motsette

Send ein førespurnad til tunneladressa til den andre peeren på ei teneste som skal svare, og vel noko betre enn ping. Eit manglande ICMP-svar kan vere vertsfiltrering og ikkje ein tunellfeil, så ein stille ping beviser ingen av retningane. Ei TCP-tilkopling til ein port du veit er open, eller ein førespurnad som returnerer data, gir deg eit svar du kan tolke.

Køyr den motsette retninga som ein eigen test med sitt eige resultat, fordi dei to retningane har separate brannmur- og AllowedIPs-oppføringar og kan feile uavhengig. Viss handtrykket verkar og førespurnaden ikkje, ligg problemet i datastien og ikkje i tunnelen: AllowedIPs, den lyttande tenesta eller ein vertsbrannmur. Fiks det før du legg til videresending, NAT eller DNS, elles brukar du ettermiddagen på å feilsøkje ein funksjon som aldri var skulda.

Å halde basisen som referanse

Lagre den fungerande topologien og profilkjelda ein stad du kan gjenopprette frå, og hald dei utanfor kvar mappe som synkroniserer til ei offentleg teneste. Legg deretter til éin funksjon om gongen, og gjenta den opphavlege førespurnaden etter kvar: videresending, NAT, ei LAN-rute og fyrst deretter DNS. Kvar tilføying som bryt testen er no identifiserbar, fordi ingenting anna flytta seg.

Ein basis som berre gjer eit ikon grønt har ikkje fortalt deg noko om kva tilføying som førte til neste feil. Hald den eine tillatne vegen i drift som referanse, og kvar seinare endring vert målt mot han.