VPN marşrut keşi dəyişikliyinizi gizlədir? Üç şeyi yoxlayın

Marşrut keşini təmizləmək dəyişiklik qüvvəyə minmədikdə ilk instinktdir və müasir Linux-da bu boşa səydir: qlobal IPv4 marşrut keşi illər əvvəl silinib, ona görə ip route show cache heç nə çap etmir və təmizlənəcək bir şey yoxdur. Sizi aldadan vəziyyət bir qat yuxarıda yaşayır: soketdə, NAT xəritəsində, həlledicidə və ya köhnə profili yenidən tətbiq edən şəbəkə menecerində. Üç sual bu halları ayırır: yanlış yol yeni axından, yoxsa köhnə bağlantıdan gəlir, platformanız ümumiyyətlə marşrutları keşləyir, və vəziyyət marşrutlaşdırmadadır, yoxsa onun üstündə. İnterfeysi sıfırlamazdan əvvəl onlara cavab verin.

Yoxlama bir: köhnə yol yeni axından gəlirmi?

Qurulmuş bağlantı yaradıldığı marşrutu saxlayır. Buna görə tunel üzərindən SSH sessiyası marşrut cədvəlinin dəyişməsini yaşayır, yeni sessiya isə dərhal yeni yolu tutur, və buna görə «dəyişiklik heç nə etmədi» çox vaxt «köhnə soket hələ də onu saxlayır» deməkdir. Artıq açıq olan pəncərə ilə deyil, yeni proseslə sınayın.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

Son əmr yeni bağlantının faktiki çatdığı ünvanı çap edir; bu, status pəncərəsinə güvənmədən real yolu görməyin ən ucuz yoludur. Onu ad məkanının və ya interfeysin istifadə etməli olduğu mənbə ünvanı ilə müqayisə edin.

Təzə axın düzgün yolu tutursa və köhnəsi bərpa olunmursa, marşrutlaşdırmaya baxmağı dayandırın. Marşrut düzgün idi; sessiya köhnə idi.

Yoxlama iki: platformanız ümumiyyətlə marşrut keşi saxlayır?

Linux-da cavab yoxdur, əksər təlimatların nəzərdə tutduğu mənada. Atılacaq qlobal təyinat keşi yoxdur və seçilmiş marşrutu saxlayan soket-üzrə qeyd soketlə birlikdə buraxılır. ip-route təlimatının keş bölməsi tarixi davranışı təsvir edir, cari nüvədə təmizləyə biləcəyiniz bir şeyi deyil.

Digər platformalar fərqlənir və məsləhətin kopyalanması məhz burada səhv gedir. Windows netsh interface ip delete destinationcache ilə təmizləyə biləcəyiniz təyinat keşi saxlayır. BSD və macOS hər təyinat üzrə axtarışları route -n get vasitəsilə təqdim edir və onların keşləri öz cədvəli üzrə bitir. Bunlardan birində işləyən əmr Linux-da heç nə etmir, buna görə eyni düzəliş onu sınayanların yarısı üçün uğursuz görünür.

NAT və ya conntrack cədvəli marşrut keşi deyil, baxmayaraq ki eyni simptomu yaradır. Dəyişikliyinizdən əvvəl tərcümə edilmiş axın tərcüməsini saxlayır və conntrack -L onu marşrutlaşdırma siyasəti çoxdan dəyişdikdən sonra göstərəcək. Bu köhnəlmiş vəziyyətdir, lakin marşrutların təmizlənməsi ona toxunmayacaq.

Yoxlama üç: vəziyyət marşrutlaşdırmadadır, yoxsa onun üstündə?

Başqa heç nə oxumazdan əvvəl cari axtarışı oxuyun: təyinat üçün ip route get, sonra from və mənbə ünvanı ilə həmin əmr, sonra ip rule show. Bu üçü nəzərdə tutduğunuzla uyğun gəlirsə, marşrutlaşdırma düzəldiləcək qat deyil və köhnəlmiş müşahidə başqa yerdən gəlib.

Üç adi şübhəli marşrutlaşdırmanın üstündə oturur. Şəbəkə meneceri marşrutu sildikdən saniyələr sonra onu yadda saxlanmış profildən yenidən quraşdıra bilər, ona görə dəyişikliyiniz geri qayıdır kimi görünür; cədvəli yenidən redaktə etməzdən əvvəl nmcli connection show --active və vahidin vəziyyətini yoxlayın. Həlledici keşi köhnə ünvan qaytarır; bu, eyni adı keşi sındıran alətlə sorğulayana qədər marşrutlaşdırma nasazlığı kimi görünür. Tətbiqin bağlantı hovuzu köhnə təyinatla işlək soketi saxlayır və nüvədən heç vaxt yeni qərar istəmir.

Üç cavab nə qənaət etməyə imkan verir

Cavabları bir araya gətirin və təmir adətən özünü bəyan edir. Marşrut keşi olmayan platformada təzə axının yanlış yolu tutması siyasətin həqiqətən yanlış olduğunu bildirir, ona görə qaydaları və tunelin quraşdırdığı cədvəli oxuyun. Təzə axın düzgün yolu tutarkən köhnə sessiyanın ilişməsi tətbiqin və ya soketin problem olduğunu bildirir. Hər iki halda düzgün marşrutlarla pozulmuş müşahidə vəziyyətin marşrutlaşdırmanın üstündə olduğunu bildirir.

Ümumi yeniləməyə müqavimət göstərin. Şəbəkə yığınını yenidən başlatmaq və ya defolt marşrutu tunel olan maşında bütün marşrutları silmək onu düzəltmək üçün istifadə etdiyiniz bağlantını kəsə bilər və hansı qatın uğursuz olduğunu deyəcək dəlilləri məhv edir.

Əgər həqiqətən nəyisə təmizləməli olsanız, diaqnoza uyğun ən kiçik şeyi təmizləyin: bir prosesin soketləri, bir conntrack qeydi, həlledici keşi. Sonra eyni təzə-axın sınağını təkrarlayın və nəyin dəyişdiyini yazın.

Qeydlərinizdə üç vəziyyəti ayrı saxlayın

Yadda saxlanmış konfiqurasiya, cari axtarış və müşahidə olunan axın üç fərqli faktdır və onları «keş»ə yığmaq nasazlığı təkrarlamağı çətinləşdirən şeydir. Marşruta sahib profili və ya vahidi, ip route get çıxışını və faktiki bağlantının mənbəyini və təyinatını yazın.

Platformanı və müştəri versiyasını onların yanında qeyd edin, çünki Windows təyinat keşini təmizləyən düzəliş Linux hostuna aid düzəliş deyil və ikisi arasında kopyalanan prosedur yanlış dərsi öyrədir. Problemi başqasına verəndə bu üç sətir onlara təxmin etmək əvəzinə nasaz vəziyyəti təkrarlamağa imkan verir.