WireGuard-standaardroute-lus: vind het eindpuntpad

De interface komt op, de peer-configuratie ziet er correct uit en er wordt nooit een handshake voltooid. Een standaardroute door de tunnel toevoegen is de stap die dit vaak veroorzaakt: dezelfde routetabel bepaalt nu waar de eigen versleutelde pakketten van de tunnel naartoe moeten, en het antwoord dat die oplevert gaat terug de tunnel in. Niets kan het buitenste pakket dragen dat het binnenste zou dragen, dus de verbinding stopt voordat ze begint. De reparatie is klein, maar heeft een volgorde, en de verificatie is belangrijker dan de wijziging.

Bevestig de lus voordat je een route wijzigt

Lees het huidige eindpuntadres van de peer en vraag dan aan de routeringsstack waar een pakket naar dat adres naartoe zou gaan. Als het antwoord de tunnelinterface noemt, is de lus bevestigd en is verdere diagnose niet nodig. Sla beide uitvoer op in het wijzigingsrecord voordat je iets aanraakt, want de vergelijking na de reparatie zijn dezelfde twee opdrachten. Een lus is niet subtiel zodra je hem ziet; de moeilijkheid is dat de interface er gezond uitziet terwijl het gebeurt.

sudo wg show wg1 endpoints
ip route get 198.51.100.20
ip rule show

Neem de beleidsregels op in die registratie. Een standaardroute die er in de hoofdtabel correct uitziet, kan nog steeds verliezen van een regel die een andere tabel kiest voor gemarkeerd of ongemarkeerd verkeer, en de lus zal terugkeren met een routetabel die er in orde uitziet.

Lees het eindpuntpad, niet het tunnelpad

Het eindpuntpad is de route die de versleutelde datagrammen nemen naar het openbare adres van de peer, en het moet buiten de tunnel blijven zolang de tunnel bestaat. Het tunnelpad is alles wat de peer mag dragen. Die twee paden delen één routetabel, en dat is precies waarom één allesomvattende vermelding ze in elkaar kan laten instorten. Het tunnelverkeer en het eigen transport van de tunnel scheiden is het hele ontwerpprobleem, en elk ondersteund hulpmiddel lost het ergens net anders op.

Controleer beide adresfamilies afzonderlijk als de interface beide draagt. Een werkende IPv4-uitsluiting zegt niets over de vraag of het IPv6-eindpunt nog bereikbaar is, en een gemengde configuratie kan lijken te werken totdat het IPv6-adres van de peer wordt gekozen.

Herstel het eindpuntpad met één samenhangende wijziging

Er bestaan twee ondersteunde benaderingen, en ze mengen is hoe een werkende opstelling onvoorspelbaar wordt. De eerste is het hulpmiddel dat de interface bezit de hele tunnel laten beheren: wg-quick heeft een eigen behandeling voor een standaard peer-bereik die een aparte tabel, beleidsregels en een socket-markering installeert, wat de buitenste pakketten uit de tunnel houdt. Laat die machinerie intact in plaats van de helft ervan met de hand na te bouwen. Een opstelling die een handmatig toegevoegde standaardroute mengt met een beheerder die al markeringen en regels installeert, faalt vaak na opnieuw verbinden, wanneer de beheerder toestand herschrijft die de handmatige stap veronderstelde.

De tweede is een handmatig ontwerp waarbij het eindpunt een expliciete hostroute via de fysieke gateway krijgt. Voeg die route toe vóór de standaardroute, vervang in plaats van toe te voegen zodat een verouderde vermelding niet kan winnen, en bevestig daarna de opzoeking.

sudo ip route replace 198.51.100.20/32 via 192.0.2.1 dev eth0
ip route get 198.51.100.20
sudo ip route add default dev wg1

Verifieer en houd dan een weg terug

Een handshake-tijdstempel die vooruitgaat is het eerste bewijs, en dat is sterker dan een interface die alleen maar bestaat. Volg het met een applicatietest door de tunnel, breng dan de interface expres naar beneden en bevestig dat de host terugkeert naar een bruikbare toestand in plaats van een standaardroute te houden die naar niets wijst. Die laatste stap slaan mensen over, en die bepaalt of een herstart de machine zonder verbinding achterlaat.

sudo wg show wg1 latest-handshakes
sudo wg-quick down wg1
ip route show default
ip route get 198.51.100.20

Sla vóór dit alles de huidige routeringstoestand op en zorg dat er een ingang is die niet van de tunnel afhangt: een console, een out-of-band-beheeradres of een collega ter plaatse. Een externe machine die haar standaardroute verliest, is niet te herstellen via de verbinding die ze net verloor, en de veiligste runbook-stap is degene die vóór de eerste opdracht wordt genomen.