Routingtabel versus echte opzoeking: waar VPN-verkeer naartoe gaat

Een dump van de routingtabel is de minst nuttige diagnostiek bij VPN-probleemoplossing en de meest geplakte. Veertig regels met prefixen vertellen je wat de machine zou kunnen doen, niet wat ze deed voor het mislukte verzoek. Het mechanisme dat je echt wilt, is de opzoeking: gegeven deze bron en deze bestemming, welke regel matchte, welke tabel werd geraadpleegd en welke interface en volgende hop kwamen eruit. Begin bij één bestemming en één bron, lees de tabel vervolgens met die vraag in de hand, en dezelfde uitvoer wordt bewijs in plaats van ruis.

Een tabel is een verzameling kandidaten, geen beslissing

Elke vermelding beschrijft een prefix en wat te doen met verkeer dat erbij past: het naar een interface sturen, aan een volgende hop geven of laten vallen. Niets in die lijst is op intentie geordend, en de vermelding die voor een mens het meest specifiek lijkt, is niet altijd degene die de kernel selecteert, omdat de selectie de langste prefixmatch volgt en, bij gelijke prefixen, de metriek.

Dus de eerste stap is de kernel vragen in plaats van de lijst lezen. De opzoekopdracht antwoordt voor een bestemming, en met een bronargument antwoordt hij voor het exacte paar dat een doorgestuurde of gebonden verbinding zou gebruiken:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Elk adres hierboven is een documentatievoorbeeld. Het punt is de vorm van het antwoord: interface, gekozen bronadres, gateway en de tabel waar de vermelding vandaan kwam. Als die uitvoer niet overeenkomt met de interface die je verwachtte, heb je het probleem met één opdracht gelokaliseerd, en geen enkele hoeveelheid lezen van de volledige tabel had je verteld welke kandidaat won.

De opzoeking loopt eerst langs regels, dan langs tabellen

Op Linux is de beslissing in twee fasen. Beleidsregels worden in prioriteitsvolgorde geëvalueerd, en de eerste regel die matcht noemt een tabel om te raadplegen; die tabel doet vervolgens de langste-prefixmatch. Een regel kan matchen op bron, bestemming, firewallmark, interface of een combinatie, waardoor een dump van de hoofdtabel volstrekt nauwkeurig en volstrekt irrelevant kan zijn voor het pakket dat je onderzoekt.

ip rule show
ip route show table all | head -40
ip route show table 100

Als een regel verkeer uit je VPN-pool naar tabel 100 stuurt, dan is tabel 100 degene die ertoe doet, en de hoofdtabel is een lokvogel. Dit is ook het mechanisme achter brongebaseerde routing op een router: dezelfde bestemming kan twee verschillende antwoorden hebben afhankelijk van waar het pakket vandaan kwam, en alleen de opzoeking met een bronargument onthult welke geldt.

IPv6 heeft zijn eigen regels en tabellen. Een ontwerp dat beide families draait, heeft beide opzoekingen nodig, en een werkend IPv4-antwoord zegt niets over het v6-pad dat een dual-stackclient kan verkiezen.

Wat de VPN-client installeert

Clients vervangen gewoonlijk niet de standaardroute, omdat dat het eigen buitenste pad van de tunnel zou breken. Ze installeren iets specifiekers dat wint op prefixlengte: een paar half-standaardroutes die 0.0.0.0/1 en 128.0.0.0/1 dekken is de klassieke truc, omdat beide langere prefixen zijn dan 0.0.0.0/0 en samen de hele ruimte dekken. Anderen installeren specifieke privéprefixen plus een beleidsregel, en sommigen voegen een mark toe zodat alleen geselecteerd verkeer wordt gevangen.

Daarom is "de VPN heeft mijn standaardroute niet veranderd" geen bewijs van falen. Controleer wat hij wél toevoegde, en of de betreffende bestemming binnen die prefixen valt:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Twee halfroutes zijn gemakkelijk te missen in een dump omdat ze niet op een standaardroute lijken. Een split-tunnelconfiguratie die vergat een prefix op te nemen, produceert precies het symptoom dat je najaagt: de applicatie die de tunnel zou moeten gebruiken, lost lokaal op en verbindt lokaal in plaats daarvan. Vergelijk de geïnstalleerde prefixen met de bestemmingen die de gebruiker echt nodig heeft, niet met de adressen die je toevallig testte. Een split-tunnellijst die de fileserver dekt maar niet de resolver, produceert een verbinding die naar een openbaar adres oplost en vervolgens niet authenticeert, wat op een wachtwoordprobleem lijkt en een routeprobleem is.

De buitenste route moet ook overleven

De tunnel is zelf verkeer. De pakketten die de ingekapselde lading dragen, gaan via de fysieke interface naar het adres van de peer, en dat pad mag niet terug de tunnel in worden gerouteerd. Als dat gebeurt, krijg je het kenmerkende falen waarbij de tunnel tot stand komt en daarna stopt met verkeer doorlaten, omdat het transport voor de tunnel nu in de tunnel zit.

Controleer het peeradres zoals je de binnenste bestemming controleerde, en bevestig dat het naar de fysieke interface oplost en niet naar de tunnel:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Een recursieve route, een beleidsregel die de peer vangt, of een standaardroute die door een full-tunnelclient is vervangen, zijn de drie gebruikelijke oorzaken. Alle drie zijn zichtbaar in de buitenste opzoeking, en geen ervan is zichtbaar in een dump van de hoofdtabel die achteraf is genomen.

Wat routinguitvoer je niet kan vertellen

Een correcte opzoeking betekent dat de kernel het pakket ergens zinvols naartoe zou sturen. Het betekent niet dat de firewall het toestaat, het IPsec-beleid het dekt, de NAT-regel het vertaalt, of de andere kant een retourroute heeft. Elk daarvan is een latere fase, en de strongSwan-notities over doorsturen beschrijven de keten die een pakket aan beide uiteinden moet passeren.

Het houdt ook geen rekening met binding op applicatieniveau. Een proces kan zich aan een interface binden, een mark zetten of zijn eigen resolver gebruiken en verbinden met een naam die anders oplost dan wat je testte. Als de opzoeking klopt en de verbinding toch faalt, is de volgende vraag welk proces haar maakt en of dat proces dezelfde tabel ziet als jij.

Houd de diagnose dus geordend: benoem de bestemming en de bron, voer de opzoeking uit, lees alleen de tabel en regel die de opzoeking noemde, en test dan de volgende fase. Die volgorde houdt een routingonderzoek binnen enkele minuten en laat een verslag achter dat iemand anders kan volgen, wat een geplakte tabel nooit doet.