Aplikace se naváže na adresu VPN a spojení přesto odchází obvyklou výchozí trasou. V navázání nic neselhalo; udělalo přesně to, co navázání dělá. Navázání socketu na místní adresu zvolí zdrojovou adresu, kterou jádro vloží do hlavičky. Neinstaluje trasu a nevytváří pravidlo zásad, které by pakety s tímto zdrojem posílalo do určitého tunelu.

Zbytek této příručky je pořadí kontrol, které používám, spolu s příkazem, jenž dává každé pozorování.

Co navázání skutečně rozhoduje

Navázání přiřadí socketu místní adresu. Jádro pak provede stejné vyhledání trasy, jaké by provedlo jinak, pokud pravidlo zásad nezmění, kterou tabulku toto vyhledání čte.

Proto může paket odejít se zdrojovou adresou VPN na fyzickém rozhraní. Na druhé straně dorazí z privátního rozsahu, který síť na této cestě nikdy neočekávala, zpětný provoz nemá trasu zpět a spojení se zasekne nebo se resetuje.

Referenční příručka socketů IP v Linuxu dokumentuje sémantiku navázání. Polovina pro směrování žije v ip-rule a ip-route a to jsou oddělené manuálové stránky z nějakého důvodu.

Ověřte, že adresa patří do tohoto jmenného prostoru

Adresa, na kterou lze navázat, musí existovat na rozhraní uvnitř síťového jmenného prostoru, ve kterém aplikace běží. Adresa protějšku, adresa brány nebo adresa, která existuje jen v jiném jmenném prostoru, navázat nelze a volání selže s EADDRNOTAVAIL.

ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>

Spusťte tyto tři příkazy ve stejném kontextu jako aplikaci: stejný jmenný prostor a stejný uživatel, pokud ho získáte. Staré schéma net30 není důkazem o tom, kterou adresu vaše současná topologie klientovi přidělila. Čtěte rozhraní, které je skutečně aktivní.

Přečtěte vyhledání pro tento zdroj a cíl

Jeden příkaz odpovídá na otázku, kterou navázání nezodpovědělo:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

První řádek vypíše trasu, kterou by paket z tohoto zdroje do tohoto cíle prošel, včetně odchozího rozhraní a preferovaného zdroje. Pokud uvede fyzické rozhraní, navázání a trasa si odporují a paket odejde se zdrojem, na který se cesta neumí vrátit.

Potom ip rule show řekne, zda by nějaké pravidlo zvolilo jinou tabulku. Priority jsou zde důležité, protože vyhrává první odpovídající pravidlo a pravidlo chytající vše nad vaším učiní vaše pravidlo neviditelným.

Instalujte pravidlo zásad jen tehdy, je-li to záměr

Směrování podle zdroje je záměrný návrh, ne oprava pro jednu aplikaci. Pokud správce zásad chce, aby provoz z podsítě tunelu používal tunel, pravidlo patří do jeho konfigurace, nikoli do jednorázového příkazu na vašem notebooku.

Funkční podoba je vyhrazená tabulka s výchozí trasou přes tunel plus pravidlo, které posílá zdrojový rozsah VPN do této tabulky. Přidejte výjimky, které návrh potřebuje, protože tabulka obsahující jen výchozí tunelovou trasu zachytí cíle, které mají zůstat místní nebo dostupné přes fyzickou cestu.

ip route add default dev tun0 table 100
ip rule add from 10.8.0.2 table 100 priority 100
ip route get 203.0.113.10 from 10.8.0.2

Vraťte zpět pomocí ip rule del a ip route flush table 100. Vše takto přidané zmizí po restartu, pokud to nezapíše správce, což je zároveň bezpečnostní vlastnost i důvod, proč nedržet jedinou kopii v historii svého shellu.

Ověřte třemi pozorováními

Zaznamenejte zdroj, který aplikace požadovala, trasu, kterou vyhledání zvolilo, a zdroj, který server skutečně viděl.

Tyto tři se mohou rozejít a každý rozpor ukazuje jinam. Zachycení na rozhraní tunelu dokazuje, že paket odešel se správným zdrojem. Zachycení na fyzickém rozhraní dokazuje, že odešel špatnou cestou. Pohled ze strany serveru je jediný, který dokazuje cestu od konce do konce.

Pokud aplikace nabízí volbu navázání na zařízení nebo režim směrování pro jednotlivé aplikace, berte to jako jiný mechanismus s jinými omezeními. Podobně vypadající nastavení nevedou všechna ke stejnému rozhodnutí jádra.

Související články