Aplikace navázaná na rozhraní? Její cesta přes VPN není výchozí

Jedna aplikace na stroji vychází přes VPN a druhá ne, a oba uživatelé přísahají, že nic nezměnili. Rozdíl je často rozhodnutí o navázání, které udělá sama aplikace: soket navázaný na zařízení, zdrojová adresa zvolená před spojením nebo jmenný prostor s vlastní směrovací tabulkou. Každé z nich mění, která cesta platí, a žádné se neprojeví v běžné kontrole IP v prohlížeči.

Tři různá navázání, tři různé účinky

Navázání na zařízení a navázání na zdrojovou adresu jsou příbuzné operace s odlišnými důsledky. Navázání na zařízení může přinutit provoz vyjít jedním rozhraním a obejít běžné hledání trasy pro daný soket. Navázání zdrojové adresy stále prochází výběrem trasy, ale zvolený zdroj může odpovídat pravidlu zásad a poslat paket jinam. Rozdíl zní akademicky, dokud pravidlo nezačne směrovat podle zdroje. Pak rozhoduje o všem.

Síťový jmenný prostor je třetí případ. Má vlastní rozhraní a směrovací tabulku, takže aplikace uvnitř není výchozím nastavením hostitele vůbec ovlivněna. Když se všechny tři považují za totéž, vznikají sebevědomá vysvětlení, která neprojdou prvním testem.

Zjistěte, co aplikace skutečně nastavuje

Předtím než sáhnete na trasy, přečtěte si síťovou konfiguraci aplikace nebo její dokumentované chování. Pokud nabízí volbu rozhraní, pole zdrojové adresy nebo volbu jmenného prostoru, je toto nastavení první věc k prozkoumání. Pokud ne, navázání může být vnitřní a viditelné jen přes trasování nebo vlastní diagnostiku.

V Linuxu mají volby soketu jako SO_BINDTODEVICE dokumentovaný rozsah a požadavky na oprávnění a neprivilegovaný proces je nemusí vůbec umět nastavit. Toto omezení je užitečná stopa: pokud volbu nelze použít, aplikace pravděpodobně není zdrojem rozdílu.

Směrování podle zásad čte zdroj

Když je nastaveno směrování podle zásad, může pravidlo vybrat tabulku na základě zdroje paketu. Soket, který navazuje zdrojovou adresu, proto může sledovat pravidlo, na které výchozí cesta vůbec nesáhne, i když žádné rozhraní není výslovně uvedeno.

Zopakujte hledání se stejnou rodinou adres, zdrojem a jmenným prostorem, které aplikace používá. Běžné hledání trasy z shellu v jmenném prostoru hostitele odpovídá na jinou otázku a tento nesoulad je nejčastějším důvodem, proč funkční trasa vypadá rozbitě.

Rozdělený tunel a pomocné procesy

Rozdělený tunel pro jednotlivé aplikace přidává další vrstvu. Klient může párovat balíček nebo proces aplikace a pomocník, který otevírá vlastní soket, je samostatný subjekt. Spouštěč a jeho služba na pozadí mohou vytvářet různé spoje pod stejným viditelným jménem.

Zkontrolujte, zda pravidlo rozděleného tunelu pokrývá proces, který se skutečně připojuje. Pokud se aplikace naváže na konkrétní rozhraní a klient VPN páruje podle balíčku, obě rozhodnutí se mohou rozejít, aniž by jedno bylo špatné.

Otestujte vlastní cestu aplikace

Po každé změně spusťte z aplikace nový požadavek. Prohlížeč, který ukazuje požadovaný výstup, není rovnocenným důkazem pro jiný program navázaný na jiné rozhraní a uložená spojení mohou starou cestu používat dlouho po změně nastavení. Před posouzením nového pravidla zavřete starou relaci. Jinak test měří minulost.

Referenční příručka soketů Linuxu dokumentuje SO_BINDTODEVICE a jeho požadavky. Nejprve si přečtěte vlastní konfiguraci aplikace, zopakujte hledání ve stejném kontextu a teprve potom rozhodněte, zda změnit trasu, nebo navázání.