Belajar WireGuard - NAT Traversal & Endpoint Discovery

#Pendahuluan

Banyak perangkat yang ingin saling terhubung lewat WireGuard berada di belakang NAT — laptop di rumah, server di kantor, atau node di jaringan seluler. NAT mengubah alamat sumber dan port, sehingga alamat yang terlihat dari luar berbeda dari alamat asli perangkat. Bagaimana WireGuard tetap menemukan jalannya?

Jawabannya ada pada sifat UDP dan desain WireGuard: endpoint tidak pernah dianggap permanen, dan selalu bisa dipelajari ulang. Episode 7 membedah mekanisme endpoint discovery, UDP hole punching, dan PersistentKeepalive sebagai pemelihara koneksi di balik NAT.

Kunci untuk memahami episode ini adalah menerima bahwa WireGuard tidak pernah mempercayai alamat tetap. Selama kriptografi valid, alamat sumber adalah fakta yang bisa dipelajari ulang kapan saja — dan inilah yang membuat NAT traversal terasa hampir ajaib.

#NAT Traversal dalam WireGuard

#Kenapa UDP Menjadi Kunci

WireGuard berjalan di atas UDP. Tidak seperti TCP, UDP tidak punya konsep koneksi yang harus dijaga oleh stack. Ini memungkinkan WireGuard menangani setiap paket secara independen dan mempelajari alamat asal paket kapan pun dibutuhkan. Sifat inilah yang membuat NAT traversal terasa mudah dibandingkan VPN berbasis TCP.

Tambahan lagi, karena UDP tanpa status, kalian tidak perlu mengelola connection state seperti di TCP. Ini menyederhanakan konfigurasi server yang melayani banyak client sekaligus, karena setiap paket dihitung terhadap peer yang sama dengan cara yang seragam.

#Mempelajari Endpoint Secara Dinamis

Field Endpoint di [Peer] hanyalah petunjuk awal. Ketika sebuah paket valid tiba dari suatu peer, WireGuard otomatis memperbarui endpoint-nya dengan alamat sumber paket tersebut. Artinya, peer di belakang NAT bisa berpindah-pindah IP dan WireGuard akan mengikutinya selama peer tersebut mengirim paket lebih dulu.

Perilaku ini juga menjelaskan kenapa kalian jarang perlu memperbarui Endpoint secara manual ketika client berpindah jaringan: begitu client mengirim paket, WireGuard di server mencatat alamat baru dan langsung memakainya. Episode 19 akan memanfaatkan sifat ini untuk failover.

sudo wg show wg0

Pada output wg show wg0, kolom endpoint menampilkan alamat yang sedang dipakai. Jika alamat itu berbeda dari Endpoint di file konfigurasi, itu bukti endpoint discovery bekerja.

Endpoint yang berubah-ubah juga menjadi petunjuk diagnostik yang berharga. Jika endpoint selalu berganti saat client berpindah jaringan, itu hal yang wajar; jika tidak pernah berganti padahal client berpindah, kemungkinan paket keepalive tidak berhasil keluar.

#UDP Hole Punching

#Membuat Lubang di NAT

Ketika dua perangkat sama-sama berada di belakang NAT, masing-masing hanya bisa dijangkau dari luar melalui mapping yang dibuat NAT saat mereka mengirim paket keluar. Strateginya: kedua sisi mengirim paket ke alamat yang diketahui lebih dulu, sehingga setiap NAT mencatat mapping keluar, dan paket yang masuk lewat mapping itu diteruskan.

Inilah yang disebut UDP hole punching. WireGuard mendukung pola ini karena sifat UDP-nya yang tanpa status. Agar berhasil, idealnya salah satu NAT bersifat normal (bukan symmetric), dan kedua perangkat tahu alamat yang bisa dijangkau dari luar.

Hole punching bekerja paling baik ketika perangkat sudah pernah mengirim paket ke tujuan, sehingga mapping keluar sudah terbentuk. Karena itu, dalam skenario dua sisi di belakang NAT, biasanya salah satu sisi menginisiasi koneksi lebih dulu dan sisi lain menunggu paket pertama masuk.

#Keterbatasan NAT yang Ketat

Pada NAT symmetric, mapping keluar dibedakan per tujuan. Dua perangkat di belakang NAT symmetric hampir mustahil saling terhubung tanpa bantuan. Untuk kasus ini, minimal satu sisi harus dapat dijangkau langsung — biasanya server dengan alamat publik atau port forwarding. Itu sebabnya hampir semua deployment WireGuard menempatkan server di alamat publik.

