Adakah Cache Laluan VPN Menyembunyikan Perubahan Anda? Semak Tiga Perkara

Mengosongkan cache laluan ialah naluri pertama apabila perubahan tidak berkesan, dan pada Linux moden ia usaha sia-sia: cache laluan IPv4 global telah dibuang bertahun-tahun lalu, jadi ip route show cache tidak mencetak apa-apa dan tiada apa untuk dibersihkan. Keadaan yang memperdaya anda hidup satu lapisan lebih tinggi: dalam socket, pemetaan NAT, penyelesai atau pengurus rangkaian yang menggunakan semula profil lama. Tiga soalan memisahkan kes itu: adakah laluan salah datang daripada aliran baharu atau sambungan lama, adakah platform anda menyimpan cache laluan sama sekali, dan adakah keadaan itu dalam penghalaan atau di atasnya. Jawab semuanya sebelum anda menetap semula antara muka.

Semakan satu: adakah laluan lama datang daripada aliran baharu?

Sambungan yang terjalin mengekalkan laluan yang digunakan semasa ia dicipta. Itulah sebabnya sesi SSH melalui terowong bertahan daripada perubahan jadual penghalaan sementara sesi baharu terus mengambil laluan baharu, dan itulah sebabnya «perubahan tidak melakukan apa-apa» selalunya bermaksud «socket lama masih memegangnya». Uji dengan proses baharu, bukan dengan tetingkap yang sudah dibuka.

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

Perintah terakhir mencetak alamat yang sebenarnya dicapai oleh sambungan baharu, dan itulah cara paling murah untuk melihat laluan sebenar tanpa mempercayai tetingkap status. Bandingkannya dengan alamat sumber yang sepatutnya digunakan oleh namespace atau antara muka.

Jika aliran baharu mengambil laluan yang betul dan yang lama tidak pulih, berhenti melihat penghalaan. Laluan itu betul; sesi itu lama.

Semakan dua: adakah platform anda menyimpan cache laluan?

Pada Linux jawapannya tidak, dalam erti kata yang dimaksudkan oleh kebanyakan panduan. Tiada cache destinasi global untuk dibuang, dan entri setiap socket yang memegang laluan terpilih dilepaskan bersama socket. Bahagian cache dalam manual ip-route menerangkan tingkah laku sejarah, bukan sesuatu yang boleh anda kosongkan pada kernel semasa.

Platform lain berbeza, dan di sinilah penyalinan nasihat menjadi salah. Windows menyimpan cache destinasi yang boleh anda bersihkan dengan netsh interface ip delete destinationcache. BSD dan macOS memaparkan carian setiap destinasi melalui route -n get, dan cache mereka luput mengikut jadual sendiri. Perintah yang berfungsi pada salah satunya tidak melakukan apa-apa pada Linux, sebab itulah pembaikan yang sama kelihatan gagal kepada separuh orang yang mencubanya.

Jadual NAT atau conntrack bukan cache laluan, walaupun ia menghasilkan gejala yang sama. Aliran yang diterjemah sebelum perubahan anda mengekalkan terjemahannya, dan conntrack -L akan menunjukkannya lama selepas dasar penghalaan bergerak ke hadapan. Itu keadaan lapuk, tetapi membersihkan laluan tidak akan menyentuhnya.

Semakan tiga: adakah keadaan itu dalam penghalaan, atau di atasnya?

Baca carian semasa sebelum membaca apa-apa lagi: ip route get untuk destinasi, kemudian perintah yang sama dengan from dan alamat sumber, kemudian ip rule show. Jika ketiga-tiganya sepadan dengan niat anda, penghalaan bukan lapisan untuk dibaiki, dan pemerhatian lapuk datang dari tempat lain.

Tiga suspek biasa duduk di atas penghalaan. Pengurus rangkaian boleh memasang semula laluan daripada profil tersimpan beberapa saat selepas anda memadamnya, jadi perubahan anda kelihatan kembali; semak nmcli connection show --active dan keadaan unit sebelum menyunting jadual lagi. Cache penyelesai mengembalikan alamat lama, yang kelihatan seperti kegagalan penghalaan sehingga anda menanyakan nama yang sama dengan alat yang memintas cache. Kolam sambungan aplikasi menyimpan socket yang berfungsi ke destinasi lama dan tidak pernah meminta keputusan baharu daripada kernel.

Apa yang boleh anda simpulkan daripada tiga jawapan

Gabungkan jawapannya dan pembaikan biasanya menyatakan dirinya sendiri. Aliran baharu yang mengambil laluan salah pada platform tanpa cache laluan bermakna dasarnya memang salah, jadi baca peraturan dan jadual yang dipasang oleh terowong. Aliran baharu yang mengambil laluan betul sementara sesi lama tersekat bermakna masalahnya ialah aplikasi atau socket. Laluan betul dengan pemerhatian rosak dalam kedua-dua kes bermakna keadaan itu di atas penghalaan.

Tentang penyegaran generik. Memulakan semula tindanan rangkaian atau memadam setiap laluan pada mesin yang laluan lalainya ialah terowong boleh memutuskan sambungan yang anda gunakan untuk membaikinya, dan ia memusnahkan bukti yang akan memberitahu anda lapisan mana yang gagal.

Jika anda benar-benar perlu membersihkan sesuatu, bersihkan perkara terkecil yang sepadan dengan diagnosis: socket satu proses, satu entri conntrack, cache penyelesai. Kemudian ulangi ujian aliran baharu yang sama dan catat apa yang berubah.

Asingkan tiga keadaan dalam nota anda

Konfigurasi tersimpan, carian semasa dan aliran yang diperhatikan ialah tiga fakta berbeza, dan meleburnya menjadi «cache» itulah yang menyukarkan kerosakan dihasilkan semula. Catat profil atau unit yang memiliki laluan, output ip route get, serta sumber dan destinasi sambungan sebenar.

Catat platform dan versi klien di sisinya, kerana pembaikan yang membersihkan cache destinasi Windows bukan pembaikan yang terpakai pada hos Linux, dan prosedur yang disalin antara keduanya mengajar pelajaran yang salah. Apabila anda menyerahkan masalah itu kepada orang lain, tiga baris itu membolehkan mereka menghasilkan semula keadaan gagal dan bukannya meneka.