VPN ünvanına bağlanan tətbiq yenə də səhv marşrutdan istifadə edir

Bir tətbiq VPN ünvanına bağlanır, amma bağlantı yenə də adi standart marşrutla çıxır. Bağlanmada heç nə uğursuz olmadı; o, bağlanmanın etdiyi işi tam olaraq etdi. Soketi yerli ünvana bağlamaq nüvənin başlığa qoyacağı mənbə ünvanını seçir. Bu, marşrut quraşdırmır və həmin mənbəni daşıyan paketləri müəyyən tunelə göndərən siyasət qaydası yaratmır.

Bu məlumat kitabının qalan hissəsi istifadə etdiyim yoxlama sırasıdır və hər müşahidəni verən əmrlə birlikdə.

Bağlanma əslində nəyi həll edir

Bağlanma soketə yerli ünvan təyin edir. Sonra nüvə əvvəl olduğu kimi eyni marşrut axtarışını aparır, məgər siyasət qaydası bu axtarışın oxuduğu cədvəli dəyişmirsə.

Buna görə paket fiziki interfeysdə VPN mənbə ünvanı ilə çıxa bilər. Digər tərəfdə o, şəbəkənin həmin yolda heç vaxt gözləmədiyi özəl aralıqdan gəlir, geri trafikin geri qayıtma marşrutu olmur və bağlantı dayanır və ya sıfırlanır.

Linux IP soket sənədi bağlanma semantikasını sənədləşdirir. Marşrutlaşdırma yarısı ip-rule və ip-route-da yaşayır və bunlar bir səbəbdən ayrı təlimat səhifələridir.

Ünvanın bu ad məkanına aid olduğunu təsdiqləyin

Bağlana bilən ünvan tətbiqin işlədiyi şəbəkə ad məkanındakı interfeysdə mövcud olmalıdır. Qarşı tərəfin ünvanı, şlüz ünvanı və ya yalnız başqa ad məkanında mövcud olan ünvan bağlana bilməz və çağırış EADDRNOTAVAIL ilə uğursuz olur.

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

Bu üçünü tətbiqlə eyni kontekstdə işlədin: eyni ad məkanı və mümkünsə eyni istifadəçi. Köhnə net30 diaqramı cari topologiyanızın müştəriyə hansı ünvanı təyin etdiyinə dair sübut deyil. Həqiqətən aktiv olan interfeysi oxuyun.

Həmin mənbə və təyinat üçün axtarışı oxuyun

Bir əmr bağlanmanın cavablandırmadığı suala cavab verir:

ip route get 203.0.113.10 from 10.8.0.2
ip rule show

Birinci sətir həmin mənbədən həmin təyinata gedən paketin tutacağı marşrutu, çıxış interfeysi və üstünlük verilən mənbə daxil olmaqla çap edir. Əgər fiziki interfeysi göstərirsə, bağlanma ilə marşrut ziddiyyət təşkil edir və paket yolun geri qayıda bilmədiyi mənbə ilə çıxacaq.

Sonra ip rule show hər hansı qaydanın başqa cədvəl seçib-seçmədiyini bildirir. Prioritetlər burada önəmlidir, çünki ilk uyğun gələn qayda qalib gəlir və qaydanızın üstündəki hər şeyi tutan qayda onu görünməz edir.

Siyasət qaydasını yalnız dizayn belədirsə quraşdırın

Mənbəyə əsaslanan marşrutlaşdırma qəsdən edilən dizayndır, bir tətbiq üçün təmir deyil. Siyasət sahibi tunel alt şəbəkəsindən gələn trafikin tuneldən istifadə etməsini istəyirsə, qayda noutbukunuzdakı birdəfəlik əmrə deyil, həmin sahibin konfiqurasiyasına aid olur.

İşlək forma tuneldən keçən standart marşrutu olan ayrılmış cədvəl və VPN mənbə aralığını həmin cədvələ göndərən qaydadır. Dizaynın ehtiyac duyduğu istisnaları əlavə edin, çünki yalnız tunel standartını saxlayan cədvəl yerli qalması və ya fiziki yolla əldə edilməsi nəzərdə tutulan təyinatları tutacaq.

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

ip rule del və ip route flush table 100 ilə geri qaytarın. Bu şəkildə əlavə edilən hər şey yenidən başlatmada itir, məgər bir menecer onu yazmırsa; bu həm təhlükəsizlik xassəsidir, həm də yeganə nüsxəni shell tarixçənizdə saxlamamaq üçün səbəbdir.

Üç müşahidə ilə yoxlayın

Tətbiqin istədiyi mənbəni, axtarışın seçdiyi marşrutu və serverin həqiqətən gördüyü mənbəni qeyd edin.

Bu üçü fərqli ola bilər və hər fərq başqa yerə işarə edir. Tunel interfeysində tutma paketin düzgün mənbə ilə çıxdığını sübut edir. Fiziki interfeysdə tutma onun səhv yolla çıxdığını sübut edir. Server tərəfinin görünüşü yolu başdan sona sübut edən yeganə görünüşdür.

Tətbiq cihaza bağlanma seçimi və ya hər tətbiq üçün marşrutlaşdırma rejimi təklif edirsə, ona fərqli məhdudiyyətləri olan fərqli mexanizm kimi baxın. Oxşar görünən parametrlər hamısı eyni nüvə qərarına gətirmir.