Två VPN-klienter, en routingtabell: vem vinner standardvägen

Det ser ut som att två VPN-klienter slåss om samma socket, och den självklara lösningen måste vara att avinstallera en. I praktiken rör de sällan samma socket. Varje anslutning skriver om operativsystemets routingtabell, och en fulltunnelprofil gör anspråk på standardvägen. Den som anslöt sist vinner oftast, och därför verkar symtomet flytta sig mellan klienterna.

Konflikten bor i routingtabellen

En virtuell adapter plus en standardväg är hur en full tunnel fångar trafiken. När den andra klienten installerar sin egen standardväg ersätts eller nedgraderas den äldre posten av metrik, och varje destination går nu genom den nyare tunneln. Den första klienten förblir ansluten och visar fortfarande en grön ikon, så gränssnittet är uppe medan vägen är borta. Just den här åtskillnaden mellan anslutningstillstånd och routingtillstånd gör beteendet förvirrande.

Klienterna är redaktörer för en delad tabell. Att veta vilken ändring som skedde sist förklarar nästan varje symtom.

Läs vilken tunnel som äger den aktuella vägen

Kontrollera det faktiska beslutet i stället för att lita på klienten som rapporterar att den är ansluten. Fråga systemet vilket gränssnitt som skulle bära en viss destination.

ip route get 10.20.0.5
route print -4

Det första kommandot namnger gränssnittet och källadressen för en destination, och det är precis den fråga du bryr dig om. Ruttutskriften visar de konkurrerande standardposterna och deras metrik i Windows, så du ser vilken som vinner just nu. Kör uppslaget för en värd i varje fjärrnät, eftersom en destination kan vara korrekt medan det andra nätet är onåbart. Om svaret namnger fel tunnel hjälper det inte att återansluta; routningspolicyn måste ändras.

Hindra den andra klienten från att göra anspråk på allt

En klient bör äga standardvägen, och den andra bör bara bära sina egna prefix. OpenVPN klienter kan avvisa det servern skjuter på.

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

route-nopull ignorerar varje påskjuten rutt, medan pull-filter ignore "redirect-gateway" bara släpper standardruttsdirektivet och behåller påskjuten DNS och andra alternativ. Välj mellan dem utifrån hur mycket av serverkonfigurationen du fortfarande vill ha, och lägg sedan till de specifika prefix som det andra nätet behöver. Tänk på DNS, eftersom en resolver som skjuts på av en tunnel som inte bär uppslagen inte returnerar något. Testa en känd värd i varje nät och bekräfta källadressen som fjärrsidan ser.

Överlappande subnät går inte att runda

När båda näten publicerar samma prefix håller kärnan en post för två olika platser och måste välja. En värdrutt kan inte hitta på den saknade skillnaden, och en metrikjustering kan inte heller. Numrera om ena sidan, eller låt dess administratör översätta fjärrområdet så att prefixen skiljer sig. Kontrollera de verkliga subnäten innan du skyller på klienterna, eftersom en hemrouters standard 192.168.1.0/24 krockar med ett kontorsområde oftare än någon förväntar sig. Anteckna båda områdena i ärendet så att nästa ändring inte återskapar överlappningen.

Skilj också två mål: att nå båda näten är ett routingproblem, medan att kedja tunnlar för integritet är en annan design med en extra operatör på vägen. Använd inte det ena för att lösa det andra.