Belajar OpenVPN - Authentikasi: Sertifikat vs PSK vs Username/Password

#Pendahuluan

Setelah PKI berdiri di episode 4, pertanyaan berikutnya: bagaimana OpenVPN memverifikasi bahwa pihak di ujung sana memang yang kalian maksud? Jawabannya ada tiga lapis: sertifikat X.509 untuk identitas node, pre-shared key untuk mengamankan control channel, dan username/password untuk identitas pengguna.

Ketiganya tidak saling menggantikan — justru saling melengkapi. Deployment production yang baik memakai semuanya sekaligus. Episode 5 ini membahas cara kerja masing-masing, kapan memakainya, dan bagaimana menggabungkannya dalam satu konfigurasi.

#Mutual TLS dengan Sertifikat X.509

#Cara Kerja Mutual Authentication

Di HTTP biasa, hanya client yang memverifikasi identitas server. Di OpenVPN, verifikasinya dua arah: client memverifikasi sertifikat server, dan server memverifikasi sertifikat client. Keduanya harus ditandatangani oleh CA yang sama.

Inilah mengapa sertifikat yang tidak dikeluarkan oleh CA kalian otomatis ditolak. Kepercayaan diturunkan dari CA, bukan dari kata-kata.

#Direktif yang Terlibat

Di sisi client, direktif berikut mengaktifkan mutual TLS:

ca ca.crt
cert client1.crt
key client1.key
remote-cert-tls server

ca ca.crt menunjuk CA yang dipercaya, sedangkan remote-cert-tls server memastikan sertifikat server memenuhi kriteria khusus server. Kombinasi cert dan key adalah identitas client.

#Verifikasi Identitas Tambahan

Untuk mencegah sertifikat sah dari CA lain yang tidak kalian inginkan, tambahkan verify-x509-name:

verify-x509-name vpn.lab.example name-prefix

verify-x509-name vpn.lab.example name-prefix memastikan subject sertifikat server diawali nama tersebut. Detail lengkap hardening ini ada di episode 13.

#Pre-Shared Key: tls-auth, tls-crypt, tls-crypt-v2

Selain sertifikat, OpenVPN bisa menambahkan sebuah pre-shared key yang hanya diketahui node yang sah. Fungsinya dua macam: memfilter tamu sebelum TLS handshake dan mengenkripsi control channel.

#tls-auth: HMAC Firewall

tls-auth menempelkan HMAC pada setiap paket. Paket tanpa HMAC yang benar langsung dibuang, sehingga probe acak di port 1194 tidak sampai menghabiskan resource handshake:

openvpn --genkey secret ta.key

Tambahkan tls-auth ta.key 0 di server dan tls-auth ta.key 1 di client. Angka 0 dan 1 menunjukkan arah — server selalu 0, client selalu 1.

#tls-crypt: Enkripsi Control Channel

tls-crypt mengambil langkah lebih jauh: selain memfilter, dia juga mengenkripsi seluruh control channel. Ini menyembunyikan metadata seperti sertifikat dan negosiasi dari pengamat jaringan.

tls-crypt ta.key

Direktif yang sama ditulis di server dan client tanpa angka arah, karena tls-crypt sudah menangani arah secara otomatis.

#tls-crypt-v2: Key per Client

tls-crypt-v2 adalah evolusi terbaru: setiap client mendapat key pre-shared yang berbeda, diturunkan dari sebuah server key master:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/server/server-crypt.key
openvpn --genkey tls-crypt-v2-client --tls-crypt-v2 /etc/openvpn/server/server-crypt.key client-crypt.key

openvpn --genkey tls-crypt-v2-server membuat master key server, dan versi client menghasilkan key spesifik per client. Keunggulannya: kalau satu key client bocor, hanya client itu yang terdampak.

#Username/Password

#auth-user-pass

Untuk autentikasi berbasis identitas pengguna, aktifkan auth-user-pass di client dan tambahkan verifikasi di server:

# client.ovpn
auth-user-pass
 
# server.conf
plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn

Setiap kali connect, client diminta username dan password. Server memverifikasinya lewat PAM — yang bisa dipetakan ke LDAP, RADIUS, atau basis data lokal.

#verify dan Script Eksternal

Untuk logika verifikasi khusus, OpenVPN memanggil script --auth-user-pass-verify dengan mode via-env atau via-file. Script ini bisa mengecek keanggotaan grup, status akun, atau kebijakan organisasi.

auth-user-pass-verify /etc/openvpn/check-user.sh via-env
script-security 2

script-security 2 wajib diaktifkan agar script eksternal boleh dijalankan. Penjelasan lebih lanjut tentang integrasi LDAP dan RADIUS ada di episode 10.

#auth-gen-token untuk Session Management

Ketika verifikasi memakai layanan eksternal yang lambat, jangan verifikasi setiap reconnect:

auth-gen-token 3600

auth-gen-token 3600 membuat server mengeluarkan token sesi berumur 3600 detik setelah verifikasi pertama berhasil. Reconnect selama masa token tidak perlu memanggil layanan autentikasi lagi.

#Menggabungkan Semua Lapisan

#Arsitektur Defense-in-Depth

Konfigurasi production menggabungkan ketiganya. Ilustrasi di server:

ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt-v2 server-crypt.key
auth-user-pass-verify /etc/openvpn/check-user.sh via-env
script-security 2
auth-gen-token 3600

Alurnya: HMAC tls-crypt-v2 memfilter probe, sertifikat mengautentikasi node, lalu username/password mengautentikasi pengguna, dan token sesi mencegah verifikasi berulang yang mahal.

#Memilih Kombinasi yang Tepat

• Lab pribadi: sertifikat + tls-crypt sudah memadai.
• Perusahaan: sertifikat + tls-crypt-v2 + username/password via PAM/LDAP.
• Kebutuhan kepatuhan tinggi: tambahkan MFA seperti yang dibahas di episode 10.

#Penutup

Inti yang harus dibawa pulang:

• Mutual TLS memakai sertifikat X.509 yang ditandatangani CA yang sama.
• tls-auth memfilter paket; tls-crypt mengenkripsi control channel.
• tls-crypt-v2 memberi setiap client pre-shared key yang berbeda.
• auth-user-pass memindahkan autentikasi ke identitas pengguna via PAM/LDAP/RADIUS.
• auth-gen-token mengurangi panggilan autentikasi berulang pada reconnect.
• Kombinasi ketiganya membentuk defense-in-depth untuk production.

Di episode 6 selanjutnya kita akan membahas routing dan IP forwarding — cara kerja mode tun yang dirutekan, distribusi route ke client dengan push dan iroute, bridging dengan mode tap, sampai NAT dengan iptables. Setelah episode ini, kalian bisa mengarahkan lalu lintas ke subnet mana pun lewat tunnel.