WireGuard volledige tunnel: AllowedIPs 0.0.0.0/0 is niet genoeg

Het 0.0.0.0/0, ::/0 in de AllowedIPs van een peer zetten is de stap die iedereen onthoudt, en die bepaalt alleen welk verkeer de peer mag dragen. Deze prefixen maken geen routes, sturen niets door aan de andere kant en laten de resolver van elke toepassing precies waar die was. Vier afzonderlijke dingen moeten tegelijk gelden wil een volledige tunnel een volledige tunnel zijn, en ze kunnen het best in de volgorde hieronder worden gecontroleerd, omdat een latere controle een eerdere niet kan redden. Elke controle hieronder is een feit dat je van een machine kunt aflezen, niet een instelling waarvan je hoopt dat die is toegepast.

Wat het peer-prefix selecteert, en wat niet

AllowedIPs is zowel een selectie als een autorisatie. Het vertelt de lokale kant welke bestemmingen naar deze peer mogen worden gestuurd, en het vertelt de ontvangende kant welke bronadressen deze peer mag presenteren. Dat is het hele werk. Niets in die beschrijving maakt een route op de host, schakelt doorsturen aan de andere kant in of raakt naamresolutie aan.

Daarom kan een configuratie er compleet uitzien en zich als een gesplitste tunnel gedragen. Het prefix zegt dat de peer alles zou accepteren; de routetabel van de host bepaalt wat daar werkelijk aankomt, en de gateway bepaalt of er iets uitgaat. Geen van die drie beslissingen woont in het peer-gedeelte.

De client routeren, niet alleen de peerlijst

Beheerders zoals wg-quick programmeren de routetabel van de host voor je, daarom gedragen twee identieke configuratiebestanden zich anders afhankelijk van hoe de interface omhoogkwam. Een minimaal profiel is kort genoeg om in één keer te lezen:

[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

Twee details dragen het werk. Het veld Address is één hostprefix in plaats van een subnet waarvan de client denkt dat hij het bezit, en het is de beheerder die de standaard-AllowedIPs omzet in een echte standaardroute. Breng hetzelfde bestand omhoog met ip link en wg setconf en er verschijnt helemaal geen route, wat op een kapotte tunnel lijkt en in werkelijkheid een gezonde is waarbij de routeringsstap is overgeslagen. De handleiding van wg-quick documenteert het routeren en het Table gedrag dat die beheerders toevoegen.

Lees het resultaat in plaats van het bestand: ip route get 1.1.1.1 zou de tunnelinterface moeten noemen, en wg show zou een recente handshake moeten melden met een bewegende overdrachtsteller. Een handshake zonder route betekent dat de beheerder nooit liep, en het profiel opnieuw bewerken lost dat niet op. Start de interface zoals de gebruiker hem start, anders meet de test je shell in plaats van de uitrol.

Het eindpunt buiten de tunnel houden

Een volledige tunnel vangt elke bestemming, ook degene waarmee hij moet praten om te bestaan. Beheerders lossen dat op door een hostroute voor het eindpunt via de oorspronkelijke gateway toe te voegen, daarom bevat een correcte configuratie bijna altijd één bewuste uitzondering. De helft van de configuratie met een beheerder en de andere helft met de hand toepassen is de gebruikelijke manier waarop deze uitzondering verloren gaat.

Als het eindpunt een hostnaam is die naar meerdere adressen oplost, of naar een familie die je niet draagt, veroudert de uitzondering slecht en kan de tunnel falen na een herverbinding die routineus leek. Zet het eindpunt vast op een adres dat je beheert, of bevestig dat de beheerder het opnieuw beoordeelt, en lees de hostroute opnieuw na elke netwerkwijziging.

Hetzelfde mechanisme verklaart waarom een volledige tunnel en een captive portal vechten. Het portaal verwacht het verkeer te onderscheppen dat je tunnel nu vangt, dus op hotel- en luchthavennetwerken breng je de tunnel omhoog na de portaal-login, nooit daarvoor.

Doorsturen en de terugweg op de gateway

Schakel op de gateway het doorsturen in voor de familie die je draagt, sta de forward-keten in beide richtingen toe wanneer je vertaalt, en bevestig de terugweg met een bronspecifieke opzoeking. Niets daarvan volgt uit een geslaagde handshake, want een handshake bewijst alleen dat de twee peers UDP kunnen uitwisselen. Hij zegt niets over wat er daarna met het gedecapsuleerde pakket gebeurt.

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

De opzoeking draait op de gateway en niet op de client, anders lees je een andere routetabel. Als hij de verkeerde interface noemt, of meldt dat er geen route is, dan levert geen enkele wijziging aan de clientkant een internetuitgang op. Wanneer de gateway clientadressen onderweg naar buiten vertaalt, hangt het antwoord van die vertaaltoestand af, dus de regel moet voor beide richtingen van de stroom bestaan en niet alleen voor de uitgaande.

DNS en de fouttoestand, apart getest

Het protocol zelf configureert de resolver van geen enkele toepassing. wg-quick past de regel DNS toe via de resolverintegratie van de distributie, containers en browsers met hun eigen stacks kunnen hem negeren, en daarom kan een naam falen terwijl de tunnel pakketten perfect draagt. Test met een hostnaam in plaats van een adres, en noteer welke server antwoordde in plaats van aan te nemen dat die uit het profiel dat deed.

Adresfamilies zijn een aparte test met een apart antwoord. Een standaardroute voor v4 zegt niets over wat de v6-verbinding van een toepassing zal doen, en een tunnel die de tweede familie stil laat lekken is erger dan een die luidruchtig faalt. Vraag een naam over elke familie, lees de interface die elk verzoek gebruikte, en controleer de vertaaltellers voor en na, want een regel die nergens op past ziet er identiek uit als een ontbrekende regel.

Ten slotte test je de toestand die je wilt wanneer de tunnel stopt. Een volledige tunnel zou gesloten moeten falen voor het verkeer dat hij opeist: als de interface wegvalt en toepassingen stil doorgaan over de fysieke verbinding, is het ontwerp een gesplitste tunnel met extra stappen. Schrijf het bedoelde foutgedrag op, controleer het bewust, en sluit af met het vastleggen van de vier antwoorden — welke beheerder de interface omhoogbrengt, welke route de standaard draagt, wie op de gateway doorstuurt en vertaalt, en welke resolver antwoordt.