OpenVPN-ruttmetrik: varför den valda rutten ändå förlorar

Du lade till en metrik på en rutt i profilen, återanslöt, och trafiken lämnar fortfarande via fel gränssnitt. Talet är sällan problemet. En metrik ordnar bara de kandidater som operativsystemet redan jämför, och ett mer specifikt prefix eller en tidigare policytabell avgör innan någon metrik läses.

Arbeta igenom profilen först, sedan den installerade tabellen och till sist urvalsreglerna. Den ordningen matchar hur klienten bygger rutten och hindrar dig från att justera ett värde som aldrig ingår i jämförelsen.

Läs ruttraden i fältordning

En Community OpenVPN 2.6-klient accepterar fyra fält på en route-rad för IPv4: nätverk, nätmask, gateway och en valfri metrik. Gateway-positionen är där det särskilda nyckelordet vpn_gateway hamnar. Det betyder nästa hopp på VPN-sidan för den här anslutningen, inte ett routingtabellnummer och inte din fysiska router. Missar du det läses resten av raden med fel uppfattning om vad den gör. Referensen för nätverksalternativ dokumenterar alla fyra fälten.

För en privat destination kan raden se ut så här:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Det explicita 30 gäller för den rutten, och 50 förblir standard för varje annan rutt i profilen som utelämnar ett tal. Att läsa raden från vänster till höger räcker för att avgöra vilket värde som gäller var.

route-metric är ett standardvärde, inte en rangordning

route-metric sätter reservvärdet för rutter som inte bär sitt eget tal. Det lyfter inte en rutt över något annat och det ordnar inte om rutter som installerats med explicita metriker.

Den skillnaden spelar roll när en profil blandar båda formerna. En enda route-metric-rad nära toppen ser auktoritativ ut och är lätt att skylla på, medan rutten som faktiskt bär trafiken kan ha sin egen metrik tre rader längre ner.

Om du vill att en rutt ska föredra en väg, sätt talet på den rutten. Om du vill ha ett konsekvent standardvärde i en genererad profil, använd route-metric och låt de enskilda raderna vara. Att blanda de två utan anledning är hur en profil slutar med en rutt som ingen kan förklara.

Inspektera vad klienten installerade

När återanslutningen är klar, fråga kärnan i stället för profilen.

ip route show listar rutterna som klienten lade till, och ip route get 172.20.5.10 svarar på den mer användbara frågan: vilken rutt den här destinationen faktiskt skulle använda, och med vilken källadress. Om destinationen saknas i tabellen installerade klienten den inte.

Ett lokalt direktiv, en push från servern eller en annan nätverkshanterare kan lägga till eller ta bort samma prefix, och den som skriver sist vinner. Håll rutt till slutpunkten i sikte medan du arbetar, eftersom anslutningen behöver en väg till fjärrservern som inte går genom tunneln den bygger.

Varför en mindre metrik ändå förlorar

Metriker jämför rutter till samma destination. De gör inte ett brett prefix mer specifikt. När redirect-gateway def1 är i spel installerar klienten 0.0.0.0/1 och 128.0.0.0/1, och de två prefixen täcker hela IPv4-rymden mer specifikt än 0.0.0.0/0. En metrik på 1 på standardrutten överträffar dem inte.

Samma logik gäller för varje överlappande par. Ett /24 slår ett /16 för en adress inuti det oavsett vilka tal som hänger med, eftersom uppslaget först väljer den mest specifika matchningen och först därefter jämför metriker mellan jämlikar.

Det här är delen som ser ut som en metrikbugg och inte är det. Kontrollera prefixlängden på båda kandidaterna innan du ändrar något tal.

Policyregler körs före tabellen

På Linux avgör ip rule vilken routingtabell som konsulteras. Regler utvärderas i prioritetsordning, så en tidigare tabell kan returnera en rutt innan huvudtabellen någonsin läses. En metrik i main kan inte överträffa en matchning i en tabell som konsulterades först.

Använd ip rule show och fråga sedan den specifika tabellen, till exempel ip route show table 100, för att se vad regeln skulle returnera. Om en VPN-klient eller en containerruntime lade till en regel kan svaret finnas där i stället för i tabellen du läst. Källadressen spelar också roll, eftersom en regel kan matcha på källan och lösa samma destination olika för tunneltrafik och LAN-trafik.

Verifiera destinationen, inte rangordningen

Testet som avslutar diskussionen är en enda fråga till en värd inom det avsedda subnätet, plus en kontroll av den källadress som kärnan valde. Om det paret matchar designen gör metrik en sin uppgift även när listningen inte ser ut som en ren rangordning.

Lämna IPv6 och DNS utanför den här kontrollen. De konfigureras av andra direktiv och löses av andra mekanismer, och en fungerande IPv4-rutt säger inget om någon av dem. Ändra ett lager i taget och kör frågan igen.