Belajar WireGuard - Handshake & Lifecycle

#Pendahuluan

Setiap paket data WireGuard berada di balik satu sesi, dan setiap sesi lahir dari proses yang disebut handshake. Memahami handshake berarti memahami mengapa koneksi pertama kali lambat beberapa milidetik, mengapa koneksi diam bisa "mati", dan bagaimana WireGuard bertahan dari serangan membanjiri paket handshake.

Episode 5 membedah mekanisme handshake Noise IK, mekanisme cookie sebagai tameng anti-DoS, kebijakan rekeying otomatis, serta peta transisi state sebuah sesi dari lahir sampai berakhir.

Sepanjang episode ini, ingatlah bahwa semua mekanisme ini berjalan otomatis di dalam kernel. Peran kalian hanyalah memastikan kondisi awal yang benar — kunci, endpoint, dan firewall — lalu membiarkan protokol menjaga dirinya sendiri.

#Noise IK Handshake

#Tiga Pesan, Satu Round-Trip

Handshake WireGuard hanya terdiri dari tiga pesan: handshake initiation (dari initiator), handshake response (dari responder), dan setelah itu kedua pihak sudah memiliki kunci sesi. Dari sudut pandang initiator ini adalah satu round-trip — tidak seperti TLS yang bisa memakan beberapa kali pertukaran.

Prosesnya dalam skema Noise IKpsk2:

• Initiator mengirim handshake initiation berisi kunci ephemeral publiknya.
• Responder memvalidasi, menghitung shared secret, dan membalas handshake response.
• Kedua pihak menurunkan kunci enkripsi data yang sama.
• Responder sudah bisa langsung mengirim data; initiator menunggu response.

wg show wg0 latest-handshakes

Output wg show wg0 latest-handshakes menampilkan waktu handshake terakhir dalam UNIX timestamp. Nilai nol berarti peer belum pernah handshake — biasanya karena endpoint salah atau port UDP tertutup.

#Packet Kehadiran

Setelah handshake, jika tidak ada data, WireGuard mengirim paket keepalive sekitar setiap 10 detik agar NAT mapping dan status sesi tetap segar. Keepalive ini tidak menghitung sebagai trafik transfer.

Keepalive ini bekerja sama dengan PersistentKeepalive yang dibahas di episode 7: keepalive internal menjaga status sesi protokol, sedangkan PersistentKeepalive menjaga mapping NAT agar sesi tetap bisa dijangkau dari luar.

#Mekanisme Cookie

#Anti-DoS pada Handshake

Handshake initiation dihitung dengan kriptografi kurva eliptik yang cukup mahal. Jika penyerang membanjiri server dengan handshake palsu, server bisa kelelahan. WireGuard meredamnya dengan mekanisme cookie.

Caranya: server meminta responder memberi cookie (nilai MAC yang diturunkan dari alamat IP tujuan) sebelum menerima handshake berikutnya. Karena cookie diikat ke alamat IP, penyerang yang memalsukan alamat tidak bisa menyelesaikan handshake. Mekanismenya efisien: tanpa perlu menyimpan state sesi per pemohon.

#Kapan Cookie Muncul

Cookie muncul ketika server berada di bawah tekanan handshake yang tinggi atau ketika tabel peer penuh. Ketika kalian melihat pesan Handshake was rate limited di log, itulah mekanisme cookie sedang bekerja.

Penting: mekanisme cookie bukan proteksi terhadap semua serangan DoS, melainkan peredam khusus untuk banjir handshake. Ini sesuai filosofi WireGuard — fokus pada satu masalah dan menyelesaikannya dengan baik.

Satu catatan praktis: umur handshake bukan satu-satunya indikator kesehatan. Kombinasi antara latest-handshakes dan transfer yang terus bertambah memberi gambaran lebih lengkap, dan keduanya akan dipakai sebagai dasar monitoring di episode 8 dan 21.

#Rekeying dan State Transitions

#Rekeying Otomatis

Kunci sesi tidak dipakai selamanya. WireGuard mengganti kunci secara otomatis:

• Berbasis waktu: rekey sekitar setiap 2 menit per arah.
• Berbasis volume: rekey setelah sejumlah besar paket terkirim.
• Berbasis idle: ketika sesi terlalu lama tidak aktif, kunci dibuang dan handshake berikutnya memulai dari awal.

Rekeying menjaga forward secrecy — bocornya satu kunci sesi tidak membuka sesi yang lain.

#Peta State Sesi

Sesi WireGuard bergerak melalui state sederhana:

• empty: belum ada handshake, kunci sesi kosong.
• handshake-initiation-sent: initiator sudah mengirim permintaan, menunggu response.
• handshake-complete: response valid, kunci sesi aktif, data bisa mengalir.
• data-received: sesi mengirim dan menerima data terenkripsi.
• timeout / rekey: sesi menua, kunci diganti, atau sesi ditutup kembali ke empty.

Transisi ini terjadi otomatis di kernel. Kalian tidak mengatur state ini secara manual — yang kalian amati hanyalah latest-handshakes dan hasil wg show.

#Mendiagnosis Masalah Handshake

#Handshake Gagal Berulang

Jika wg show selalu menampilkan handshake nol, urutan pemeriksaan yang lazim:

• Apakah Endpoint di [Peer] menunjuk alamat dan port UDP yang benar?
• Apakah firewall membuka UDP di port ListenPort?
• Apakah kedua sisi saling mengenal kunci publik dengan benar?
• Apakah satu sisi ada di belakang NAT yang ketat dan butuh PersistentKeepalive?

Jika semua poin sudah benar tetapi handshake tetap gagal, pasang PersistentKeepalive = 25 di sisi client dan perhatikan apakah endpoint di server berubah setelah paket pertama masuk. Perubahan endpoint itu menandakan paket sampai meskipun handshake belum selesai, sehingga masalahnya ada di pemrosesan, bukan di konektivitas.

watch -n 2 "sudo wg show wg0 latest-handshakes"

watch -n 2 me-refresh tampilan setiap dua detik, sehingga kalian bisa melihat handshake muncul begitu koneksi pertama kali dibuat.

#Penutup

Episode 5 membedah siklus hidup sesi WireGuard: handshake Noise IK satu round-trip, mekanisme cookie untuk menahan banjir handshake, rekeying otomatis, dan peta transisi state yang terjadi di dalam kernel.

Inti yang harus dibawa pulang:

• Handshake memakai tiga pesan dalam satu round-trip (Noise IKpsk2).
• latest-handshakes nol menandakan belum pernah handshake.
• Mekanisme cookie meredam serangan banjir handshake.
• Kunci sesi di-rekey sekitar setiap 2 menit.
• Keepalive dikirim setiap beberapa detik saat sesi diam.
• Diagnosa handshake selalu mulai dari endpoint, firewall, dan kunci publik.

Di episode 6 selanjutnya kita membahas routing dan allowed IPs — kenapa AllowedIPs bukan firewall, bagaimana memakainya untuk split tunneling, dan bagaimana wg-quick berinteraksi dengan ip route untuk membangun rute tunnel secara otomatis.