OpenVPN terputus setelah pembaruan DHCP: pertahankan rute endpoint

Tunnel tersambung, lalu pembaruan sewa pada tautan akses mematikannya, dan log menyalahkan batas waktu alih-alih rute. Tidak ada yang berubah pada konfigurasi VPN, dan itulah petunjuknya: sesuatu di luarnya berubah. Peristiwa DHCP menulis ulang alamat atau gateway, dan rute host yang menjaga endpoint tunnel tetap terjangkau kini menunjuk ke hop berikutnya yang tidak ada lagi. Ini masalah kepemilikan sebelum menjadi masalah perutean.

Bandingkan gejalanya dengan rute setengah-default

Dengan redirect-gateway def1, OpenVPN memasang 0.0.0.0/1 dan 128.0.0.0/1 alih-alih mengganti rute default. Bersama-sama keduanya menutupi seluruh ruang alamat, dan keduanya mengalahkan 0.0.0.0/0 hanya dari panjang prefiks. Karena itu setiap tujuan tanpa kecocokan yang lebih spesifik masuk ke tunnel.

Endpoint membutuhkan pengecualian. OpenVPN menambahkan rute host ke alamat server melalui gateway akses asli sebelum rute setengah-default dipasang, agar paket yang dienkapsulasi bisa keluar. Ketika pengecualian itu hilang, atau mempertahankan hop berikutnya yang tidak ada lagi, paket luar tunnel itu sendiri cocok dengan rute setengah-default dan dikirim kembali ke dalam tunnel. Hasilnya koneksi yang mati pada keepalive atau handshake berikutnya, tanpa ada apa pun di log yang tampak seperti kesalahan perutean.

Pastikan bentuk tabelnya sebelum menyentuh hal lain. ip route show seharusnya mencantumkan kedua belahan ditambah rute host untuk alamat server; ketika rute host hilang, sisa penyelidikan punya titik awal yang jelas.

Mengapa rute setengah-default menang tanpa perubahan metrik

Metrik yang lebih rendah tidak mengalahkan prefiks yang lebih panjang. Rute /1 menang karena kernel mencocokkan rute paling spesifik lebih dulu, jadi menaikkan metrik pada rute default tidak mengubah apa pun tentang ke mana lalu lintas menuju tunnel pergi. Mengejar metrik adalah kesalahan paling umum dalam diagnosis ini.

Periksa pemilihan dengan ip route get 203.0.113.10, dengan menggantinya dengan alamat server yang sebenarnya. Jawabannya menyebut antarmuka dan hop berikutnya yang benar-benar akan dipakai kernel, yang lebih informatif daripada membaca tabel dan menalar tentangnya.

Jalankan perintah itu sebelum tunnel mulai, saat tunnel hidup, dan setelah peristiwa sewa. Tiga jawaban dari satu perintah, dan titik perbedaannya menjadi terlihat.

Ambil tiga snapshot, bukan satu

Kumpulkan alamat akses, gateway akses, tujuan endpoint, rute yang dipilih, dan aturan kebijakan apa pun pada tiga momen: setelah tautan akses dikonfigurasi, setelah VPN tersambung, dan setelah peristiwa sewa atau operator. Setiap snapshot adalah segenggam perintah, dan semuanya hanya bermakna bersama. Snapshot tunggal setelah kegagalan mencatat keadaan, bukan transisi. Tuliskan perintahnya ke dalam skrip kecil agar setiap snapshot diambil dengan cara yang sama.

Simpan snapshot dalam satu berkas dengan stempel waktu, karena pertanyaan menarik nanti adalah urutannya. Apakah peristiwa DHCP datang sebelum atau setelah OpenVPN menyegarkan rutenya? Jawabannya menentukan siapa yang harus memperbaikinya. Stempel waktu dari jam yang salah lebih buruk daripada tidak ada, jadi ambillah dari host yang memiliki tabel perutean.

Ketika endpoint dikonfigurasi sebagai nama alih-alih alamat, selesaikan juga di setiap snapshot. Perubahan DNS pada tautan akses dapat memindahkan endpoint tanpa satu pun rute disentuh.

Putuskan komponen mana yang menyegarkan pengecualian

Pada sistem dhcpcd, hook berjalan dari direktori hook dan dari hook keluar, dan mode manajer berbeda cakupannya dari mode per antarmuka. Apa pun yang dilakukan hook, itu harus idempoten, karena pembaruan bisa datang bergelombang.

Pemilik yang andal adalah integrasi yang sudah mengenal kedua sisi: manajer jaringan yang mengelola koneksi VPN, atau unit yang diurutkan setelah tautan akses naik. Rute statis yang ditambahkan hook bekerja sampai perubahan gateway berikutnya, lalu gagal dengan cara yang persis sama. Jika Anda tetap memakai hook, buat hook membaca gateway saat ini pada waktu jalan alih-alih mengodekan yang Anda lihat hari ini.

Catat pemiliknya di dalam konfigurasi. Orang berikutnya yang men-debug sambungan ulang perlu tahu bahwa hook, bukan VPN, bertanggung jawab atas rute pengecualian.

Uji siklus hidup, bukan hanya sambungan ulang

Paksa pembaruan dengan dhcpcd -n eth0 atau dengan melepaskan dan mengambil ulang sewa, lalu periksa lagi ip route get untuk endpoint. Lakukan dua kali, karena putaran kedua menangkap hook yang menambahkan rute ganda. Lalu mulai ulang, karena ketahanan adalah sifat yang berbeda dari kebenaran.

Tunnel yang bertahan dari pembaruan dan mulai ulang punya pemilik dan pengecualian yang bekerja. Yang hanya bertahan dari mulai ulang manual tidak punya keduanya, dan akan gagal pada peristiwa berikutnya yang tidak bisa Anda jadwalkan.