Belajar OpenVPN - Connection Broker & Scalability

#Pendahuluan

Server VPN kalian sehat untuk sepuluh pengguna. Sekarang bayangkan seratus, lima ratus, atau lebih. OpenVPN menangani ribuan koneksi dalam satu proses, tetapi ada batas praktis dan risiko: koneksi yang melonjak bisa menghabiskan CPU handshake, dan satu server berarti satu titik kegagalan.

Episode 11 ini membahas connection broker dan scalability. Kalian akan belajar membatasi resource dengan --max-clients, mengendalikan laju koneksi dengan --connect-freq dan rate limiting, menjalankan banyak instance OpenVPN untuk melayani segmen berbeda, serta mendistribusikan beban dengan learn-address dan round-robin DNS.

Tujuan akhirnya sederhana: infrastruktur VPN yang tumbuh tanpa rasa sakit, tetap responsif saat trafik memuncak, dan tidak runtuh ketika satu node bermasalah.

#Connection Broker

#Membatasi Client dengan max-clients

Parameter pertama yang harus kalian kendalikan adalah jumlah koneksi bersamaan. Direktif max-clients menetapkan batas atas client yang bisa terhubung ke satu instance:

max-clients 200

max-clients 200 membuat koneksi ke-201 ditolak. Ini melindungi daemon dari kehabisan file descriptor dan melindungi jaringan dari satu instance yang kewalahan. Angka ideal tergantung pada kapasitas CPU dan bandwidth server.

#Mengendalikan Laju Koneksi dengan connect-freq

Serangan reconnect yang berulang — karena client error atau serangan — bisa menghabiskan resource handshake. --connect-freq membatasi jumlah percobaan connect per menit per client:

connect-freq 20 60

connect-freq 20 60 mengizinkan maksimal 20 percobaan dalam jendela 60 detik untuk alamat asal yang sama. Di atas itu, percobaan berikutnya ditolak. Ini mencegah satu client rusak atau satu penyerang menyumbat proses handshake.

#Rate Limiting dan Connection Pooling

Untuk proteksi yang lebih granular, kombinasikan dengan batasan di level firewall atau service:

iptables -A INPUT -p udp --dport 1194 -m hashlimit \
  --hashlimit-above 30/sec --hashlimit-mode srcip \
  --hashlimit-name openvpn -j DROP

Aturan iptables dengan hashlimit ini menolak koneksi yang melebihi 30 paket per detik dari satu sumber IP. Gunakan rule ini sebagai lapisan pertama, lalu biarkan connect-freq menangani logika khusus OpenVPN. Pola berlapis seperti inilah yang disebut defense-in-depth.

#Banyak Instance OpenVPN

#Instance Berbeda untuk Segmen Berbeda

Ketika satu instance tidak cukup, kalian tidak harus memindahkan semuanya ke satu daemon besar. OpenVPN mendukung banyak instance dalam satu host, masing-masing dengan port atau protokol berbeda:

systemctl enable openvpn-server@udp1194
systemctl enable openvpn-server@tcp443
systemctl start openvpn-server@udp1194
systemctl start openvpn-server@tcp443

Instance udp1194 melayani client biasa via UDP, sementara tcp443 melayani client yang terjebak di belakang jaringan yang hanya mengizinkan HTTPS. Setiap instance punya file konfigurasi sendiri dan subnet sendiri, sehingga beban dan zona kegagalan dipisahkan.

#Manfaat Pemisahan

Memisahkan instance membawa tiga keuntungan: isolasi kegagalan — satu instance crash tidak menimpa yang lain, segmentasi kebijakan — instance berbeda bisa memakai CA dan kebijakan berbeda, dan linear scalability — kapasitas bertambah cukup dengan menambah instance.

Perlu dicatat bahwa setiap instance tetap harus dijaga dengan batas resource yang sama: max-clients diterapkan per instance, jadi total kapasitas adalah jumlah dari semua instance. Begitu pula monitoring harus mencakup semua instance, bukan hanya yang pertama — tema yang akan dibahas di episode 19.

#High Availability dan Load Balancing

#learn-address untuk Scripting Dinamis

Ketika banyak instance berbagi satu subnet VPN, konflik alamat antar instance bisa terjadi. Direktif learn-address memanggil script setiap kali alamat berubah:

learn-address /etc/openvpn/scripts/learn-address.sh

Script learn-address.sh menerima tiga argumen: operasi (add, update, delete), alamat, dan common name. Script ini sering dipakai untuk menyinkronkan tabel rute antar instance atau menolak alamat duplikat.

#Round-Robin DNS

Cara termurah untuk mendistribusikan client adalah DNS dengan banyak record A untuk satu nama:

vpn.example.com  A  203.0.113.10
vpn.example.com  A  203.0.113.11
vpn.example.com  A  203.0.113.12

Client yang melakukan lookup akan menerima alamat dalam urutan berbeda sehingga beban tersebar. Kekurangannya: DNS round-robin tidak tahu kondisi server, jadi client bisa diarahkan ke server yang sedang bermasalah.

#Distribusi Cerdas di Level Application

Untuk distribusi yang sadar kondisi, taruh broker di depan banyak instance. learn-address dan management interface dari episode 8 bisa dipakai oleh broker untuk menolak redirect client ke server yang sehat. Kombinasi ini akan diperdalam di episode 17 tentang multi-server dan cluster.

#Penutup

Inti yang harus dibawa pulang:

• max-clients membatasi koneksi bersamaan per instance.
• connect-freq membatasi laju percobaan connect dari satu sumber.
• Rate limiting di level kernel melindungi proses handshake.
• Banyak instance memisahkan segmen dan zona kegagalan.
• learn-address menyinkronkan alamat antar instance lewat script.
• Round-robin DNS adalah load balancer paling sederhana.

Di episode 12 selanjutnya kita akan membahas configuration management dan automation — menulis konfigurasi berbasis template, hardening systemd unit, pola env-file untuk rahasia, sampai provisioning otomatis dengan Ansible dan script komunitas seperti openvpn-install.sh. Setelah episode ini, konfigurasi VPN kalian bisa direproduksi dengan satu perintah.