To VPN-klienter, én rutetabel: hvem vinder standardruten

Det ser ud, som om to VPN-klienter slås om den samme socket, og den oplagte løsning må være at afinstallere den ene. I praksis rører de sjældent den samme socket. Hver forbindelse overskriver styresystemets rutetabel, og en fuldtunnel-profil kræver standardruten. Den, der sluttede sidst, vinder som regel, og derfor ser symptomet ud til at flytte sig mellem klienterne.

Konflikten bor i rutetabellen

En virtuel adapter plus en standardrute er, hvordan en fuld tunnel fanger trafik. Når den anden klient installerer sin egen standardrute, erstattes eller nedgraderes den ældre post af metrikken, og hver destination rejser nu gennem den nyere tunnel. Den første klient bliver forbundet og viser stadig et grønt ikon, så grænsefladen er oppe, mens vejen er væk. Netop den adskillelse mellem forbindelsestilstand og rutetilstand gør adfærden forvirrende.

Klienterne er redaktører af én fælles tabel. At vide, hvilken ændring der skete sidst, forklarer næsten hvert symptom.

Læs, hvilken tunnel der ejer den aktuelle vej

Kontrollér den faktiske beslutning i stedet for at stole på den klient, der melder sig forbundet. Spørg systemet, hvilken grænseflade der ville bære en bestemt destination.

ip route get 10.20.0.5
route print -4

Den første kommando navngiver grænsefladen og kildeadressen for én destination, og det er netop det spørgsmål, du bekymrer dig om. Ruteudskriften viser de konkurrerende standardposter og deres metrikker på Windows, så du kan se, hvilken der vinder lige nu. Kør opslaget for en vært i hvert fjernnetværk, fordi én destination kan være korrekt, mens det andet netværk er utilgængeligt. Hvis svaret navngiver den forkerte tunnel, hjælper det ikke at genoprette forbindelsen; rutepolitikken skal ændres.

Stop den anden klient i at kræve alt

Én klient bør eje standardruten, og den anden bør kun bære sine egne præfikser. OpenVPN klienter kan afvise det, serveren skubber ind.

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

route-nopull ignorerer hver skubbet rute, mens pull-filter ignore "redirect-gateway" kun dropper standardrute-direktivet og beholder skubbet DNS og andre muligheder. Vælg mellem dem ud fra, hvor meget af serverens konfiguration du stadig vil have, og tilføj derefter de specifikke præfikser, som det andet netværk har brug for. Husk DNS, fordi en resolver, der skubbes ind af en tunnel, som ikke bærer opslagene, ikke returnerer noget. Test én kendt vært i hvert netværk, og bekræft den kildeadresse, fjernsiden ser.

Overlappende undernet kan ikke routes udenom

Når begge netværk offentliggør det samme præfiks, har kernen én post til to forskellige steder og må vælge. En værtsrute kan ikke opfinde den manglende forskel, og en metrikjustering kan heller ikke. Omnummerér den ene side, eller lad dens administrator oversætte det fjernintervall, så præfikserne er forskellige. Kontrollér de rigtige undernet, før du skyder skylden på klienterne, fordi en hjemmerouters standard 192.168.1.0/24 oftere støder sammen med et kontorinterval, end nogen forventer. Notér begge intervaller i sagen, så den næste ændring ikke genskaber overlapningen.

Adskil også to mål: at nå begge netværk er et routingproblem, mens at kæde tunneller sammen for privatliv er et andet design med en ekstra operatør på vejen. Brug ikke det ene til at løse det andet.