Dva VPN klienti na jednom počítači: co se sráží a co funguje

Dva klienti se perou o výchozí trasu, resolver a filtrační ovladače. Zapište, kdo vlastní odchod, a pak oddělte druhý tunel pomocí VM nebo netns.

Váš druhý klient se připojí, prostředky prvního se přestanou překládat a tiket tvrdí, že pracovní VPN rozbila tu osobní. Nic není rozbité ve smyslu závady: oba klienti dělali to, k čemu byli navrženi, a stroj má jen jednu směrovací tabulku. Srážka je o čtyři prostředky, které každý klient považuje za vlastní. Projděte je popořadě a oprava se obvykle stane designovým rozhodnutím, ne opravou.

Krok 1: zjistěte, který klient vlastní odchod

Přečtěte si aktuální rozhodnutí o odchodu, než cokoli změníte. Vyhledání trasy k veřejné adrese vám řekne, které rozhraní a který další skok by paket právě teď použil, a to je odpověď na to, kdo vyhrál. Porovnejte to s názvy rozhraní, která klienti vytvořili; obvykle nesou název produktu nebo protokolu. Pokud vyhledání ukazuje na tunel, který jste nečekali, srážku jste už našli.

ip route get 1.1.1.1
ip route show default
route print

Někteří klienti výchozí trasu vůbec nenahrazují; přidají dvě poloviny, jednu pro spodní polovinu adresního prostoru a jednu pro horní, které dohromady pokrývají všechno. Tím zůstane původní výchozí trasa viditelná a ruční oprava vypadá správně, zatímco provoz stále odchází tunelem. Čtěte metriku a délku prefixu, ne jen přítomnost výchozí položky.

Zastavte se, pokud oba klienti tvrdí stejný prefix se stejnou metrikou. Jádro vybere jeden a druhý se bude jevit jako připojený, ale nic neponese.

Krok 2: zkontrolujte resolver a překrývající se prefixy

DNS je druhá srážka a dává výrazný příznak: názvy selhávají, zatímco adresy fungují. Každý klient prosadí svůj resolver a poslední zápis vyhraje pro následující dotazy. Ptejte se služby resolveru, co používá pro každé spojení, místo abyste četli stránku nastavení klienta.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Pak porovnejte privátní prefixy, které obě sítě používají. Pokud obě strany přidělují ze stejného rozsahu, žádné opatření na straně klienta to nespraví, protože stroj nemůže říct, která destinace 10.0.0.0/8 patří kterému tunelu. Jedna strana musí být přečíslována nebo přeložena, a to je rozhovor s vlastníky sítě, ne změna konfigurace. Překryv je jediná srážka, u níž je poctivá odpověď, že se musí změnit návrh.

Zastavte se zde, pokud se prefixy překrývají. Všechno další v tomto seznamu předpokládá, že se nepřekrývají.

Krok 3: vyberte vzor oddělení, který vydrží

Spolehlivé vzory se vyhýbají provozu dvou klientů proti stejné směrovací tabulce. Jeden klient s politikou rozděleného tunelu, která dosáhne na obě privátní sítě je nejjednodušší, pokud se destinace nepřekrývají a vlastník politiky souhlasí. Virtuální stroj nebo síťový jmenný prostor je další stupeň, protože každý dostane vlastní tabulku a vlastní resolver.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Jmenný prostor dává stejné oddělení jako virtuální stroj bez druhého operačního systému, ale má hrubé hrany: tunelové zařízení se do něj musí přesunout a aplikace se v něm musí spustit. Samostatné fyzické zařízení je často nejméně překvapivá volba pro osobní VPN vedle spravovaného pracovního klienta. Skládání jednoho tunelu do druhého není vzor oddělení; vnitřní koncový bod musí zůstat dosažitelný přes vnější tunel a takové uspořádání navíc přidává problémy s MTU a latencí.

Vyberte jeden vzor a zapište proč. Míchání jmenného prostoru pro jednu aplikaci s rozděleným tunelem pro ostatní znovu vytváří původní srážku v podobě, která se hůř ladí.

Krok 4: ověřte obě sítě ze stejné relace

Otestujte jeden prostředek v každé privátní síti z prostředí, kde aplikace skutečně běží, ne ze svého shellu, pokud aplikace běží uvnitř jmenného prostoru. Zkontrolujte odchozí rozhraní, přeloženou adresu a kód odpovědi společně, protože úspěch v jedné ze tří věcí může skrýt selhání v ostatních. Opakujte po restartu, protože pořadí, v jakém se klienti spouštějí, rozhoduje o tom, kdo vyhraje. Právě toto pořadí lidé zapomínají zaznamenat.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Zaznamenejte verze klientů, rozhraní, stav resolveru a prefixy pro každou síť. Když se klient aktualizuje a změní své chování při směrování, tento záznam je rozdíl mezi pětiminutovou opravou a přestavbou. Další člověk nebude sdílet vaši paměť o tom, který tunel se zvedl první.

Seznam je hotový, když dokážete pojmenovat rozhraní, které vlastní výchozí trasu, resolver, který používá každý název, vzor, který odděluje druhý tunel, a výsledek jednoho požadavku na síť po restartu. Cokoli méně je konfigurace, která dnes náhodou funguje.

Související články