Belajar OpenVPN - Control Channel & Data Channel

#Pendahuluan

Dalam episode 2, kalian diperkenalkan dengan konsep control channel dan data channel. Episode 6 menjelaskan ke mana paket dikirim. Sekarang saatnya memahami bagaimana dua jalur komunikasi itu bekerja sampai ke level protokol.

Pembagian tugasnya jelas: control channel menangani semua negosiasi — siapa kalian, cipher apa yang dipakai, dan kunci sesi apa yang disepakati. Sementara data channel menangani beban lalu lintas — HTTP, SSH, database — yang sudah dienkripsi dan dibungkus. Keduanya berjalan di atas satu koneksi UDP atau TCP yang sama, dipisahkan oleh bit penanda dalam header.

Episode 7 ini membahas parameter yang mengendalikan kedua jalur tersebut. Kalian akan memahami direktif tls-version-min, tls-cipher, dan remote-cert-tls untuk control channel, lalu cipher, auth, dan ncp-ciphers untuk data channel. Ini fondasi yang akan dimatangkan di episode 13 tentang hardening.

#Control Channel

#Alur TLS Handshake di OpenVPN

Ketika client pertama kali connect, yang terjadi adalah sebuah TLS handshake di dalam control channel. Client dan server bertukar sertifikat, memverifikasi tanda tangan CA, menyepakati versi TLS, dan menghasilkan kunci sesi. Semua ini terjadi sebelum satu byte data VPN dikirim.

OpenVPN membungkus handshake ini dalam paket-paket datagramnya sendiri. Karena UDP tidak menjamin urutan, OpenVPN menangani retransmisi paket handshake di lapisan atasnya. Ini alasan mengapa verb tinggi pada log menunjukkan urutan lengkap handshake meskipun jalurnya UDP.

#Renegotiation dan Rotasi Kunci

Handshake tidak berhenti di koneksi pertama. Secara default OpenVPN melakukan renegotiation secara periodik untuk memutar kunci data. Ini menjaga forward secrecy: jika kunci sesi bocor, dampaknya terbatas pada jendela waktu singkat, bukan seluruh sesi.

Frekuensi renegotiation diatur dengan reneg-sec. Nilai defaultnya 3600 detik. Untuk environment yang menuntut keamanan lebih ketat, nilai bisa diturunkan:

reneg-sec 1800

reneg-sec 1800 memaksa kunci sesi berganti setiap 30 menit. Trade-offnya: renegotiation memakan sedikit CPU dan bisa terasa saat koneksi sedang padat, jadi jangan menurunkannya tanpa alasan.

#tls-version-min dan tls-cipher

Untuk memaksa versi TLS minimal dan daftar cipher yang diizinkan, pakai tls-version-min dan tls-cipher:

tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

tls-version-min 1.2 menolak handshake di bawah TLS 1.2, sekaligus menyumbang kepatuhan terhadap pedoman RFC 7525. tls-cipher membatasi suite cipher TLS yang boleh dinegosiasikan. Satu baris ini saja bisa menolak klien lama yang menggunakan cipher lemah.

#remote-cert-tls server

Direktif remote-cert-tls server di sisi client memastikan bahwa sertifikat yang diterima memang sertifikat server, bukan sembarang sertifikat yang kebetulan ditandatangani CA yang sama. Ini mencegah serangan di mana penyerang dengan sertifikat client mencoba menyamar sebagai server.

remote-cert-tls server

#Data Channel

#cipher dan auth

Setelah handshake selesai, lalu lintas aktual dienkripsi di data channel. Enkripsi dilakukan dengan algoritma yang disepakati lewat direktif cipher, dan integritasnya dijaga dengan HMAC dari direktif auth:

cipher AES-256-GCM
auth SHA256
ncp-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305

cipher AES-256-GCM memakai enkripsi authenticated encryption dengan mode GCM yang sekaligus menjamin kerahasiaan dan integritas. auth SHA256 tetap dipertahankan untuk kompatibilitas, meskipun cipher GCM sudah membawa otentikasi sendiri.

#ncp-ciphers: Negosiasi Cipher

Sejak OpenVPN 2.4, daftar cipher yang boleh dinegosiasikan diatur lewat NCP (Negotiable Crypto Parameters). Direktif ncp-ciphers di server menentukan daftar preferensi yang ditawarkan ke client:

ncp-ciphers AES-256-GCM:CHACHA20-POLY1305:AES-128-GCM

Server akan memilih cipher pertama yang juga didukung client. Urutan dalam daftar adalah urutan prioritas, jadi letakkan cipher terkuat di paling depan. Jika client tidak mendukung NCP, fallback ke cipher yang dideklarasikan.

#Memahami Pilihan Cipher

• AES-256-GCM: standar industri, didukung perangkat keras pada hampir semua CPU modern, dan didukung luas di semua platform.
• ChaCha20-Poly1305: pilihan ketika CPU tidak punya akselerasi AES, misalnya perangkat ARM tanpa instruksi AES. Performanya konsisten tanpa dukungan hardware.
• AES-128-GCM: kecepatan lebih tinggi dengan keamanan yang masih memadai untuk kebutuhan umum.

GCM dan ChaCha20 sama-sama authenticated encryption, jadi keduanya kebal terhadap serangan padding oracle yang menimpa cipher mode CBC lama. Untuk praktik keamanan modern, hindari cipher mode CBC di deployment baru.

#Melihat Dua Channel dalam Aksi

#Log dengan verb 4

Cara paling mudah melihat kedua channel bekerja adalah lewat log dengan tingkat verbosity 4:

openvpn --config client.ovpn --verb 4

Log akan menampilkan fase TLS: Initial packet from ... untuk control channel, lalu Peer Connection Initiated setelah handshake sukses, dan akhirnya Initialization Sequence Completed ketika data channel siap. Memahami urutan log ini sangat membantu saat troubleshooting di episode 8.

#Verifikasi Kunci Sesi Aktif

Untuk melihat detail negosiasi sesi, aktifkan verb 5 dan amati blok Data Channel: cipher ... serta Control Channel: TLSv1.3, cipher ... di dalam log. Informasi ini menunjukkan cipher yang benar-benar terpilih setelah negosiasi, bukan sekadar yang dikonfigurasi.

#Penutup

Inti yang harus dibawa pulang:

• Control channel menangani TLS handshake dan renegotiation.
• tls-version-min dan tls-cipher membatasi negosiasi TLS.
• remote-cert-tls server memverifikasi peran sertifikat server di sisi client.
• Data channel memakai cipher dan ncp-ciphers untuk enkripsi lalu lintas.
• AES-256-GCM dan ChaCha20-Poly1305 adalah pilihan modern yang direkomendasikan.
• reneg-sec mengatur rotasi kunci sesi dan menjaga forward secrecy.

Di episode 8 selanjutnya kita akan membahas logging, monitoring, dan troubleshooting — cara membaca status dan file log, mengaktifkan management interface untuk inspeksi runtime, menganalisis kegagalan TLS handshake, dan memakai tcpdump serta --verb 6 untuk melacak masalah sampai ke level paket. Setelah episode ini, kalian punya alat untuk men-debug hampir semua gangguan VPN.