WireGuard fuld tunnel: AllowedIPs 0.0.0.0/0 er ikke nok

At sætte 0.0.0.0/0, ::/0 i en peers AllowedIPs er det skridt, alle husker, og det afgør kun, hvilken trafik peer’en må bære. Disse præfikser opretter ingen ruter, videresender intet på den anden side og lader hver applikations resolver blive præcis, hvor den var. Fire separate ting skal gælde samtidig, for at en fuld tunnel er en fuld tunnel, og de kontrolleres bedst i rækkefølgen nedenfor, fordi en senere kontrol ikke kan redde en tidligere. Hver kontrol nedenfor er et faktum, du kan læse af en maskine, ikke en indstilling, du håber er anvendt.

Hvad peer-præfikset vælger, og hvad det ikke vælger

AllowedIPs er både en selektor og en godkender. Det fortæller den lokale side, hvilke destinationer der må sendes til denne peer, og det fortæller den modtagende side, hvilke kildeadresser denne peer må fremvise. Det er hele opgaven. Intet i den beskrivelse opretter en rute på værten, aktiverer videresendelse på den fjerne side eller rører navneopløsning.

Det er derfor, en konfiguration kan se komplet ud og opføre sig som en split tunnel. Præfikset siger, at peer’en ville acceptere alt; værtens rutetabel afgør, hvad der faktisk når derhen, og gatewayen afgør, om noget forlader. Ingen af de tre beslutninger bor i peer-afsnittet.

Rut klienten, ikke kun peer-listen

Administratorer som wg-quick programmerer værtens rutetabel for dig, og derfor opfører to identiske konfigurationsfiler sig forskelligt afhængigt af, hvordan interfacet kom op. En minimal profil er kort nok til at læse i ét hug:

[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

To detaljer bærer arbejdet. Feltet Address er et enkelt værtspræfiks i stedet for et undernet, som klienten tror, den ejer, og det er administratoren, der omdanner standard-AllowedIPs til en egentlig standardrute. Bring den samme fil op med ip link og wg setconf og der vises slet ingen ruter, hvilket ser ud som en ødelagt tunnel og er en sund en med rutetrinnet sprunget over. Håndbogen for wg-quick dokumenterer rutningen og den Table adfærd, som disse administratorer tilføjer.

Læs resultatet i stedet for filen: ip route get 1.1.1.1 bør navngive tunnelinterfacet, og wg show bør rapportere et nyligt handshake med en transfertæller, der bevæger sig. Et handshake uden rute betyder, at administratoren aldrig kørte, og det hjælper ikke at redigere profilen igen. Start interfacet, som brugeren vil starte det, ellers måler testen din shell i stedet for udrulningen.

Hold endpointet uden for tunnelen

En fuld tunnel fanger hver destination, inklusive den, den skal tale med for at eksistere. Administratorer håndterer det ved at tilføje en værtsrute til endpointet gennem den oprindelige gateway, og derfor indeholder en korrekt konfiguration næsten altid én bevidst undtagelse. At anvende halvdelen af konfigurationen med en administrator og den anden halvdel manuelt er den sædvanlige måde, denne undtagelse forsvinder på.

Hvis endpointet er et værtsnavn, der opløses til flere adresser eller til en familie, du ikke bærer, ældes undtagelsen dårligt, og tunnelen kan fejle efter en genopkobling, der så rutinemæssig ud. Fastlås endpointet til en adresse, du kontrollerer, eller bekræft, at administratoren revurderer det, og læs værtsruten igen efter hver netværksændring.

Den samme mekanisme forklarer, hvorfor en fuld tunnel og en captive portal slås. Portalen forventer at opfange den trafik, din tunnel nu fanger, så på hotel- og lufthavnsnetværk bringer du tunnelen op efter portallogin, aldrig før.

Videresendelse og returvejen på gatewayen

På gatewayen skal du aktivere videresendelse for den familie, du bærer, tillade forward-kæden i begge retninger, når du oversætter, og bekræfte returvejen med et kildespecifikt opslag. Intet af det følger af et vellykket handshake, fordi et handshake kun beviser, at de to peers kan udveksle UDP. Det siger intet om, hvad der sker med den afkapslede pakke bagefter.

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

Opslaget kører på gatewayen og ikke på klienten, ellers læser du en anden rutetabel. Hvis det navngiver det forkerte interface eller rapporterer ingen rute, så vil ingen ændring på klientsiden give en internetudgang. Når gatewayen oversætter klientadresser på vej ud, afhænger svaret af den oversættelsestilstand, så reglen skal findes for begge retninger af flowet og ikke kun den udgående.

DNS og fejltilstanden, testet hver for sig

Protokollen selv konfigurerer ingen applikations resolver. wg-quick anvender linjen DNS gennem distributionens resolverintegration, containere og browsere med deres egne stakke kan ignorere det, og derfor kan et navn fejle, mens tunnelen bærer pakker perfekt. Test med et værtsnavn i stedet for en adresse, og noter hvilken server der svarede i stedet for at antage, at den i profilen gjorde det.

Adressefamilier er en separat test med et separat svar. En v4-standardrute siger intet om, hvad en applikations v6-forbindelse vil gøre, og en tunnel, der lydløst lækker den anden familie, er værre end en, der fejler højlydt. Forespørg et navn over hver familie, læs det interface, hver anmodning brugte, og kontroller oversættelsestællere før og efter, fordi en regel, der ikke matcher noget, ser identisk ud med en regel, der mangler.

Til sidst skal du teste den tilstand, du ønsker, når tunnelen stopper. En fuld tunnel bør fejle lukket for den trafik, den hævder: hvis interfacet går ned, og applikationer stille fortsætter over det fysiske link, er designet en split tunnel med ekstra trin. Skriv den tilsigtede fejladfærd ned, kontroller den bevidst, og afslut med at registrere de fire svar — hvilken administrator bringer interfacet op, hvilken rute bærer standarden, hvem videresender og oversætter på gatewayen, og hvilken resolver svarer.