AllowedIPs er en ruterliste, ikke en brannmurregel

De fleste leser AllowedIPs som en tillatelsesliste, altså adressene som kan koble til en peer, omtrent som en brannmurregel skrevet for en tunnel. Det er ikke tilfellet. Feltet er en rutetabell som virker i begge retninger: den velger en peer for en utgående pakke og validerer kilden til en inngående. Å lese det som en tilgangsliste gir konfigurasjoner som ruter trafikk ingen har bedt om.

Ett felt, to lesere: valg ut og kildekontroll

Hos en klient avgjør prefiksene hvilke destinasjoner som reiser til den peeren, og hvilke som blir på det vanlige nettverket. En oppføring for 0.0.0.0/0 fanger derfor enhver IPv4-destinasjon, og derfor sender import av en fulltunnelprofil vanlig surfing gjennom den eksterne maskinen. Smale oppføringer gjør det motsatte: de ruter bare nettverkene du listet opp og lar alt annet bli der det var. Avsnittet om kryptonøkkelrutting i WireGuard-dokumentasjonen beskriver begge oppgavene på ett sted: valg av utgående peer og validering av inngående kilde.

På serveren beskriver samme felt hvilke kildeadresser hver peer kan bruke. Det er en kryptografisk kontroll og ikke et pakkefilter: en pakke der den indre kilden ikke samsvarer med peerens liste, slippes inne i WireGuard før noen brannmur på verten ser den. Begge oppgavene deler én liste, og nettopp derfor oppfører en liste kopiert fra et annet sted seg feil på et sted du ikke hadde tenkt på.

Klientblokken er der mesteparten av denne forvirringen starter. En delt tunnel navngir de eksterne nettverkene, og en full tunnel er samme felt med et standardprefiks:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Begge former er komplette i seg selv, og de er alternativer snarere enn trinn. Den første sender bare de to nettverkene gjennom tunnelen; den andre sender hver destinasjon, med oppføringen ::/0 som legger IPv6 til IPv4-standarden. Uansett hva du velger, er disse prefiksene hele rutingsbeslutningen for den peeren når wg-quick begynner å installere ruter.

Huben trenger en annen liste

En hub lister opp hver klients tunneladresse som vertsprefiks, i tillegg til ethvert nettverk som faktisk ligger bak den klienten. Å kopiere en klients brede liste til hver hub-peer forteller huben at mange peers kan bruke de samme adressene som kilde, og det er ikke en adresseplan. Feltet Endpoint hører til et helt annet lag: det navngir peerens ytre adresse og port, aldri en destinasjon inne i tunnelen.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Vertsprefikset bærer tunneladressen, og nettverksprefikset bærer det som ligger bak klienten, og begge trengs. Uten vertsprefikset kan huben ikke returnere klientens egen trafikk, og uten nettverksprefikset blir LAN-et bak det utilgjengelig; en peer uten noe bak seg får bare vertsprefikset.

Å hoppe over ruteinstallasjon etterlater et gap

wg-quick, hjelperen som reiser et grensesnitt fra en konfigurasjonsfil, installerer grensesnittadresser og ruter som en del av den jobben. Å sette Table = off forteller hjelperen å hoppe over rutearbeidet, noe som ikke installerer erstatninger og ikke gjør det private nettverket tilgjengelig. Når automatiske ruter allerede gjør jobben, er det den tydeligere konfigurasjonen å navngi prefiksene du trenger. Å slå av rutebehandling og la erstatningen være uskrevet er ikke et design, det er en utelatelse.

Grunnverktøyet wg oppfører seg annerledes: det konfigurerer grensesnittet og rører aldri ruter, så et oppsett bygget direkte på det trenger sine egne rutekommandoer. Instruksjoner skrevet for ett verktøy kan se feil ut når de følges mot det andre. En vellykket ping er også svakt bevis, fordi den prøver én vei i stedet for hver applikasjonsvei du trenger.

DNS og IPv6 avgjøres hver for seg

Sjekk DNS-serveradressen tunnelen annonserer, og bekreft at det finnes en rute til den adressen gjennom prefiksene du valgte. En resolverinnstilling gjør ikke resolveren tilgjengelig, og å snevre inn en tunnel kan stille fjerne ruten som førte dit. Undersøk også IPv6 for seg, fordi en korrekt IPv4-deling ikke sier noe om en IPv6-standardrute som fortsatt peker på den fysiske forbindelsen. Tre separate beslutninger kan endre seg på én gang når du redigerer én peer-blokk.

Åpne deretter én privat ressurs og ett vanlig nettsted fra en kjent startkonfigurasjon. Hvis ressursen svarer og surfing fortsatt går ut gjennom den lokale forbindelsen, gjør delingen det du ba om. Hvis surgingen bryter sammen i samme øyeblikk, har tunnelen tatt standardruten, og prefikslisten er stedet å se.