A VPN-címhez kötött alkalmazás mégis a rossz útvonalat használja
A VPN-címhez kötött socket a szokásos alapértelmezett útvonalat követi. Ellenőrizze a cím tulajdonjogát és a forrás tudatos keresést, mielőtt házirend-szabályokat ad hozzá.
Egy alkalmazás a VPN címéhez kötődik, és a kapcsolat mégis a szokásos alapértelmezett útvonalon megy ki. A kötésben semmi nem hibázott; pontosan azt tette, amit a kötés tesz. Egy socket helyi címhez kötése kiválasztja azt a forráscímet, amelyet a kernel a fejlécbe tesz. Nem telepít útvonalat, és nem hoz létre olyan házirend-szabályt, amely az ezt a forrást hordozó csomagokat egy adott alagútba küldené.
A kézikönyv többi része az általam használt ellenőrzési sorrend, azzal a paranccsal együtt, amely az egyes megfigyeléseket adja.
Mit dönt el valójában a kötés
A kötés helyi címet rendel a sockethez. Ezután a kernel ugyanazt az útvonalkeresést futtatja, amelyet egyébként futtatott volna, kivéve ha egy házirend-szabály megváltoztatja, melyik táblát olvassa ez a keresés.
Ezért léphet ki csomag VPN forráscímmel fizikai interfészen. A túloldalon olyan privát tartományból érkezik, amelyet a hálózat soha nem várt ezen az úton, a visszirányú forgalomnak nincs visszaútja, és a kapcsolat lefagy vagy visszaáll.
A Linux IP socket referencia dokumentálja a kötés szemantikáját. Az útválasztási rész az ip-rule-ban és az ip-route-ban él, és ezek okkal külön kézikönyvek.
Erősítse meg, hogy a cím ehhez a névtérhez tartozik
Egy cím, amelyhez kötni tud, csak annak a hálózati névtérnek az interfészén létezhet, amelyben az alkalmazás fut. A partner címe, az átjáró címe vagy egy csak másik névtérben létező cím nem köthető, és a hívás EADDRNOTAVAIL hibával meghiúsul.
ip -br addr show
ip netns identify <pid>
ss -tanp | grep <port>Futtassa ezt a hármat ugyanabban a kontextusban, mint az alkalmazást: ugyanaz a névtér, és ha lehet, ugyanaz a felhasználó. Egy régi net30 diagram nem bizonyíték arra, melyik címet osztotta ki a jelenlegi topológiája az ügyfélnek. Azt az interfészt olvassa, amely valóban aktív.
Olvassa el a keresést ahhoz a forráshoz és célhoz
Egyetlen parancs válaszol arra a kérdésre, amelyre a kötés nem:
ip route get 203.0.113.10 from 10.8.0.2
ip rule showAz első sor azt az útvonalat írja ki, amelyet egy csomag ettől a forrástól ehhez a célhoz venne, beleértve a kimenő interfészt és az előnyben részesített forrást. Ha a fizikai interfészt nevezi meg, a kötés és az útvonal ellentmond, és a csomag olyan forrással lép ki, ahová az út nem tud visszatérni.
Ezután az ip rule show megmondja, hogy valamelyik szabály másik táblát választott volna-e. Itt számítanak a prioritások, mert az első illeszkedő szabály nyer, és a saját szabálya felett mindent elkapó szabály láthatatlanná teszi a sajátját.
Csak akkor telepítsen házirend-szabályt, ha ez a terv
A forrásalapú útválasztás szándékos terv, nem egy alkalmazás javítása. Ha a házirend tulajdonosa azt akarja, hogy az alagút alhálózatának forgalma az alagutat használja, a szabály az ő konfigurációjába tartozik, nem egy egyszeri parancsba a laptopján.
Működő forma egy dedikált tábla alapértelmezett útvonallal az alagúton keresztül, valamint egy szabály, amely a VPN forrástartományt ebbe a táblába küldi. Adja hozzá a tervhez szükséges kivételeket, mert a csak alagút-alapértelmezést tartalmazó tábla elkapja azokat a célokat, amelyeknek helyben kell maradniuk vagy a fizikai úton elérhetőnek lenniük.
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.2Vonja vissza az ip rule del és az ip route flush table 100 paranccsal. Minden így hozzáadott dolog eltűnik újraindításkor, hacsak egy kezelő nem írja le, ami egyszerre biztonsági tulajdonság és ok arra, hogy ne az egyetlen példányt tartsa a shell-előzményeiben.
Ellenőrizze három megfigyeléssel
Jegyezze fel a forrást, amelyet az alkalmazás kért, az útvonalat, amelyet a keresés választott, és a forrást, amelyet a kiszolgáló valóban látott.
Ez a három eltérhet, és minden eltérés másfelé mutat. Az alagút interfészén készült rögzítés bizonyítja, hogy a csomag a helyes forrással lépett ki. A fizikai interfészen készült rögzítés bizonyítja, hogy rossz úton lépett ki. Csak a kiszolgáló oldali nézet bizonyítja az utat végponttól végpontig.
Ha az alkalmazás eszközhöz kötési lehetőséget vagy alkalmazásonkénti útválasztási módot kínál, kezelje más mechanizmusként, más korlátokkal. A hasonlónak látszó beállítások nem mind ugyanahhoz a kernel-döntéshez vezetnek.