WireGuard kan ha en färsk handskakning och ingen adress samtidigt, och det tillståndet är sammanhängande, inte självmotsägande. Handskakningen är en peer-händelse, adressen tillhör gränssnittet, och rutten avgör vilken upplänk ett paket lämnar via. Tre lager, tre ägare, och var och en kan fallera medan de andra två ser friska ut.

Att läsa dem som en enda status är det som förvandlar en tvåminutersdiagnos till en hel eftermiddag av omstarter av tjänster.

En handskakning är en peer-händelse, inte en adresseringshändelse

WireGuards handskakning bevisar att den konfigurerade peeren svarade med en giltig nyckel och att sessionsnycklarna är aktuella. Den säger ingenting om den lokala adressen på gränssnittet, och ingenting om huruvida någon rutt pekar dit. En hjälpare eller nätverkshanterare tilldelar adressen, medan protokollkonfigurationen bara namnger peers och nycklar. Att blanda ihop de två är hur en frisk handskakning läses som en tunnel som fungerar.

Därför kan wg show rapportera en handskakning som är sekunder gammal på ett gränssnitt som inte kan ta emot ett enda paket från en applikation.

En hanterare som återskapar gränssnittet kan tappa adressen utan att röra peer-konfigurationen, och nästa handskakning lyckas direkt eftersom nycklarna aldrig ändrades. Loggraden om en lyckad handskakning är korrekt och irrelevant för felet.

ObservationWhich layer it belongs toWrong conclusion it invites
Handshake a few seconds oldPeer and keysThe tunnel is usable for application traffic
Address present on wg0Interface configurationTraffic actually egresses through it
Route points at wg0Forwarding tableThe outer packet uses the intended uplink

Gränssnittets adress har sin egen ägare

En adress på tunnelenheten kan komma från en hjälpares Address rad, från en DHCP-klient som kör på gränssnittet, eller från en administrationsdaemon som skapar den vid anslutning. Vad det än är, äger den komponenten adressen och återställer den eller inte enligt sin egen logik. Att läsa adressen utan att namnge dess ägare lämnar dig utan förklaring till varför den försvann.

Två ägare på ett gränssnitt är det klassiska felet. Att starta en hjälpare och en skrivbordsnätverkshanterare över samma enhet skapar ett kapplöpning där den ena tar bort det den andra just konfigurerade, och slutpunkten fortsätter att svara hela tiden.

Välj en enda ägare och låt det andra verktyget observera i stället för att hantera. Det beslutet är värt att skriva ned, eftersom symtomet dyker upp veckor senare och ser ut som en slumpmässig adressförlust.

En rutt väljer en upplänk, inte gränssnittet

En inre rutt som pekar på wg0 avgör att trafiken går in i tunneln. Ett separat beslut skickar de krypterade yttre paketen mot peeren, och på en värd med flera upplänkar kommer det beslutet från vidarebefordringstabellen och policyreglerna. En Wi-Fi-roaming kan ändra den yttre vägen utan att röra den inre adressen.

Så en tunnel som fungerar och en peer som inte går att nå är förenliga tillstånd, och detsamma gäller en korrekt peer och en trasig inre rutt. De tre observationerna måste tas tillsammans, i samma ögonblick, annars är jämförelsen meningslös.

Jämför de tre tillstånden i en genomgång

Tre skrivskyddade kommandon besvarar de tre frågorna i den ordning som isolerar felet snabbast. Kör dem utan att ändra något mellan dem.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

Den första visar om gränssnittet har någon adress alls, och den andra visar vilken enhet en viss destination skulle använda just nu. Den tredje rapporterar tiden för den senaste handskakningen och byträknarna, och den är den enda av de tre som beskriver peeren i stället för den lokala värden.

Läs räknarna såväl som tidsstämpeln. En handskakning som ständigt förnyas medan överföringen står stilla betyder att peeren svarar men att inget användbart går igenom, vilket pekar på routning eller en ACL snarare än på nycklar. En tidsstämpel som slutar flytta sig medan en adress finns pekar i stället uppströms. Båda läsningarna kommer från samma utdatarad, och ingen av dem syns om du bara kontrollerar att en handskakning finns.

Rätta till det specifika tillstånd som är fel, och testa sedan applikationen i stället för tunneln. En färsk handskakning är peer-bevis, och bevis om peeren är inte bevis för att nästa begäran från din webbläsare hittar en adress, en rutt och en upplänk som fungerar. wg-quick-handboken säger uttryckligen vilka av dessa hjälparen ställer in och vilka som hör till protokollet.

Relaterade artiklar