To VPN-klientar, éi rutetabell: kven vinn standardruta

Det ser ut som om to VPN-klientar slåst om den same socketen, og den opplagde løysinga må vere å avinstallere éin. I praksis rører dei sjeldan den same socketen. Kvar tilkopling skriv om rutetabellen til operativsystemet, og ein fulltunnelprofil krev standardruta. Den som kopla til sist vinn som regel, og difor ser symptomet ut til å flytte seg mellom klientane.

Konflikten bur i rutetabellen

Ein virtuell adapter pluss ei standardrute er korleis ein full tunnel fangar trafikken. Når den andre klienten installerer si eiga standardrute, blir den eldre oppføringa erstatta eller degradert av metrikken, og kvar destinasjon går no gjennom den nyare tunnelen. Den første klienten blir verande tilkopla og viser framleis eit grønt ikon, så grensesnittet er oppe medan vegen er borte. Nettopp denne skilnaden mellom tilkoplingstilstand og rutetilstand gjer åtferda forvirrande.

Klientane er redaktørar av éi delt tabell. Å vite kva endring som skjedde sist forklarer nesten kvart symptom.

Les kva tunnel som eig den gjeldande vegen

Kontroller den faktiske avgjerda i staden for å stole på klienten som melder seg tilkopla. Spør systemet kva grensesnitt som ville bere ein bestemd destinasjon.

ip route get 10.20.0.5
route print -4

Den første kommandoen namngir grensesnittet og kjeldeadressa for éin destinasjon, og det er nettopp spørsmålet du bryr deg om. Ruteutskrifta viser dei konkurrerande standardoppføringane og metrikkane deira på Windows, så du ser kven som vinn no. Køyr oppslaget for ein vert i kvart fjernnett, fordi éin destinasjon kan vere rett medan det andre nettet er utilgjengeleg. Viss svaret namngir feil tunnel, hjelper det ikkje å kople til på nytt; rutepolitikken må endrast.

Hindre den andre klienten i å krevje alt

Éin klient bør eige standardruta, og den andre bør berre bere sine eigne prefiks. OpenVPN klientar kan avvise det serveren skyt på.

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

route-nopull ignorerer kvar påskoten rute, medan pull-filter ignore "redirect-gateway" berre droppar standardrutedirektivet og held på påskoten DNS og andre val. Vel mellom dei ut frå kor mykje av serverkonfigurasjonen du framleis vil ha, og legg deretter til dei spesifikke prefiksa det andre nettet treng. Hugs DNS, fordi ein resolver som blir påskoten av ein tunnel som ikkje ber oppslaga, returnerer ingenting. Test éin kjend vert i kvart nett og stadfest kjeldeadressa fjernsida ser.

Overlappande subnett kan ikkje rutast rundt

Når begge netta publiserer same prefiks, held kjernen éi oppføring for to ulike stader og må velje. Ei vertsrute kan ikkje finne opp den manglande skilnaden, og ein metrikkjustering kan heller ikkje. Omnummerer éi side, eller la administratoren hennar omsetje fjernområdet slik at prefiksa blir ulike. Kontroller dei verkelege subnettet før du klandrar klientane, fordi standarden 192.168.1.0/24 på ein heimeruttar oftare kolliderer med eit kontorområde enn nokon ventar. Noter begge områda i saka slik at neste endring ikkje gjenopprettar overlappinga.

Skil også to mål: å nå begge nett er eit ruteproblem, medan å kjede tunnelar for personvern er eit anna design med ein ekstra operatør på vegen. Ikkje bruk det eine til å løyse det andre.