Metrik rute OpenVPN: mengapa rute yang dipilih tetap kalah

Anda menambahkan metrik ke sebuah rute di profil, menghubungkan ulang, dan lalu lintas tetap keluar melalui antarmuka yang salah. Angkanya jarang menjadi masalah. Metrik hanya mengurutkan kandidat yang sudah dibandingkan oleh sistem operasi, dan prefiks yang lebih spesifik atau tabel kebijakan yang lebih awal memutuskan sebelum metrik apa pun dibaca.

Telusuri profil lebih dulu, lalu tabel yang terpasang, lalu aturan pemilihan. Urutan itu sesuai dengan cara klien membangun rute dan mencegah Anda menyetel nilai yang tidak pernah masuk perbandingan.

Baca baris rute sesuai urutan bidang

Klien komunitas OpenVPN 2.6 menerima empat bidang pada baris route IPv4: jaringan, mask jaringan, gateway, dan metrik opsional. Posisi gateway adalah tempat kata kunci khusus vpn_gateway berada. Artinya hop berikutnya di sisi VPN untuk koneksi ini, bukan nomor tabel perutean dan bukan router fisik Anda. Lewatkan itu dan sisa baris dibaca dengan pemahaman keliru tentang apa yang dilakukannya. referensi opsi jaringan mendokumentasikan keempat bidang.

Untuk tujuan privat, barisnya bisa berbunyi:

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

Angka 30 yang eksplisit berlaku untuk rute itu, dan 50 tetap menjadi default untuk setiap rute lain di profil yang menghilangkan angka. Membaca baris dari kiri ke kanan sudah cukup untuk mengetahui nilai mana berlaku di mana.

route-metric adalah default, bukan peringkat

route-metric menetapkan nilai cadangan untuk rute yang tidak membawa angkanya sendiri. Itu tidak menaikkan rute di atas apa pun, dan tidak menyusun ulang rute yang dipasang dengan metrik eksplisit.

Perbedaan itu penting ketika profil mencampur kedua bentuk. Satu baris route-metric di dekat atas tampak berwibawa dan mudah disalahkan, sementara rute yang benar-benar membawa lalu lintas mungkin membawa metriknya sendiri tiga baris di bawahnya.

Jika Anda ingin satu rute lebih memilih suatu jalur, letakkan angkanya pada rute itu. Jika Anda ingin default yang konsisten di seluruh profil yang dihasilkan, gunakan route-metric dan biarkan baris individual apa adanya. Mencampur keduanya tanpa alasan adalah cara profil berakhir dengan rute yang tidak bisa dijelaskan siapa pun.

Periksa apa yang dipasang klien

Setelah koneksi ulang selesai, tanyakan kernel, bukan profil.

ip route show mencantumkan rute yang ditambahkan klien, dan ip route get 172.20.5.10 menjawab pertanyaan yang lebih berguna: rute mana yang sebenarnya akan dipakai tujuan ini, dan dengan alamat sumber apa. Jika tujuan tidak ada di tabel, klien tidak memasangnya.

Direktif lokal, dorongan server, atau manajer jaringan lain dapat menambah atau menghapus prefiks yang sama, dan penulis terakhir yang menang. Jaga rute titik akhir tetap terlihat selama Anda bekerja, karena koneksi membutuhkan jalur ke server jauh yang tidak melewati terowongan yang sedang dibangunnya.

Mengapa metrik yang lebih kecil tetap kalah

Metrik membandingkan rute ke tujuan yang sama. Metrik tidak membuat prefiks lebar menjadi lebih spesifik. Ketika redirect-gateway def1 aktif, klien memasang 0.0.0.0/1 dan 128.0.0.0/1, dan kedua prefiks itu mencakup seluruh ruang IPv4 secara lebih spesifik daripada 0.0.0.0/0. Metrik 1 pada rute default tidak mengalahkan keduanya.

Logika yang sama berlaku untuk pasangan apa pun yang tumpang tindih. Sebuah /24 mengalahkan /16 untuk alamat di dalamnya terlepas dari angka yang dilekatkan, karena pencarian memilih kecocokan paling spesifik lebih dulu dan baru setelah itu membandingkan metrik di antara yang setara.

Inilah bagian yang tampak seperti bug metrik dan bukan. Periksa panjang prefiks pada kedua kandidat sebelum Anda mengubah angka apa pun.

Aturan kebijakan berjalan sebelum tabel

Di Linux, ip rule menentukan tabel perutean mana yang dikonsultasikan. Aturan dievaluasi dalam urutan prioritas, sehingga tabel yang lebih awal dapat mengembalikan rute sebelum tabel utama pernah dibaca. Metrik di dalam main tidak dapat mengalahkan kecocokan di tabel yang dikonsultasikan lebih dulu.

Gunakan ip rule show lalu tanyakan tabel tertentu, misalnya ip route show table 100, untuk melihat apa yang akan dikembalikan aturan itu. Jika klien VPN atau runtime kontainer menambahkan aturan, jawabannya mungkin ada di sana alih-alih di tabel yang Anda baca. Alamat sumber juga penting, karena aturan dapat mencocokkan sumber dan menyelesaikan tujuan yang sama secara berbeda untuk lalu lintas terowongan dan lalu lintas LAN.

Verifikasi tujuan, bukan peringkat

Uji yang mengakhiri perdebatan adalah satu kueri ke host di dalam subnet yang dimaksud, ditambah pemeriksaan alamat sumber yang dipilih kernel. Jika pasangan itu cocok dengan desain, metrik menjalankan tugasnya bahkan ketika daftar tidak tampak seperti peringkat yang rapi.

Jauhkan IPv6 dan DNS dari pemeriksaan ini. Keduanya dikonfigurasi oleh direktif yang berbeda dan diselesaikan oleh mekanisme yang berbeda, dan rute IPv4 yang berfungsi tidak mengatakan apa pun tentang keduanya. Ubah satu lapisan pada satu waktu dan jalankan ulang kueri.