Mengapa rute berbiaya sama membuat kesalahan VPN sulit terlihat
Saat beberapa terowongan berbagi biaya yang sama, setiap aliran dapat memilih yang berbeda. Ping yang berhasil tidak menjelaskan apa pun tentang jalur yang sebenarnya dipakai aplikasi Anda.
Seorang pengguna melaporkan bahwa aplikasi internal berfungsi dari satu mesin dan gagal dari mesin lain, padahal ping yang Anda jalankan dari gateway berhasil pada kedua kasus. Dengan beberapa terowongan berbiaya sama, itu bukan kontradiksi. Setiap aliran ditempatkan pada hop berikutnya masing-masing, jadi pemeriksaan Anda dan sesi pengguna bisa saja memakai jalur yang berbeda. Penelusuran di bawah ini mereproduksi pilihan tersebut sebelum ada yang diubah.
Satu ping, beberapa kemungkinan jalur
Ketika sebuah rute memiliki lebih dari satu hop berikutnya dengan biaya yang sama, router harus memilih satu per paket. Sebagian besar implementasi melakukan hash pada bidang paket, biasanya alamat sumber dan tujuan bersama protokol dan port, agar respons tetap berada di jalur yang sama. Aplikasi berbeda, bahkan koneksi berbeda dari satu aplikasi, menghasilkan hash yang berbeda.
Itulah sebabnya diagnosis dari gateway begitu sedikit membuktikan. Pemeriksaan gateway punya alamat dan port sendiri, dan karena itu hash sendiri. Ia bisa mendarat di terowongan yang sehat sementara pengguna terus mendarat di yang rusak.
Bagaimana platform memilih hop berikutnya
Reproduksi pilihan itu alih-alih menebaknya. Tanyakan kepada kernel rute mana yang akan dipakai untuk sumber dan tujuan yang sama dengan sesi yang gagal. Pencarian itu mencakup bidang yang diabaikan pencarian tujuan biasa. Jalankan juga dari klien yang berfungsi dan bandingkan kedua jawabannya:
ip route get 10.20.5.7 from 10.20.0.14Rilis iproute2 yang lebih baru juga menerima protokol dan port tujuan, yang penting ketika hash menyertakannya. Bandingkan keluaran itu dengan pencarian yang sama dari klien yang berfungsi, dan selisihnya adalah bukti yang Anda lewatkan.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Ikuti aliran yang gagal, bukan tabel rute
Tabel rute mencantumkan kedua terowongan dan secara definisi tampak benar. Pertanyaannya adalah apa yang dilakukan setiap terowongan terhadap paket setelah dipilih. Pastikan keduanya membawa prefiks terlindungi yang sama, izin penerusan yang sama, dan jalur balik yang mencapai klien yang sama.
Perhatikan perangkat stateful di tengah. Jika permintaan keluar melalui satu terowongan dan balasannya kembali melalui terowongan lain, firewall atau NAT yang tidak pernah melihat aliran aslinya akan membuangnya. Kedua terowongan meneruskan lalu lintas dengan benar, dan koneksi tetap gagal.
Periksa juga MTU per jalur. Jalur dengan enkapsulasi tambahan memperkecil ukuran yang dapat dipakai, dan transfer yang berhasil pada satu terowongan terhenti pada terowongan lain tepat pada ukuran tempat yang lebih kecil putus.
Bandingkan satu jalur setiap kali
Di mana desain memungkinkan pemeliharaan, keluarkan satu terowongan dari layanan dan ulangi tugas pengguna. Jika kegagalan hilang, masalahnya milik jalur yang Anda keluarkan, dan langkah berikutnya adalah membandingkan konfigurasinya dengan tetanggannya alih-alih memeriksa ulang tabel rute.
Bandingkan aplikasi yang sebenarnya, bukan ping berulang. Catat apakah kegagalan mengikuti hop berikutnya tertentu, ukuran paket, atau transisi setelah menyambung ulang, karena ketiga pola itu menunjuk pada perbaikan yang berbeda.
Terakhir, catat mengapa jalur dianggap setara dan bagaimana kegagalan seharusnya mengeluarkan salah satunya dari layanan. Multipath hanya aman bila jalurnya benar-benar dapat dipertukarkan, dan itu pernyataan desain yang layak diperiksa alih-alih diasumsikan.