Linux-da VPN tərəfindən göndərilən marşrutları statik marşrutlardan necə ayırd etmək olar

Tunel qalxanda noutbukda bir prefiks görünür, ona görə VPN onu quraşdırmış kimi hiss olunur. Ola bilər, amma eyni nəticə qoşulma zamanı işləyən klient skriptindən, alt şəbəkəni sadalayan bağlantı profilindən və ya əvvəldən mövcud olub yalnız interfeys yarandıqdan sonra işləməyə başlayan statik marşrutdan da gələ bilər. Səhv sahibi seçmək marşrutun hər təmizləmədən sonra qayıtması deməkdir və növbəti şəxs eyni düzəlişi təkrarlayır. Aşağıdakı ardıcıllıq heç nəyi dəyişməzdən əvvəl bu üçünü ayırır.

Addım 1: prefiksləri quraşdıran mexanizmi adlandırın

Müxtəlif protokollar əlçatanlığı müxtəlif yollarla təmin edir və hamısını elan adlandırmaq fərqi gizlədir. OpenVPN serveri nəzarət kanalı üzərindən marşrut direktivi göndərir və pull filtri mane olmasa, klient onu quraşdırır. WireGuard konfiqurasiyası icazə verilən prefiksləri yerli olaraq sadalayır; klient onlardan həm kriptoaçar marşrutlaşdırması, həm də əlavə etdiyi marşrutlar üçün istifadə edir. IPsec tuneli qarşı tərəflə trafik seçiciləri üzərində razılaşır və nüvə həmin seçicilərdən marşrutlar quraşdırır.

Hər hansı cədvəli oxumazdan əvvəl tunelinizin bunlardan hansını istifadə etdiyini müəyyənləşdirin. Qoşulma anında göndərilən marşrut marşrutlaşdırma protokolunun elanı deyil və prefiksin uzaq tərəfin arxasında əlçatan olmasına zəmanət vermir. Mexanizmi prefiksin yanında qeyd edin, çünki düzəlişin hara aid olduğunu o müəyyən edir.

Addım 2: cədvəli qoşulma boyunca müqayisə edin

Əsas cədvəli tunel söndürülmüş halda saxlayın, onu qaldırın, yenidən saxlayın və iki çıxarışı müqayisə edin. Görünən hər şey bağlantının həyat dövrünə aiddir, qalan hər şey isə yerli konfiqurasiyaya aiddir.

Onu ip route show table main > /tmp/route-down.txt ilə çıxarın, qoşulun və yenidən çıxarın. Sayt IPv6 istifadə edirsə, ip -6 route üçün də eyni şeyi edin, çünki orada çatışmayan prefiks marşrutlaşdırma ilə əlaqəsiz görünən nasazlıqlar yaradır.

Addım 3: yalnız varlığı deyil, metrikanı oxuyun

Eyni prefiks üçün iki giriş birlikdə mövcud ola bilər və nüvə aşağı metrikanı seçir. Metrikası 50 olan statik marşrut, hər ikisi görünsə də, 100 metrikalı göndərilən marşrutu məğlub etməyə davam edəcək; buna görə «marşrut oradadır» və «trafik ondan istifadə edir» fərqli ifadələrdir.

ip route get 10.20.5.7 ilə birbaşa nüvədən soruşun və bildirdiyi interfeysi oxuyun. Trafik fiziki adapterdən çıxarkən cədvəldə tunel marşrutu durursa, bunu metrika və ya prefiks uzunluğu izah edir, VPN klienti yox. Tunelin arxasında olduğunu bildiyiniz bir host və olmadığını bildiyiniz bir host üçün axtarışı təkrarlayın; fərq bölünmənin nəzərdə tutulduğu kimi işləyib-işləmədiyini göstərir.

Addım 4: tuneldən daha uzun yaşayan girişləri tapın

Statik marşrutlar dizayn olaraq əlaqənin kəsilməsindən sağ çıxır və köhnəlmiş girişlər buradan gəlir. Artıq mövcud olmayan interfeysə işarə edən davamlı marşrut alt şəbəkəni səssizcə udmağa bilər, yenidən istifadə olunan interfeys adına işarə edən biri isə yenidən başlatmadan sonra şəxsi trafiki səhv qapıdan çıxara bilər.

Davamlı tərəfi paylanmanızın istifadə etdiyi yerdə yoxlayın: systemd-networkd vahidi, NetworkManager profili və ya klientin up qovluğundakı skript ola bilər. Cari cədvəli ip route del ilə düzəltmək yalnız növbəti qoşulmaya qədər davam edir. Bu silməni təmir deyil, fərziyyənin sınağı kimi qəbul edin.

Uzaq tərəf səhv əhatə təqdim edirsə, hər şeyi filtrləmək əvəzinə bunu operatora bildirin. Bütün göndərilən parametrləri atmaq profilin asılı olduğu DNS və bölünmüş tunel siyasətini də atır.

Addım 5: klienti günahlandırmazdan əvvəl geri yolu təsdiqləyin

Saytlararası və ya tunelin arxasındakı alt şəbəkə üçün uzaq tərəfə klient ünvanınıza geri marşrut və şlüzda yönləndirmənin aktiv olması lazımdır. Birtərəfli yol müştəri marşrutlaşdırma xətasına tam bənzəyir, sadəcə əl sıxma və gedən paket birlikdə uğur qazanır.

Əks yol filtrləmə Linux şlüzlərində ikinci tələ yaradır. Marşrutun gözlədiyindən fərqli interfeysə gələn cavab sərt rejim tərəfindən atılır və iki provayderdən keçən asimmetrik yollar bunu etibarlı şəkildə tetikləyir. Filtrləmənin səbəb olub-olmadığını şlüzdakı, klientdəki deyil, atma sayğacları deyir.

Addım 6: pingi deyil, resursu sınayın

Seçilmiş marşrut düzgün olduqdan sonra faktiki resursu açın və geri trafiki təsdiqləyin. Ping cavabı yolu bir istiqamətdə sübut edir və xidmət haqqında heç nə demir; keşlənmiş bağlantıda cavab verən xidmət isə daha azını sübut edir.

Sonra yenidən qoşulmadan sonra bütün yoxlamanı təkrarlayın. Ardıcıllığın dəyəri ondadır ki, növbəti qoşulmanın nə edəcəyini proqnozlaşdırır; buna görə həm müqayisə, həm də metrika bilettə aiddir.