Vnořená VPN: který tunel nese vnější spojení?

Dva klienti VPN běžící současně nevytvářejí vnořený tunel; vytvářejí dva tunely a hádku o směrování. Vnořený tunel existuje, když je spojení vnitřního klienta s vlastním serverem samo neseno vnějším tunelem, a to je uspořádání, které se staví záměrně. Když to vyjde, vnitřní server vidí adresu vnějšího serveru; když ne, jeden klient se tiše připojí znovu kolem druhého. O tom, zda je vnoření skutečné nebo náhodné, rozhodují tři podmínky.

O vnoření rozhodují tři podmínky

První je, který koncový bod potřebuje kterou cestu. Pojmenuj adresu vnitřního serveru, pojmenuj adresu vnějšího serveru a výslovně uveď, že vnitřní server je dostupný jen přes vnější tunel. Vše ostatní z té věty plyne, včetně toho, které trasy patří do které tabulky.

Druhá je, zda cestu vidíš na každé vrstvě. Pokud se nemůžeš jádra zeptat, kterou trasu by konkrétní cíl použil, odvozuješ řetěz z konečné výstupní IP, a to je právě ten důkaz, který nedokáže rozeznat vnoření od náhody.

Třetí je, co se stane, když vnější tunel spadne. Vnitřní tunel se s ním může zastavit, připojit se znovu přes běžnou síť, nebo zůstat zablokovaný, dokud se vnější cesta nevrátí, a všechny tři jsou obhajitelné politiky. Nejsou to stejné politiky a výchozí chování většiny klientů je ta druhá. Klient, který znovu připojí svůj koncový bod přes fyzickou síť, zatímco ukazuje zdravé spojení, je nejčastější způsob, jak se zamýšlený řetěz tiše stane dvěma nesouvisejícími tunely.

Podmínka jedna: který koncový bod potřebuje kterou cestu

ip route get 203.0.113.10 na tu otázku odpovídá přímo: vypíše trasu, zdrojovou adresu a rozhraní, které by jádro pro daný cíl právě teď použilo.

Spusť to pro vnitřní server před startem vnitřního klienta a pak znovu po něm, a porovnej. Pokud se odpověď změní z fyzického rozhraní na rozhraní vnějšího tunelu, je vnoření v tu chvíli skutečné. Pokud se nezmění, vnitřní klient se připojuje přímo, ať panel říká cokoli. Zopakuj to pro adresu vnějšího serveru, která se stále musí překládat přes fyzické rozhraní, protože trasa, která rekurzivně zachytí oba koncové body, je porucha, která stroj zcela odpojí od sítě.

Podmínka dvě: prozkoumej cestu na každé vrstvě

Výběr trasy je na moderním klientovi víc než hlavní tabulka. Pravidla politiky mohou posílat označené pakety do jiné tabulky, klient může svůj socket připoutat k rozhraní a kontejner nebo jmenný prostor má vlastní tabulky. ip rule a ip route show table all jsou způsob, jak zjistit, který z těchto mechanismů je ve hře.

Klient, který nastavuje SO_MARK na vlastním socketu nebo je nakonfigurován k připoutání ke konkrétnímu zařízení, obchází výchozí trasu, o níž jsi si myslel, že jsi ji zařídil. To je funkce, ne chyba, a znamená to, že jediná spolehlivá kontrola je ta, která běží ve stejném jmenném prostoru jako klient. Pokud klienti běží v kontejnerech, spouštěj kontroly v těch kontejnerech, ne na hostiteli.

Podmínka tři: co se stane, když vnější tunel spadne

Chování při poruše vyžaduje rozhodnutí, ne výchozí hodnotu. Zapiš, co se má stát s vnitřním tunelem, když vnější zmizí, a pak to nech klienty dělat.

Možnosti jsou konkrétní. Zastavení vnitřního klienta, když vnější cesta zmizí, dává čistý řetěz a zjevný výpadek. Nechat ho připojit se přímo dává dostupnost a tiše odstraňuje vlastnost, pro kterou byl řetěz postaven. Blokovat do návratu vnější cesty je nejpřísnější a provozně nejotravnější, protože každé zakolísání vnějšího tunelu se stane viditelnou událostí.

Otestuj všechny tři s neškodným provozem a záměrnou poruchou vnějšího tunelu, protože čtení konfigurace ti neřekne, kterou máš. Zabi vnější tunel, sleduj, co dělá vnitřní klient, a zkontroluj trasu znovu, dokud je dole. Potom vnější tunel vrať a potvrď, že se řetěz znovu vytvoří, místo aby vnitřní klient zůstal na přímé cestě, kterou si mezitím vybral.

Co ti řetěz nedá

Další vrstvy přidávají koncové body, klíče a režimy poruch; nepřidávají žádnou záruku anonymity a nezpůsobují, že vnější operátor nemůže vidět, že tunel existuje. Každé tvrzení o tom, před čím vnoření chrání, musí pojmenovat pozorovatele, před kterým chrání.

Výstupem je krátký dokument, ne fungující spojení: který koncový bod používá kterou cestu, co se stane při vnější poruše a tři příkazy, které ukazují aktuální stav. Dokumentace strongSwan o předávání je užitečný odkaz pro to, jak se tunelový provoz předává mezi rozhraními na hostiteli Linux. Spouštěj kontroly znovu po každé aktualizaci klienta, protože výchozí hodnoty, které vytvořily tvůj řetěz, nejsou smlouva. Vnořený tunel, který nemůžeš prozkoumat, je fáma se stavovou kontrolkou.