Aplikácia naviazaná na adresu VPN stále používa nesprávnu trasu

Aplikácia sa naviaže na adresu VPN a spojenie napriek tomu odchádza obvyklou predvolenou trasou. V naviazaní nič nezlyhalo; urobilo presne to, čo naviazanie robí. Naviazanie socketu na lokálnu adresu vyberie zdrojovú adresu, ktorú jadro vloží do hlavičky. Neinštaluje trasu a nevytvára pravidlo politiky, ktoré by pakety s týmto zdrojom posielalo do určitého tunela.

Zvyšok tejto príručky je poradie kontrol, ktoré používam, spolu s príkazom, ktorý dáva každé pozorovanie.

Čo naviazanie skutočne rozhoduje

Naviazanie priradí socketu lokálnu adresu. Jadro potom vykoná to isté vyhľadanie trasy, aké by vykonalo inak, ak pravidlo politiky nezmení, ktorú tabuľku toto vyhľadanie číta.

Preto môže paket odísť so zdrojovou adresou VPN na fyzickom rozhraní. Na druhej strane prichádza z privátneho rozsahu, ktorý sieť na tejto ceste nikdy nečakala, spätná premávka nemá trasu späť a spojenie zamrzne alebo sa resetuje.

Referenčná príručka socketov IP v Linuxe dokumentuje sémantiku naviazania. Polovica o smerovaní žije v ip-rule a ip-route a to sú oddelené manuálové stránky z nejakého dôvodu.

Overte, že adresa patrí do tohto menného priestoru

Adresa, na ktorú sa dá naviazať, musí existovať na rozhraní vnútri sieťového menného priestoru, v ktorom aplikácia beží. Adresa partnera, adresa brány alebo adresa, ktorá existuje iba v inom mennom priestore, sa naviazať nedá a volanie zlyhá s EADDRNOTAVAIL.

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

Spustite tieto tri v rovnakom kontexte ako aplikáciu: rovnaký menný priestor a rovnaký používateľ, ak ho získate. Stará schéma net30 nie je dôkazom o tom, ktorú adresu vaša súčasná topológia pridelila klientovi. Čítajte rozhranie, ktoré je skutočne aktívne.

Prečítajte vyhľadanie pre tento zdroj a cieľ

Jeden príkaz odpovedá na otázku, ktorú naviazanie nezodpovedalo:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Prvý riadok vypíše trasu, ktorou by paket z tohto zdroja do tohto cieľa prešiel, vrátane odchádzajúceho rozhrania a preferovaného zdroja. Ak uvedie fyzické rozhranie, naviazanie a trasa si odporujú a paket odíde so zdrojom, na ktorý sa cesta nevie vrátiť.

Potom ip rule show povie, či by nejaké pravidlo zvolilo inú tabuľku. Priority sú tu dôležité, pretože vyhráva prvé zodpovedajúce pravidlo a pravidlo chytajúce všetko nad vaším urobí vaše pravidlo neviditeľným.

Inštalujte pravidlo politiky len vtedy, ak je to zámer

Smerovanie podľa zdroja je zámerný návrh, nie oprava pre jednu aplikáciu. Ak správca politiky chce, aby premávka z podsiete tunela používala tunel, pravidlo patrí do jeho konfigurácie, nie do jednorazového príkazu na vašom notebooku.

Funkčná podoba je vyhradená tabuľka s predvolenou trasou cez tunel plus pravidlo, ktoré posiela zdrojový rozsah VPN do tejto tabuľky. Pridajte výnimky, ktoré návrh potrebuje, pretože tabuľka obsahujúca iba predvolenú trasu tunela zachytí ciele, ktoré majú zostať lokálne alebo dostupné cez fyzickú 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

Vráťte späť pomocou ip rule del a ip route flush table 100. Všetko takto pridané zmizne po reštarte, ak to nezapíše správca, čo je zároveň bezpečnostná vlastnosť aj dôvod nedržať jedinú kópiu v histórii svojho shellu.

Overte tromi pozorovaniami

Zaznamenajte zdroj, ktorý aplikácia požadovala, trasu, ktorú vyhľadanie zvolilo, a zdroj, ktorý server skutočne videl.

Tieto tri sa môžu rozísť a každý rozpor ukazuje inam. Zachytenie na rozhraní tunela dokazuje, že paket odišiel so správnym zdrojom. Zachytenie na fyzickom rozhraní dokazuje, že odišiel nesprávnou cestou. Iba pohľad zo strany servera dokazuje cestu od konca do konca.

Ak aplikácia ponúka voľbu naviazania na zariadenie alebo režim smerovania pre jednotlivé aplikácie, berte to ako iný mechanizmus s inými obmedzeniami. Podobne vyzerajúce nastavenia nevedú všetky k rovnakému rozhodnutiu jadra.