Dva VPN klienti, jedna routovací tabulka: kdo získá výchozí trasu

Vypadá to, že dva VPN klienti bojují o stejný socket, a zřejmou opravou musí být jednoho odinstalovat. Ve skutečnosti se málokdy dotknou stejného socketu. Každé připojení přepíše routovací tabulku operačního systému a profil plného tunelu si nárokuje výchozí trasu. Obvykle vyhraje ten, kdo se připojil naposledy, a proto jako by se symptom přesouval mezi klienty.

Konflikt žije v routovací tabulce

Virtuální adaptér plus výchozí trasa – tak plný tunel zachytí provoz. Když druhý klient nainstaluje svou výchozí trasu, starší záznam se nahradí nebo se sníží metrikou a každý cíl nyní putuje novějším tunelem. První klient zůstává připojený a stále ukazuje zelenou ikonu, takže rozhraní je aktivní, zatímco cesta zmizela. Právě toto oddělení stavu připojení a stavu routování dělá chování matoucím.

Klienti jsou editory jedné sdílené tabulky. Vědět, která změna byla poslední, vysvětlí téměř každý symptom.

Přečtěte si, který tunel vlastní aktuální cestu

Zkontrolujte skutečné rozhodnutí místo toho, abyste věřili klientovi, který hlásí připojení. Zeptejte se systému, které rozhraní by neslo konkrétní cíl.

ip route get 10.20.0.5
route print -4

První příkaz pojmenuje rozhraní a zdrojovou adresu pro jeden cíl, což je přesně ta otázka, která vás zajímá. Výpis tras ukazuje v Windows soupeřící výchozí záznamy a jejich metriky, takže vidíte, který právě vítězí. Spusťte vyhledání pro hostitele v každé vzdálené síti, protože jeden cíl může být správný, zatímco druhá síť je nedostupná. Pokud odpověď jmenuje špatný tunel, opětovné připojení nepomůže; politika routování se musí změnit.

Zastavte druhého klienta v nárokování všeho

Jeden klient by měl vlastnit výchozí trasu a druhý by měl nést jen své vlastní prefixy. OpenVPN klienti mohou odmítnout to, co server protlačuje.

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

route-nopull ignoruje každou protlačenou trasu, zatímco pull-filter ignore "redirect-gateway" zahodí jen direktivu výchozí trasy a ponechá protlačené DNS a další volby. Vyberte mezi nimi podle toho, kolik konfigurace serveru ještě chcete, a pak přidejte konkrétní prefixy, které druhá síť potřebuje. Mějte na paměti DNS, protože resolver protlačený tunelem, který dotazy nenese, nic nevrací. Vyzkoušejte jednoho známého hostitele v každé síti a potvrďte zdrojovou adresu, kterou vidí vzdálená strana.

Překrývající se podsítě nelze obejít

Když obě sítě publikují stejný prefix, jádro drží jeden záznam pro dvě různá místa a musí volit. Trasa hostitele nemůže chybějící rozdíl vymyslet a úprava metriky také ne. Přečíslujte jednu stranu, nebo ať její správce přeloží vzdálený rozsah, aby se prefixy lišily. Zkontrolujte skutečné podsítě, než obviníte klienty, protože výchozí 192.168.1.0/24 domácího routeru koliduje s kancelářským rozsahem častěji, než kdo čeká. Zapište oba rozsahy do tiketu, aby příští změna překryv znovu nevytvořila.

Oddělte také dva cíle: dosáhnout obou sítí je problém routování, zatímco řetězení tunelů kvůli soukromí je jiný návrh s dalším operátorem na cestě. Nepoužívejte jedno k vyřešení druhého.