VPN-routemetriek is veranderd na verbinden: wat het betekent
Een lagere metriek beslist alleen tussen even specifieke routes. Lees de beleidsregel, de prefix en de hostroute van het eindpunt voordat je een VPN-routenummer aanpast.
Je verbindt de VPN, voert route print uit, en de standaardroute heeft nu een veel lagere metriek dan voorheen. De voor de hand liggende conclusie is dat de VPN de standaardroute heeft overgenomen omdat het nummer kleiner is. Soms is dat precies wat er is gebeurd. Vaak is de metriek helemaal niet de beslissende factor, en eraan sleutelen verandert niets omdat de keuze eerder is gemaakt, door de prefixlengte of door een beleidsregel.
Het symptoom is echt: verkeer dat eerder via de Wi-Fi-adapter naar buiten ging, gaat nu door de tunnel, of andersom. De metriek is één invoer voor een opzoeking die in een vaste volgorde verloopt, en die volgorde moet je lezen voordat je een nummer aanraakt.
Waarmee het nummer echt concurreert
De eerste vergelijking is specificiteit, niet voorkeur. Een route voor 10.20.0.0/16 wint van 10.0.0.0/8, en beide winnen van 0.0.0.0/0, wat hun metrieken ook zeggen. Een VPN die een standaardroute met de laagste metriek op de machine installeert, verliest nog steeds van elke specifiekere route die bij de bestemming past, inclusief de hostroute die de client voor zijn eigen server installeert.
Daarom kan een lagere metriek op een standaardroute een direct verbonden subnet niet de tunnel in dwingen. Wil je dat subnet binnen de VPN, voeg dan een route voor de prefix toe of kies de tunneltabel met een beleidsregel. De metriek is de verkeerde hendel voor dat werk.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux kiest de tabel vóór de metriek
Op Linux raadpleegt de kernel eerst de beleidsdatabase. ip rule somt de regels en de tabellen op die ze selecteren, en ip route get 203.0.113.10 rapporteert de tabel, route en bronadres die de kernel voor die bestemming werkelijk zou gebruiken. Een metriek binnen tabel 100 concurreert nooit met een route in de hoofdtabel, omdat de regel de tabel al had gekozen voordat er een metriek werd vergeleken.
Daarom kan een route er in ip route show table all goed uitzien en toch geen verkeer dragen. Lees de regel die overeenkwam, dan de tabel die die koos, en vergelijk dan de routes daarin. Is de verkeerde tabel gekozen, dan helpt geen enkele metriekaanpassing in de andere tabel.
Windows combineert twee metrieken
Windows heeft standaard geen beleidsdatabase, maar combineert wel een routemetriek met een interfacemetriek, en de automatische interfacemetriek kan veranderen met de linksnelheid en de adapterstatus. Daarom kan dezelfde route zich anders gedragen nadat een dockingstation of een virtuele adapter verschijnt. Find-NetRoute -RemoteIPAddress 203.0.113.10 rapporteert het gekozen bronadres, de volgende hop en de interface, wat dichter bij de echte beslissing staat dan de ruwe tabel.
Lees de route- en interfacewaarden samen. Een interfacemetriek verhogen kan verkeer verplaatsen zonder dat er een route-item verandert, en een VPN-client die zijn routes bezit, installeert ze bij herverbinden opnieuw en gooit je aanpassing weg.
Houd het eindpunt van de tunnel buiten de tunnel
Elke tunnel heeft een pad naar zijn eigen server nodig dat niet door de tunnel loopt. Clients installeren een hostroute voor het eindpunt via de fysieke gateway, en die route moet specifieker blijven dan de standaardroute die de client toevoegt. Verwijder hem, of laat de tunnel de opzoeking voor dat adres winnen, en de ingekapselde pakketten proberen de tunnel binnen te gaan die ze zouden moeten bouwen. De verbinding mislukt of raakt in een lus.
Controleer die hostroute voor en na elke metriekwijziging: hij moet naar de fysieke volgende hop wijzen en een herverbinding overleven. Bezit de client hem, wijzig dan het profiel of de beheerde configuratie in plaats van een runtimewaarde die wordt overschreven.
Controleer beide adresfamilies en de app-context
IPv4 en IPv6 zijn aparte beslissingen met aparte tabellen. Een VPN kan IPv4 dragen terwijl IPv6 de lokale router blijft gebruiken, en een metriekwijziging in de ene familie zegt niets over de andere. Controleer beide en controleer daarna de applicatiecontext. Een proces dat aan een interface is gebonden, een containernaamruimte of een VPN per app kan een andere tabel zien dan je shell.
Verifieer met het gereedschap dat de beslissing voor de echte bestemming rapporteert, niet met de volledige tabellijst. Is de gekozen route degene die het ontwerp bedoelt, stop dan. Een metriek die niet het kleinste getal op het scherm is, is geen fout, en hem dwingen de kleinste te zijn kan het pad van het eindpunt breken waarvan de tunnel afhangt.