WireGuard-peer oåtkomlig medan en annan fungerar: checklista

En WireGuard-peer släpper igenom trafik och en andra genomför handskakningen men når aldrig något bakom tunneln. Den fungerande peeren berättar att gränssnittet, UDP-porten och serverns nyckel förmodligen är i ordning. Den säger ingenting om den andra peerens AllowedIPs, dess inre källadress eller vidarebefordringsreglerna däremellan. Arbeta igenom listan i ordning och stanna vid det första steget vars villkor inte håller.

Steg 1: Skriv ned den väg paketet ska ta

Två klienter på samma hubb når inte varandra automatiskt. I en hubb-och-eker-design tar servern emot paketet på wg0 och måste vidarebefordra det ut ur wg0 igen till den andra peeren, vilket kräver IP-vidarebefordran och en vidarebefordringsregel. I en direkt peer-till-peer-design behöver varje sida den andras slutpunkt och den andras tunneladress inom AllowedIPs. Bestäm vilken design du felsöker innan du läser någon konfiguration.

Den förväntade vägen berättar också var du ska titta. Om paketet ska passera hubben är det misslyckade hoppet antingen avsändarens AllowedIPs, vidarebefordran i hubben eller mottagarens AllowedIPs. Om det ska gå direkt är hubben irrelevant och slutpunktsfälten på båda peerarna är de som spelar roll.

Steg 2: Jämför AllowedIPs på båda sidor, inte bara en

WireGuard använder AllowedIPs både som routingtabell och som åtkomstlista. Vid sändning slås destinationsadressen upp i peerens AllowedIPs för att välja tunneln; vid mottagning måste den inre källadressen ligga inom den sändande peerens AllowedIPs, annars kastas paketet. Ett saknat intervall på någon av sidorna ger samma symptom: transporten fungerar, lasten försvinner.

Läs det levande tillståndet i stället för filen, eftersom en omladdning kan ha misslyckats tyst: sudo wg show wg0 allowed-ips. På servern måste posten för den misslyckade peeren innehålla dess tunneladress, till exempel 10.90.0.3/32. På klienten måste posten för server-peeren innehålla det mål du testar, vare sig det är hubbens tunneladress eller fjärrsubnätet. Överlappande intervall gör uppslaget tvetydigt och kan välja en peer du inte menade, så håll dem åtskilda.

Steg 3: Kontrollera den inre källadressen

En klient som routar 10.90.0.3 via wg0 men skickar paket från sin Wi-Fi-adress kommer att avvisas av mottagaren, eftersom källan inte matchar peerens AllowedIPs. Bekräfta vad kärnan faktiskt väljer med ip route get 10.90.0.3 from 10.90.0.2, och bekräfta adressen som tilldelats tunnelgränssnittet med ip -brief addr show wg0.

På den mottagande Linux-värden är omvänd sökvägsfiltrering en andra port. En strikt rp_filter på gränssnittet som äger returvägen kan kasta tunneltrafik vars returväg inte matchar gränssnittet den kom in på. Kontrollera det effektiva värdet innan du stänger av det; i många topologier är den rätta åtgärden en rutt, inte ett uppmjukat filter.

Steg 4: Granska vidarebefordran i hubben och returvägen

Om hubben måste vidarebefordra mellan peerar behöver kärnan net.ipv4.ip_forward=1, och brandväggen måste acceptera det vidarebefordrade flödet: in på wg0, ut på wg0, från avsändarens tunneladress till mottagarens. Ett vanligt fel är en indataregel som accepterar UDP 51820 men ingen vidarebefordringsregel], så handskakningen lyckas och lasten dör. Lista de gällande reglerna med sudo nft list ruleset eller motsvarande för din brandväggshanterare.

Kontrollera sedan svaret. Destinationsvärden måste ha en rutt tillbaka till avsändaren, antingen via hubben eller via sin egen gateway. Om hubben också NAT:ar tunnelsubnätet, bekräfta att översättningen gäller det vidarebefordrade flödet och att svaret når hubben innan tillståndet löper ut. Ett enkelriktat fel som ser ut som ett nyckelproblem är ofta bara denna returväg.

Slutligen, separera handskakningen från data. En peer som slutför handskakningen men stannar vid stora överföringar har oftast ett MTU- eller MSS-problem på just den vägen, inte ett AllowedIPs-problem. Testa först med en liten ping, sedan med en i full storlek, och jämför de två peerarna.

Steg 5: Ändra en sak och håll den fungerande peeren intakt

Gör en enda ändring på den misslyckade vägen och testa båda peerarna igen. Att ersätta varje peers AllowedIPs med 0.0.0.0/0 är det snabbaste sättet att bryta den peer som redan fungerade, eftersom det ändrar routingbeslutet för all trafik på det gränssnittet. Redigera den enda posten, ladda om och läs tillbaka det levande tillståndet.

Anteckna vilken väg som lyckades, vilken som misslyckades och den exakta kommandoutskriften för varje. Den jämförelsen är värd mer än en allmän rapport om att VPN:en är trasig, och det är det första nästa person kommer att fråga efter.