WireGuard-hostprefix: waarom één adres werkt en de rest niet

De tunnel staat, de handshake gebeurt elke twee minuten, en precies één adres aan de andere kant antwoordt. Pings naar het tunneladres van de peer werken; alles erachter niet. Iemand leest de interfaceconfiguratie, ziet een hostprefix en concludeert dat het masker fout is. Het verbreden naar een /24 lost de ping een tijdje op en breekt daarna iets anders. Het prefix was nooit de schuld, en de ontbrekende route is niet degene die het masker beheert.

Wat het interfaceprefix werkelijk aanmaakt

Op Linux maakt het toewijzen van een adres aan een interface een verbonden route voor dat prefix aan. Wijs je een hostprefix toe, dan dekt de verbonden route één adres. Wijs je een /24 toe, dan dekt die 256 adressen, en elk daarvan geldt nu als bereikbaar via die link.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Een hostprefix is voor een point-to-pointtunnel een volstrekt normale keuze, want er is precies één peer aan de andere kant. Het derde commando is degene die de vraag van de gebruiker beantwoordt: het zegt welke interface de kernel voor die bestemming zou gebruiken, en het toont niets nuttigs als er geen route past.

Dat is de hele verklaring voor het symptoom. Eén adres antwoordt omdat er een verbonden route voor bestaat, of omdat de toegestane lijst van de peer het toevallig bevat. Voor al het andere is er geen route en het wordt weggegooid voordat WireGuard eraan te pas komt. De tunnel is al die tijd gezond, en daarom blijft de handshaketeller er geruststellend uitzien.

AllowedIPs zijn twee regels onder één naam

De toegestane lijst per peer van WireGuard doet twee taken tegelijk, en de configuratiesyntaxis laat ze als één lijken. Inkomend bepaalt zij welke bronadressen een peer mag presenteren. Uitgaand kiest zij naar welke peer een pakket gaat, door de meest specifieke overeenkomst te zoeken.

Geen van beide taken is routing. De kernel moet nog steeds beslissen dat een pakket op de tunnelinterface thuishoort voordat WireGuard ernaar kijkt, en die beslissing komt uit de routingtabel. Een peer-item met een brede toegestane lijst installeert niet vanzelf een route.

Daarom kan een configuratie compleet lijken en zich asymmetrisch gedragen. De client stuurt naar de overkant omdat er een route bestaat, en antwoorden komen nooit aan omdat de toegestane lijst van de overkant de bron van de client niet toestaat, of omdat de overkant geen terugweg heeft. Beide richtingen zijn afzonderlijke beslissingen met afzonderlijke faalwijzen. Opschrijven welke je test is de halve diagnose.

Waar de route vandaan komt

Als je wg-quick gebruikt, worden de routes voor je gegenereerd uit de toegestane lijst van elke peer, tenzij je Table = off hebt ingesteld en het beheer zelf hebt overgenomen. Dat is het gedrag dat het hulpmiddel documenteert, en het is de reden dat een configuratie zonder expliciete routedirectieven toch werkt.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Vergelijk de toegestane lijst met de routes die er werkelijk zijn. Een peer die een heel subnet toestaat maar alleen een hostroute opleverde, betekent dat de helper nooit liep, of dat je de interface rechtstreeks met wg en ip beheert; dan genereert niets routes voor je.

Beheer je het met de hand, dan is de route één regel en haar vorm expliciet: de bestemming via de interface, zonder gateway omdat de link point-to-point is. Haar toevoegen is geen noodoplossing voor een slecht prefix; het is de ontbrekende helft van een ontwerp dat routing bewust zelf beheert.

Een breder prefix voegt het peer-item niet toe

De verleidelijke oplossing is het adres naar een /24 te veranderen zodat de verbonden route het LAN van de server dekt. Het lijkt te werken, en de reden dat het lijkt te werken is dat de verbonden route nu past, niet dat WireGuard iets nieuws heeft geleerd.

Wat je ook deed, is het hele bereik opeisen als rechtstreeks bereikbaar via die link, inclusief adressen die bij andere peers horen of bij een LAN dat feitelijk achter de server ligt. Verkeer naar die adressen komt nu de tunnel in, en of het er aan de andere kant uitkomt hangt af van de routing en de toegestane lijsten van de server.

De cryptokant blijft hoe dan ook onaangetast. WireGuard heeft nog steeds een item in de toegestane lijst nodig dat de bestemming dekt om een peer te kiezen, en de overkant heeft nog steeds een item nodig dat jouw bron dekt om die te accepteren. Een breder interfaceprefix kan geen van beide leveren.

Bevestig beide richtingen voordat je iets verandert

Werk de twee uiteinden apart af en schrijf op wat elk zegt. Op de client de route en het peer-item; op de server het spiegelbeeld plus zijn eigen retourpad:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

De capture is wat geschillen over de richting beslist. Als uitgaande pakketten op de tunnelinterface verschijnen en de server niets logt, verwerpt de overkant ze, meestal omdat jouw bron buiten haar toegestane lijst valt. Als er helemaal niets verschijnt, ontbreekt de route of wijst zij elders heen.

Repareer dan het smalste uiteinde. Een item in de toegestane lijst aan serverzijde voor jouw clientadres en een item aan clientzijde voor het bestemmingssubnet is de normale vorm, en zij laat het interfaceprefix met rust. Verbreed het prefix alleen als het adresplan echt een gedeeld subnet op die link wil, en doe het als een planwijziging in plaats van als een debuggingstap.