Marşrut cədvəli və faktiki axtarış: VPN trafiki hara gedir

Marşrut cədvəlinin dumpı VPN nasazlıqlarının axtarışında ən az faydalı diaqnostikadır və ən çox yapışdırılanıdır. Qırx sətir prefiks sizə maşının nə edə biləcəyini deyir, uğursuz sorğu üçün nə etdiyini yox. Əslində istədiyiniz mexanizm axtarışdır: bu mənbə və bu təyinat verildikdə hansı qayda uyğun gəldi, hansı cədvələ baxıldı, hansı interfeys və növbəti hop çıxdı. Bir təyinat və bir mənbədən başlayın, sonra cədvəli bu sualla birlikdə oxuyun və eyni çıxış səs-küy əvəzinə sübuta çevrilir.

Cədvəl namizədlər toplusudur, qərar deyil

Hər giriş bir prefiksi və ona uyğun gələn trafiklə nə ediləcəyini təsvir edir: onu interfeysə göndərin, növbəti hopa ötürün və ya atın. Bu siyahıda heç nə niyyətə görə sıralanmayıb və insana ən spesifik görünən giriş həmişə nüvənin seçdiyi olmur, çünki seçim ən uzun prefiks uyğunluğuna, bərabər prefikslər arasında isə metrikiyaya əsaslanır.

Deməli, ilk addım siyahını oxumaq əvəzinə nüvədən soruşmaqdır. Axtarış əmri bir təyinat üçün cavab verir və mənbə arqumenti ilə yönləndirilən və ya bağlanan əlaqənin istifadə edəcəyi dəqiq cüt üçün cavab verir:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Yuxarıdakı hər ünvan sənədləşdirmə nümunəsidir. Məsələ cavabın formasıdır: interfeys, seçilmiş mənbə ünvanı, şlüz və girişin gəldiyi cədvəl. Əgər bu çıxış gözlədiyiniz interfeysə uyğun gəlmirsə, problemi bir əmrlə lokallaşdırmışsınız və tam cədvəli oxumağın heç bir miqdarı hansı namizədin qazandığını sizə deməzdi.

Axtarış əvvəl qaydalardan, sonra cədvəllərdən keçir

Linux-da qərar iki mərhələdən ibarətdir. Siyasət qaydaları prioritet sırası ilə qiymətləndirilir və uyğun gələn ilk qayda baxılacaq cədvəlin adını çəkir; sonra həmin cədvəl ən uzun prefiks uyğunluğunu edir. Qayda mənbə, təyinat, firewall mark, interfeys və ya birləşmə üzrə uyğunlaşa bilər, buna görə də əsas cədvəlin dumpı tam dəqiq və araşdırdığınız paket üçün tamamilə əhəmiyyətsiz ola bilər.

ip rule show
ip route show table all | head -40
ip route show table 100

Əgər qayda VPN hovuzunuzdan trafiki 100 cədvəlinə göndərirsə, əhəmiyyətli olan 100 cədvəlidir və əsas cədvəl yemdir. Bu, həm də marşrutlaşdırıcıda mənbəyə əsaslanan marşrutlaşdırmanın mexanizmidir: eyni təyinat paketin haradan gəldiyindən asılı olaraq iki fərqli cavaba malik ola bilər və yalnız mənbə arqumenti ilə axtarış hansının tətbiq olunduğunu üzə çıxarır.

IPv6-nın öz qaydaları və cədvəlləri var. Hər iki ailəni işlədən dizayn hər iki axtarışa ehtiyac duyur və işləyən IPv4 cavabı ikili stekli müştərinin üstün tuta biləcəyi v6 yolu haqqında heç nə demir.

VPN müştərisi nə quraşdırır

