Belajar OpenVPN - Network Policy & Split Tunneling

#Pendahuluan

Episode 6 memperkenalkan routing, episode 15 menghubungkan jaringan antar kantor. Sekarang pertanyaannya lebih strategis: lalu lintas mana yang harus masuk tunnel, dan mana yang boleh langsung ke internet? Jawabannya adalah network policy, dan alat utamanya adalah split tunneling.

Episode 16 ini membahas dua sisi kebijakan jaringan. Sisi pertama adalah routing: memilih rute dengan push "route ...", membawa semua lalu lintas dengan redirect-gateway, dan selective routing dengan allow-pull-fqdn. Sisi kedua adalah DNS: mendistribusikan resolver dengan dhcp-option, dan mencegah kebocoran query DNS keluar dari tunnel.

Mengapa ini penting? Kebijakan yang salah tidak hanya memperlambat koneksi, tapi juga bisa membocorkan informasi sensitif. Konfigurasi DNS yang salah adalah celah umum yang membuat alamat situs yang seharusnya aman di dalam tunnel justru keluar ke internet.

#Split Tunneling dan Rute Selektif

#Kembali ke Konsep push

Split tunneling memberi setiap client pilihan rute yang dikendalikan dari server. Server menentukan rute mana yang didorong ke client lewat push "route ...". Client hanya melewati tunnel untuk subnet yang didorong:

push "route 10.10.0.0 255.255.255.0"
push "route 10.20.0.0 255.255.255.0"

Dengan konfigurasi ini, lalu lintas ke 10.10.0.0/24 dan 10.20.0.0/24 masuk tunnel, sementara akses internet tetap lewat jalur lokal. Konsekuensinya: server tidak melihat lalu lintas internet client, dan bandwidth server tidak tersedot oleh browsing.

#Kelebihan dan Kekurangan Split

• Kelebihan: bandwidth server hemat, akses internet tetap cepat, dan isolasi antar jaringan lebih bersih.
• Kekurangan: lalu lintas internet client tidak diproteksi, dan kebijakan keamanan perusahaan sulit diterapkan di luar tunnel.
• Kompromi: split tunneling selektif untuk subnet internal ditambah kontrol internet di level yang lain.

#allow-pull-fqdn untuk Selective Routing

Secara default, direktif route di sisi client hanya menerima alamat IP. Ketika ingin mendefinisikan rute berdasarkan hostname — misalnya FQDN dari layanan internal — client perlu mengizinkan pull FQDN:

allow-pull-fqdn

allow-pull-fqdn membuat client mau menerima route yang membawa nama host, bukan sekadar alamat. FQDN tersebut akan di-resolve ke IP saat rute dipasang. Ini berguna ketika IP layanan internal berubah namun hostname tetap stabil.

#Full Tunneling dengan redirect-gateway

#Mengirim Semua Lalu Lintas ke Tunnel

Kebalikan dari split tunneling adalah full tunneling: seluruh lalu lintas client — termasuk internet — masuk tunnel. Server mengaktifkannya dengan push "redirect-gateway def1":

push "redirect-gateway def1"

push "redirect-gateway def1" menambahkan dua rute default di tabel client yang mengarah ke tunnel. Rute def1 menggunakan alamat 0.0.0.0/1 dan 128.0.0.0/1 untuk meniru rute default tanpa mengesampingkan rute lokal yang sudah ada.

#Konsekuensi Full Tunneling

Dengan full tunneling, server melihat seluruh lalu lintas client — cocok untuk kebijakan keamanan perusahaan dan untuk menyembunyikan aktivitas client dari ISP lokal. Biayanya: seluruh bandwidth client masuk server, dan latensi ke situs publik bertambah karena melewati hop ekstra.

#Verifikasi Rute Default

Untuk memastikan semua lalu lintas benar-benar lewat tunnel, periksa tabel routing client:

ip route show
ip route show table 0 | grep default

ip route show menampilkan rute utama. Rute default dengan gateway 10.8.0.1 menandakan lalu lintas keluar lewat tunnel. Jika masih ada rute default ke router lokal, lalu lintas tetap bocor ke internet.

#Konfigurasi DNS

#Mendistribusikan DNS dengan dhcp-option

Tunnel tidak hanya membutuhkan rute, tapi juga resolver DNS yang tepat. Server mendistribusikan resolver lewat push "dhcp-option DNS":

push "dhcp-option DNS 10.10.0.10"
push "dhcp-option DOMAIN corp.example"

push "dhcp-option DNS 10.10.0.10" memberitahu client memakai 10.10.0.10 sebagai resolver, yang hanya bisa dijangkau lewat tunnel. dhcp-option DOMAIN menambahkan sufiks pencarian sehingga hostname internal di-resolve dengan domain otomatis.

#Mencegah DNS Leak di Linux

Setelah rute default masuk tunnel, query DNS biasanya ikut masuk. Tapi di beberapa sistem, resolver yang dikonfigurasi manual bisa mengirim query langsung ke internet. Cara paling andal: pastikan resolver yang aktif hanya yang didorong server, dan periksa dengan tool seperti resolvectl:

resolvectl status

resolvectl status menampilkan DNS server yang sedang aktif per interface. Pastikan interface tun0 memakai resolver dari server dan tidak ada aturan yang mengirim query DNS keluar dari tunnel.

#block-outside-dns untuk Windows

Windows punya masalah khusus: browser bisa melewati VPN dan mengirim query DNS ke resolver lama. OpenVPN menyediakan direktif khusus untuk menutup celah ini:

block-outside-dns

block-outside-dns menginstal filter di Windows yang memblokir query DNS yang tidak lewat interface tunnel. Direktif ini aman ditambahkan di client.ovpn karena di Linux dan macOS akan diabaikan dengan warning.

#Memilih Kebijakan yang Tepat

#Pola yang Umum Dipakai

• Remote worker individu: split tunneling — hanya subnet kantor yang masuk tunnel.
• Kebijakan kepatuhan ketat: full tunneling — semua lalu lintas diaudit server.
• Site-to-site: tidak ada default redirect; hanya subnet partner yang dirutekan.

#Menguji Kebijakan

Setiap perubahan kebijakan harus diuji di kedua arah: pastikan layanan internal terjangkau, dan pastikan apa yang seharusnya keluar tetap keluar. Kombinasikan ip route show untuk routing dan resolvectl status untuk DNS, lalu catat hasilnya sebagai baseline.

#Penutup

Inti yang harus dibawa pulang:

• push "route ..." membuat split tunneling selektif dari sisi server.
• allow-pull-fqdn mengizinkan rute berbasis hostname di client.
• redirect-gateway def1 mengirim seluruh lalu lintas ke tunnel.
• dhcp-option DNS dan DOMAIN mendistribusikan resolver dan sufiks.
• DNS leak dicegah dengan memastikan resolver hanya dari tunnel.
• block-outside-dns menutup celah query DNS di Windows.

Di episode 17 selanjutnya kita akan membahas multi-server dan cluster — menjalankan banyak instance OpenVPN untuk segmentasi dan skala, scripting learn-address untuk sinkronisasi alamat, sampai high availability dengan keepalived dan HAProxy di depan banyak server. Setelah episode ini, infrastruktur VPN kalian siap melayani banyak region.