WireGuard full tunnel: AllowedIPs 0.0.0.0/0 räcker inte

Att sätta 0.0.0.0/0, ::/0 i en peers AllowedIPs är steget alla minns, och det avgör bara vilken trafik peeren får bära. Dessa prefix skapar inga rutter, vidarebefordrar ingenting på andra sidan och lämnar varje applikations resolver precis där den var. Fyra separata saker måste gälla samtidigt för att en full tunnel ska vara en full tunnel, och de kontrolleras bäst i ordningen nedan, eftersom en senare kontroll inte kan rädda en tidigare. Varje kontroll nedan är ett faktum du kan läsa av en maskin, inte en inställning du hoppas har tillämpats.

Vad peer-prefixet väljer, och vad det inte väljer

AllowedIPs är både en väljare och en auktorisering. Det talar om för den lokala sidan vilka destinationer som får skickas till den här peeren, och det talar om för mottagarsidan vilka källadresser den här peeren får presentera. Det är hela jobbet. Ingenting i den beskrivningen skapar en rutt på värden, slår på vidarebefordran på fjärrsidan eller rör namnmatchning.

Därför kan en konfiguration se komplett ut och bete sig som en delad tunnel. Prefixet säger att peeren skulle acceptera allt; värdens routingtabell avgör vad som faktiskt kommer dit, och gatewayen avgör om något går ut. Ingen av dessa tre beslut bor i peer-avsnittet.

Routa klienten, inte bara peer-listan

Hanterare som wg-quick programmerar värdens routingtabell åt dig, och därför beter sig två identiska konfigurationsfiler olika beroende på hur gränssnittet kom upp. En minimal profil är kort nog att läsa i ett svep:

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

Två detaljer bär arbetet. Fältet Address är ett enda värdprefix i stället för ett subnät som klienten tror sig äga, och det är hanteraren som omvandlar standard-AllowedIPs till en riktig standardrutt. Ta upp samma fil med ip link och wg setconf och det visas inga rutter alls, vilket ser ut som en trasig tunnel och egentligen är en frisk sådan med routingsteget överhoppat. Handboken för wg-quick dokumenterar routningen och det Table beteende som dessa hanterare lägger till.

Läs resultatet i stället för filen: ip route get 1.1.1.1 bör namnge tunnelns gränssnitt, och wg show bör rapportera en nyligen genomförd handskakning med en överföringsräknare som rör sig. En handskakning utan rutt betyder att hanteraren aldrig körde, och det hjälper inte att redigera profilen igen. Starta gränssnittet som användaren kommer att starta det, annars mäter testet ditt skal i stället för utrullningen.

Hålla ändpunkten utanför tunneln

En full tunnel fångar varje destination, även den den måste tala med för att existera. Hanterare löser det genom att lägga till en värdrutt för ändpunkten via den ursprungliga gatewayen, och därför innehåller en korrekt konfiguration nästan alltid ett medvetet undantag. Att tillämpa halva konfigurationen med en hanterare och den andra halvan för hand är det vanliga sättet som detta undantag försvinner på.

Om ändpunkten är ett värdnamn som löses upp till flera adresser, eller till en familj du inte bär, åldras undantaget dåligt och tunneln kan misslyckas efter en återanslutning som såg rutinmässig ut. Fäst ändpunkten vid en adress du kontrollerar, eller bekräfta att hanteraren omvärderar den, och läs om värdrutten efter varje nätverksändring.

Samma mekanism förklarar varför en full tunnel och en captive portal bråkar. Portalen förväntar sig att fånga trafiken som din tunnel nu fångar, så på hotell- och flygplatsnät tar du upp tunneln efter portalens inloggning, aldrig före.

Vidarebefordran och returvägen i gatewayen

I gatewayen slår du på vidarebefordran för den familj du bär, tillåter forward-kedjan i båda riktningarna när du översätter, och bekräftar returvägen med en källspecifik uppslagning. Ingenting av detta följer av en lyckad handskakning, eftersom en handskakning bara bevisar att de två peerarna kan utbyta UDP. Den säger ingenting om vad som händer med det avkapslade paketet efteråt.

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

Uppslagningen körs i gatewayen och inte på klienten, annars läser du en annan routingtabell. Om den anger fel gränssnitt, eller rapporterar att det inte finns någon rutt, kommer ingen ändring på klientsidan att ge en internetutgång. När gatewayen översätter klientadresser på väg ut beror svaret på det översättningstillståndet, så regeln måste finnas för båda riktningarna av flödet och inte bara den utgående.

DNS och feltillståndet, testade var för sig

Protokollet självt konfigurerar inte någon applikations resolver. wg-quick tillämpar raden DNS via distributionens resolverintegration, containrar och webbläsare med egna stackar kan ignorera den, och därför kan ett namn misslyckas medan tunneln bär paket perfekt. Testa med ett värdnamn i stället för en adress, och notera vilken server som svarade i stället för att anta att den i profilen gjorde det.

Adressfamiljer är ett eget test med ett eget svar. En standardrutt för v4 säger ingenting om vad en applikations v6-anslutning kommer att göra, och en tunnel som tyst läcker den andra familjen är sämre än en som misslyckas högt. Fråga efter ett namn över varje familj, läs gränssnittet varje begäran använde, och kontrollera översättningsräknarna före och efter, eftersom en regel som inte matchar något ser identisk ut med en regel som saknas.

Testa till sist det tillstånd du vill ha när tunneln stannar. En full tunnel bör misslyckas stängt för den trafik den hävdar: om gränssnittet går ner och applikationer tyst fortsätter över den fysiska länken är designen en delad tunnel med extra steg. Skriv ner det avsedda felbeteendet, kontrollera det medvetet, och avsluta med att registrera de fyra svaren — vilken hanterare som tar upp gränssnittet, vilken rutt som bär standarden, vem som vidarebefordrar och översätter i gatewayen, och vilken resolver som svarar.