OpenVPN-rutemetrik: hvorfor den valgte rute stadig taber

Du tilføjede en metrik til en rute i profilen, genoprettede forbindelsen, og trafikken går stadig ud gennem den forkerte grænseflade. Tallet er sjældent problemet. En metrik ordner kun de kandidater, som styresystemet allerede sammenligner, og et mere specifikt præfiks eller en tidligere policytabel afgør sagen, før nogen metrik bliver læst.

Gå først gennem profilen, derefter den installerede tabel, derefter udvalgsreglerne. Den rækkefølge svarer til den måde, klienten bygger ruten på, og forhindrer dig i at justere en værdi, der aldrig indgår i sammenligningen.

Læs rutelinjen i feltrækkefølge

En OpenVPN 2.6-fællesskabsklient accepterer fire felter på en IPv4 route-linje: netværk, netmaske, gateway og en valgfri metrik. Gateway-positionen er der, hvor det særlige nøgleord vpn_gateway hører til. Det betyder det næste hop på VPN-siden for denne forbindelse, ikke et nummer på rutetabellen og ikke din fysiske router. Overser du det, læses resten af linjen med en forkert idé om, hvad den gør. netværksindstillinger-reference dokumenterer alle fire felter.

For en privat destination kan linjen se sådan ud:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Det eksplicitte 30 gælder for den rute, og 50 forbliver standarden for alle andre ruter i profilen, der udelader et tal. At læse linjen fra venstre mod højre er nok til at se, hvilken værdi der gælder hvor.

route-metric er en standard, ikke en rang

route-metric sætter reserveværdien for ruter, der ikke har deres eget tal. Det løfter ikke en rute over noget andet, og det omarrangerer ikke ruter, der blev installeret med eksplicitte metrikker.

Den forskel betyder noget, når en profil blander begge former. En enkelt route-metric-linje nær toppen ser autoritativ ud og er let at bebrejde, mens den rute, der faktisk bærer trafik, måske har sin egen metrik tre linjer længere nede.

Hvis du vil have én rute til at foretrække en vej, skal du sætte tallet på den rute. Hvis du vil have en ensartet standard på tværs af en genereret profil, skal du bruge route-metric og lade de enkelte linjer være. At blande de to uden grund er måden, en profil ender med en rute, som ingen kan forklare.

Undersøg, hvad klienten installerede

Når genoprettelsen er færdig, skal du spørge kernen i stedet for profilen.

ip route show viser de ruter, klienten tilføjede, og ip route get 172.20.5.10 svarer på det mere nyttige spørgsmål: hvilken rute denne destination faktisk ville bruge, og med hvilken kildeadresse. Hvis destinationen mangler i tabellen, har klienten ikke installeret den.

Et lokalt direktiv, et server-push eller en anden netværksadministrator kan tilføje eller fjerne det samme præfiks, og den sidste skribent vinder. Hold slutpunktsruten i syne, mens du arbejder, fordi forbindelsen har brug for en vej til den eksterne server, der ikke går gennem den tunnel, den bygger.

Hvorfor en mindre metrik stadig taber

Metrikker sammenligner ruter til den samme destination. De gør ikke et bredt præfiks mere specifikt. Når redirect-gateway def1 er i spil, installerer klienten 0.0.0.0/1 og 128.0.0.0/1, og de to præfikser dækker hele IPv4-rummet mere specifikt end 0.0.0.0/0. En metrik på 1 på standardruten overgår dem ikke.

Den samme logik gælder for ethvert overlappende par. En /24 slår en /16 for en adresse indeni uanset de vedhæftede tal, fordi opslaget først vælger det mest specifikke match og først derefter sammenligner metrikker blandt ligestillede.

Det er den del, der ligner en metrikfejl og ikke er det. Kontroller præfikslængden på begge kandidater, før du ændrer noget tal.

Policyregler kører før tabellen

På Linux afgør ip rule, hvilken rutetabel der konsulteres. Regler evalueres i prioritetsrækkefølge, så en tidligere tabel kan returnere en rute, før hovedtabellen overhovedet læses. En metrik i main kan ikke overgå et match i en tabel, der blev konsulteret først.

Brug ip rule show og forespørg derefter den specifikke tabel, for eksempel ip route show table 100, for at se, hvad den regel ville returnere. Hvis en VPN-klient eller et container-miljø tilføjede en regel, kan svaret være der i stedet for i den tabel, du har læst. Kildeadressen betyder også noget, fordi en regel kan matche kilden og løse den samme destination forskelligt for tunneltrafik og LAN-trafik.

Bekræft destinationen, ikke rangordenen

Testen, der afslutter diskussionen, er en enkelt forespørgsel til en vært i det tilsigtede undernet plus et tjek af den kildeadresse, som kernen valgte. Hvis det par matcher designet, gør metrikken sit arbejde, selv når listen ikke ser ud som en ren rangorden.

Hold IPv6 og DNS ude af dette tjek. De konfigureres af forskellige direktiver og løses af forskellige mekanismer, og en fungerende IPv4-rute siger intet om nogen af dem. Skift ét lag ad gangen, og kør forespørgslen igen.