To VPN-klienter, én rutetabell: hvem vinner standardruten

Det ser ut som om to VPN-klienter slåss om samme socket, og den åpenbare løsningen må være å avinstallere én. I praksis berører de sjelden samme socket. Hver tilkobling skriver om operativsystemets rutetabell, og en fulltunnelprofil krever standardruten. Den som koblet til sist vinner som regel, og derfor ser symptomet ut til å flytte seg mellom klientene.

Konflikten bor i rutetabellen

En virtuell adapter pluss en standardrute er hvordan en full tunnel fanger trafikken. Når den andre klienten installerer sin egen standardrute, blir den eldre oppføringen erstattet eller degradert av metrikken, og hver destinasjon går nå gjennom den nyere tunnelen. Den første klienten forblir tilkoblet og viser fortsatt et grønt ikon, så grensesnittet er oppe mens veien er borte. Nettopp denne skillen mellom tilkoblingstilstand og rutetilstand gjør oppførselen forvirrende.

Klientene er redaktører av én delt tabell. Å vite hvilken endring som skjedde sist forklarer nesten hvert symptom.

Les hvilken tunnel som eier den gjeldende veien

Kontroller den faktiske avgjørelsen i stedet for å stole på klienten som melder seg tilkoblet. Spør systemet hvilket grensesnitt som ville bære en bestemt destinasjon.

ip route get 10.20.0.5
route print -4

Den første kommandoen navngir grensesnittet og kildeadressen for én destinasjon, og det er nettopp spørsmålet du bryr deg om. Ruteutskriften viser de konkurrerende standardoppføringene og metrikkene deres på Windows, så du ser hvilken som vinner nå. Kjør oppslaget for en vert i hvert fjernnett, fordi én destinasjon kan være riktig mens det andre nettet er utilgjengelig. Hvis svaret navngir feil tunnel, hjelper det ikke å koble til på nytt; rutepolicyen må endres.

Hindre den andre klienten i å kreve alt

Én klient bør eie standardruten, og den andre bør bare bære sine egne prefikser. OpenVPN klienter kan avvise det serveren skyver på.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignorerer hver påskjøvet rute, mens pull-filter ignore "redirect-gateway" bare dropper standardrutedirektivet og beholder påskjøvet DNS og andre alternativer. Velg mellom dem ut fra hvor mye av serverkonfigurasjonen du fortsatt vil ha, og legg deretter til de spesifikke prefiksene det andre nettet trenger. Husk DNS, fordi en resolver som skyves på av en tunnel som ikke bærer oppslagene, ikke returnerer noe. Test én kjent vert i hvert nett og bekreft kildeadressen fjernsiden ser.

Overlappende subnett kan ikke rutes rundt

Når begge nettene publiserer samme prefiks, holder kjernen én oppføring for to forskjellige steder og må velge. En vertsrute kan ikke finne opp den manglende forskjellen, og en metrikkjustering kan heller ikke. Omnummerer én side, eller la administratoren dens oversette fjernområdet slik at prefiksene blir forskjellige. Kontroller de virkelige subnettene før du klandrer klientene, fordi en hjemmeruters standard 192.168.1.0/24 oftere kolliderer med et kontorområde enn noen forventer. Noter begge områdene i saken slik at neste endring ikke gjenoppretter overlappingen.

Skill også to mål: å nå begge nett er et ruteproblem, mens å kjede tunneler for personvern er et annet design med en ekstra operatør på veien. Ikke bruk det ene til å løse det andre.