Recursieve routering: wanneer de tunnel zijn eigen pakketten vangt

De tunnel komt op, het log toont een voltooide handshake, en een seconde later sterft dezelfde sessie en verbindt opnieuw in een lus. Dat patroon heeft een specifieke oorzaak: de route naar de server wijst nu de tunnel in, dus de pakketten die de tunnel dragen worden door de tunnel verzonden. Aan de authenticatie is niets veranderd, en daarom maakt opnieuw inloggen geen verschil. Vergelijk het buitenste pad voor en na de routewijziging en de recursie wordt zichtbaar.

Controleer eerst het buitenste pad

Er zijn twee pakketten in het spel, niet één. Het binnenste pakket hoort bij de toepassing en zou versleuteld moeten zijn, terwijl het buitenste pakket aan de server is geadresseerd en hem moet bereiken over een pad dat niet van de tunnel afhangt.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Vraag de kernel naar de route naar het adres van de server nadat de tunnel op is, en opnieuw nadat de standaardroute is gewijzigd. Een volgende hop die op het tunnelapparaat landt, is de recursie, en die is zichtbaar zonder enige pakketopname. Een binding aan de interface, markeringen of een netwerknaamruimte kunnen een gewone opzoeking onvolledig maken, dus gebruik de context die de client zelf gebruikt. Als het antwoord juist lijkt maar de sessie blijft lussen, lees dan de regels van het routeringsbeleid en niet alleen de hoofdtabel.

Waarom de sessie even overleeft

De handshake is voltooid voordat de nieuwe route wordt geïnstalleerd, dus de eerste seconden lijken gezond. Zodra de client de standaardroute toevoegt, volgt het volgende buitenste pakket die de interface in waar dat pakket doorheen moet. De server ziet niets, de client verstuurt opnieuw, en de poging verloopt of beëindigt de sessie en begint overnieuw.

Die volgorde verklaart waarom een tunnel op een laptop kan werken en op een router kan falen, en waarom de storing vaak begint wanneer het verkeer start en niet bij het verbinden. Ze verklaart ook de lus: elke herstart herstelt de sessie voordat de route dat onmogelijk maakt.

Zoek uit wie de uitzondering van het eindpunt bezit

Ondersteunde clients regelen hun eigen uitzondering: een hostroute naar de server via de oorspronkelijke gateway, of een markering die de buitenste socket buiten de tunnel houdt. De vraag is of iets anders die heeft verwijderd of overschreven.

Bij routegebaseerde IPsec onderzoekt u de beleidsselectoren die bepalen welke pakketten de tunnel in gaan, en bevestigt u dat het adres van de peer daarvan is uitgesloten. Bij WireGuard houden de firewallmarkering van de interface en de beleidsregels de transportpakketten buiten de tunnel, dus een handmatig toegevoegde standaardroute kan die ordening breken. Een tweede VPN-profiel of een beheerscript dat de standaardroute herschrijft is een veelvoorkomende schuldige. Brede omzeilingsregels die één voor één worden toegevoegd zijn het gebruikelijke resultaat, en ze veranderen een routeringsfout in een tabel die niemand kan onderhouden.

Controleer opnieuw na een netwerkwijziging

Een hostroute via een Wi-Fi-gateway is juist tot de machine naar een ander netwerk verhuist. Dan komt hetzelfde symptoom terug zonder enige configuratiewijziging.

Noteer het adres van het eindpunt, de route voor en na het verbinden, en de interface die elk daarvan gebruikte. Die drie feiten scheiden meestal een clientfout van een overschrijving, en ze overleven de persoon die ze verzamelde.

Verbind opnieuw op het nieuwe netwerk en herhaal de uitlezing. Als de uitzondering weer ontbreekt, hoort de correctie in het profiel dat hem bezit, niet in een eenmalige opdracht die tijdens een storing is getypt.