Perutean rekursif: saat terowongan menangkap paketnya sendiri

Terowongan naik, log menunjukkan jabat tangan yang selesai, dan sedetik kemudian sesi yang sama mati dan menyambung ulang dalam lingkaran. Pola itu punya penyebab khusus: rute ke server kini mengarah ke dalam terowongan, sehingga paket yang membawa terowongan dikirim melalui terowongan. Tidak ada yang berubah pada autentikasi, karena itu memasukkan ulang kredensial tidak mengubah apa pun. Bandingkan jalur luar sebelum dan sesudah perubahan rute dan rekursinya menjadi terlihat.

Periksa jalur luar lebih dulu

Ada dua paket yang bermain, bukan satu. Paket dalam milik aplikasi dan seharusnya terenkripsi, sedangkan paket luar dialamatkan ke server dan harus mencapainya melalui jalur yang tidak bergantung pada terowongan.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Tanyakan kepada kernel rute ke alamat server setelah terowongan naik, lalu sekali lagi setelah rute bawaan berubah. Lompatan berikutnya yang mendarat di perangkat terowongan itulah rekursinya, dan itu terlihat tanpa penangkapan paket apa pun. Pengikatan antarmuka, tanda, atau ruang nama jaringan dapat membuat pencarian biasa tidak lengkap, jadi gunakan konteks yang dipakai klien itu sendiri. Ketika jawabannya tampak benar tetapi sesi tetap berputar, bacalah aturan kebijakan perutean, bukan hanya tabel utama.

Mengapa sesi bertahan sesaat

Jabat tangan selesai sebelum rute baru dipasang, jadi detik-detik pertama tampak sehat. Begitu klien menambahkan rute bawaan, paket luar berikutnya mengikutinya masuk ke antarmuka yang harus dilalui paket luar itu. Server tidak melihat apa pun, klien mengirim ulang, dan percobaan itu entah kehabisan waktu atau membunuh sesi dan mulai dari awal.

Urutan itu menjelaskan mengapa terowongan bisa bekerja di laptop dan gagal di perute, dan mengapa kegagalan sering dimulai saat lalu lintas mulai, bukan saat menyambung. Ini juga menjelaskan lingkarannya: setiap mulai ulang membangun kembali sesi sebelum rute membuatnya mustahil.

Temukan siapa pemilik pengecualian titik akhir

Klien yang didukung mengatur pengecualiannya sendiri: rute host ke server melalui gateway asli, atau tanda yang menjaga soket luar tetap di luar terowongan. Pertanyaannya adalah apakah ada hal lain yang menghapus atau menimpanya.

Pada IPsec berbasis rute, periksa pemilih kebijakan yang menentukan paket mana yang masuk ke terowongan dan pastikan alamat rekan dikecualikan darinya. Pada WireGuard, tanda tembok api antarmuka dan aturan kebijakannya menjaga paket transportasi di luar terowongan, sehingga rute bawaan yang ditambahkan secara manual dapat merusak tatanan itu. Profil VPN kedua atau skrip manajemen yang menulis ulang rute bawaan adalah pelaku yang lazim. Aturan pintas yang luas dan ditambahkan satu per satu adalah hasil biasanya, dan aturan itu mengubah bug perutean menjadi tabel yang tidak bisa dirawat siapa pun.

Periksa ulang setelah perubahan jaringan

Rute host melalui gateway Wi-Fi benar sampai mesin berpindah ke jaringan lain. Gejala yang sama lalu kembali tanpa perubahan konfigurasi sama sekali.

Catat alamat titik akhir, rute sebelum dan sesudah menyambung, dan antarmuka yang dipakai masing-masing. Ketiga fakta itu biasanya memisahkan bug klien dari penimpaan, dan tetap bertahan setelah orang yang mengumpulkannya pergi.

Sambungkan lagi di jaringan baru dan ulangi pembacaan. Jika pengecualian hilang lagi, perbaikan ada pada profil yang memilikinya, bukan pada perintah sekali pakai yang diketik saat gangguan.