Server dan klien OpenVPN di satu host: mengapa klien terputus

Tambahkan profil klien ke mesin yang sudah menjalankan server VPN, dan layanan semula menjadi korban pertama. Tunnel baru mungkin tidak pernah terbentuk, atau naik sementara klien server yang sudah ada diam-diam berhenti menerima balasan. Dua benturan menghasilkan kedua akibat itu: kumpulan tunnel yang sudah dipakai, dan rute default yang dipasang oleh separuh klien baru dan menutupi seluruh tabel. Keduanya tidak memunculkan pesan galat OpenVPN, karena itu kegagalan dibaca sebagai masalah server.

Satu mesin, dua peran, dan dua jawaban yang tidak cocok tentang ke mana balasan harus pergi.

Kumpulan sama, dua server: siapa yang menang

Setiap instans server memerlukan subnet tunnel sendiri. Menyalin baris seperti server 10.8.0.0 255.255.255.0 ke konfigurasi kedua memberi kedua instans prefiks yang sama, dan hasilnya entah penolakan untuk mulai entah pertarungan senyap yang klien salah satu server mendapat alamat yang juga dianggap milik server lain. Port UDP dan nama perangkat yang berbeda tidak membantu, karena keduanya tidak menyentuh ruang alamat. Ubah kumpulan kedua, dan ubah di semua tempat yang disebut rute.

Daftarkan apa yang aktif sebelum menyunting: ip -4 addr show mendaftar perangkat tunnel, ss -lunp mendaftar pendengar, dan systemctl list-units menyebut unit. Sekilas pandang ke alamat tunnel menentukan apakah kumpulannya bentrok.

Apa yang ditambahkan profil klien ke tabel

Separuh klien menulis rute begitu tersambung. redirect-gateway def1 memecah rute default menjadi 0.0.0.0/1 plus 128.0.0.0/1, keduanya dirutekan lewat perangkat baru, bersama rute host ke server jauh yang sengaja dipaku ke antarmuka fisik. Paku itu ada agar tunnel tetap punya jalur untuk transportnya sendiri. Semua hal lain, termasuk balasan yang wajib dikirim server lokal kepada kliennya sendiri, kini mengikuti default baru dan keluar lewat tautan jauh.

Jadi benturan kedua bukan tunnel rusak. Itu tunnel yang berfungsi di tempat yang salah dalam tabel.

Tiga cara memisahkan peran

Perbaikan paling tidak invasif menjauhkan rute default dari profil klien: route-nopull ditambah baris route eksplisit untuk prefiks jauh, sehingga tabel lokal berubah hanya di tempat yang Anda minta. Langkah berikutnya adalah aturan kebijakan yang mengecualikan subnet tunnel lokal, sehingga balasan bagi klien lokal keluar lewat antarmuka tempat balasan itu datang meski ada rute default. Paling menyeluruh adalah ruang nama jaringan terpisah untuk peran klien, yang menghapus tabel bersama sepenuhnya dan membutuhkan konteks perutean kedua untuk dirawat.

Jalur mana pun yang Anda ambil, pengecualian harus menyebut subnet tunnel lokal, bukan LAN. Balasan yang dikirim server lokal bertujuan alamat tunnel, jadi pengecualian berbentuk LAN tidak pernah cocok.

Instans mana yang bersalah

Hentikan instans klien dan uji ulang klien semula. Pemulihan seketika berarti perutean, bukan server. Nyalakan kembali klien dan lacak satu balasan dengan ip route get yang diberi alamat sumber dan tujuan, yang memperlihatkan jalur yang akan dipilih kernel, lalu amati antarmuka yang benar-benar dipakai paket dengan tcpdump -ni any port 1194. Berkas status server, yang ditulis setiap beberapa detik melalui direktif status, memuat daftar klien tersambung dan penghitung bita untuk kedua arah.

Baca penghitung itu satu terhadap yang lain. Lalu lintas yang keluar dan tak pernah kembali adalah jawaban perutean, bukan masalah handshake.