Klien OpenVPN macet saat servernya berjalan di host yang sama

Saya punya mesin lab yang menerima tunnel dari situs jarak jauh dan juga melakukan dial keluar ke jaringan vendor. Profil keluar sudah berfungsi selama berminggu-minggu. Setelah server masuk ditambahkan, yang keluar terhubung lalu berhenti melewatkan lalu lintas dalam hitungan detik, atau menolak mulai dengan kesalahan alamat sudah digunakan. Berkas konfigurasi tidak berubah; host hanya memperoleh proses OpenVPN kedua yang punya pendapat sendiri soal port dan rute.

Kegagalan ini tidak acak, dan bukan masalah autentikasi. Dua daemon di satu mesin bersaing untuk soket lokal yang sama dan tabel rute yang sama, dan yang terakhir mulai atau menyambung ulang cenderung menang. Mengetahui mana dari dua tabrakan itu yang Anda alami menentukan ke mana harus melihat lebih dulu.

Baca gejalanya dari belakang

Mulailah dari kapan tunnel mati. Kesalahan bind saat mulai menunjuk ke sisi pendengar: sesuatu sudah memiliki port itu, dan OpenVPN menolak mulai daripada membaginya. Tunnel yang naik lalu diam menunjuk ke perutean, karena rute yang dipasang oleh instans lain dapat menarik paket koneksi luar dari jalurnya.

Kedua kasus menghasilkan keluhan pengguna yang sama, itulah sebabnya loop percobaan ulang dan skrip pengawas tidak memperbaiki apa pun. Keduanya menyambungkan klien kembali ke konflik yang sama. Pertanyaan pertama yang berguna adalah apakah prosesnya masih berjalan saat lalu lintas berhenti.

Satu soket dan satu perangkat per instans

Server yang mendengarkan mengikat portnya; klien keluar juga memerlukan port lokal untuk lalu lintas terenkapsulasinya. Ketika keduanya tinggal di host yang sama, perilaku bawaan klien dapat bertabrakan dengan port server. Port lokal klien dapat dipatok, dan pengikatan dapat dilewati bila rekan tidak memerlukan port sumber tetap:

lport 1195
nobind
dev tun1

Angka-angka itu contoh, bukan keharusan. Yang penting adalah klien berhenti berebut port server dan setiap instans mendapat perangkat tunnel terpisah. Dua daemon yang berbagi tun0 saling menimpa status perangkat bahkan ketika port mereka berbeda, jadi satu perangkat per tunnel bukan pilihan.

nobind milik sisi klien. Server tetap harus mengikat dan mendengarkan, jadi jangan menyalin baris itu ke konfigurasi server, dan jangan menonaktifkan pengikatan pada klien yang rekannya menyaring pada port sumber tetap.

Pilih satu pemilik untuk rute default

Hanya satu koneksi yang dapat memasang rute default. Jika kedua profil mengalihkan semua lalu lintas, koneksi kedua diam-diam menggantikan yang pertama, dan yang pertama tampak rusak. Entah pertahankan tunnel keluar terpisah dan dorong hanya prefiks vendor, atau beri ia tabel perutean terpisah.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Alamat dan nomor tabel di atas adalah placeholder. Segera setelah menambahkan aturan, pastikan alamat server VPN itu sendiri masih diselesaikan melalui tabel normal; tabel yang menangkap transport luar merusak tunnel yang seharusnya dilindunginya, dan loop sambung ulang yang mengikuti tampak seperti penyedia yang tidak andal.

Untuk penyiapan yang harus bertahan dari sambung ulang dan reboot, namespace jaringan adalah batas yang lebih kokoh. Klien kedua berjalan di dalam namespace-nya sendiri dengan antarmuka dan rutenya sendiri, dan hanya layanan yang harus menyeberang yang diekspos. Host mempertahankan satu rute default, dan sambung ulang namespace tidak dapat menulis ulang rute itu.

Verifikasi dengan tabel, bukan baris status

Klien yang melaporkan terhubung hanya membuktikan kanal kontrolnya. Tangkap status perutean sebelum dan sesudah setiap koneksi, lalu tanyakan ke kernel perangkat mana yang akan digunakan tujuan nyata:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Jika perangkat yang dipilih untuk alamat vendor berubah saat tunnel kedua mulai, Anda mengalami tabrakan rute. Jika kedua proses muncul pada port lokal yang sama, Anda mengalami tabrakan soket. Memperbaiki yang pertama tanpa yang kedua hanya memindahkan kegagalan ke sambung ulang berikutnya.

Tulis port, perangkat, tabel, dan pemilik rute ke runbook host. Jika tidak, orang berikutnya yang menambahkan tunnel ketiga akan menemukan kembali tabrakan yang sama, dan satu-satunya bukti yang terlihat adalah koneksi yang berfungsi sampai daemon orang lain dimulai ulang.