WireGuard di Sisi Server: Tambah Peer Tanpa Downtime

Saya punya server rumahan (sebuah Mac Studio) yang saya expose ke internet lewat reverse proxy tunnel dari VPS. Awalnya saya pakai varian client tunnel berbasis Java dengan SSL bawaan. Masalahnya: koneksi itu putus setiap kira-kira 60 detik begitu dijalankan di atas versi Java yang lebih baru. Mode plain tanpa SSL justru stabil, tapi ya, datanya lewat polos tanpa enkripsi. Bukan trade-off yang saya suka.

Root Cause: Library Networking yang Ditinggal Zaman

Setelah ditelusuri, biang keroknya bukan di logika tunnel-nya, tapi di library networking (Netty) yang dipakainya. Versi yang dipakai itu peninggalan sekitar tahun 2015 dan sudah lama tidak dirawat, sementara handshake SSL-nya ternyata tidak cocok dengan perilaku Java modern. Hasilnya, koneksi SSL kena putus berkala meski jaringan di kedua sisi baik-baik saja. Menunggu upstream memperbaiki library selawas itu rasanya tidak realistis, jadi saya putuskan untuk tidak bergantung pada SSL bawaan tunnel itu sama sekali.

Solusi: Bungkus dengan WireGuard, Bukan Perbaiki SSL-nya

Alih-alih menambal lapisan enkripsi yang rapuh, saya pasang WireGuard sebagai lapisan terpisah yang membungkus seluruh hop tunnel. Jadi tunnel-nya sendiri boleh jalan mode plain, karena enkripsi sudah ditangani WireGuard di bawahnya.

Di sisi VPS ini cukup mudah karena Ubuntu modern sudah punya modul WireGuard di kernel, jadi saya tinggal pasang tools-nya saja. Ini beda dengan macOS di sisi Mac Studio yang harus pakai implementasi userspace lewat Homebrew karena tidak ada modul kernel setara.

Langkah setup di VPS kira-kira begini: bikin keypair, siapkan file konfigurasi dengan opsi supaya file itu sendiri yang jadi sumber kebenaran (bukan di-overwrite otomatis oleh state runtime), lalu satu peer per mesin dengan izin akses dibatasi hanya ke alamat khusus mesin itu di dalam jaringan WireGuard. Terakhir, buka port UDP yang relevan di firewall.

Satu hal yang sempat bikin saya bingung sendiri: VPS ini reboot terjadwal tiap hari, dan kalau service WireGuard tidak didaftarkan untuk auto-start, gejalanya persis seperti "tunnel down" padahal cuma lupa mendaftarkan service-nya supaya nyala lagi setelah reboot. Jadi wajib hukumnya enable service ini saat setup, bukan cuma start manual sekali.

Untuk menambah mesin baru sebagai peer tanpa mengganggu mesin lain yang sudah konek, saya tambahkan peer langsung di runtime tanpa restart layanan, lalu tulis juga perubahan yang sama ke file konfigurasi supaya permanen kalau layanan itu suatu saat direstart. Untuk firewall, urutannya saya jaga hati-hati: tambah aturan baru dulu, verifikasi jalan, baru hapus aturan lama — dan karena firewall menyimpan aturan IPv4 dan IPv6 secara terpisah, keduanya harus dihapus satu-satu, jangan cuma salah satunya.

Bagian yang paling krusial: server tunnel utama sendiri tidak punya mekanisme reload halus. Restart penuh di server tunnel akan memutus semua client yang sedang konek sekaligus, bukan cuma satu. Jadi kalau saya cuma mau memindahkan satu client ke jalur baru, yang saya restart adalah proses client itu, bukan server tunnelnya.

Pelajaran: Pola Cutover 5 Langkah

Verifikasi end-to-end saya lakukan di tiga level: cek status handshake dan counter transfer di WireGuard, cek koneksi established di level OS, dan pastikan situs tetap merespons normal dari kedua sisi.

Dari proses ini saya rangkum pola cutover yang bisa dipakai ulang untuk mesin lain mana pun:

  1. Siapkan konfigurasi baru
  2. Tambahkan sebagai peer
  3. Aktifkan jalur barunya
  4. Uji end-to-end (handshake, ping, koneksi) sebelum menyentuh jalur lama sama sekali — kalau gagal, matikan dulu jalur baru sebelum debugging
  5. Baru setelah yakin, tutup jalur lama

Semua langkah dibekali script rollback yang bisa memulihkan dari backup konfigurasi kalau ada yang gagal di tengah jalan.

Menariknya, kerjaan ini saya lakukan berkolaborasi dengan sesi AI di kedua mesin: sesi di VPS dan sesi di Mac Studio cuma saling bertukar public key lewat pesan teks. Perintah yang butuh akses root di sisi Mac (menyalakan WireGuard-nya) tetap saya jalankan sendiri secara manual, karena sesi AI di sana memang tidak diberi akses seluas itu.

Takeaway

Kalau enkripsi bawaan sebuah tool sudah usang dan bergantung pada library yang tidak dirawat, kadang solusinya bukan menambal tool itu, tapi membungkusnya dengan lapisan lain yang lebih modern. Dan untuk perubahan jaringan yang menyentuh koneksi live, urutan "tambah dulu, uji, baru hapus yang lama" jauh lebih aman daripada restart layanan yang memutus semua orang sekaligus.