Müştərilər adətən defolt marşrutu əvəz etmir, çünki bu, tunelin öz xarici yolunu pozardı. Prefiks uzunluğuna görə qazanan daha spesifik bir şey quraşdırırlar: 0.0.0.0/1 və 128.0.0.0/1-i əhatə edən yarım-defolt cütü klassik hiylədir, çünki hər ikisi 0.0.0.0/0-dan uzun prefiksdir və birlikdə bütün məkanı əhatə edir. Digərləri xüsusi şəxsi prefikslərə əlavə olaraq siyasət qaydası quraşdırır, bəziləri isə yalnız seçilmiş trafikin tutulması üçün mark əlavə edir.

Buna görə də "VPN defolt marşrutumu dəyişmədi" uğursuzluğa dəlil deyil. Onun həqiqətən nə əlavə etdiyini və sözügedən təyinatın həmin prefikslərin içində olub-olmadığını yoxlayın:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

İki yarım-marşrutu dumpda asanlıqla qaçırmaq olar, çünki onlar defolta bənzəmir. Prefiksi daxil etməyi unudan split-tunnel konfiqurasiyası məhz axtardığınız simptomu yaradır: tuneldən istifadə etməli olan tətbiq əvəzində lokal olaraq həll edir və qoşulur. Quraşdırılmış prefiksləri istifadəçinin həqiqətən ehtiyac duyduğu təyinatla müqayisə edin, təsadüfən sınaqdan keçirdiyiniz ünvanlarla deyil. Fayl serverini əhatə edib həlledicisini əhatə etməyən split-tunnel siyahısı ümumi ünvana həll olunan, sonra isə autentifikasiyada uğursuz olan əlaqə yaradır; bu, parol problemi kimi görünür, əslində isə marşrut problemidir.

Xarici marşrut da sağ qalmalıdır

Tunel özü trafikdir. Kapsullaşdırılmış yükü daşıyan paketlər fiziki interfeys üzərindən peer ünvanına gedir və həmin yol tunelin içinə geri yönləndirilməməlidir. Yönləndiriləndə tunelin qurulub sonra trafiki keçirməyi dayandırdığı səciyyəvi nasazlıq yaranır, çünki tunelin nəqliyyatı artıq tunelin içindədir.

Peer ünvanını daxili təyinatı yoxladığınız kimi yoxlayın və onun tunelə deyil, fiziki interfeysə həll olunduğunu təsdiqləyin:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Rekursiv marşrut, peer-i tutan siyasət qaydası və ya tam tunel müştərisi ilə əvəz edilmiş defolt üç adi səbəbdir. Hər üçü xarici axtarışda görünür və heç biri fakt sonrası alınmış əsas cədvəl dumpında görünmür.

Marşrut çıxışı sizə nə deyə bilməz

Düzgün axtarış nüvənin paketi ağlabatan bir yerə göndərəcəyi deməkdir. Bu, firewallun ona icazə verdiyi, IPsec siyasətinin onu əhatə etdiyi, NAT qaydasının onu tərcümə etdiyi və ya uzaq tərəfin qaytarma marşrutu olduğu demək deyil. Bunların hər biri sonrakı mərhələdir və strongSwan yönləndirmə qeydləri paketin hər iki tərəfdə keçməli olduğu zənciri təsvir edir.

O, həmçinin tətbiq səviyyəsində bağlanmanı nəzərə almır. Proses interfeysə bağlana, mark qoya və ya öz həlledicisini istifadə edib sınaqdan keçirdiyinizdən fərqli həll olunan adla qoşula bilər. Axtarış düzgün olduqda və əlaqə hələ də uğursuz olduqda, növbəti sual hansı prosesin bunu etdiyi və həmin prosesin sizin gördüyünüz eyni cədvəli görüb-görmədiyidir.

Diaqnozu sıralı saxlayın: təyinatı və mənbəyi adlandırın, axtarışı işlədin, yalnız axtarışın adlandırdığı cədvəli və qaydanı oxuyun, sonra növbəti mərhələni sınayın. Bu ardıcıllıq marşrut araşdırmasını dəqiqələrlə saxlayır və başqasının izləyə biləcəyi qeyd qoyur; yapışdırılmış cədvəl bunu heç vaxt etmir.