Belajar OpenVPN - Performance Tuning & Benchmarking

#Pendahuluan

DCO dari episode 14 menaikkan batas atas throughput. Tapi DCO saja tidak cukup — banyak faktor lain yang menentukan berapa Mbps yang benar-benar kalian dapatkan. Buffer yang terlalu kecil, MTU yang tidak pas, atau konfigurasi default yang tidak cocok dengan jaringan bisa membuat angka performa jauh di bawah potensi.

Episode 18 ini membahas performance tuning dan benchmarking. Kalian akan belajar menyesuaikan buffer dengan sndbuf dan rcvbuf, mengatur antrean dengan txqueuelen, memutar sekitar MTU dengan tun-mtu, fragment, dan mssfix, lalu membuktikan hasilnya dengan iperf3.

Prinsip utamanya: jangan pernah mengubah parameter tanpa pengukuran. Benchmark dulu, ubah satu variabel, ukur lagi. Hanya dengan cara itu kalian tahu perubahan mana yang benar-benar berdampak.

#Tuning Buffer dan Antrean

#sndbuf dan rcvbuf

Buffer kernel menentukan berapa banyak data yang bisa menunggu sebelum diproses. sndbuf mengatur buffer pengiriman, rcvbuf buffer penerimaan. Nilai default kernel sering terlalu kecil untuk VPN berkecepatan tinggi:

sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

sndbuf 393216 dan rcvbuf 393216 menaikkan buffer menjadi 384 KB. Bagian push penting: nilai di sisi server dan client harus selaras, karena kecepatan dibatasi sisi yang paling lambat.

#txqueuelen pada Interface Tun

Antrean transmisi interface tun0 mempengaruhi seberapa banyak paket yang bisa diproses sekaligus. Jika antrean terlalu pendek, paket dibuang dan TCP harus mengirim ulang — performa menukik:

ip link set tun0 txqueuelen 1000

ip link set tun0 txqueuelen 1000 menaikkan panjang antrean. Nilai ini tidak persisten setelah reboot; untuk permanen, jalankan lewat systemd unit atau masukkan ke dalam skrip setup interface.

#Tuning MTU

#Memahami MTU dan MSS

Setiap paket tunnel punya dua lapisan ukuran: MTU tunnel yang terlihat aplikasi, dan paket fisik yang lewat internet. Jika paket fisik melebihi MTU jalur, paket dipecah atau dibuang. Ketidakcocokan inilah sumber klasik masalah performa dan koneksi terputus.

#tun-mtu dan mssfix

Direktif tun-mtu mengatur MTU yang diiklankan ke dalam tunnel, dan mssfix menyesuaikan ukuran segmen TCP agar muat di dalam batas:

tun-mtu 1400
mssfix 1360

tun-mtu 1400 mengurangi MTU tunnel dari default 1500 untuk memberi ruang header UDP dan enkapsulasi OpenVPN. mssfix 1360 memberitahu koneksi TCP di dalam tunnel untuk memakai segmen yang lebih kecil. Keduanya bekerja bersama untuk menghindari fragmentasi.

#Fragment Sebagai Cadangan

Untuk jalur yang tidak bisa diprediksi, fragment memecah paket di sisi pengirim. Ini menambah overhead dan umumnya hanya dipakai ketika mssfix tidak cukup — misalnya pada koneksi PPPoE yang MTU-nya tidak standar:

fragment 1300

fragment 1300 membuat paket yang lebih besar dipecah menjadi 1300 byte sebelum dikirim. Nilai ini harus lebih kecil atau sama dengan MTU fisik jalur. Mulailah dengan nilai aman dan turunkan hanya jika masalah persist.

#Menemukan MTU yang Benar

Cara paling akurat menemukan MTU: ukur path MTU dengan ping yang tidak terfragmentasi:

ping -M do -s 1400 8.8.8.8

ping -M do -s 1400 8.8.8.8 menguji paket 1400 byte tanpa fragmentasi. Naikkan ukuran sampai ping gagal; titik terakhir yang sukses menunjukkan MTU jalur. Informasi ini menjadi dasar nilai tun-mtu dan mssfix yang tepat.

#Benchmarking dengan iperf3

#Menyiapkan Server iperf3

Untuk mengukur throughput nyata tunnel, jalankan iperf3 dalam mode server di salah satu sisi tunnel:

iperf3 -s

iperf3 -s memulai server pengukuran. Jalankan di mesin yang bisa dijangkau lewat tunnel — idealnya di jaringan belakang server, sehingga pengukuran mencakup seluruh jalur VPN, bukan hanya link antara dua interface.

#Mengukur Throughput dari Client

Dari sisi client, jalankan iperf3 dalam mode client menuju alamat tunnel:

iperf3 -c 10.8.0.1 -t 30 -P 4

iperf3 -c 10.8.0.1 -t 30 -P 4 menguji throughput selama 30 detik dengan 4 aliran paralel. Uji dengan 1 aliran untuk melihat latensi TCP, dan banyak aliran untuk melihat throughput maksimum. Catat hasil keduanya sebagai baseline.

#Mengukur Latensi

Latensi diukur dengan ping ke alamat tunnel versus ping ke jaringan biasa:

ping -c 20 10.8.0.1
ping -c 20 8.8.8.8

ping -c 20 10.8.0.1 mengukur latensi tunnel; bandingkan dengan ping -c 20 8.8.8.8 untuk melihat overhead VPN. Overhead normal dalam orde milidetik. Latensi yang melonjak biasanya menandakan buffer yang terlalu besar atau jalur yang penuh.

#Proses Tuning yang Disiplin

#Satu Variabel, Satu Pengukuran

Ubah satu parameter, benchmark, lalu bandingkan. Mencoba banyak perubahan sekaligus membuat kalian tidak tahu mana yang berpengaruh. Simpan hasil dalam tabel sederhana: parameter, nilai, throughput, latensi. Rekomendasi di episode 18 ini hanyalah titik awal — jaringan kalian yang menentukan angka akhir.

#Menjaga Setting Default yang Aman

Jika tidak ada masalah performa yang terukur, jangan mengubah apa pun. Parameter tuning yang salah — terutama buffer terlalu besar — bisa membuat masalah baru: memori boros dan latensi membengkak. Benchmark adalah hakim terakhir.

#Penutup

Inti yang harus dibawa pulang:

• sndbuf dan rcvbuf harus selaras antara server dan client.
• txqueuelen mencegah paket dibuang pada interface tun.
• tun-mtu dan mssfix bekerja bersama untuk menghindari fragmentasi.
• fragment dipakai hanya untuk jalur dengan MTU yang sulit diprediksi.
• iperf3 mengukur throughput nyata lewat tunnel.
• Ubah satu variabel dan ukur ulang sebelum mengganti yang lain.

Di episode 19 selanjutnya kita akan membahas observability dan monitoring — memanfaatkan openvpn-status.log sebagai sumber metrik, mengekspos data ke Prometheus dengan openvpn exporter, membangun dashboard Grafana, sampai alerting untuk deteksi koneksi putus dan peringatan kedaluwarsa sertifikat. Setelah episode ini, kondisi VPN kalian bisa dipantau dalam satu layar.