Handshake kører, adresse væk: tre WireGuard-tilstande
Et nyt handshake beviser, at peeren svarede, ikke at interfacet beholder sin adresse, eller at den næste pakke tager den tilsigtede uplink.
WireGuard kan have et friskt handshake og ingen adresse på samme tid, og den tilstand er sammenhængende, ikke modstridende. Handshaket er en peer-hændelse, adressen tilhører interfacet, og ruten afgør, hvilken uplink en pakke forlader via. Tre lag, tre ejere, og hver af dem kan fejle, mens de to andre ser sunde ud.
At læse dem som én status er det, der gør en to minutters diagnose til en hel eftermiddag med genstart af tjenester.
Et handshake er en peer-hændelse, ikke en adresseringshændelse
WireGuards handshake beviser, at den konfigurerede peer svarede med en gyldig nøgle, og at sessionsnøglerne er aktuelle. Det siger intet om den lokale adresse på interfacet og intet om, hvorvidt nogen rute peger derhen. En hjælper eller netværksadministrator tildeler adressen, mens protokolkonfigurationen kun navngiver peers og nøgler. At forveksle de to er, hvordan et sundt handshake læses som en tunnel, der virker.
Derfor kan wg show rapportere et handshake, der er sekunder gammelt, på et interface, der ikke kan tage imod en enkelt pakke fra en applikation.
En administrator, der genskaber interfacet, kan tabe adressen uden at røre peer-konfigurationen, og det næste handshake lykkes med det samme, fordi nøglerne aldrig blev ændret. Loglinjen om et vellykket handshake er korrekt og irrelevant for fejlen.
| Observation | Which layer it belongs to | Wrong conclusion it invites |
|---|---|---|
| Handshake a few seconds old | Peer and keys | The tunnel is usable for application traffic |
Address present on wg0 | Interface configuration | Traffic actually egresses through it |
Route points at wg0 | Forwarding table | The outer packet uses the intended uplink |
Interfaceadressen har sin egen ejer
En adresse på tunneleenheden kan komme fra en hjælpers Address linje, fra en DHCP-klient, der kører på interfacet, eller fra en styringsdaemon, der opretter den ved forbindelse. Uanset hvad ejer den komponent adressen og gendanner den eller ej efter sin egen logik. At læse adressen uden at navngive dens ejer efterlader dig uden forklaring på, hvorfor den forsvandt.
To ejere på ét interface er den klassiske fejl. At starte en hjælper og en skrivebordsnetværksadministrator over den samme enhed skaber et kapløb, hvor den ene fjerner det, den anden netop har konfigureret, og endepunktet bliver ved med at svare hele tiden.
Vælg én ejer, og lad det andet værktøj observere i stedet for at styre. Den beslutning er værd at skrive ned, fordi symptomet dukker op uger senere og ligner et tilfældigt adresstab.
En rute vælger en uplink, ikke interfacet
En indre rute, der peger på wg0, afgør, at trafikken går ind i tunnelen. En separat beslutning sender de krypterede ydre pakker mod peeren, og på en vært med flere uplinks kommer den beslutning fra videresendelsestabellen og politikreglerne. Et Wi-Fi-roaming kan ændre den ydre vej uden at røre den indre adresse.
Så en tunnel, der virker, og en peer, der ikke kan nås, er forenelige tilstande, og det samme er en korrekt peer og en brudt indre rute. De tre observationer skal tages sammen, i samme øjeblik, ellers er sammenligningen meningsløs.
Sammenlign de tre tilstande i ét gennemløb
Tre skrivebeskyttede kommandoer besvarer de tre spørgsmål i den rækkefølge, der isolerer fejlen hurtigst. Kør dem uden at ændre noget imellem.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferDen første viser, om interfacet overhovedet har en adresse, og den anden viser, hvilken enhed en bestemt destination ville bruge lige nu. Den tredje rapporterer tidspunktet for det sidste handshake og bytetællingerne, og den er den eneste af de tre, der beskriver peeren i stedet for den lokale vært.
Læs tællingerne såvel som tidsstemplet. Et handshake, der bliver ved med at forny sig, mens overførslen står stille, betyder, at peeren svarer, men at intet nyttigt går igennem, hvilket peger på routing eller en ACL snarere end på nøgler. Et tidsstempel, der holder op med at flytte sig, mens en adresse er til stede, peger opstrøms i stedet. Begge læsninger kommer fra den samme outputlinje, og ingen af dem er synlige, hvis du kun kontrollerer, at et handshake findes.
Ret den specifikke tilstand, der er forkert, og test derefter applikationen i stedet for tunnelen. Et nyt handshake er peer-bevis, og bevis om peeren er ikke bevis for, at den næste anmodning fra din browser finder en adresse, en rute og en uplink, der virker. wg-quick-manualen er tydelig om, hvilke af disse hjælperen sætter op, og hvilke der hører til protokollen.