Dvaja klienti VPN na jednom počítači: čo koliduje a čo funguje

Dvaja klienti sa bijú o predvolenú trasu, resolver a filtračné ovládače. Zapíšte, kto vlastní výstup, a potom oddeľte druhý tunel pomocou VM alebo netns.

Váš druhý klient sa pripojí, prostriedky prvého sa prestanú prekladať a tiket tvrdí, že pracovná VPN pokazila tú osobnú. Nič nie je pokazené v zmysle poruchy: obaja klienti robili to, na čo boli navrhnutí, a počítač má len jednu smerovaciu tabuľku. Kolízia sa týka štyroch prostriedkov, ktoré každý klient považuje za vlastné. Prejdite ich po poradí a oprava sa zvyčajne stane dizajnovým rozhodnutím, nie opravou.

Krok 1: zistite, ktorý klient vlastní výstup

Prečítajte si aktuálne rozhodnutie o výstupe, skôr než čokoľvek zmeníte. Vyhľadanie trasy k verejnej adrese vám povie, ktoré rozhranie a ktorý ďalší skok by paket práve teraz použil, a to je odpoveď na to, kto vyhral. Porovnajte to s názvami rozhraní, ktoré klienti vytvorili; zvyčajne nesú názov produktu alebo protokolu. Ak vyhľadanie ukazuje na tunel, ktorý ste nečakali, kolíziu ste už našli.

ip route get 1.1.1.1
ip route show default
route print

Niektorí klienti predvolenú trasu vôbec nenahrádzajú; pridajú dve polovice, jednu pre spodnú polovicu adresného priestoru a jednu pre hornú, ktoré spolu pokrývajú všetko. Tým zostane pôvodná predvolená trasa viditeľná a ručná oprava vyzerá správne, hoci prevádzka stále odchádza tunelom. Čítajte metriku a dĺžku prefixu, nie len prítomnosť predvolenej položky.

Zastavte sa, ak obaja klienti žiadajú rovnaký prefix s rovnakou metrikou. Jadro vyberie jeden a druhý bude vyzerať pripojený, no nebude nič prenášať.

Krok 2: skontrolujte resolver a prekrývajúce sa prefixy

DNS je druhá kolízia a dáva výrazný príznak: názvy zlyhávajú, zatiaľ čo adresy fungujú. Každý klient presadí svoj resolver a posledný zapisujúci vyhrá pre nasledujúce dopyty. Pýtajte sa služby resolvera, čo používa pre každé spojenie, namiesto čítania stránky nastavení klienta.

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

Potom porovnajte súkromné prefixy, ktoré používajú obe siete. Ak obe strany prideľujú z rovnakého rozsahu, žiadne opatrenie na strane klienta to nespraví, pretože počítač nedokáže povedať, ktorá destinácia 10.0.0.0/8 patrí ktorému tunelu. Jedna strana musí byť prečíslovaná alebo preložená, a to je rozhovor s vlastníkmi siete, nie zmena konfigurácie. Prekrytie je jediná kolízia, pri ktorej je čestná odpoveď, že návrh sa musí zmeniť.

Zastavte sa tu, ak sa prefixy prekrývajú. Všetko ďalšie v tomto zozname predpokladá, že sa neprekrývajú.

Krok 3: vyberte vzor oddelenia, ktorý vydrží

Spoľahlivé vzory sa vyhýbajú prevádzke dvoch klientov proti tej istej smerovacej tabuľke. Jeden klient s politikou rozdeleného tunela, ktorá dosiahne obe súkromné siete je najjednoduchší, ak sa destinácie neprekrývajú a vlastník politiky súhlasí. Virtuálny stroj alebo sieťový menný priestor je ďalší krok, pretože každý dostane vlastnú tabuľku 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/

Menný priestor dáva rovnaké oddelenie ako virtuálny stroj bez druhého operačného systému, ale má drsné okraje: tunelové zariadenie sa doň musí presunúť a aplikácia sa v ňom musí spustiť. Samostatné fyzické zariadenie je často najmenej prekvapujúca voľba pre osobnú VPN vedľa spravovaného pracovného klienta. Skladanie jedného tunela do druhého nie je vzor oddelenia; vnútorný koncový bod musí zostať dostupný cez vonkajší tunel a také usporiadanie pridáva navyše problémy s MTU a latenciou.

Vyberte jeden vzor a zapíšte prečo. Miešanie menného priestoru pre jednu aplikáciu s rozdeleným tunelom pre ostatné znovu vytvára pôvodnú kolíziu v ťažšie ladiacom tvare.

Krok 4: overte obe siete z tej istej relácie

Otestujte jeden prostriedok v každej súkromnej sieti z prostredia, kde aplikácia skutočne beží, nie zo svojho shellu, ak aplikácia beží v mennom priestore. Skontrolujte výstupné rozhranie, preloženú adresu a kód odpovede spoločne, pretože úspech v jednom z troch môže skryť zlyhanie v ostatných. Zopakujte po reštarte, pretože poradie, v ktorom klienti štartujú, rozhoduje o tom, kto vyhrá. Práve toto poradie ľudia zabúdajú zaznamenať.

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

Zaznamenajte verzie klientov, rozhrania, stav resolvera a prefixy pre každú sieť. Keď sa klient aktualizuje a zmení svoje správanie pri smerovaní, tento záznam je rozdiel medzi päťminútovou opravou a prestavbou. Ďalší človek nebude zdieľať vašu pamäť o tom, ktorý tunel sa zdvihol prvý.

Zoznam je hotový, keď dokážete pomenovať rozhranie, ktoré vlastní predvolenú trasu, resolver, ktorý používa každý názov, vzor, ktorý oddeľuje druhý tunel, a výsledok jednej požiadavky na sieť po reštarte. Čokoľvek menej je konfigurácia, ktorá dnes náhodou funguje.

Súvisiace články