Prinsip desain yang perlu kalian ingat: NAT traversal bukan tujuan utama WireGuard, melainkan efek samping dari desainnya yang berbasis UDP. Inilah mengapa WireGuard tetap sederhana meskipun menghadapi jaringan yang rumit.

#PersistentKeepalive

#Menjaga Mapping Tetap Hidup

NAT mapping biasanya kedaluwarsa setelah beberapa puluh detik hingga beberapa menit tanpa trafik. Jika kalian diam, mapping bisa hilang dan server tidak bisa lagi menjangkau client. Solusinya: kirim paket keepalive secara berkala.

[Peer]
PublicKey = <kunci publik server>
Endpoint = 203.0.113.5:51820
PersistentKeepalive = 25

Nilai 25 detik adalah rekomendasi standar untuk client di belakang NAT: cukup sering untuk menjaga mapping sebagian besar NAT, dan cukup hemat untuk baterai perangkat seluler.

sudo wg set wg0 peer <PUBLIK_SERVER> persistent-keepalive 25

Perintah wg set wg0 peer ... persistent-keepalive 25 mengubah keepalive tanpa mematikan interface. Nilai nol menonaktifkan keepalive.

Keepalive tidak mengganggu transfer normal: paket keepalive hanya berukuran kecil dan dihitung terpisah dari trafik data. Karena itu, memakainya di hampir semua sisi yang berada di belakang NAT adalah keputusan yang aman.

#Kapan Keepalive Tidak Diperlukan

Jika peer berada di alamat publik dan selalu aktif menerima trafik masuk, PersistentKeepalive tidak wajib. Namun memakainya tetap tidak berbahaya — hanya menambah beberapa paket kecil per menit. Sebagai aturan praktis: pasang PersistentKeepalive = 25 di sisi yang berada di belakang NAT.

Satu hal lain yang perlu diperhatikan: nilai keepalive yang terlalu besar membuat mapping NAT bisa kedaluwarsa di antara dua kiriman, sementara nilai yang terlalu kecil hanya membuang bandwidth. Dua puluh lima detik adalah titik tengah yang sudah terbukti baik di lapangan.

#Skema Koneksi yang Umum

#Client di Belakang NAT, Server di Alamat Publik

Skema paling standar untuk remote access:

• Server: alamat publik, ListenPort = 51820 dibuka di firewall.
• Client: di belakang NAT, Endpoint menunjuk server, PersistentKeepalive = 25.

Jika memakai pola ini, kalian juga perlu mencatat bahwa alamat Endpoint di file konfigurasi client boleh berupa hostname yang diselesaikan DNS. Jika alamat publik server berubah, kalian hanya perlu mengubah record DNS, tanpa menyentuh konfigurasi client.

Dengan skema ini, client selalu bisa dijangkau server setelah keepalive pertama, dan server selalu bisa dijangkau client lewat endpoint tetapnya. Kombinasi inilah yang dipakai mayoritas deployment WireGuard di dunia nyata.

Dengan pola ini, kalian juga mendapat keuntungan observability sederhana: wg show di server selalu menampilkan endpoint client yang sedang aktif, sehingga perubahan jaringan client langsung terlihat tanpa perlu bertanya kepada pengguna.

Terakhir, jangan lupa menguji skenario pindah jaringan secara nyata: ganti dari Wi-Fi ke hotspot seluler dan amati berapa lama tunnel kembali hidup. Hasil pengamatan ini menjadi bukti bahwa konfigurasi NAT traversal kalian benar.

#Penutup

Episode 7 menuntaskan topik NAT traversal: WireGuard mempelajari endpoint secara dinamis dari paket yang masuk, UDP hole punching memungkinkan dua sisi di balik NAT saling bicara, dan PersistentKeepalive menjaga mapping tetap hidup.

Inti yang harus dibawa pulang:

• Endpoint adalah petunjuk awal; endpoint nyata dipelajari dari paket masuk.
• WireGuard berjalan di UDP sehingga tanpa status dan ramah NAT.
• UDP hole punching berhasil bila setidaknya satu NAT tidak symmetric.
• PersistentKeepalive = 25 menjaga mapping client di belakang NAT.
• Skema standar: server di alamat publik, client memakai keepalive.

Di episode 8 selanjutnya kita membahas tools dan monitoring — perintah wg dan wg-quick secara lengkap, membaca wg show wg0 latest-handshakes dan transfer, serta membuat skrip bash untuk health check tunnel.