OpenVPN terputus selepas pembaharuan DHCP: kekalkan laluan titik akhir

Terowong bersambung, kemudian pembaharuan pajakan pada pautan akses mematikannya, dan log menyalahkan tamat masa dan bukan laluan. Tiada apa berubah dalam konfigurasi VPN, dan itulah petunjuknya: sesuatu di luarnya berubah. Peristiwa DHCP menulis semula alamat atau gateway, dan laluan hos yang memastikan titik akhir terowong boleh dicapai kini menunjuk ke hop seterusnya yang tidak lagi wujud. Ini masalah pemilikan sebelum ia menjadi masalah penghalaan.

Bandingkan gejala dengan laluan separa lalai

Dengan redirect-gateway def1, OpenVPN memasang 0.0.0.0/1 dan 128.0.0.0/1 dan bukannya menggantikan laluan lalai. Bersama-sama kedua-duanya meliputi seluruh ruang alamat, dan ia mengalahkan 0.0.0.0/0 hanya melalui panjang awalan. Oleh itu setiap destinasi tanpa padanan yang lebih khusus masuk ke dalam terowong.

Titik akhir memerlukan pengecualian. OpenVPN menambah laluan hos ke alamat pelayan melalui gateway akses asal sebelum separa lalai dimasukkan, supaya paket yang dikapsulkan boleh keluar. Apabila pengecualian itu hilang, atau mengekalkan hop seterusnya yang tidak lagi wujud, paket luar terowong itu sendiri sepadan dengan separa lalai dan dihantar kembali ke dalam terowong. Hasilnya ialah sambungan yang mati pada keepalive atau jabat tangan seterusnya, tanpa apa-apa dalam log yang kelihatan seperti ralat penghalaan.

Sahkan bentuk jadual sebelum menyentuh apa-apa lagi. ip route show sepatutnya menyenaraikan kedua-dua separuh serta laluan hos untuk alamat pelayan; apabila laluan hos tiada, baki siasatan mempunyai titik permulaan yang jelas.

Mengapa separa lalai menang tanpa perubahan metrik

Metrik yang lebih rendah tidak mengalahkan awalan yang lebih panjang. Laluan /1 menang kerana kernel memadankan laluan paling khusus dahulu, jadi menaikkan metrik pada laluan lalai tidak mengubah apa-apa tentang ke mana trafik yang menuju terowong pergi. Mengejar metrik ialah kesilapan paling biasa dalam diagnosis ini.

Semak pemilihan dengan ip route get 203.0.113.10, dengan menggantikannya dengan alamat pelayan sebenar. Jawapannya menamakan antara muka dan hop seterusnya yang benar-benar akan digunakan oleh kernel, yang lebih bermaklumat daripada membaca jadual dan menaakulnya.

Jalankan arahan itu sebelum terowong bermula, semasa ia hidup, dan selepas peristiwa pajakan. Tiga jawapan daripada satu arahan, dan titik perbezaan menjadi kelihatan.

Ambil tiga petikan, bukan satu

Kumpulkan alamat akses, gateway akses, destinasi titik akhir, laluan yang dipilih dan sebarang peraturan dasar pada tiga saat: selepas pautan akses dikonfigurasikan, selepas VPN bersambung, dan selepas peristiwa pajakan atau pembawa. Setiap petikan ialah segenggam arahan, dan ia hanya bermakna bersama-sama. Petikan tunggal selepas kegagalan merekodkan keadaan dan bukan peralihan. Tulis arahan itu ke dalam skrip kecil supaya setiap petikan diambil dengan cara yang sama.

Simpan petikan dalam satu fail dengan cap masa, kerana soalan menarik kemudiannya ialah susunan. Adakah peristiwa DHCP datang sebelum atau selepas OpenVPN menyegarkan laluannya? Jawapannya menentukan siapa yang perlu membaikinya. Cap masa daripada jam yang salah lebih buruk daripada tiada, jadi ambil daripada hos yang memiliki jadual penghalaan.

Apabila titik akhir dikonfigurasikan sebagai nama dan bukan alamat, selesaikannya dalam setiap petikan juga. Perubahan DNS pada pautan akses boleh menggerakkan titik akhir tanpa sebarang laluan disentuh.

Tentukan komponen mana yang menyegarkan pengecualian

Pada sistem dhcpcd, cangkuk berjalan dari direktori cangkuk dan dari cangkuk keluar, dan mod pengurus berbeza dari segi skop daripada mod setiap antara muka. Apa pun yang dilakukan cangkuk, ia mesti idempoten, kerana pembaharuan boleh datang berkelompok.

Pemilik yang boleh dipercayai ialah integrasi yang sudah mengenali kedua-dua pihak: pengurus rangkaian yang menguruskan sambungan VPN, atau unit yang disusun selepas pautan akses naik. Laluan statik yang ditambah oleh cangkuk berfungsi sehingga perubahan gateway seterusnya, kemudian gagal dengan cara yang sama. Jika anda tetap menggunakan cangkuk, biarkan ia membaca gateway semasa pada masa jalan dan bukan mengodkan yang anda lihat hari ini.

Rekodkan pemilik di dalam konfigurasi. Orang seterusnya yang menyahpepijat sambungan semula perlu tahu bahawa cangkuk, bukan VPN, bertanggungjawab atas laluan pengecualian.

Uji kitaran hayat, bukan hanya sambungan semula

Paksa pembaharuan dengan dhcpcd -n eth0 atau dengan melepaskan dan mengambil semula pajakan, kemudian semak semula ip route get untuk titik akhir. Lakukan dua kali, kerana larian kedua menangkap cangkuk yang menambah laluan berganda. Kemudian but semula, kerana ketahanan ialah sifat yang berbeza daripada ketepatan.

Terowong yang bertahan melalui pembaharuan dan but semula mempunyai pemilik dan pengecualian yang berfungsi. Yang hanya bertahan melalui mula semula manual tidak mempunyai kedua-duanya, dan akan gagal pada peristiwa seterusnya yang tidak boleh anda jadualkan.