Episode ini membahas perjalanan paket di dalam tunnel: distribusi route ke client lewat push, subnetting per client dengan iroute, perbedaan mode tun dan tap, hingga IP forwarding dan NAT dengan iptables agar client bisa mengakses jaringan luar.

Episode 5 menuntaskan lapisan autentikasi. Sekarang paket sudah bisa masuk ke tunnel, dan pertanyaan berikutnya adalah: ke mana paket itu dikirim? Jawabannya ada di routing. OpenVPN pada dasarnya adalah router virtual: ia menerima paket dari client, mencari rute tujuan, lalu meneruskannya ke jaringan di belakang server.
Episode 6 ini membedah tiga hal. Pertama, bagaimana server mendistribusikan rute ke client lewat direktif push. Kedua, perbedaan mendasar antara mode tun yang dirutekan dan mode tap yang dibridge. Ketiga, bagaimana server bisa menjadi gateway sehingga client mencapai internet, yaitu lewat IP forwarding dan NAT.
Mengapa episode ini penting? Karena hampir semua masalah VPN di lapangan — client connect tapi tidak bisa akses internet, atau ping ke subnet belakang gagal — berakar pada routing dan NAT yang salah. Setelah episode ini, kalian tahu persis apa yang harus dicek ketika lalu lintas tidak mengalir.
Mode tun bekerja di layer 3: paket dirutekan berdasarkan alamat IP, bukan frame layer 2. Ini adalah mode paling umum untuk remote access karena efisien dan tidak perlu konfigurasi broadcast. Setiap client mendapat alamat dari subnet virtual yang dikelola server.
Konfigurasi server paling dasar untuk mode tun:
port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
topology subnet
push "route 10.10.0.0 255.255.255.0"Direktif server 10.8.0.0 255.255.255.0 membuat subnet virtual 10.8.0.0/24. Server mengambil 10.8.0.1 sebagai gateway, lalu mengalokasikan alamat ke client. Baris topology subnet membuat semua client berada dalam satu subnet yang sama sehingga bisa saling ping.
Rute di sisi client bisa ditulis manual, tapi cara yang benar adalah didorong dari server. Direktif push "route ..." membuat client menambahkan rute ke tabel routing lokalnya begitu tunnel naik.
push "route 10.10.0.0 255.255.255.0" memberitahu client: untuk menjangkau jaringan LAN 10.10.0.0/24 di belakang server, gunakan tunnel. Tanpa baris ini, client hanya bisa menjangkau alamat di dalam subnet VPN 10.8.0.0/24.
Sebelum OpenVPN 2.5, mode tun memakai topology net30 sebagai default — setiap client mendapat titik alamat yang dipisahkan, meniru sambungan point-to-point klasik. Skema ini boros alamat dan merepotkan dalam audit. topology subnet jauh lebih praktis karena semua client berbagi subnet yang sama.
Pada topology p2p, server dan client hanya melihat sepasang alamat tanpa konsep subnet. Mode ini dipakai untuk koneksi site-to-site sederhana dan akan dibahas lagi di episode 15.
Ketika sebuah client harus mewakili jaringan lokal di belakangnya, kalian tidak cukup dengan push "route ..." saja. Server juga harus tahu bahwa subnet milik client tertentu bisa dijangkau lewat tunnel client itu. Inilah pekerjaan iroute.
iroute dideklarasikan di dalam file per-client yang dipetakan lewat client-config-dir. Contoh untuk client bernama site-b:
iroute 192.168.10.0 255.255.255.0
ifconfig-push 10.8.0.10 10.8.0.9Baris iroute 192.168.10.0 255.255.255.0 memberitahu server: subnet 192.168.10.0/24 hanya bisa dijangkau melalui client site-b. Sementara ifconfig-push memberi client alamat tetap di dalam subnet VPN. Detail lengkap client-config-dir ada di episode 9.
Pola umum untuk koneksi site-to-site: iroute di sisi server memberi tahu cara menjangkau subnet client, sedangkan push "route ..." di sisi server memberi tahu client cara menjangkau subnet server. Kedua arah harus didefinisikan agar lalu lintas mengalir dua arah.
Mode tap bekerja di layer 2: client bergabung ke jaringan yang sama dengan server, seolah-olah mereka terhubung ke switch yang sama. Broadcast dan protokol yang bergantung pada layer 2, seperti ARP dan DHCP, ikut bekerja normal di dalam tunnel.
Kelebihan ini sekaligus jadi kelemahan: lalu lintas broadcast ikut masuk tunnel sehingga performanya lebih rendah. Mode tap hanya direkomendasikan ketika aplikasi memang membutuhkan layer 2, misalnya game berbasis broadcast atau mesin produksi yang bergantung pada protokol non-IP.
Bridging di OpenVPN dilakukan dengan server-bridge. Server terlebih dahulu membuat jembatan dengan brctl:
brctl addbr br0
brctl addif br0 eth0
ip addr add 192.168.1.10/24 dev br0
ip link set br0 upLalu di server.conf:
dev tap
server-bridge 192.168.1.10 255.255.255.0 192.168.1.100 192.168.1.200server-bridge menerima empat argumen: IP jembatan, netmask, alamat awal pool, dan alamat akhir pool. Client di pool ini tampak seperti host biasa di jaringan 192.168.1.0/24.
tun untuk remote access, site-to-site, dan hampir semua kebutuhan VPN modern.tap untuk koneksi yang membutuhkan broadcast dan protokol layer 2.tun lebih cepat, lebih aman, dan jauh lebih mudah ditroubleshoot.Agar server bisa meneruskan paket dari tunnel ke jaringan lain, kernel Linux harus diizinkan melakukan forwarding. Tanpa ini, paket yang masuk dari client hanya berhenti di server dan tidak pernah sampai ke tujuannya.
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -psysctl -p menerapkan konfigurasi tanpa perlu reboot. Nilai ini harus bernilai 1 di server, karena server bertindak sebagai router antara tunnel dan jaringan luar.
Mengaktifkan forwarding saja belum cukup. Agar client bisa mencapai internet, server juga harus melakukan masquerade — menyamarkan alamat client menjadi alamat server ketika paket keluar ke jaringan publik:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPTAturan pertama mengganti source address paket client dengan alamat publik server. Dua aturan berikutnya mengizinkan paket bolak-balik antara tun0 dan eth0. Untuk memastikan aturan bertahan setelah reboot, simpan dengan iptables-persistent atau turunkan lewat systemd.
Tidak semua lalu lintas client wajib lewat tunnel. Dengan split tunneling, kalian memilih rute mana yang masuk tunnel dan mana yang langsung ke internet. Server menentukan batasannya lewat direktif push:
push "route 10.10.0.0 255.255.255.0"
push "route 192.168.50.0 255.255.255.0"Dengan konfigurasi ini, lalu lintas ke 10.10.0.0/24 dan 192.168.50.0/24 melewati tunnel, sedangkan sisanya tetap lewat internet lokal. Kebalikannya — semua lalu lintas masuk tunnel — memakai push "redirect-gateway def1", yang akan dibandingkan detailnya di episode 16.
Inti yang harus dibawa pulang:
tun merutekan paket di layer 3; topology subnet adalah standar modern.push "route ..." mendistribusikan rute dari server ke client.iroute memberi tahu server cara menjangkau subnet di belakang sebuah client.tap memakai server-bridge dan brctl untuk bridging layer 2.net.ipv4.ip_forward=1.Di episode 7 selanjutnya kita akan membahas control channel dan data channel — bagaimana TLS handshake dan renegotiation bekerja, direktif tls-version-min, tls-cipher, dan remote-cert-tls untuk control channel, sampai pemilihan cipher seperti AES-256-GCM dan ChaCha20-Poly1305 untuk data channel. Setelah episode ini, kalian paham mengapa lalu lintas VPN aman dan bagaimana negosiasinya terjadi.