OpenVPN-rutemetrikk: hvorfor den valgte ruten fortsatt taper

Du la til en metrikk på en rute i profilen, koblet til på nytt, og trafikken går fortsatt ut gjennom feil grensesnitt. Tallet er sjelden problemet. En metrikk ordner bare kandidater som operativsystemet allerede sammenligner, og et mer spesifikt prefiks eller en tidligere polisjetabell avgjør før noen metrikk leses.

Gå gjennom profilen først, deretter den installerte tabellen, og til slutt utvalgsreglene. Den rekkefølgen følger måten klienten bygger ruten på og hindrer deg i å justere en verdi som aldri kommer inn i sammenligningen.

Les ruttelinjen i feltrekkefølge

En Community OpenVPN 2.6-klient godtar fire felt på en IPv4 route-linje: nettverk, nettmaske, gateway og en valgfri metrikk. Gateway-posisjonen er der det spesielle nøkkelordet vpn_gateway står. Det betyr neste hopp på VPN-siden for denne tilkoblingen, ikke et rutingtabellnummer og ikke den fysiske ruteren din. Går det tapt, leses resten av linjen med en feil oppfatning av hva den gjør. network-options-referansen dokumenterer alle fire feltene.

For en privat destinasjon kan linjen se slik ut:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Den eksplisitte 30 gjelder for den ruten, og 50 forblir standarden for alle andre ruter i profilen som utelater et tall. Å lese linjen fra venstre til høyre er nok til å si hvilken verdi som gjelder hvor.

route-metric er en standard, ikke en rang

route-metric setter fallbacken for ruter som ikke har sitt eget tall. Den skyver ikke en rute over noe annet, og den omorganiserer ikke ruter som ble installert med eksplisitte metrikker.

Den forskjellen betyr noe når en profil blander begge formene. En enkelt route-metric-linje nær toppen ser autoritativ ut og er lett å skylde på, mens ruten som faktisk bærer trafikk kan bære sin egen metrikk tre linjer lenger ned.

Hvis du vil at én rute skal foretrekke en vei, sett tallet på den ruten. Hvis du vil ha en konsistent standard gjennom en generert profil, bruk route-metric og la de enkelte linjene være. Å blande de to uten grunn er hvordan en profil ender opp med en rute ingen kan forklare.

Undersøk hva klienten installerte

Når gjentilkoblingen er ferdig, spør kjernen og ikke profilen.

ip route show lister rutene klienten la til, og ip route get 172.20.5.10 svarer på det mer nyttige spørsmålet: hvilken rute denne destinasjonen faktisk ville bruke, og med hvilken kildeadresse. Hvis destinasjonen mangler i tabellen, installerte ikke klienten den.

En lokal direktiv, en server-push eller en annen nettverksbehandler kan legge til eller fjerne det samme prefikset, og den som skriver sist vinner. Hold endepunkt-ruten i syne mens du jobber, fordi tilkoblingen trenger en vei til fjernserveren som ikke går gjennom tunnelen den bygger.

Hvorfor en mindre metrikk fortsatt taper

Metrikker sammenligner ruter til samme destinasjon. De gjør ikke et bredt prefiks mer spesifikt. Når redirect-gateway def1 er i spill, installerer klienten 0.0.0.0/1 og 128.0.0.0/1, og de to prefiksene dekker hele IPv4-rommet mer spesifikt enn 0.0.0.0/0. En metrikk på 1 på standardruten slår dem ikke.

Den samme logikken gjelder for ethvert overlappende par. En /24 slår en /16 for en adresse innenfor, uansett hvilke tall som er festet, fordi oppslaget velger det mest spesifikke treffet først og bare deretter sammenligner metrikker mellom like.

Dette er delen som ser ut som en metrikkfeil og ikke er det. Sjekk prefikslengden på begge kandidatene før du endrer noe tall.

Polisjeregler kjører før tabellen

På Linux avgjør ip rule hvilken rutingtabell som konsulteres. Regler vurderes i prioritetsrekkefølge, så en tidligere tabell kan returnere en rute før hovedtabellen i det hele tatt leses. En metrikk i hoved kan ikke slå et treff i en tabell som ble konsultert først.

Bruk ip rule show og spør deretter den spesifikke tabellen, for eksempel ip route show table 100, for å se hva den regelen ville returnere. Hvis en VPN-klient eller en container-runtime la til en regel, kan svaret være der i stedet for i tabellen du har lest. Kildeadressen betyr også noe, siden en regel kan matche på kilden og løse samme destinasjon ulikt for tunneltrafikk og LAN-trafikk.

Verifiser destinasjonen, ikke rangeringen

Testen som avslutter diskusjonen er et enkelt oppslag mot en vert i det tiltenkte subnettet, pluss en sjekk av kildeadressen kjernen valgte. Hvis det paret passer med designet, gjør metrikken jobben sin selv når listen ikke ser ut som en ryddig rangering.

Hold IPv6 og DNS utenfor denne sjekken. De konfigureres av andre direktiver og løses av andre mekanismer, og en fungerende IPv4-rute sier ingenting om noen av dem. Endre ett lag om gangen og kjør oppslaget på nytt.