Privat nøgle her, offentlig nøgle der: WireGuard-nøgler
Din private nøgle bliver på din enhed; peer-posten holder den anden sides offentlige nøgle. Del kun den offentlige halvdel, og giv hver enhed sin egen identitet.
De fleste håndbyggede WireGuard-fejl bunder i, hvilken nøgle der endte hvor. Interface-afsnittet rummer den private nøgle til den enhed, du konfigurerer, mens et peer-afsnit rummer den offentlige nøgle til maskinen i den anden ende. Bytter man de halvdele, eller indsætter den forkerte, får man et handshake, der aldrig fuldføres, og en log, der aldrig nævner en nøgle. Gå de fire kontroller nedenfor igennem i rækkefølge, før du rører ved AllowedIPs eller DNS.
To nøgler, to retninger
En privat nøgle tilhører præcis én enhed og bliver i den enheds interface-afsnit. Dens offentlige halvdel er det, enhver anden peer skal bruge for at genkende enheden, og værktøjet udleder den i stedet for at opfinde den. På serveren optræder din enheds offentlige nøgle som en peer-post; på din enhed har serverens offentlige nøgle den rolle. Læser man en konfiguration højt i de termer, fanger man de fleste forvekslinger, før de når et handshake.
Kommandoen wg udskriver, hvad det lokale interface faktisk bruger, inklusive begge offentlige nøgler. Det gør den til den hurtigste måde at skelne en konfigurationsfejl fra et forbindelsesproblem:
wg show
wg show interfaces
Det første output lister hver peer med dens offentlige nøgle, det endepunkt den sidst brugte, og alderen på dens seneste handshake. En handshake-alder på aldrig i den ene ende og en ny i den anden peger på en nøgle, som kun den ene ende accepterede. Den anden kommando navngiver de interfaces, du kan undersøge nærmere.
Hvad man deler, og hvad man aldrig deler
En offentlig nøgle er beregnet til at blive givet videre, selv om den stadig identificerer en enhedsrelation, og derfor er det forskelligt at sende den til administratoren, der bad om den, og at offentliggøre den. En privat nøgle forlader aldrig den enhed, der genererede den. En eksporteret profil eller en QR-kode rummer hele konfigurationen inklusive den private nøgle, så ingen af dem er sikre at sende rundt, og at skjule teksten inde i et billede ændrer intet. Foruddelte nøgler er valgfrie og lige så hemmelige, og begge ender skal have samme værdi, ellers stopper handshaket på det trin.
Endnu en sondring er værd at sige ligeud: et endepunkt er en adresse og en port, aldrig en nøgle. Indsætter man en offentlig nøgle i endepunktfeltet, eller en adresse i et nøglefelt, får man en profil, der parses og derefter ikke gør noget. Værktøjet fanger det ikke, for begge felter er bare strenge. WireGuard-hurtigstarten viser generer-og-udled-pipelinen på én linje.
Én enhed, én peer-post
Hvor tjenesten tillader det, bør hver enhed have sin egen peer-identitet. Indsætter man en laptops komplette profil på en telefon, sløres det, hvilken enhed der har den identitet på serveren, og det gør det sværere at tilbagekalde én tabt håndsæt. Hvis en privat nøgle lækker, skal du fjerne den gamle peer-godkendelse på serveren og skaffe en erstatning. Sletter man den lokale fil, fjernes serverens post ikke, og en ny klientnøgle hjælper ingen, før serveren kender dens offentlige halvdel.
Hold koblingen fra enhed til offentlig nøgle ved siden af adresselisten. Den liste er det, der gør en tilbagekaldelse til en opgave på to minutter i stedet for en hel eftermiddag.
Hvad der stadig fejler efter handshaket
Nøglepar identificerer peers; de afgør ikke netværksadfærd. AllowedIPs knytter adresseområder til en peer, og klienten eller opsætningsværktøjet styrer ruterne omkring det. Symptomet siger som regel, hvilket lag der skal åbnes næste gang:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
DNS kan fejle, efter at begge peers er godkendt korrekt, og en applikation kan fejle, mens tunnelen selv er sund, så et fungerende handshake er ikke slutningen på diagnosen. Nøgler siger heller intet om en udbyders logningspraksis eller om et websted genkender din konto, og de spørgsmål hører til andre steder. Gå videre til netværkslagene, når de fire kontroller består, for en manglende nøgle er ikke et skjult ruteproblem.