Waarom een verwijderde VPN-route terugkomt na opnieuw verbinden

Een route die je handmatig hebt verwijderd, is na de volgende nieuwe verbinding terug, en de tabel ziet er precies zo uit als voorheen. Dit is geen routingbug: iets maakt de vermelding opnieuw aan vanuit de configuratie of vanuit een actie in de levenscyclus van de verbinding. De meeste runbooks stoppen bij de actieve tabel, waardoor het verwijderen een minuut lijkt te werken en daarna mislukt. Identificeer de eigenaar, wijzig die en bewijs het bij een nieuwe verbinding.

Wie de route heeft geïnstalleerd

Begin met een lijst met kandidaten in plaats van met een oplossing. Een VPN-profiel kan zijn eigen routes meedragen, een server kan ze bij het verbinden pushen, een netwerkbeheerprofiel kan ze declareren, een opstarteenheid of script kan ze toevoegen, en IPsec-implementaties installeren routes voor de verkeersselectors die ze onderhandelen. Policy-routingregels kunnen verkeer ook volledig naar een andere tabel omleiden.

Timing scheidt ze sneller dan configuratiearcheologie. Een vermelding die verschijnt op het moment dat de interface omhoogkomt, hoort bij de client; een die een seconde later binnenkomt, kwam meestal van een server-push; een die bij het opstarten bestaat, hoort bij de opgeslagen configuratie. Noteer de tabel voor en na een verbinding, een verbreking en een herstart, en het patroon noemt de eigenaar. Een route die alleen terugkomt wanneer de dienst opnieuw start, wijst op een eenheid en niet op de VPN.

Lees de tabel voordat je hem wijzigt

Kijk naar het eigen beeld van de kernel in plaats van een opgeslagen bestand. De protocolkolom laat zien wat elke vermelding heeft geïnstalleerd:

ip route show
ip route show table all
ip rule show

Het protocolveld, de metriek en het tabelnummer vertellen je of je naar een statische vermelding, een door de kernel gemaakte vermelding of iets door een daemon toegevoegds kijkt. De regellijst is belangrijk omdat een opzoeking de hoofdtabel volledig kan verlaten, waardoor een wijziging daar onzichtbaar wordt voor de applicatie die je aan het debuggen bent. Lees de regel van links naar rechts: bestemming, gateway, apparaat, protocol en metriek.

Vraag daarna aan de kernel welke route hij werkelijk zou gebruiken. Een beschermd adres is een betere sonde dan een openbaar:

ip route get 10.20.5.7

Wijzig de eigenaar, niet het symptoom

Zodra de eigenaar bekend is, hoort de wijziging bij die eigenaar. Verwijder de route uit het clientprofiel, corrigeer de gepushte route op de server, of bewerk de netwerkbeheerverbinding in plaats van een concurrerende permanente route toe te voegen die op metriek wint. Twee regels die elkaar bestrijden leveren een tabel op die niemand later kan uitleggen.

Behoud de uitsluiting van het eindpunt. Een hostroute die het eigen openbare adres van de VPN-server via de fysieke gateway stuurt, is wat de buitenste tunnelpakketten laat stromen; verwijder hem en de tunnel probeert zichzelf te dragen. Bij een split-tunnelprofiel geldt dezelfde zorg voor de lokale subnetten die de tunnel moeten omzeilen.

Verbind opnieuw en controleer beide paden

Verbind opnieuw en controleer dan beide bestemmingen in één keer. Het beschermde adres en het uitgesloten eindpunt beantwoorden verschillende vragen:

ip route get 10.20.5.7
ip route get 198.51.100.20

De eerste zou via de tunnelinterface moeten worden opgelost en de tweede via de fysieke gateway. Als beide via de tunnel worden opgelost, ontbreekt de uitsluiting; als geen van beide, heeft de profielwijziging niet gewerkt en kijk je naar een andere eigenaar dan je dacht.

Schrijf het doel van de route, de eigenaar en hoe lang die moet leven op. Die notitie is wat de volgende persoon ervan weerhoudt dezelfde cyclus van verwijderen en opnieuw verbinden te herhalen.