Twee VPN-kliënte, een roettabel: wie wen die verstekroete

Dit lyk of twee VPN-kliënte oor 'n sokkel baklei, en die ooglopende oplossing moet wees om een te verwyder. In die praktyk raak hulle selde dieselfde sokkel aan. Elke verbinding herskryf die bedryfstelsel se roettabel, en 'n voltonnel-profiel eis die verstekroete. Die een wat laas verbind het, wen gewoonlik, en daarom lyk dit of die simptoom tussen kliënte rondskuif.

Die konflik sit in die roettabel

'n Virtuele adapter plus 'n verstekroete is hoe 'n voltonnel verkeer vasvang. Wanneer die tweede kliënt sy eie verstek installeer, word die ouer inskrywing vervang of deur die metriek afgegradeer, en elke bestemming reis nou deur die nuwer tonnel. Die eerste kliënt bly verbind en wys steeds 'n groen ikoon, so die koppelvlak is op terwyl die pad weg is. Daardie skeiding tussen verbindingstoestand en roetetoestand maak die gedrag verwarrend.

Die kliënte is bewerkers van een gedeelde tabel. As jy weet watter wysiging laas gebeur het, verduidelik dit byna elke simptoom.

Lees watter tonnel die huidige pad besit

Kontroleer die werklike besluit in plaas daarvan om die kliënt te vertrou wat sê hy is verbind. Vra die stelsel watter koppelvlak 'n bepaalde bestemming sou dra.

ip route get 10.20.0.5
route print -4

Die eerste opdrag noem die koppelvlak en bronadres vir een bestemming, en dit is die presiese vraag wat jou aangaan. Die roetelys wys die mededingende verstekinskrywings en hul metrieks op Windows, sodat jy kan sien wie tans wen. Doen die opsoek vir 'n gasheer in elke afgeleë netwerk, want een bestemming kan reg wees terwyl die ander netwerk onbereikbaar is. As die antwoord die verkeerde tonnel noem, sal herverbinding nie help nie; die roetebeleid moet verander.

Keer dat die tweede kliënt alles opeis

Een kliënt moet die verstekroete besit, en die ander moet net sy eie prefikse dra. OpenVPN kliënte kan weier wat die bediener stoot.

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

route-nopull ignoreer elke gestuurde roete, terwyl pull-filter ignore "redirect-gateway" net die verstekroete-richtlijn laat val en gestuurde DNS en ander opsies behou. Kies tussen hulle op grond van hoeveel van die bediener se konfigurasie jy nog wil hê, en voeg dan die spesifieke prefikse by wat die tweede netwerk nodig het. Hou DNS in gedagte, want 'n oplosser wat deur 'n tonnel gestuur word wat nie die opsoeke dra nie, gee niks terug. Toets een bekende gasheer in elke netwerk en bevestig die bronadres wat die ander kant sien.

Oorvleuelende subnette kan nie omseil word nie

Wanneer albei netwerke dieselfde prefiks publiseer, hou die kern een inskrywing vir twee verskillende plekke en moet kies. 'n Gasheerroete kan nie die ontbrekende onderskeid versin nie, en 'n metriekaanpassing ook nie. Herbenoem een kant, of laat sy administrateur die afgeleë reeks vertaal sodat die prefikse verskil. Kyk na die werklike subnette voordat jy die kliënte blameer, want 'n tuisroeteerder se verstek van 192.168.1.0/24 bots meer dikwels met 'n kantoorreeks as wat iemand verwag. Teken albei reekse in die kaartjie aan sodat die volgende wysiging nie die oorvleueling herskep nie.

Skei ook twee doelwitte: om albei netwerke te bereik is 'n roeteprobleem, terwyl die koppeling van tonnels vir privaatheid 'n ander ontwerp is met 'n ekstra operateur in die pad. Moenie die een gebruik om die ander op te los nie.