WireGuard: twee halve routes tegenover 0.0.0.0/0 in wg-quick

Twee /1-prefixen dekken precies dezelfde IPv4-adressen als één /0, en die gelijkheid geldt alleen binnen de lijst met toegestane prefixen van de peer. Ze houdt op te gelden op het moment dat het installatiegereedschap beslist hoe er gerouteerd wordt, omdat Linux wg-quick een standaardprefix als speciaal geval behandelt en niet als rekenkunde. De speciale tak installeert een aparte tabel, twee beleidsregels, een socketmark en instellingen voor de omgekeerde route die een paar halve routes nooit krijgt. Wanneer een proxy of een browser na de wijziging dus stopt met werken, zijn de prefixen het minst interessante deel van de wijziging.

De prefixlijst is niet de hele configuratie

AllowedIPs doet twee dingen tegelijk, en slechts één daarvan gaat over dekking. Voor WireGuard zelf is de lijst cryptosleutelroutering: hij bepaalt welke bestemmingen naar een peer toe versleuteld worden en welke bronadressen die peer mag gebruiken. Voor wg-quick dient dezelfde lijst ook als routespecificatie, en de route die hij oplevert hangt af van welke tak de lijst toevallig raakt. Identieke dekking bij twee verschillende lijstvormen zegt dus niets over een identieke hoststatus.

De standaardconfiguratie neemt die beslissing uit uw handen, omdat Table standaard automatisch is en het gereedschap kiest waar de routes landen. Een andere netwerkbeheerder, een distributiewrapper of een aangepaste Table-waarde verandert de uitkomst opnieuw, en daarom kan advies dat voor de ene host is geschreven op de volgende verkeerd lijken.

Wat de standaardtak toevoegt bovenop een route

Een /0-item stuurt wg-quick de standaardroute in: een aparte routingtabel ontvangt de standaard, één beleidsregel stuurt ongemarkeerd verkeer daarheen, een tweede regel houdt specifiekere routes van de hoofdtabel gezaghebbend, en de interface krijgt een firewallmark op zijn eigen socket. Die mark is de lusbewaking. De versleutelde datagrammen die het tunnelverkeer dragen, vertrekken met de mark gezet, zodat de regel die al het andere de tunnel in stuurt, niet de eigen transportpakketten van de tunnel opslokt.

Een paar /1-items neemt juist de gewone route. Twee routes landen in de geconfigureerde tabel, en niets van de omringende machinerie verschijnt, niet omdat het overbodig is, maar omdat dat codepad nooit is betreden.

Waar de twee opstellingen uiteenlopen

De afwijking toont zich eerst als recursie. Met de halve routes in de hoofdtabel valt het eigen transportadres van de peer binnen een tunnelprefix, zodat het pakket dat de tunnel zou moeten dragen, overeenkomt met een route die de tunnel in wijst. Iets moet het uitzonderen: een hostroute voor het huidige eindpunt, een met de hand gezette mark of een interfacespecifieke regel. Een hostroute werkt tot het adres van het eindpunt verandert, wat gebeurt bij op DNS gebaseerde eindpunten, rondzwervende clients en configuraties met meerdere peers.

Ten tweede verandert alles wat over marks redeneert zijn gedrag. Een transparante proxy die verbindingen lokaal omleidt, maakt nieuwe sockets waarvan de marks en bronnen afwijken van de oorspronkelijke clientstroom, en de beleidsregels die de standaardtak genereert, waren deel van wat die stromen uit elkaar hield. De eigen uitgaande verbinding van de proxy lezen is een andere oefening dan testen of de oorspronkelijke bestemming bereikbaar is.

Lees de regels en marks voordat u wijzigt

Leg de huidige toestand vast terwijl de tunnel gezond is, en daarna opnieuw na de wijziging, en vergelijk de twee dumps in plaats van te redeneren vanuit het configuratiebestand. Neem de beleidsregels, elke tabel, de mark van de interface en de vastgelegde eindpunten op.

ip rule show
ip -4 route show table all | grep -E 'default|wg1'
wg show wg1 fwmark
wg show wg1 endpoints

Als de eerste uitvoerregel de regel voor ongemarkeerd verkeer is kwijtgeraakt en de aparte tabel leeg is, draait de standaardtak niet en geen enkele prefix-rekenkunde herstelt de effecten ervan. Een mark van nul op een interface die er eerder een droeg, is hetzelfde signaal, zichtbaar in één enkele waarde.

Oefen het verlies van de tunnel voordat u uitrolt

Als de halve-route-opstelling de bewuste keuze is, moet die de ontbrekende onderdelen expliciet leveren: een eindpuntpad dat adreswijzigingen overleeft, het bedoelde gedrag wanneer de tunnel wegvalt en de gelijkwaardige behandeling voor IPv6. Schrijf dat op als eisen in plaats van het tijdens een storing te ontdekken. Oefen daarna de storing, want een volledige tunnel die stil terugvalt op de fysieke uplink is erger dan een die stopt met werken.

sudo ip -4 route add 198.51.100.20/32 via 192.0.2.1 dev eth0
ip -4 route get 198.51.100.20
sudo wg-quick down wg1

De routeopzoeking zou het eindpunt via de fysieke interface moeten oplossen zonder de tunnel te doorkruisen, en het neerhalen van de interface zou de host moeten achterlaten in de toestand die het ontwerp beloofde. Een proxy die na de vervanging werkt, bewijst dat de gegenereerde hosttoestand ertoe deed; hij bewijst niet dat luspreventie en gedrag in neergehaalde toestand de wijziging hebben overleefd.