Hoe je VPN-geduwde routes van statische onderscheidt op Linux

Een prefix verschijnt op de laptop wanneer de tunnel omhoog komt, dus het voelt alsof de VPN hem heeft geïnstalleerd. Dat kan, maar hetzelfde resultaat kan komen van een clientscript dat bij verbinden draait, een verbindingsprofiel dat het subnet vermeldt, of een statische route die er altijd al was en pas ging werken toen de interface bestond. De verkeerde eigenaar kiezen betekent dat de route na elke opruiming terugkomt, en de volgende persoon herhaalt dezelfde oplossing. De volgorde hieronder scheidt de drie voordat er iets verandert.

Stap 1: benoem het mechanisme dat prefixen installeert

Verschillende protocollen leveren bereikbaarheid op verschillende manieren, en dat allemaal een aankondiging noemen verbergt het onderscheid. Een OpenVPN-server duwt een routedirectief over het controlekanaal en de client installeert het tenzij een pull-filter het blokkeert. Een WireGuard-configuratie vermeldt toegestane prefixen lokaal, die de client zowel voor cryptosleutel-routing als voor de routes die hij toevoegt gebruikt. Een IPsec-tunnel spreekt verkeersselectoren af met de peer, en de kernel installeert routes uit die selectoren.

Bepaal welke daarvan je tunnel gebruikt voordat je een tabel leest. Een route die bij verbinden wordt geduwd is geen aankondiging van een routingprotocol en belooft niet dat de prefix achter het verre uiteinde bereikbaar is. Noteer het mechanisme naast de prefix, want het bepaalt waar de oplossing thuishoort.

Stap 2: vergelijk de tabel over een verbinding

Bewaar de hoofdtabel met de tunnel omlaag, breng hem omhoog, bewaar opnieuw en vergelijk de twee opnames. Alles wat verscheen hoort bij de levenscyclus van de verbinding, en alles wat bleef hoort bij de lokale configuratie.

Leg hem vast met ip route show table main > /tmp/route-down.txt, verbind en leg opnieuw vast. Doe hetzelfde voor ip -6 route als de site IPv6 gebruikt, want een ontbrekende prefix daar veroorzaakt storingen die niets met routing lijken te maken.

Stap 3: lees de metriek, niet alleen de aanwezigheid

Twee vermeldingen voor dezelfde prefix kunnen naast elkaar bestaan, en de kernel kiest de laagste metriek. Een statische route met metriek 50 blijft winnen van een geduwde route op 100 ook al zijn beide zichtbaar, daarom zijn 'de route is er' en 'het verkeer gebruikt hem' verschillende uitspraken.

Vraag de kernel rechtstreeks met ip route get 10.20.5.7 en lees de interface die hij meldt. Als verkeer via de fysieke adapter naar buiten gaat terwijl een tunnelroute in de tabel staat, verklaren de metriek of de prefixlengte dat, niet de VPN-client. Herhaal de opzoeking voor een host waarvan je weet dat hij achter de tunnel zit en een waarvan je weet dat hij dat niet doet, en het verschil laat zien of de splitsing zich gedraagt zoals bedoeld.

Stap 4: vind de vermeldingen die de tunnel overleven

Statische routes overleven een verbreking door ontwerp, en daar komen verouderde vermeldingen vandaan. Een permanente route naar een interface die niet meer bestaat kan een subnet stil verzwelgen, en een naar een hergebruikte interfacenaam kan na een herstart privéverkeer door de verkeerde deur sturen.

Controleer de permanente kant op de plek die je distributie gebruikt, of dat nu een systemd-networkd-unit, een NetworkManager-profiel of een script in de up-map van de client is. De live tabel repareren met ip route del houdt alleen tot de volgende verbinding. Behandel dat verwijderen als een test van de hypothese en niet als de reparatie.

Waar het verre uiteinde de verkeerde dekking levert, leg het bij de operator neer in plaats van alles te filteren. Alle geduwde instellingen laten vallen gooit ook DNS en split-tunnelbeleid weg waarvan het profiel afhankelijk is.

Stap 5: bevestig de terugweg voordat je de client de schuld geeft

Voor site-naar-site of een subnet achter de tunnel heeft de verre kant een route terug naar je clientadres nodig en doorsturen aan op de gateway. Een eenrichtingspad ziet er precies uit als een client-routingfout, behalve dat de handshake en het uitgaande pakket beide slagen.

Filteren van de terugweg voegt een tweede valkuil toe op Linux-gateways. Een antwoord dat op een andere interface aankomt dan de route voorspelt, wordt in strikte modus weggegooid, en asymmetrische paden via twee providers lokken dat betrouwbaar uit. De drop-tellers op de gateway, niet op de client, vertellen je of het filteren de oorzaak is.

Stap 6: test de bron, niet de ping

Zodra de gekozen route klopt, open je de werkelijke bron en bevestigt het terugverkeer. Een ping-antwoord bewijst het pad in één richting en niets over de dienst, en een dienst die antwoordt op een gecachte verbinding bewijst nog minder.

Herhaal daarna de hele controle na opnieuw verbinden. De waarde van de volgorde is dat hij voorspelt wat de volgende verbinding gaat doen, daarom horen zowel de vergelijking als de metriek in de ticket.