Rute VPN hilang di NetworkManager: kebijakan profil atau skrip?

Anda tersambung, antarmuka tunnel muncul, dan satu prefiks yang Anda butuhkan tidak ada di tabel. Langkah berikutnya biasanya mencari skrip yang menambahkannya. Pencarian itu berujung pada jawaban yang menempelkan pembantu OpenVPN ke dalam profil, dan separuh jawaban itu membuat keadaan lebih buruk, bukan lebih baik, karena rute yang hilang punya tiga kemungkinan pemilik dan hanya satu di antaranya adalah skrip yang hilang.

Putuskan pemilik mana yang bertanggung jawab sebelum Anda menulis apa pun.

Tiga pemilik, satu prefiks yang hilang

Prefiks bisa tidak ada karena tidak ada yang menyediakannya, karena profil menolaknya, atau karena prefiks itu dipasang di tempat yang tidak Anda lihat. Itu kerusakan yang berbeda dan punya perbaikan yang berbeda.

Yang pertama paling mudah diperiksa: pernahkah server atau plugin menawarkan rute itu? Backend yang tidak pernah menerima prefiks tidak bisa memasangnya, dan skrip pembantu tidak bisa mengarang keterjangkauan yang tidak pernah dijelaskan oleh rekan. Yang kedua adalah kebijakan profil, yang bisa menekan rute yang seharusnya diambil koneksi. Yang ketiga adalah tabel atau aturan, yang bisa menyimpan rute di tempat yang tidak pernah dilihat pencarian bawaan.

Pemilik keempat adalah Anda, nanti: skrip yang menambahkan rute saat tersambung tetapi tidak menghapusnya saat terputus. Itu menghasilkan prefiks yang bertahan lebih lama dari tunnel, menunjuk ke antarmuka yang mati, dan membingungkan orang berikutnya yang men-debug mesin itu.

Baca profil sebelum menambahkan apa pun

Mulailah dari properti koneksi tersimpan itu sendiri. Baca tanpa membocorkan rahasia, dan gunakan UUID jika nama profil ambigu.

nmcli -f vpn.service-type,ipv4.never-default,ipv4.ignore-auto-routes,ipv4.route-table,ipv4.routes connection show office

vpn.service-type memberi tahu Anda backend mana yang memiliki koneksi, dan itu penting karena data plugin spesifik untuk backend. Kunci yang diterima satu plugin bukan instruksi yang didukung untuk plugin lain, jadi cuplikan yang disalin dari dokumentasi klien lain bukan bukti apa pun.

ipv4.ignore-auto-routes dan ipv4.never-default menjawab pertanyaan yang berbeda. Yang pertama bisa menolak rute yang seharusnya diambil koneksi secara otomatis, dan yang kedua mengatur apakah profil boleh menjadi rute bawaan. Profil yang mengabaikan rute otomatis dan tidak mengandalkan apa pun lagi akan tersambung dengan bersih dan hampir tidak memasang apa pun.

ip -4 rule show
ip -4 route show table all

Dua perintah itu menyelesaikan kemungkinan ketiga. Cari prefiks Anda di setiap tabel, bukan hanya main, dan periksa apakah aturan kebijakan mengirim pencarian terkait ke tempat lain. Jika prefiks ada di tabel lain dan tidak ada yang menanyakannya, Anda tidak punya rute yang hilang; Anda punya pencarian yang tidak pernah mencapainya.

Apa yang tidak bisa diperbaiki skrip

Menambahkan skrip pembantu memberi vpn.data NetworkManager sebuah program untuk dijalankan. Itu mekanisme nyata, dan itu mekanisme yang salah untuk sebagian besar kasus ini, karena skrip mendapat kendali setelah kebijakan profil itu sendiri sudah memutuskan apa yang diterima.

script-security OpenVPN adalah kebingungan berulang lainnya. Itu pengaturan OpenVPN yang mengatur skrip mana yang boleh dijalankan klien dan apa yang boleh ditaruhnya di lingkungan skrip; level 3 mengizinkan penerusan kredensial melalui lingkungan, yang merupakan keputusan penanganan rahasia, bukan perbaikan perutean. Menempelkannya ke profil yang backend-nya bukan OpenVPN, atau menaikkannya saat tidak ada skrip yang membutuhkannya, menambah paparan tanpa menambah rute.

Lalu ada refleks memulai ulang. Memulai ulang layanan NetworkManager meruntuhkan dan membangun ulang setiap tautan terkelola, termasuk tautan yang Anda gunakan untuk tersambung jika Anda bekerja dari jarak jauh. Itu tindakan yang mengganggu, bukan diagnostik yang tidak berbahaya, dan di server hal itu bisa menjadi selisih antara sesi yang bertahan dan yang tidak.

Keputusannya, secara berurutan

Ajukan tiga pertanyaan secara berurutan. Apakah rekan menyediakan prefiks, yang akan ditunjukkan log backend atau keluaran statusnya sendiri? Jika ya, apakah profil dikonfigurasi untuk menerima dan memasang rute, atau justru menekannya? Jika rute itu ada di suatu tempat, apakah jalur pencariannya benar untuk lalu lintas yang Anda uji?

Hanya ketika jawaban pertama ya, jawaban kedua ya, dan yang ketiga benar, skrip tambahan menjadi bisa dipertahankan, dan bahkan saat itu Anda harus bertanya apakah backend mendukung rute itu secara asli. Referensi pengaturan VPN mendokumentasikan service-type dan kamus data khusus plugin, dan dari sanalah sebaiknya mulai sebelum mengasumsikan sebuah kunci ada.

Setelah koreksi yang disetujui, sambungkan ulang dan uji tujuan berdasarkan alamat lalu berdasarkan nama, kemudian putuskan dan sambungkan lagi untuk memastikan keadaannya bisa diulang. Satu pemilik, satu tabel, dan rute yang hilang bersama tunnel adalah hasil yang layak didapat.