Proč druhý VPN tunel rozbije ten první?

Instalace druhého VPN klienta kvůli přístupu do jedné zákaznické sítě je obvyklý způsob, jak to začíná, a první tunel zhasne, zatímco oba klienti hlásí úspěch. Každý klient nainstaloval výchozí trasu, ta druhá byla konkrétnější, a jádro ji teď následuje pro všechno kromě vlastního vnějšího spojení prvního tunelu. Nic nespadlo a žádný profil není špatný. Jedna trasa nahradila druhou a řešením je rozhodnout, který tunel má vlastnit výchozí trasu.

Příznak: druhý klient tiše vyhraje

OpenVPN: volba redirect-gateway def1 nepřepisuje 0.0.0.0/0. Přidává 0.0.0.0/1 a 128.0.0.0/1: dohromady pokrývají každou adresu IPv4 a každý prefix poráží obyčejnou výchozí trasu délkou. Původní výchozí trasa zůstává v tabulce a přestává se používat pro běžný provoz a hostitelská trasa k VPN serveru brání tunelu zachytit jeho vlastní vnější pakety. Oba klienti to dělají a druhý prostě svou dvojici nainstaluje později.

Proto první tunel vypadá mrtvý, ne odpojený. Jeho rozhraní je nahoře, řídicí kanál žije a žádný provoz aplikací se k němu už nedostane. Opačná stížnost má stejný chybějící push: telefon, který se připojí, ale nic neposílá, obvykle mluví se serverem, který nikdy neinzeroval redirect-gateway, takže zařízení si ponechá svou výchozí trasu a dosáhne jen na pool.

Pořiďte snímek tras před připojením druhého klienta a po něm. Dvě poloviční trasy, které se v tabulce objeví, jsou celá změna a vysvětlují obě stížnosti. Nic jiného v tabulce se kvůli příznaku hýbat nemusí. Proto odebrání druhého klienta okamžitě obnoví první.

Přečtěte si, který tunel skutečně vyhraje

Neodvozujte vítěze z pořadí, v jakém se klienti spustili, ani z ikony v oznamovací oblasti. Zeptejte se jádra, kterou trasu by použilo pro cíl mimo obě privátní sítě, a přečtěte si vrácené rozhraní.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

První dva příkazy jsou odpověď Linuxu a poslední dva ekvivalent Windows. Spusťte je, dokud jsou oba tunely nahoře, pak jeden odpojte a spusťte je znovu. Rozdíl mezi dvěma výstupy je fakt, který potřebujete před volbou řešení, a zabere méně času než čtení logu kteréhokoli klienta.

Zaznamenejte výsledek včetně názvu rozhraní a prefixu, který odpovídal. Tiket, který říká, že druhý VPN rozbil první, je popis příznaku, ne směrovací tvrzení, na kterém by se dalo stavět. Vyhledání z něj udělá fakt, který příští inženýr zopakuje jedním příkazem.

Windows: zabraňte, aby jeden profil vlastnil výchozí trasu

Windows uchovává uložené profily a vestavěný klient umožňuje, aby jeden závisel na druhém, takže první naskočí automaticky, když se druhý vytočí. Profil připojený naposledy má tendenci držet výchozí trasu, takže praktickým vlastníkem je poslední vytočení, ne první. Dejte každému profilu jeho vlastní push trasy a zapněte split tunneling u toho, který výchozí trasu vlastnit nemá.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling to mění: do tabulky se dostanou jen prefixy pushnuté serverem, což nechá výchozí trasu prvnímu tunelu. Návrh stále selhává, pokud oba servery pushují výchozí trasu, protože pak vyhraje poslední spojení a žádné nastavení na straně klienta to nezmění. Opravte push na serveru, nebo přijměte jednoho vlastníka.

Profily spouštěné aplikací jsou jiná funkce a stojí za to je znát: profil Windows se může spustit při startu pojmenovaného spustitelného souboru a filtry provozu rozhodují, co ponese. Je to nastavení profilu, ne pravidlo firewallu, a řeší jiný problém než konflikt výchozí trasy.

Linux: držte druhý tunel mimo hlavní tabulku

Spuštění dvou instancí openvpn --config na jednom stroji dá oba klienty do stejné tabulky a tři možnosti je oddělí s rostoucí izolací. Nejlehčí je přestat nechat druhého klienta tabulku vůbec upravovat: route-nopull s explicitními trasami nebo skript route-up, který nainstaluje jen to, co zamýšlíte. Pak druhý tunel nese přesně vámi pojmenované prefixy a nic jiného. Pak rozhodujete, které prefixy kam jdou, místo abyste to zjišťovali dodatečně.

Policy routing je prostřední možnost. Pravidlo vybere samostatnou tabulku pro jednu zdrojovou adresu nebo značku firewallu a tato tabulka nese trasy druhého tunelu. Filtrování reverzní cesty je zde past, protože odpověď, která dorazí na jiné rozhraní, než by tabulka vybrala, se zahodí, takže před závěrem, že je tunel rozbitý, zkontrolujte nastavení rp_filter.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Síťové namespacy jsou nejtěžší a nejčistší možnost. Spusťte druhého klienta uvnitř ip netns, dejte mu pár veth a vstupte do tohoto namespace, abyste ho používali. Rušení zmizí, protože každý namespace vlastní vlastní tabulky místo sdílení jedné; to stojí za nastavení navíc, když oba tunely musí zůstat nahoře týdny.

Podle aplikace a řetězení jako samostatný problém

Někdy má druhý tunel používat jen jeden program. Na Linuxu toho dosáhne policy routing podle uživatele, cgroup nebo portu a jedna destinace se dá připnout k rozhraní, aniž by se výchozí trasa vůbec dotkla. Aplikace, která připne svůj socket k jednomu rozhraní, tabulku tras vůbec nekonzultuje, takže launcher může dál používat fyzický adaptér, dokud se adresa nevybere v jeho vlastním nastavení.

Řetězení je jiná operace než provozování dvou tunelů vedle sebe. Zřetězit A přes B znamená, že adresa vnitřního serveru musí být dosažitelná zevnitř vnějšího tunelu. Vnější klient také nesmí považovat šifrované pakety vnitřního klienta za únik. Jeden klient ve virtuálním stroji je hrubá, ale spolehlivá verze; oba na jednom hostiteli vyžadují směrovací práci výše plus vnější cestu k vnitřnímu serveru, která nikdy nevstoupí do vnitřního tunelu.

Zapište vlastníka výchozí trasy, seznam prefixů každého tunelu a cestu DNS. Tyto tři fakta promění příští incident ve vyhledání místo vyšetřování.