Handshake oppe, adresse borte: tre WireGuard-tilstander
En fersk handshake beviser at peeren svarte, ikke at grensesnittet beholder adressen sin eller at neste pakke tar den tiltenkte opplenken.
WireGuard kan ha en fersk handshake og ingen adresse samtidig, og den tilstanden er sammenhengende, ikke selvmotsigende. Handshaken er en peer-hendelse, adressen tilhører grensesnittet, og ruten avgjør hvilken opplenke en pakke forlater via. Tre lag, tre eiere, og hver av dem kan feile mens de to andre ser sunne ut.
Å lese dem som én status er det som gjør en to minutters diagnose til en hel ettermiddag med å starte tjenester på nytt.
En handshake er en peer-hendelse, ikke en adresseringshendelse
Handshaken til WireGuard beviser at den konfigurerte peeren svarte med en gyldig nøkkel, og at sesjonsnøklene er aktuelle. Den sier ingenting om den lokale adressen på grensesnittet, og ingenting om hvorvidt noen rute peker dit. En hjelper eller nettverksbehandler tildeler adressen, mens protokollkonfigurasjonen bare navngir peere og nøkler. Å forveksle de to er hvordan en sunn handshake leses som en tunnel som virker.
Derfor kan wg show rapportere en handshake som er sekunder gammel på et grensesnitt som ikke kan ta imot en eneste pakke fra en applikasjon.
En behandler som gjenoppretter grensesnittet kan miste adressen uten å røre peer-konfigurasjonen, og neste handshake lykkes umiddelbart fordi nøklene aldri ble endret. Logglinjen om en vellykket handshake er korrekt og irrelevant for feilen.
| 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 |
Grensesnittadressen har sin egen eier
En adresse på tunnel-enheten kan komme fra en hjelpers Address linje, fra en DHCP-klient som kjører på grensesnittet, eller fra en administrasjonsdaemon som oppretter den ved tilkobling. Uansett hva det er, eier den komponenten adressen og gjenoppretter den eller ikke etter sin egen logikk. Å lese adressen uten å navngi eieren lar deg stå uten forklaring på hvorfor den forsvant.
To eiere på ett grensesnitt er den klassiske feilen. Å starte en hjelper og en skrivebordsnettverksbehandler over samme enhet skaper et kappløp der den ene fjerner det den andre nettopp konfigurerte, og endepunktet fortsetter å svare hele tiden.
Velg én eier og la det andre verktøyet observere i stedet for å administrere. Den beslutningen er verdt å skrive ned, fordi symptomet dukker opp uker senere og ser ut som et tilfeldig adresstap.
En rute velger en opplenke, ikke grensesnittet
En indre rute som peker på wg0 avgjør at trafikken går inn i tunnelen. En separat beslutning sender de krypterte ytre pakkene mot peeren, og på en vert med flere opplenker kommer den beslutningen fra videresendingstabellen og policyreglene. En Wi-Fi-roaming kan endre den ytre veien uten å røre den indre adressen.
Så en tunnel som virker og en peer som ikke kan nås er forenlige tilstander, og det samme er en korrekt peer og en brutt indre rute. De tre observasjonene må tas sammen, i samme øyeblikk, ellers er sammenligningen meningsløs.
Sammenlign de tre tilstandene i én gjennomgang
Tre skrivebeskyttede kommandoer besvarer de tre spørsmålene i den rekkefølgen som isolerer feilen raskest. Kjør dem uten å endre noe imellom.
ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transferDen første viser om grensesnittet har en adresse i det hele tatt, og den andre viser hvilken enhet en bestemt destinasjon ville bruke akkurat nå. Den tredje rapporterer tidspunktet for siste handshake og bytetellerne, og den er den eneste av de tre som beskriver peeren i stedet for den lokale verten.
Les tellerne så vel som tidsstemplet. En handshake som stadig fornyes mens overføringen står stille betyr at peeren svarer, men at ingenting nyttig går gjennom, noe som peker på ruting eller en ACL snarere enn på nøkler. Et tidsstempel som slutter å flytte seg mens en adresse er til stede, peker oppstrøms i stedet. Begge lesningene kommer fra den samme utdatalinjen, og ingen av dem er synlige hvis du bare kontrollerer at en handshake finnes.
Rett opp den spesifikke tilstanden som er feil, og test deretter applikasjonen i stedet for tunnelen. En fersk handshake er peer-bevis, og bevis om peeren er ikke bevis for at den neste forespørselen fra nettleseren din finner en adresse, en rute og en opplenke som virker. wg-quick-håndboken er tydelig på hvilke av disse hjelperen setter opp, og hvilke som hører til protokollen.