Twee VPN-clients, één routetabel: wie wint de standaardroute

Het lijkt of twee VPN-clients om dezelfde socket vechten, en de voor de hand liggende oplossing moet zijn er één te verwijderen. In de praktijk raken ze zelden dezelfde socket aan. Elke verbinding herschrijft de routetabel van het besturingssysteem, en een fulltunnelprofiel claimt de standaardroute. Wie het laatst verbond, wint meestal, en daarom lijkt het symptoom tussen clients te verschuiven.

Het conflict zit in de routetabel

Een virtuele adapter plus een standaardroute is hoe een volledige tunnel verkeer opvangt. Wanneer de tweede client zijn eigen standaard installeert, wordt de oudere vermelding vervangen of door de metriek verlaagd, en elke bestemming gaat nu via de nieuwere tunnel. De eerste client blijft verbonden en toont nog steeds een groen pictogram, dus de interface is actief terwijl het pad weg is. Juist die scheiding tussen verbindingsstatus en routeringsstatus maakt het gedrag verwarrend.

De clients zijn redacteuren van één gedeelde tabel. Weten welke wijziging het laatst gebeurde, verklaart bijna elk symptoom.

Lees welke tunnel het huidige pad bezit

Controleer de werkelijke beslissing in plaats van de client te vertrouwen die zich als verbonden meldt. Vraag het systeem welke interface een bepaalde bestemming zou dragen.

ip route get 10.20.0.5
route print -4

De eerste opdracht noemt de interface en het bronadres voor één bestemming, en dat is precies de vraag die u aangaat. De routedump toont op Windows de concurrerende standaardvermeldingen en hun metrieken, zodat u ziet welke nu wint. Voer de opzoeking uit voor een host in elk extern netwerk, want één bestemming kan kloppen terwijl het andere netwerk onbereikbaar is. Als het antwoord de verkeerde tunnel noemt, helpt opnieuw verbinden niet; het routebeleid moet veranderen.

Voorkom dat de tweede client alles opeist

Eén client zou de standaardroute moeten bezitten, en de andere alleen zijn eigen prefixen dragen. OpenVPN clients kunnen weigeren wat de server pusht.

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

route-nopull negeert elke gepushte route, terwijl pull-filter ignore "redirect-gateway" alleen de standaardroute-richtlijn laat vallen en de gepushte DNS en andere opties behoudt. Kies tussen beide op basis van hoeveel van de serverconfiguratie u nog wilt, en voeg daarna de specifieke prefixen toe die het tweede netwerk nodig heeft. Houd DNS in gedachten, want een resolver die door een tunnel wordt gepusht die de opzoekingen niet draagt, geeft niets terug. Test één bekende host in elk netwerk en bevestig het bronadres dat de externe kant ziet.

Overlappende subnetten zijn niet te omzeilen

Wanneer beide netwerken hetzelfde prefix publiceren, houdt de kernel één vermelding voor twee verschillende plaatsen en moet kiezen. Een hostroute kan het ontbrekende onderscheid niet verzinnen, en een metriekaanpassing ook niet. Hernummer één kant, of laat de beheerder het externe bereik vertalen zodat de prefixen verschillen. Controleer de echte subnetten voordat u de clients de schuld geeft, want de standaard 192.168.1.0/24 van een thuisrouter botst vaker met een kantoorbereik dan iemand verwacht. Noteer beide bereiken in het ticket, zodat de volgende wijziging de overlap niet opnieuw maakt.

Scheid ook twee doelen: beide netwerken bereiken is een routeringsprobleem, terwijl tunnels aaneenrijgen voor privacy een ander ontwerp is met een extra operator in het pad. Gebruik het ene niet om het andere op te lossen.