WireGuard-handskakningen fungerar men det finns inget internet: följ paketet

Tunneln är uppe, wg show rapporterar en färsk handskakning, du kan pinga serverns tunneladress, och inget bortom den svarar. Den första impulsen är att generera om nycklarna eller dela konfigurationen igen. Det ändrar precis den del av vägen som redan är bevisat fungerande.

En slutförd handskakning säger att de två parterna är överens om nycklarna, att UDP når slutpunkten och att krypteringsroutningen accepterar paketet. Den säger ingenting om huruvida paketet därefter kan lämna servern.

Följ därför ett paket i stället för att gissa. Det finns fyra ställen där det kan dö, och varje ställe lämnar ett olikt spår.

Vad handskakningen faktiskt bevisar

WireGuard är ett UDP-protokoll som upprättar en session med en Noise-handskakning och sedan krypterar paket för en peer. När wg show visar en handskakning som är några sekunder gammal och en stigande överföringsmätare är slutpunkten, nycklarna och peerens publika nyckel alla korrekta.

Det bevisar inte att din klient över huvud taget skickar internettrafik in i gränssnittet, att servern är villig att vidarebefordra den eller att ett svar kan hitta vägen tillbaka. Det är routing- och brandväggsbeslut i kärnan, och de fattas utanför tunneln.

Det är därför ping mot serverns tunneladress är ett så missvisande test. Det paketet är adresserat till servern själv, så det avslutas lokalt. Det behöver aldrig vidarebefordran, aldrig översättning och aldrig en returväg från internet.

AllowedIPs är ett routingbeslut

På klienten gör AllowedIPs två jobb. Det är krypteringsnyckelns routingtabell som avgör vilka destinationsadresser som skickas in i den här peerens tunnel, och det är listan över källadresser som peeren accepterar från dig. Om klientkonfigurationen bara listar 10.8.0.0/24 kommer publika destinationer aldrig in i gränssnittet och din vanliga standardrutt för dem utanför tunneln. Då fungerar tunneln perfekt och gör inget av det du ville.

Titta på vad klienten faktiskt installerade i stället för vad konfigurationsfilen säger:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Det andra kommandot är det avgörande. Om svaret namnger ditt fysiska gränssnitt och den vanliga gatewayen tunnlas paketet inte och ingen ändring på serversidan rättar det. Lägg till 0.0.0.0/0 för IPv4 och ::/0 för IPv6 separat; en regel som fångar allt för den ena familjen lämnar den andra på sin ursprungliga väg, och det är en vanlig orsak till en fungerande IPv4-tunnel och en fastnad IPv6-sökning.

Var paketet dör på gatewayen

Om rutten är korrekt och paketet fortfarande inte kommer någonstans anländer det till servern och stannar där. Fyra kontroller täcker de flesta gatewayer.

Vidarebefordran. sysctl net.ipv4.ip_forward som returnerar 0 är det klassiska svaret, och många distributioner står fortfarande på 0 som standard. Det måste vara 1, och sättas varaktigt i en sysctl-fil i stället för med ett kommando som försvinner vid omstart. Vidarebefordran av IPv6 är en egen brytare.

Filterpolicyn. En FORWARD-kedja med standardpolicy för drop kastar tunneltrafik medan den tillåter trafik till värden själv, vilket passar exakt på symtomet. Läs den levande regeluppsättningen, inte en sparad fil: nft list ruleset eller iptables -S.

Översättning eller routing. Klienter med privata tunneladresser behöver antingen käll-NAT på serverns utgående gränssnitt eller ett routat prefix som nätverket ovanför kan returnera. Valet mellan dem följer adressplanen. Att lägga till MASQUERADE i ett nätverk som redan routar ditt prefix tillbaka är ofarligt men meningslöst, och att utelämna det där ingen rutt finns lämnar svaren adresserade till ett icke-routbart privat område.

Returvägen. I routade designer behöver routern ovanför en rutt som pekar på din server. Leverantörens nätverk kan också blockera det: flera moln aktiverar en käll- och destinationskontroll på instansen, som tyst släpper paket vars källa inte är instansens egen adress, tills kontrollen stängs av.

DNS misslyckas annorlunda än routing

Ett paket till en känd adress och en namnsökning är två olika fel, och felmeddelandena vilseleder i motsatta riktningar. Om ping 1.1.1.1 fungerar och en webbläsare inte kan ladda något är rutten okej och namnmatchningen inte. Om själva pinget misslyckas är DNS irrelevant och du är tillbaka i föregående avsnitt.

wg-quick kan sätta en resolver från raden DNS = i konfigurationen, och systemd-resolved har sitt eget beteende per länk. En VPN som skriver över resolvern med en adress som bara går att nå inuti tunneln kommer att misslyckas med varje sökning i samma stund som tunneln faller, vilket ser ut som att tunneln förstör internet.

En ordning som ger bevis

Kör kontrollen på klientsidan först, eftersom det är ett kommando och det eliminerar hälften av möjligheterna. Bekräfta sedan om servern över huvud taget är tänkt som en internetutgång; en gateway byggd för privat åtkomst är inte trasig när publika destinationer misslyckas.

På servern, håll koll på gränssnittet medan du skickar en ping från klienten: tcpdump -ni wg0 icmp bör visa begäran, och tcpdump -ni eth0 icmp bör visa att den går ut, översatt eller inte. Om den syns på den första och aldrig på den andra är stoppet lokalt på servern. Om den går ut och inget svar kommer tillbaka ligger problemet längre upp, och det är ett annat samtal.

Se slutligen till att rättelsen överlever en omstart. Vidarebefordran hör hemma i en sysctl-fil, brandväggsregler i tjänsten som laddar dem, och klientrutter i konfigurationen som reser gränssnittet i stället för i ett skal du kommer att glömma. Anslut igen, upprepa samma två tester och bekräfta att mätarna rör sig.