OpenVPN-routemetriek: waarom de gekozen route toch verliest

Je voegde een metriek toe aan een route in het profiel, maakte opnieuw verbinding, en het verkeer gaat nog steeds via de verkeerde interface naar buiten. Het getal is zelden het probleem. Een metriek ordent alleen kandidaten die het besturingssysteem al vergelijkt, en een specifieker prefix of een eerdere beleidstabel beslist voordat er ooit een metriek wordt gelezen.

Werk eerst het profiel door, dan de geïnstalleerde tabel en dan de selectieregels. Die volgorde komt overeen met de manier waarop de client de route bouwt en voorkomt dat je een waarde afstelt die nooit in de vergelijking komt.

Lees de routelijn in veldvolgorde

Een Community OpenVPN 2.6-client accepteert vier velden op een IPv4 route-regel: netwerk, netmasker, gateway en een optionele metriek. De gatewaypositie is waar het speciale trefwoord vpn_gateway staat. Dat betekent de volgende hop aan de VPN-kant voor deze verbinding, geen routingtabelnummer en niet je fysieke router. Mis je dat, dan wordt de rest van de regel gelezen met een verkeerd idee van wat die doet. De network-options-referentie documenteert alle vier velden.

Voor een privébestemming kan de regel er zo uitzien:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

De expliciete 30 geldt voor die route, en de 50 blijft de standaard voor elke andere route in het profiel die een getal weglaat. De regel van links naar rechts lezen is genoeg om te zeggen welke waarde waar geldt.

route-metric is een standaard, geen rang

route-metric stelt de terugval in voor routes die hun eigen getal niet dragen. Het duwt een route niet boven iets anders en het herordent geen routes die met expliciete metrieken zijn geïnstalleerd.

Dat onderscheid is belangrijk wanneer een profiel beide vormen mengt. Een enkele route-metric-regel bovenaan ziet gezaghebbend uit en is makkelijk de schuld te geven, terwijl de route die daadwerkelijk verkeer draagt drie regels verderop zijn eigen metriek kan dragen.

Wil je dat één route een pad verkiest, zet het getal dan op die route. Wil je een consistente standaard in een gegenereerd profiel, gebruik dan route-metric en laat de afzonderlijke regels met rust. Beide zonder reden mengen is hoe een profiel eindigt met een route die niemand kan uitleggen.

Kijk wat de client heeft geïnstalleerd

Vraag na het opnieuw verbinden de kernel, niet het profiel.

ip route show somt de routes op die de client heeft toegevoegd, en ip route get 172.20.5.10 beantwoordt de nuttiger vraag: welke route deze bestemming werkelijk zou gebruiken, met welk bronadres. Ontbreekt de bestemming in de tabel, dan heeft de client die niet geïnstalleerd.

Een lokale richtlijn, een server-push of een andere netwerkbeheerder kan hetzelfde prefix toevoegen of verwijderen, en de laatste schrijver wint. Houd de endpoint-route in het oog terwijl je werkt, want de verbinding heeft een pad naar de externe server nodig dat niet door de tunnel loopt die hij bouwt.

Waarom een kleinere metriek toch verliest

Metrieken vergelijken routes naar dezelfde bestemming. Ze maken een breed prefix niet specifieker. Wanneer redirect-gateway def1 in het spel is, installeert de client 0.0.0.0/1 en 128.0.0.0/1, en die twee prefixen dekken de hele IPv4-ruimte specifieker dan 0.0.0.0/0. Een metriek van 1 op de standaardroute overtreft ze niet.

Dezelfde logica geldt voor elk overlappend paar. Een /24 verslaat een /16 voor een adres erbinnen, ongeacht de getallen die eraan hangen, omdat de opzoeking eerst de meest specifieke overeenkomst kiest en pas daarna metrieken tussen gelijken vergelijkt.

Dit is het deel dat op een metriekfout lijkt en er geen is. Controleer de prefixlengte op beide kandidaten voordat je een getal wijzigt.

Beleidsregels lopen vóór de tabel

Op Linux bepaalt ip rule welke routingtabel wordt geraadpleegd. Regels worden in prioriteitsvolgorde geëvalueerd, dus een eerdere tabel kan een route teruggeven voordat de hoofdtabel ooit wordt gelezen. Een metriek in main kan geen overeenkomst overtreffen in een tabel die als eerste werd geraadpleegd.

Gebruik ip rule show en vraag dan de specifieke tabel op, bijvoorbeeld ip route show table 100, om te zien wat die regel zou teruggeven. Als een VPN-client of een container-runtime een regel heeft toegevoegd, kan het antwoord daar staan in plaats van in de tabel die je hebt gelezen. Het bronadres is ook belangrijk, omdat een regel op de bron kan matchen en dezelfde bestemming anders kan oplossen voor tunnelverkeer en LAN-verkeer.

Controleer de bestemming, niet de ranglijst

De test die de discussie beëindigt is één opzoeking bij een host binnen het bedoelde subnet, plus een controle van het bronadres dat de kernel koos. Als dat paar bij het ontwerp past, doet de metriek zijn werk ook wanneer de lijst er niet als een nette ranglijst uitziet.

Laat IPv6 en DNS buiten deze controle. Die worden door andere richtlijnen geconfigureerd en door andere mechanismen opgelost, en een werkende IPv4-route zegt daar niets over. Wijzig één laag per keer en voer de opzoeking opnieuw uit.