AllowedIPs er en ruterliste, ikke en firewallregel

De fleste læser AllowedIPs som en tilladelsesliste, altså de adresser, der må forbinde til en peer, nærmest som en firewallregel skrevet til en tunnel. Det er ikke tilfældet. Feltet er en rutetabel, der virker i begge retninger: den vælger en peer til en udgående pakke og validerer kilden til en indgående. Læst som adgangsliste giver det konfigurationer, der ruter trafik, ingen har bedt om.

Ét felt, to læsere: valg udad og kildekontrol

Hos en klient afgør præfikserne, hvilke destinationer der rejser til den peer, og hvilke der bliver på det almindelige netværk. En post for 0.0.0.0/0 fanger derfor enhver IPv4-destination, og derfor sender import af en fuldtunnelprofil almindelig browsing gennem den fjernede maskine. Smalle poster gør det modsatte: de ruter kun de netværk, du har angivet, og lader alt andet blive, hvor det var. Afsnittet om kryptonøgle-rutning i WireGuard-dokumentationen beskriver begge opgaver ét sted: valg af udgående peer og validering af indgående kilde.

På serveren beskriver samme felt, hvilke kildeadresser hver peer må bruge. Det er en kryptografisk kontrol og ikke et pakkefilter: en pakke, hvis indre kilde ikke matcher peerens liste, droppes inde i WireGuard, før nogen firewall på værten ser den. Begge opgaver deler én liste, og netop derfor opfører en liste kopieret fra et andet sted sig forkert på et sted, du ikke havde overvejet.

Klientblokken er, hvor det meste af denne forvirring starter. En delt tunnel angiver de fjernede netværk, og en fuld tunnel er det samme felt med et standardpræfiks:

[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 sig selv, og de er alternativer snarere end trin. Den første sender kun de to netværk gennem tunnelen; den anden sender enhver destination, idet posten ::/0 føjer IPv6 til IPv4-standarden. Uanset hvad du vælger, er disse præfikser hele rutningsbeslutningen for den peer, når wg-quick begynder at installere ruter.

Hubben har brug for en anden liste

En hub angiver hver klients tunneladresse som et værtspræfiks plus ethvert netværk, der reelt ligger bag den klient. At kopiere en klients brede liste til hver hub-peer fortæller hubben, at mange peers kan have de samme adresser som kilde, og det er ikke en adresseplan. Feltet Endpoint hører til et helt andet lag: det angiver peerens ydre adresse og port, aldrig en destination inde 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

Værtspræfikset bærer tunneladressen, og netværkspræfikset bærer det, der ligger bag klienten, og begge er nødvendige. Uden værtspræfikset kan hubben ikke returnere klientens egen trafik, og uden netværkspræfikset forbliver LAN'et bag det uopnåeligt; en peer uden noget bag sig får kun værtspræfikset.

At springe ruteinstallation over efterlader et hul

wg-quick, hjælperen der rejser et interface fra en konfigurationsfil, installerer interface-adresser og ruter som en del af det arbejde. At sætte Table = off fortæller hjælperen at springe rutearbejdet over, hvilket ikke installerer erstatninger og ikke gør det private netværk tilgængeligt. Når automatiske ruter allerede klarer arbejdet, er det den tydeligere konfiguration at angive de præfikser, du har brug for. At slå rutestyring fra og lade erstatningen være uskrevet er ikke et design, det er en udeladelse.

Det grundlæggende wg-værktøj opfører sig anderledes: det konfigurerer interfacet og rører aldrig ruter, så en opsætning bygget direkte på det har brug for sine egne rutekommandoer. Instruktioner skrevet til ét værktøj kan se forkerte ud, når de følges mod det andet. En vellykket ping er også et svagt bevis, fordi den afprøver én vej i stedet for hver den applikationsvej, du har brug for.

DNS og IPv6 afgøres hver for sig

Kontroller den DNS-serveradresse, tunnelen annoncerer, og bekræft, at der findes en rute til den adresse gennem de præfikser, du valgte. En resolverindstilling gør ikke resolveren tilgængelig, og en indsnævring af tunnelen kan stille fjerne den rute, der førte dertil. Undersøg også IPv6 for sig selv, fordi en korrekt IPv4-opdeling intet siger om en IPv6-standardrute, der stadig peger på det fysiske link. Tre separate beslutninger kan ændre sig på én gang, når du redigerer én peer-blok.

Åbn derefter en privat ressource og et almindeligt websted fra en kendt startkonfiguration. Hvis ressourcen svarer, og browsing stadig forlader gennem den lokale forbindelse, gør opdelingen, hvad du bad om. Hvis browsing bryder sammen i samme øjeblik, har tunnelen taget standardruten, og præfikslisten er stedet at kigge.