WireGuard full tunnel: AllowedIPs 0.0.0.0/0 er ikke nok

Å sette 0.0.0.0/0, ::/0 i AllowedIPs til en peer er trinnet alle husker, og det avgjør bare hvilken trafikk peer-en får bære. Disse prefiksene lager ingen ruter, videresender ingenting på den andre siden og lar resolveren til hver applikasjon bli nøyaktig der den var. Fire separate ting må gjelde samtidig for at en full tunnel skal være en full tunnel, og de kontrolleres best i rekkefølgen nedenfor, fordi en senere kontroll ikke kan redde en tidligere. Hver kontroll nedenfor er et faktum du kan lese av en maskin, ikke en innstilling du håper er anvendt.

Hva peer-prefikset velger, og hva det ikke velger

AllowedIPs er både en velger og en autorisasjon. Det forteller den lokale siden hvilke destinasjoner som kan sendes til denne peer-en, og det forteller mottakersiden hvilke kildeadresser denne peer-en kan presentere. Det er hele jobben. Ingenting i den beskrivelsen lager en rute på verten, slår på videresending på den fjerne siden eller berører navneoppslag.

Derfor kan en konfigurasjon se komplett ut og oppføre seg som en delt tunnel. Prefikset sier at peer-en ville godta alt; rutetabellen på verten avgjør hva som faktisk kommer dit, og gatewayen avgjør om noe går ut. Ingen av disse tre beslutningene bor i peer-delen.

Rute klienten, ikke bare peer-listen

Behandlere som wg-quick programmerer rutetabellen på verten for deg, og derfor oppfører to identiske konfigurasjonsfiler seg ulikt avhengig av hvordan grensesnittet kom opp. En minimal profil er kort nok til å leses i ett:

[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 arbeidet. Feltet Address er ett vertsprefiks i stedet for et subnett som klienten tror den eier, og det er behandleren som gjør standard-AllowedIPs om til en ekte standardrute. Ta den samme filen opp med ip link og wg setconf og det vises ingen ruter i det hele tatt, noe som ser ut som en ødelagt tunnel og egentlig er en sunn en med rutetrinnet hoppet over. Håndboken for wg-quick dokumenterer rutingen og Table oppførselen som disse behandlerne legger til.

Les resultatet i stedet for filen: ip route get 1.1.1.1 skal nevne tunnelgrensesnittet, og wg show skal rapportere en nylig handshake med en overføringsteller som beveger seg. En handshake uten rute betyr at behandleren aldri kjørte, og det hjelper ikke å redigere profilen igjen. Start grensesnittet slik brukeren vil starte det, ellers måler testen skallet ditt i stedet for utrullingen.

Holde endepunktet utenfor tunnelen

En full tunnel fanger hver destinasjon, også den den må snakke med for å eksistere. Behandlere håndterer det ved å legge til en vertsrute for endepunktet gjennom den opprinnelige gatewayen, og derfor inneholder en riktig konfigurasjon nesten alltid ett bevisst unntak. Å bruke halvparten av konfigurasjonen med en behandler og den andre halvparten for hånd er den vanlige måten dette unntaket forsvinner på.

Hvis endepunktet er et vertsnavn som løses til flere adresser, eller til en familie du ikke bærer, eldes unntaket dårlig, og tunnelen kan feile etter en gjenoppkobling som så rutinemessig ut. Fest endepunktet til en adresse du kontrollerer, eller bekreft at behandleren vurderer det på nytt, og les vertsruten på nytt etter hver nettverksendring.

Den samme mekanismen forklarer hvorfor en full tunnel og en captive portal krangler. Portalen forventer å fange trafikken tunnelen din nå fanger, så på hotell- og flyplassnett tar du tunnelen opp etter portalinnloggingen, aldri før.

Videresending og returveien i gatewayen

I gatewayen slår du på videresending for familien du bærer, tillater forward-kjeden i begge retninger når du oversetter, og bekrefter returveien med et kildespesifikt oppslag. Ingenting av dette følger av en vellykket handshake, fordi en handshake bare beviser at de to peer-ene kan utveksle UDP. Den sier ingenting om hva som skjer med den dekapsulerte pakken etterpå.

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

Oppslaget kjører i gatewayen og ikke på klienten, ellers leser du en annen rutetabell. Hvis det nevner feil grensesnitt, eller rapporterer at det ikke finnes noen rute, vil ingen endring på klientsiden gi en internettutgang. Når gatewayen oversetter klientadresser på vei ut, avhenger svaret av den oversettelsestilstanden, så regelen må finnes for begge retninger av flyten og ikke bare den utgående.

DNS og feiltilstanden, testet hver for seg

Protokollen selv konfigurerer ikke resolveren til noen applikasjon. wg-quick bruker linjen DNS gjennom distribusjonens resolverintegrasjon, containere og nettlesere med sine egne stabler kan ignorere den, og derfor kan et navn feile mens tunnelen bærer pakker perfekt. Test med et vertsnavn i stedet for en adresse, og noter hvilken server som svarte i stedet for å anta at den i profilen gjorde det.

Adressefamilier er en egen test med et eget svar. En standardrute for v4 sier ingenting om hva en applikasjons v6-forbindelse vil gjøre, og en tunnel som stille lekker den andre familien er verre enn en som feiler høyt. Spør om et navn over hver familie, les grensesnittet hver forespørsel brukte, og kontroller oversettelsestellerne før og etter, fordi en regel som ikke passer med noe ser identisk ut med en regel som mangler.

Til slutt tester du tilstanden du ønsker når tunnelen stopper. En full tunnel bør feile lukket for trafikken den hevder: hvis grensesnittet går ned og applikasjoner stille fortsetter over den fysiske lenken, er designet en delt tunnel med ekstra trinn. Skriv ned den tiltenkte feiloppførselen, kontroller den med vilje, og avslutt med å registrere de fire svarene — hvilken behandler som tar grensesnittet opp, hvilken rute som bærer standarden, hvem som videresender og oversetter i gatewayen, og hvilken resolver som svarer.