Een Linux-VPN-interface inspecteren met ip link, laag per laag

Het clientpictogram zegt verbonden, de interface bestaat, en de toepassing bereikt nog steeds niets. Die combinatie komt vaak voor, omdat een virtuele interface kan blijven bestaan terwijl de externe peer, de adressen of de routes ontbreken. ip link is het juiste eerste hulpmiddel, en ook het makkelijkst te overinterpreteren. Flags en tellers beschrijven één laag, en de lagen daarboven falen onafhankelijk. Het is ook het hulpmiddel dat mensen citeren als ze willen bewijzen dat de tunnel actief is, precies de bewering die het op zichzelf niet kan ondersteunen.

Lees de interface voordat je het pictogram leest

Begin met ip -details link show dev tun0 zoals gedocumenteerd in de ip-link-handleiding, en vervang de interfacenaam door degene die je client echt bezit in plaats van de conventionele naam. Flags, type, MTU en interface-identiteit zijn nuttige waarnemingen. De toestandsaanduiding van een virtuele interface hoeft zich niet te gedragen als de carrier-indicatie van een fysieke kabel, dus behandel UP als een uitspraak over de interface en niet over de tunnel.

Die distintie verklaart het verwarrendste geval: een interface die blijft bestaan terwijl de externe kant opnieuw verbindt of onbereikbaar is.

Persistentie-instellingen kunnen de link juist in stand houden zodat het opnieuw verbinden hem niet opbouwt, wat betekent dat aanwezigheid geen gezondheid is.

Voeg tellers toe en een verzoek dat ze zou moeten gebruiken

Gebruik de ondersteunde statistiekweergave, ip -s link show dev tun0, en noteer de packet- en bytetellers in beide richtingen. Genereer dan een onschadelijk verzoek dat de interface zou moeten passeren en vergelijk de relevante richting. Een verzoek dat de directe route van een andere toepassing nam, zal die tellers niet verplaatsen, en dat is precies het punt.

Als de verzendteller beweegt en de ontvangstteller niet, dan is het pakket vertrokken en is er niets teruggekomen. Dat is een ander probleem dan een interface die nooit iets heeft gedragen. Als beide tellers bewegen en de toepassing faalt nog steeds, zit de fout boven de interface, wat vooruitgang is in plaats van een doodlopende weg.

Neem de meting twee keer, één keer voor en één keer na, in plaats van één momentopname te vertrouwen.

Adressen en routes zijn aparte stappen

Een link kan bestaan zonder het prefix, de resolverconfiguratie of de route die de toepassing nodig heeft. Controleer het adres met ip address show dev tun0, en controleer dan welke route de bestemming zou kiezen met ip route get voor het werkelijke doel. Die drie waarnemingen beantwoorden drie verschillende vragen, en alleen de laatste gaat over doorsturen.

Voor IPsec kunnen beveiligingsbeleid en associatiestatus ook van belang zijn, en niet elk IPsec-ontwerp verschijnt als een simpele tun-interface. Zoeken naar een tun-apparaat dat nooit zou bestaan is een snelle manier om de verkeerde conclusie te trekken.

Leg de exacte naam, de namespace en de tijd vast bij elke uitvoer die je bewaart, want dezelfde ogende naam in een andere container of een herstelde sessie vertegenwoordigt een heel andere context.

Verwijder niet wat je niet hebt geidentificeerd

Een onbekende interface is niet automatisch verouderd. Identificeer de eigenaar voordat je iets verwijdert, en gebruik de gedocumenteerde teardown van de client of de beheerde configuratie wanneer verwijdering echt bedoeld is. Een actieve tunnel verwijderen om te zien wat er gebeurt is een test die een vraag beantwoordt die niemand stelde.

Als de interface toebehoort aan een container-runtime of een netwerknamespace die je niet hebt gemaakt, is de eigenaar één commando verwijderd en de moeite waard om eerst te vinden.

Die voorzichtigheid geldt ook voor ip link set down, dat omkeerbaar lijkt en dat vaak niet is.

Wat de inspectie je moet opleveren

Een goede inspectie eindigt met vier feiten: de interfacenaam en namespace, de flags en MTU, de tellerdelta van een echt verzoek, en de route en het adres die de toepassing werkelijk nodig heeft. Met die feiten opgeschreven is de volgende stap duidelijk en hoort die bij een specifieke laag. Zonder hen is elke volgende wijziging een gok met een terugdraaiplan.

Vergelijk die vier feiten met dezelfde vier uit een werkende sessie. Als de interfacenaam en namespace overeenkomen maar de tellerdelta nul is, heeft het verzoek de tunnel nooit bereikt. Als de tellerdelta gezond is en de route elders heen wijst, is de tunnel in orde en de routering niet. Die vergelijking is wat een berg uitvoer in een beslissing verandert.

Bewaar de uitvoer bij het ticket, want een latere vergelijking is alleen nuttig als je kunt zien wat er veranderd is.

Sluit dan de cirkel door de toepassing opnieuw te testen, want de interface was nooit wat de gebruiker interesseerde.