Waarom een VPN-route geen gateway toont in de uitvoer van ip route

Routingtabellen worden als kapot gelezen zodra de gateway-kolom leeg blijft, terwijl de regel meestal op zichzelf al compleet is. Het veld via verschijnt alleen wanneer de kernel het pakket aan een next-hop-adres overhandigt; een route die aan een interface hangt bereikt zijn bestemmingen juist via resolutie op de linklaag of via een punt-tot-punt-partner. De kolommen van links naar rechts lezen vertelt je in welk geval je zit, en dat lezen zou moeten gebeuren voordat iemand een standaardroute aanpast. De meeste tickets over een ontbrekende gateway eindigen bij dit onderscheid.

Lees een routelijn kolom voor kolom

Elke vermelding begint met de bestemming en de lengte van het prefix en voegt dan modifiers toe in een vaste woordenschat: via, dev, proto, scope, src en metric. Een regel als 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 is dicht maar volledig gespecificeerd. Er ontbreekt niets aan, en er wordt geen routeradres geïmpliceerd.

Het ontbreken van via is het interessante deel. Zonder next hop lost de kernel de bestemming rechtstreeks op de genoemde interface op, wat voor een tunnel betekent dat het frame aan het tunnelapparaat wordt gegeven en de inkapseling het vanaf daar overneemt. proto kernel legt vast dat de vermelding automatisch is geïnstalleerd toen een adres werd toegewezen, niet door een beheerder getypt. scope link zegt dat de bestemming op die link bereikbaar is zonder een router te passeren, en src noemt het adres dat de kernel als bron voor passend verkeer zal verkiezen.

Lees nu een standaardroute op dezelfde manier: default via 192.0.2.254 dev eth0 proto static metric 100. Hier is via aanwezig omdat het pakket echt een next hop nodig heeft, en die hop moet zelf bereikbaar zijn op eth0. De twee regels zijn geen varianten van elkaar; ze beantwoorden verschillende vragen over waar het verkeer heen gaat.

Twee routevormen die met elkaar worden verward

Een tunnelsubnetroute en een standaardroute lijken op een schermafbeelding op elkaar en gedragen zich totaal verschillend. Gebruik de tabel hieronder als leeshulp voor de velden en bevestig daarna de werkelijke getallen op de machine die je debugt in plaats van een voorbeeld uit een handleiding te vertrouwen.

Wat de tabel je niet kan vertellen, is de bedoeling. Een directe route naar een privébereik door een tunnel is een bewust ontwerp met gesplitste tunnel; dezelfde vorm op een host die alles via de VPN zou moeten sturen is een symptoom. De bedoeling leeft in de configuratie die de vermelding heeft gemaakt, dus kijk naar het gereedschap dat hem heeft geïnstalleerd voordat je concludeert dat de kernel iets fout deed.

Evenzo is een ontbrekende gateway geen toestemming om er een te verzinnen. Als een route echt een next hop nodig heeft, moet die hop bereikbaar zijn op de interface die hem draagt, en voor een punt-tot-punt-tunnel is het adres van de partner niet hetzelfde object als het lokale adres. Het lokale tunneladres als Ethernet-router behandelen is een veelvoorkomende manier om een route te maken die er correct uitziet en niets doorstuurt.

Vraag de kernel welke regel hij werkelijk gaat gebruiken

De tabel lezen is niet hetzelfde als de opzoeking uitvoeren, omdat de kernel beleidsregels, meerdere tabellen en gecachte vermeldingen raadpleegt voordat hij antwoordt. Het werkwoord dat de echte opzoeking uitvoert is ip route get, en het drukt de route af die een pakket met die eigenschappen zou nemen.

ip route get 203.0.113.37 from 198.51.100.2 iif tun0

Vervang door de bestemming die je echt belangrijk vindt, en voeg dan from of iif toe wanneer het verkeer op bron wordt geselecteerd of doorgestuurd, omdat een gewone lokale opzoeking een ander pad kan kiezen dan een doorgestuurde client. Het antwoord noemt de interface, het gekozen bronadres en een eventuele next hop, wat dezelfde informatie is waarmee een pakket op dat moment gerouteerd zou worden.

Als het antwoord je verrast, druk dan de regels af voordat je iets wijzigt: ip -4 rule show somt ze in prioriteitsvolgorde op, en een VPN-client die zijn eigen tabel of een regel voor gemarkeerde pakketten installeert, zal helemaal niet in de hoofdtabel verschijnen. Alle tabellen opsommen sluit die kloof.

ip -4 route show table all | grep -E 'tun|default'

Controleer de onderlaag voordat je de standaardroute vervangt

De pakketten van de tunnel zelf moeten het externe eindpunt bereiken, en dat doen ze via de fysieke interface met de route die bestond voordat de VPN omhoogkwam. Het vervangen van de hele standaardroute zonder dat eindpunt vast te zetten, stuurt de ingekapselde pakketten de tunnel in die ze juist zouden moeten opbouwen, en de verbinding stort in. Bevestig eerst het pad naar het eindpunt met een opzoeking op alleen het eindpuntadres.

Houd drie dingen gescheiden wanneer je de wijziging doorvoert: de eindpuntroute die op de fysieke interface moet blijven, de privébereiken die de tunnel in moeten, en de standaardroute die al het andere bepaalt. Splits ze in die volgorde, pas er één per keer toe, en voer de opzoeking na elke stap opnieuw uit. Een mislukte ping daarna bewijst op zichzelf heel weinig, omdat rechten, antwoordroutering, DNS en de dienst zelf allemaal stroomafwaarts van een correcte route liggen.

Schrijf de vier waarden op die de regel je voor de wijziging gaf: bestemming, next hop of het ontbreken daarvan, apparaat en gekozen bron. Als een latere wijziging er een verplaatst, weet je welke beslissing werkelijk is veranderd, en kun je één vermelding herstellen in plaats van de hele tabel te raden.