Du kobler til tunnelen, kjører ip route, og den opprinnelige standardgatewayen står der fortsatt. Den neste tanken er at klienten ikke har tatt over ruten, så du sletter standardruten manuelt og mister forbindelsen helt. Den oppføringen skal bli stående. Med redirect-gateway def1 installerer OpenVPN to mer spesifikke ruter som overgår den vanlige standardruten i stedet for å erstatte den. Den gamle gatewayen blir stående og slutter å bære trafikken du testet.

Hva def1 faktisk gjør

Flagget legger til 0.0.0.0/1 og 128.0.0.0/1, begge pekende mot tunnelen. 0.0.0.0/1 dekker hver adresse der første oktett er 0 til 127, og 128.0.0.0/1 dekker 128 til 255, så hver IPv4-destinasjon har en mer spesifikk match enn den gamle standardruten. Det er prefiksets lengde, ikke metrikken, som avgjør hvilken rute som vinner.

Å la den opprinnelige standardruten bli stående er bevisst. Klienten trenger ikke huske hva den erstattet, og den skriver ikke om ruten som bærer dens egen forbindelse til VPN-serveren. Ved frakobling fjerner den de to halve rutene, og tabellen går tilbake til slik den var.

Hvorfor /1 og ikke /0

Ruting velger det lengste samsvarende prefikset, ikke den laveste metrikken, så en /1 slår en /0 uansett hva standardrutens metrikk sier. Begge halvdelene finnes fordi en /1 bare dekker halve rommet; med bare 0.0.0.0/1 til stede følger alt fra 128.0.0.0 og oppover fortsatt den gamle standardruten, noe som gir det forvirrende symptomet der noen nettsteder virker og andre ikke.

Å heve eller senke metrikken til den gamle standardruten endrer ingenting, og en standardrute med lavere metrikk på et annet grensesnitt stjeler heller ikke trafikken. Først avgjør prefiksets lengde, og bare like prefikser faller tilbake på metrikken.

Les en ekte rutetabell

En tilkoblet vert kan vise alle tre oppføringene samtidig, med tunnelen som bærer halvdelene og den opprinnelige gatewayen fortsatt på listen. Adressene er eksempler og ikke en konfigurasjon å kopiere, fordi grensesnittnavn, tunneltopologi og ekstra ruter varierer etter plattform og klient.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

Det viktige er forholdet: to bestemte halvdeler over én generell standardrute. Linjen med den gamle gatewayen blir stående fordi ingenting erstattet den.

Sjekk hvilken rute pakken faktisk tar

Mer spesifikke ruter kan fortsatt vinne: en rute for et privat område, et lokalt subnett eller VPN-serverens egen adresse er lengre enn en /1. Tunnelen trenger en ytre vei til serveren sin, og å sende den forbindelsen tilbake i tunnelen ville bryte den umiddelbart. På Linux spør kjernen i stedet for å lese tabellen med øyet: ip route get med destinasjonen du er interessert i skriver ut den valgte ruten, grensesnittet og kilden. Hvis policy-ruting er konfigurert, undersøk også reglene, fordi en regel kan velge en annen tabell før hovedtabellen blir konsultert.

Hvis bare en del av IPv4 oppfører seg feil, bekreft at begge halvdelene er installert, og se deretter etter et unntak som matcher destinasjonen som feiler. Å slette den gamle standardruten er ikke en løsning, og det fjerner ruten klienten trenger for å rive tunnelen rent ned.

Hva def1 ikke dekker

To IPv4-oppføringer sier ingenting om IPv6: en vert med IPv6-tilkobling fortsetter å bruke sin egen standardrute til noe omdirigerer den familien separat, og derfor ser noe trafikk ut til å omgå tunnelen på et dual-stack-nettverk. Andre klienter og nettverksadministratorer implementerer full-tunnel-ruting annerledes, og tabellene deres vil ikke stemme. def1-oppførselen som er beskrevet her, tilhører OpenVPNs dokumenterte flagg, ikke enhver VPN på maskinen.

En kill switch svarer på et annet spørsmål: hva maskinen gjør når tunnelen faller. Ruteprioritet avgjør hvor trafikken går mens tunnelen er oppe; det avgjør ikke hva en brannmur gjør etterpå. Arbeidsrekkefølge: les tabellen, bekreft at begge halvdelene finnes, kjør ip route get for destinasjonen som feiler, sjekk policyreglene, og se deretter på IPv6 separat. La den gamle standardruten bli stående der den er.

Relaterte artikler