WireGuard: geen route naar peer na een subnetwissel — twee uitwegen

De handshake is vers in wg show, het endpoint klopt, de sleutels zijn nooit gewijzigd — en ping zegt nog steeds dat er geen route naar peer is. Je hebt het subnet van de tunnel een uur geleden gewijzigd. Dat symptoom is de signatuur van een prefixverschil en niet van een sleutelprobleem: WireGuard rondde de handshake af en liet de gegevens daarna vallen omdat een bronadres niet langer overeenkomt met wat de ontvangende peer accepteert. Er zijn twee verstandige manieren om een subnetwissel door te voeren, en ze falen op verschillende plaatsen.

Twee manieren om de wijziging door te voeren, en wat elk kost

Optie A is hernummeren ter plaatse: pas het interfaceadres, de peerranges, de routes en elke kopie van de configuratie aan en herlaad daarna. Optie B is een tweede interface op het nieuwe prefix naast de oude bouwen, peers overzetten en de oude interface verwijderen zodra het verkeer echt is verhuisd.

De half toegepaste toestand maakt optie A gevaarlijk, omdat die er niet kapot uitziet. De interface komt omhoog, de handshake slaagt en alleen het datapad faalt. Optie B kost meer werk maar houdt een werkend pad in leven terwijl je elke verwijzing vindt.

Wat aan jouw kant samen moet bewegen

Vier dingen op de lokale host beschrijven hetzelfde subnet, en een wijziging aan één is een wijziging aan alle: het adres van de interface, de AllowedIPs van elke peer, de route die het systeem voor die bestemmingen gebruikt en alles wat de beheerder namens jou installeert. Met wg-quick worden de laatste twee bij elke keer dat de interface omhoog komt uit de configuratie gegenereerd, dus een verouderde kopie herinstalleert stil het oude prefix.

Vergelijk wat geconfigureerd is met wat live is in plaats van een van beide te vertrouwen:

wg show
wg showconf wg0
ip addr show wg0
ip route get 10.90.0.5

De routeopzoeking is de stap die mensen overslaan. Die antwoordt wat de kernel werkelijk voor een bestemming zou doen, inclusief een specifiekere route die een beheerder of container-runtime heeft achtergelaten. Als die een andere interface dan de tunnel meldt, is de configuratie niet het probleem.

Pas voor een draaiende interface het bewerkte bestand toe zonder de tunnel af te breken:

wg syncconf wg0 <(wg-quick strip wg0)

Dat werkt peers en ranges ter plaatse bij. Het werkt het interfaceadres of de routes niet bij, omdat dat geen WireGuard-instellingen zijn — een hernummering vereist dus nog steeds dat de interface opnieuw wordt gemaakt of het adres met ip wordt gewijzigd, en daarna dat de routering opnieuw wordt gecontroleerd.

Wat aan de verre kant samen moet bewegen

Hier sterft een subnetwissel meestal. AllowedIPs is niet alleen een routeringshint; het is ook de lijst met bronadressen die een peer mag presenteren. Wanneer je clients hernummert en de AllowedIPs van de server op het oude prefix laat staan, accepteert de server de handshake, ontvangt de versleutelde pakketten en gooit ze weg omdat de interne bron niet overeenkomt met een bereik dat hij aan die peer koppelt. Er wordt geen fout gelogd en de client ziet een time-out.

Werk dus de ontvangende kant bewust bij: de peer-entry op de server moet het nieuwe clientprefix vermelden, de eigen terugroute van de server moet voor dat prefix naar de tunnel wijzen, en elk stroomafwaarts netwerk achter de server moet het nieuwe pad leren. Firewallbeleid dat het oude bereik noemde heeft dezelfde behandeling nodig, en alles wat op bron gebaseerde selectie doet ook.

De diagnostiek die de twee storingen scheidt is goedkoop. Een recente handshake zonder gegevens betekent dat de tunnel staat en dat de interne adressering het niet eens is. Helemaal geen handshake betekent dat je naar bereikbaarheid of sleutels kijkt. Draai geen sleutels voor een prefixprobleem; dat reset het enige dat werkte.

Verouderde kopieën die je bewerking overleven

Een bestand bewerken is niet hetzelfde als het draaiende systeem wijzigen, en de kopieën zijn talrijker dan mensen verwachten: de unit of beheerder die de interface bezit, een tweede profiel met dezelfde naam in een andere map, een container met de configuratie in een image gebakken, een router-UI met zijn eigen bewerkte versie en een clientapp die bij het starten een opgeslagen tunnel opnieuw importeert. Elk daarvan kan het oude prefix herstellen nadat je wijziging compleet lijkt.

Namen reizen ook. Als de numerieke route werkt maar de hostnaam faalt, wijst een interne DNS-record of een serviceconfiguratie nog naar het oude tunneladres. Repareer de verwijzing in plaats van elke peerrange te verbreden, wat het echte probleem zou bedekken en tegelijk de bron-ACL zou vergroten.

Houd één herstelpad open terwijl je werkt: een tweede manier om op de host te komen, een seriële console of een geplande terugdraaiing van de configuratiebestanden. Een tunnelwijziging die je buiten de machine sluit die je wijzigt, is de meest voorkomende manier waarop deze taak een avond wordt.

Kiezen tussen de twee, en de omschakeling verifiëren

Kies A wanneer je elke peer bezit, het aantal klein is en een korte onderbreking acceptabel is. Kies B wanneer peers verre handen zijn die je niet beheert, wanneer een verbinding tussen locaties moet blijven staan of wanneer je niet kunt garanderen dat elke kopie in één doorgang wordt bijgewerkt. Voeg in dat geval het nieuwe prefix aan beide interfaces toe, verplaats peers één voor één, houd het verkeer op de nieuwe in de gaten en verwijder pas daarna de oude interface en zijn routes.

Onder beide opties is de wijziging klaar wanneer vier controles slagen: de handshake is recent, de routeopzoeking voor een bestemming met het nieuwe prefix noemt de tunnel, een lading van een paar honderd bytes gaat in beide richtingen over, en hetzelfde geldt na een herstart van de host of de beheerder. De wg(8)-handleiding is de referentie voor wat AllowedIPs in elke richting betekent, en het loont om die opnieuw te lezen voordat je een bereik verbreedt om een symptoom te laten verdwijnen.

• Recente handshake en geen gegevens: kijk naar de AllowedIPs bij de ontvanger voordat je sleutels aanraakt.
• Routeopzoeking wijst naar de verkeerde interface: een beheerder of container bezit de route, niet jouw bestand.
• Numeriek adres in orde en hostnaam kapot: een oude verwijzing, geen routeringslus.
• De wijziging is pas compleet wanneer een herstart nog steeds het nieuwe prefix gebruikt.