Dua gerbang jaringan, satu VPN: mengapa OpenVPN memilih jalur naik yang salah

Dua jalur naik, satu terowongan, dan lalu lintas keluar melalui jalur yang tidak Anda pilih. Subnet privat dapat dijangkau, log melaporkan koneksi berhasil, dan tautan bermeteran itulah yang membawanya. Tidak ada yang menyebut gateway di keluaran OpenVPN, karena klien tidak pernah memilih salah satunya. Ia membuka soket ke alamat jauh dan membiarkan kernel memutuskan bagaimana mencapai alamat itu.

Alamat terowongan bukan titik akhir

Ada dua jalur berbeda di setiap sesi. Jalur luar membawa transport terenkripsi ke alamat publik server. Jalur dalam membawa apa pun yang didorong server ke dalam terowongan, dan aturan perutean untuk yang satu tidak berpengaruh pada yang lain.

Entri remote di profil menyebut tujuan luar, jadi itulah alamat yang harus dipatok. Itu juga nilai yang berubah ketika nama host diresolusi berbeda atau profil mencantumkan beberapa remote.

Temukan alamat yang benar-benar dihubungi klien

Baca soket yang hidup, bukan berkas konfigurasi. Tabel soket menunjukkan peer yang benar-benar dihubungi proses, dan itulah nilai yang harus cocok dengan pengecualian. Profil dapat diedit setelah sesi dimulai, dan soket adalah satu-satunya bukti tentang apa yang dihubungi:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Baris log menyebut alamat dan port peer pada saat koneksi. Jika tidak cocok dengan profil, ada sesuatu di depan klien yang menulis ulang tujuan sebelum koneksi dimulai.

Periksa juga keluarga alamatnya. Profil tumpukan ganda dapat terhubung melalui IPv6 sementara pengecualian Anda hanya mencakup IPv4, dan lalu lintas kemudian mengikuti aturan yang berbeda dari yang Anda tulis. Hal yang sama berlaku untuk proxy yang menjawab atas nama titik akhir. Kedua kasus menghasilkan terowongan yang berfungsi sementara rute Anda tidak melakukan apa pun.

Patok titik akhir dan baca urutan kebijakan

Rute host lebih spesifik daripada rute bawaan mana pun. Karena itu /32 untuk alamat peer menang di dalam tabel yang memuatnya. Bentuk biasanya menyebut gateway dan perangkat secara eksplisit:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Rute itu hanya membantu jika pencarian mencapai tabel tersebut. Aturan kebijakan dievaluasi berurutan dan kecocokan pertama yang menentukan, jadi aturan yang mengirim semuanya ke tabel kedua melewati rute host Anda di main. Baca aturannya sebelum menganggap rute itu berwenang:

ip rule show
ip route get 203.0.113.40

Tanyakan perintah kedua dengan alamat sumber atau tanda yang sama yang digunakan klien ketika kebijakan bergantung padanya. Perintah itu melaporkan rute yang akan dipilih kernel, yang merupakan bukti tentang pencarian dan bukan bukti bahwa soket hidup memakai jalur itu.

Saat titik akhir berpindah

Nama host yang diresolusi ke beberapa alamat membatalkan /32 permanen begitu jawabannya berubah. Profil dengan beberapa baris remote punya masalah yang sama, karena klien bisa mendarat di salah satunya. Segarkan rute dari kait siklus hidup klien sendiri alih-alih menambahkannya secara manual. Skrip up yang membaca peer yang dinegosiasikan dan memasang rute host menjaga pengecualian tetap selaras dengan kenyataan, dan skrip down yang sesuai menghapusnya.

Catat penyegaran di tempat yang sama dengan konfigurasi perutean host lainnya. Rute yang hanya bertahan sampai reboot berikutnya adalah uji coba, bukan perbaikan.

Pisahkan kebijakan dalam

Memindahkan jalur luar tidak memberi akses ke subnet privat baru dan tidak mengubah tujuan mana yang didorong server ke dalam terowongan. Rute lapisan bawah memilih kabel; rute yang didorong memilih apa yang masuk ke terowongan. Menjaga kedua keputusan itu terpisah membuat pemisahan dapat diprediksi.

Jika tujuannya hanya menjauhkan transport terenkripsi dari tautan bermeteran, biarkan rute bawaan dan tambahkan satu pengecualian host. Mengganti rute bawaan seluruh mesin untuk memindahkan satu koneksi VPN merusak setiap aplikasi lain di host.

Konfirmasi hasilnya dengan dua pengamatan independen: alamat lokal dan perangkat soket, dan rute ke mana tujuan privat diresolusi. Ketika keduanya sesuai dengan niat Anda, pemisahannya nyata. Panduan OpenVPN 2.6 mencakup opsi remote dan pengikatan lokal yang menentukan alamat mana yang dihubungi klien.