Prefiks publik melalui OpenVPN: perbaiki jalur kembali

Amati tunnel naik dan klien mem-ping sisi jauh, lalu alamat publik yang berada di balik VPN menjawab dari tempat lain, atau tidak menjawab sama sekali. Gejala itu biasanya tidak ada hubungannya dengan cipher atau sertifikat. Prefiks yang dirutekan penyedia dikirim sebagai rute IP, dan membawanya lewat OpenVPN berarti mereproduksi rute itu pada dua tingkat dan mempertahankan alamat sumber pada jalur kembali. Menjembatani WAN tidak diperlukan, dan menambahkan alamat ke antarmuka tidak membuat rute hulu.

Prefiks harus dirutekan ke Anda terlebih dahulu

Tanyakan kepada penyedia bagaimana blok dikirim. Prefiks yang dirutekan ke alamat utama server Anda berbeda dengan alamat yang diharapkan penyedia dapat dijangkau langsung pada segmen WAN. Hanya model pertama yang cocok dengan desain di sini.

Jika penyedia merutekan 198.51.100.64/28 ke server masuk Anda, paket untuk rentang itu tiba di server dan berhenti di sana kecuali Anda meneruskannya. Jika penyedia justru menjembatani rentang itu ke uplink Anda, server harus menjawab ARP untuknya, yang merupakan masalah lain.

Uji model pengiriman sebelum menyentuh OpenVPN: dari luar, ping alamat di blok itu dan lihat antarmuka mana yang menerimanya. Jika tidak ada yang tiba, konfigurasi tunnel apa pun tidak akan membantu. Jika alamat menjawab langsung di WAN, penyedia menjembatani alih-alih merutekan, dan desain di bawah tidak berlaku.

Dua tingkat perutean: rute kernel dan iroute

OpenVPN membutuhkan prefiks di dua tempat. Kernel harus tahu bahwa prefiks milik perangkat tunnel, agar paket yang diteruskan masuk ke OpenVPN alih-alih rute default. OpenVPN juga harus tahu klien terautentikasi mana yang memiliki prefiks, dan itulah entri iroute di direktori khusus klien.

Rute sisi server tampak seperti ini, dengan prefiks dan mask yang cocok dengan alokasi:

ip route add 198.51.100.64/28 dev tun0

Konfigurasi khusus klien menetapkan kepemilikan. Letakkan di berkas CCD yang dinamai menurut nama umum sertifikat klien, dan pastikan direktori itu yang benar-benar dibaca server:

iroute 198.51.100.64 255.255.255.240

Dokumentasi OpenVPN tentang jaringan yang dirutekan menjelaskan kedua tingkat dan mengapa keduanya terpisah. Rute kernel tanpa iroute mengirim paket ke tunnel tanpa pemilik, dan OpenVPN membuangnya. iroute tanpa rute kernel membiarkan paket pada jalur default server. Kedua kesalahan tampak seperti tunnel rusak dari sisi klien.

Di mana alamat layanan berada

Prefiks yang didelegasikan bukan hal yang sama dengan alamat tunnel itu sendiri. Beri nomor tautan dari ruang privat jika mau, dan tempatkan alamat layanan publik di tempat layanan benar-benar berjalan.

Pada klien Linux yang mengakhiri layanan secara lokal, satu alamat host sudah cukup:

ip address add 198.51.100.70/32 dev lo

Jika prefiks dirutekan lebih jauh ke host VM atau LAN lain, konfigurasikan jalur hilir itu dan rute kembalinya sebagai gantinya. Menetapkan setiap alamat di blok itu ke klien VPN tidak diperlukan dan menimbulkan konflik kemudian.

Pertahankan sumber publik pada jalur kembali

Balasan dari prefiks yang didelegasikan harus keluar melalui tunnel dan mencapai rute penyedia. Jika host jarak jauh mengirimnya melalui ISP-nya sendiri, alamat sumber tampak dipalsukan, dan penyedia atau tujuan membuangnya. Perbaikannya adalah aturan berbasis sumber atau tabel perutean khusus, bukan NAT yang lebih luas. Tanpanya, layanan bekerja dari rekan tunnel dan gagal dari tempat lain.

Di server masuk, aturan masquerade yang luas adalah tersangka biasa. Aturan itu menulis ulang sumber publik ke alamat utama server, dan klien tidak pernah melihat yang asli:

iptables -t nat -S POSTROUTING

Batasi NAT pada klien VPN privat yang membutuhkannya dan biarkan prefiks yang didelegasikan tidak diterjemahkan. Lalu pastikan server meneruskan prefiks itu sama sekali, karena rantai penerusan dengan penolakan default membuangnya secara diam-diam.

Verifikasi kedua arah sebelum memercayainya

Verifikasi adalah empat pengamatan, bukan satu. Pastikan rute penyedia tiba, kernel mengirim prefiks ke tunnel, OpenVPN mengaitkannya dengan klien yang tepat, dan balasan kembali dengan sumber publik utuh. Setiap pengamatan punya perintahnya sendiri, sehingga kegagalan menunjuk ke satu lapisan alih-alih seluruh desain. Jalankan dalam urutan itu setelah setiap perubahan konfigurasi.

Tanyakan kepada kernel jalur mana yang diambil alamat yang didelegasikan, dan amati tunnel saat permintaan berjalan:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Pemfilteran jalur terbalik dapat membatalkan rute yang benar. Periksa setelan efektif pada tunnel dan pada uplink, dan ingat bahwa mode ketat menolak lalu lintas yang sumbernya tidak cocok dengan antarmuka tempat ia tiba:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Terakhir, uji kasus kegagalan. Hentikan tunnel dan pastikan prefiks publik tidak bocor melalui uplink biasa. Memulihkan VPN seharusnya mengembalikan layanan tanpa memperluas port mana yang diekspos host.