Apakah Cache Rute VPN Menyembunyikan Perubahan Anda? Periksa Tiga Hal

Mengosongkan cache rute adalah naluri pertama saat perubahan tidak berlaku, dan di Linux modern itu usaha sia-sia: cache rute IPv4 global dihapus bertahun-tahun lalu, jadi ip route show cache tidak mencetak apa pun dan tidak ada yang perlu dibersihkan. Keadaan yang menipu Anda hidup satu lapis di atasnya: di socket, pemetaan NAT, resolver, atau manajer jaringan yang menerapkan ulang profil lama. Tiga pertanyaan memisahkan kasus itu: apakah jalur salah datang dari aliran baru atau koneksi lama, apakah platform Anda menyimpan rute di cache sama sekali, dan apakah keadaannya di perutean atau di atasnya. Jawab semuanya sebelum Anda mereset antarmuka.

Pemeriksaan satu: apakah jalur lama datang dari aliran baru?

Koneksi yang sudah terbentuk mempertahankan rute saat ia dibuat. Itulah sebabnya sesi SSH lewat tunnel bertahan dari perubahan tabel perutean sementara sesi baru langsung mengambil jalur baru, dan itulah sebabnya «perubahan tidak melakukan apa pun» sering berarti «socket lama masih memegangnya». Uji dengan proses baru, bukan dengan jendela yang sudah terbuka.

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 benar-benar dicapai koneksi baru, dan itu cara termurah melihat jalur nyata tanpa mempercayai jendela status. Bandingkan dengan alamat sumber yang seharusnya dipakai namespace atau antarmuka.

Jika aliran baru mengambil jalur yang benar dan yang lama tidak pulih, berhenti melihat perutean. Rutenya benar; sesinya lama.

Pemeriksaan dua: apakah platform Anda menyimpan cache rute?

Di Linux jawabannya tidak, dalam arti yang dimaksud sebagian besar panduan. Tidak ada cache tujuan global untuk dibuang, dan entri per socket yang menyimpan rute terpilih dilepas bersama socket. Bagian cache di manual ip-route menjelaskan perilaku historis, bukan sesuatu yang bisa Anda kosongkan di kernel saat ini.

Platform lain berbeda, dan di sinilah menyalin saran menjadi salah. Windows menyimpan cache tujuan yang bisa Anda bersihkan dengan netsh interface ip delete destinationcache. BSD dan macOS menampilkan pencarian per tujuan melalui route -n get, dan cache mereka kedaluwarsa menurut jadwalnya sendiri. Perintah yang bekerja di salah satunya tidak melakukan apa pun di Linux, karena itu perbaikan yang sama tampak gagal bagi separuh orang yang mencobanya.

Tabel NAT atau conntrack bukan cache rute, meskipun menghasilkan gejala yang sama. Aliran yang diterjemahkan sebelum perubahan Anda mempertahankan terjemahannya, dan conntrack -L akan menunjukkannya lama setelah kebijakan perutean bergerak maju. Itu keadaan basi, tetapi membersihkan rute tidak akan menyentuhnya.

Pemeriksaan tiga: apakah keadaannya di perutean, atau di atasnya?

Baca pencarian saat ini sebelum membaca apa pun: ip route get untuk tujuan, lalu perintah yang sama dengan from dan alamat sumber, lalu ip rule show. Jika ketiganya cocok dengan yang Anda maksud, perutean bukan lapisan yang harus diperbaiki, dan pengamatan basi datang dari tempat lain.

Tiga tersangka umum duduk di atas perutean. Manajer jaringan dapat memasang ulang rute dari profil tersimpan beberapa detik setelah Anda menghapusnya, sehingga perubahan Anda tampak kembali; periksa nmcli connection show --active dan status unit sebelum menyunting tabel lagi. Cache resolver mengembalikan alamat lama, yang terlihat seperti kegagalan perutean sampai Anda menanyakan nama yang sama dengan alat yang menembus cache. Kumpulan koneksi aplikasi menyimpan socket yang berfungsi ke tujuan lama dan tidak pernah meminta keputusan baru kepada kernel.

Apa yang dapat Anda simpulkan dari ketiga jawaban

Satukan jawabannya dan perbaikannya biasanya menyatakan dirinya sendiri. Aliran baru yang mengambil jalur salah di platform tanpa cache rute berarti kebijakannya memang salah, jadi baca aturan dan tabel yang dipasang tunnel. Aliran baru yang mengambil jalur benar sementara sesi lama macet berarti masalahnya ada di aplikasi atau socket. Rute yang benar dengan pengamatan rusak pada kedua kasus berarti keadaannya di atas perutean.

Tolak penyegaran generik. Memulai ulang tumpukan jaringan atau menghapus setiap rute di mesin yang rute bawaannya adalah tunnel dapat memutus justru koneksi yang Anda pakai untuk memperbaikinya, dan itu menghancurkan bukti yang seharusnya menunjukkan lapisan mana yang gagal.

Jika Anda memang harus membersihkan sesuatu, bersihkan hal terkecil yang cocok dengan diagnosis: socket satu proses, satu entri conntrack, cache resolver. Lalu ulangi uji aliran baru yang sama dan catat apa yang berubah.

Pisahkan ketiga keadaan dalam catatan Anda

Konfigurasi tersimpan, pencarian saat ini, dan aliran teramati adalah tiga fakta berbeda, dan meleburnya menjadi «cache» itulah yang membuat kesalahan sulit direproduksi. Catat profil atau unit yang memiliki rute, keluaran ip route get, serta sumber dan tujuan koneksi sebenarnya.

Catat platform dan versi klien di sampingnya, karena perbaikan yang membersihkan cache tujuan Windows bukan perbaikan yang berlaku untuk host Linux, dan prosedur yang disalin di antara keduanya mengajarkan pelajaran yang salah. Saat Anda menyerahkan masalah itu kepada orang lain, ketiga baris itu memungkinkan mereka mereproduksi keadaan gagal alih-alih menebak.