WireGuard full tunnel: AllowedIPs 0.0.0.0/0 er ikkje nok

Å setje 0.0.0.0/0, ::/0 i AllowedIPs til ein peer er trinnet alle hugsar, og det avgjer berre kva trafikk peer-en får bera. Desse prefiksa lagar ingen ruter, vidaresender ingenting på den andre sida og lèt resolvaren til kvar applikasjon bli nøyaktig der han var. Fire separate ting må gjelde samstundes for at ein full tunnel skal vere ein full tunnel, og dei blir best kontrollerte i rekkjefølgja nedanfor, fordi ein seinare kontroll ikkje kan redde ein tidlegare. Kvar kontroll nedanfor er eit faktum du kan lese av ein maskin, ikkje ei innstilling du håpar er brukt.

Kva peer-prefikset vel, og kva det ikkje vel

AllowedIPs er både ein veljar og ein autorisasjon. Det fortel den lokale sida kva destinasjonar som kan sendast til denne peer-en, og det fortel mottakarsida kva kjeldeadresser denne peer-en kan presentere. Det er heile jobben. Ingenting i den skildringa lagar ei rute på verten, slår på vidaresending på den fjerne sida eller rører namneoppslag.

Derfor kan ein konfigurasjon sjå komplett ut og oppføre seg som ein delt tunnel. Prefikset seier at peer-en ville godta alt; rutetabellen på verten avgjer kva som faktisk kjem dit, og gatewayen avgjer om noko går ut. Ingen av desse tre avgjerdene bur i peer-delen.

Rute klienten, ikkje berre peer-lista

Handterarar som wg-quick programmerer rutetabellen på verten for deg, og derfor oppfører to identiske konfigurasjonsfiler seg ulikt avhengig av korleis grensesnittet kom opp. Ein minimal profil er kort nok til å lesast i eitt:

[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 detaljar ber arbeidet. Feltet Address er eitt vertsprefiks i staden for eit subnett som klienten trur han eig, og det er handteraren som gjer standard-AllowedIPs om til ei ekte standardrute. Ta den same fila opp med ip link og wg setconf og det viser seg ingen ruter i det heile, noko som ser ut som ein øydelagd tunnel og eigentleg er ein sunn ein med rutetrinnet hoppa over. Handboka for wg-quick dokumenterer rutinga og Table åtferda som desse handterarane legg til.

Les resultatet i staden for fila: ip route get 1.1.1.1 skal nemne tunnelgrensesnittet, og wg show skal rapportere ein nyleg handshake med ein overføringsteljar som flyttar seg. Ein handshake utan rute tyder på at handteraren aldri køyrde, og det hjelper ikkje å redigere profilen igjen. Start grensesnittet slik brukaren vil starte det, elles måler testen skalet ditt i staden for utrullinga.

Halde endepunktet utanfor tunnelen

Ein full tunnel fangar kvar destinasjon, også den han må snakke med for å eksistere. Handterarar handterer det ved å leggje til ei vertsrute for endepunktet gjennom den opphavlege gatewayen, og derfor inneheld ein riktig konfigurasjon nesten alltid eitt medvite unntak. Å bruke halvparten av konfigurasjonen med ein handterar og den andre halvparten for hand er den vanlege måten dette unntaket forsvinn på.

Viss endepunktet er eit vertsnamn som løysast til fleire adresser, eller til ein familie du ikkje ber, eldast unntaket dårleg, og tunnelen kan feile etter ei gjenoppkopling som såg rutinemessig ut. Fest endepunktet til ei adresse du kontrollerer, eller stadfest at handteraren vurderer det på nytt, og les vertsruta på nytt etter kvar nettverksendring.

Den same mekanismen forklarer kvifor ein full tunnel og ein captive portal kranglar. Portalen ventar å fange trafikken tunnelen din no fangar, så på hotell- og flyplassnett tek du tunnelen opp etter portalinnlogginga, aldri før.

Vidaresending og returvegen i gatewayen

I gatewayen slår du på vidaresending for familien du ber, tillèt forward-kjeda i båe retningar når du omset, og stadfester returvegen med eit kjeldespesifikt oppslag. Ingenting av dette følgjer av ein vellukka handshake, fordi ein handshake berre beviser at dei to peer-ane kan utveksle UDP. Han seier ingenting om kva 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 køyrer i gatewayen og ikkje på klienten, elles les du ein annan rutetabell. Viss det nemner feil grensesnitt, eller rapporterer at det ikkje finst noka rute, vil inga endring på klientsida gje ein internettutgang. Når gatewayen omset klientadresser på veg ut, avheng svaret av den omsetjingstilstanden, så regelen må finnast for båe retningane av flyten og ikkje berre den utgåande.

DNS og feiltilstanden, testa kvar for seg

Protokollen sjølv konfigurerer ikkje resolvaren til nokon applikasjon. wg-quick brukar linja DNS gjennom resolverintegrasjonen til distribusjonen, containerar og nettlesarar med sine eigne stablar kan ignorere han, og derfor kan eit namn feile medan tunnelen ber pakkar perfekt. Test med eit vertsnamn i staden for ei adresse, og noter kva tenar som svara i staden for å anta at den i profilen gjorde det.

Adressefamiliar er ein eigen test med eit eige svar. Ei standardrute for v4 seier ingenting om kva v6-tilkoplinga til ein applikasjon vil gjere, og ein tunnel som stille lek den andre familien er verre enn ein som feilar høgt. Spør om eit namn over kvar familie, les grensesnittet kvar førespurnad brukte, og kontroller omsetjingsteljarane før og etter, fordi ein regel som ikkje passar med noko ser identisk ut med ein regel som manglar.

Til slutt testar du tilstanden du ønskjer når tunnelen stoppar. Ein full tunnel bør feile lukka for trafikken han hevdar: viss grensesnittet går ned og applikasjonar stille held fram over den fysiske lenkja, er designet ein delt tunnel med ekstra trinn. Skriv ned den tiltenkte feilåtferda, kontroller henne med vilje, og avslutt med å registrere dei fire svara — kva handterar som tek grensesnittet opp, kva rute som ber standarden, kven som vidaresender og omset i gatewayen, og kva resolver som svarar.