Mikrotik : Praktikum Uji WireGuard Site-to-Site

Artikel pagi sudah memasang terowongan WireGuard antara dua kantor. Sekarang kita berbuat sebaliknya: sengaja merusaknya sedikit demi sedikit, lalu membaca gejala yang muncul.

Cara ini lebih berguna daripada menghafal perintah. Di lapangan, terowongan jarang gagal karena salah ketik; ia gagal karena satu hal kecil tidak cocok, dan gejalanya sering menipu.

🎯 Tujuan

Setelah lab ini, kamu diharapkan bisa:

• Membedakan empat lapis pemeriksaan WireGuard: jangkauan UDP, handshake, alamat/rute, dan MTU.
• Membaca `last-handshake`, `rx`, dan `tx` sebagai alat diagnosa.
• Menjatuhkan terowongan dengan sengaja lalu memprediksi gejalanya.
• Menemukan penyebab "handshake hidup tetapi LAN tidak bisa diakses".
• Mengukur MTU dan memasang MSS clamp agar transfer besar tidak menggantung.

📍 Konteks nyata

Analogi: artikel pagi mengajarkan cara **memasang pipa** antara dua gedung. Lab ini mengajarkan cara **mengetuk pipa** untuk mencari bocornya.

Kalau hanya tahu memasang, kita bingung saat pipa bocor. Apakah bocornya di sambungan kunci, di keran firewall, di papan petunjuk rute, atau karena pipanya terlalu sempit.

🔥 Kasus nyata: Sebuah SMK menyambungkan lab gedung B ke server CBT di gedung A memakai WireGuard. Ping 32 byte selalu mulus, jadi terowongan dianggap sehat. Saat ujian, unggahan jawaban siswa menggantung. Ternyata jalur cadangan memakai modem 4G ber-MTU 1400, sedangkan terowongan memakai MTU bawaan 1420. Paket besar dibuang karena bertanda *do not fragment*. Setelah `mtu` diturunkan ke 1340 dan MSS di-clamp ke 1300, unggahan normal kembali.

💡 Tips: Ping kecil yang hijau bukan bukti terowongan sehat. Selalu uji dengan paket besar juga.

🧠 Konsep singkat

🔹 Empat lapis yang harus lulus

WireGuard tidak punya satu tombol "status". Ada empat lapis yang harus lulus berurutan.

Lapis	Yang diperiksa	Alat bukti	Gejala kalau gagal
1. Jangkauan UDP	Paket UDP port tunnel sampai ke lawan	Counter firewall, log	`last-handshake` tetap `never`
2. Handshake	Kunci publik cocok dan sah	`last-handshake`, `rx`, `tx`	`never`, atau `tx` naik tetapi `rx` nol
3. Alamat dan rute	`allowed-address` dan tabel rute benar	`/ip route print`, ping ujung tunnel	Tunnel hidup, LAN lawan mati
4. MTU dan MSS	Ukuran paket muat di jalur nyata	Ping `do-not-fragment`, transfer file	Ping kecil lancar, transfer menggantung

🔹 Tiga status handshake yang wajib dibedakan

Yang terlihat	Arti	Arah pemeriksaan
`never`, `tx` diam	Belum ada paket keluar	Rute ke endpoint, interface, atau endpoint salah
`never`, `tx` naik	Paket keluar, tidak dijawab	Kunci salah, firewall lawan, atau port beda
`last-handshake` kecil, `rx`/`tx` naik	Sehat	Lanjut uji LAN dan MTU
`last-handshake` membesar, `tx` diam	Sesi lama, kemungkinan mati	Keepalive, NAT, atau jalur putus

🔹 Handshake adalah denyut nadi

WireGuard memutar kunci sesi secara berkala. Sesi lama dibuang kalau tidak ada handshake baru, kira-kira setelah **180 detik**.

Jadi "tadi terowongan hidup" bukan bukti "sekarang hidup". Lihat angka `last-handshake` yang masih kecil, bukan hanya status `running`.

📊 Angka penting: Standar protokol WireGuard memakai batas 180 detik sebelum sesi kedaluwarsa. Handshake sehat selalu jauh di bawah tiga menit.

🔹 Kenapa MTU sering menipu

Setiap paket yang masuk terowongan dibungkus lagi. Untuk IPv4, bungkusnya sekitar **60 byte**: 20 header IP + 8 UDP + 32 WireGuard.

Interface ber-MTU 1420 menghasilkan paket luar sekitar 1480 byte. Selama jalur mendukung 1500 byte, aman. Begitu jalur hanya 1400 byte, paket besar dibuang.

Yang membuat repot: banyak penyedia memblokir ICMP *fragmentation needed*, sehingga *Path MTU Discovery* tidak jalan. Router tidak tahu paketnya terlalu besar, dan TCP menggantung tanpa pesan error.

💡 Tips: Solusi praktisnya dua langkah: turunkan `mtu` interface tunnel, lalu clamp MSS agar pengirim TCP memakai segmen lebih kecil sejak awal.

🔹 allowed-address mengarahkan, bukan hanya mengizinkan

`allowed-address` menyaring paket masuk sekaligus memilih peer untuk paket keluar. Kalau daftarnya kurang satu subnet, tunnel tetap hidup tetapi paket ke subnet itu tidak punya peer tujuan.

Gejalanya khas: ping ke ujung tunnel berhasil, ping ke LAN lawan gagal.

⚠️ Hati-hati: Satu subnet tidak boleh diklaim dua peer pada interface yang sama. RouterOS menolak `allowed-address` yang tumpang tindih.

🧩 Istilah penting

Istilah	Arti sederhana
`last-handshake`	Umur handshake terakhir dalam detik. Makin kecil, makin segar.
`rx` dan `tx`	Jumlah byte yang diterima dan dikirim untuk peer itu.
`current-endpoint-address`	Alamat sumber terakhir yang lolos autentikasi. Berguna saat peer berpindah IP.
`persistent-keepalive`	Paket kosong berkala agar mapping NAT tidak ditutup.
`responder=yes`	Menandai peer yang hanya menjawab, tidak terus mencoba menghubungi.
PMTUD	Pencarian MTU jalur otomatis. Sering gagal karena ICMP diblokir.
MSS clamp	Menurunkan ukuran segmen TCP lewat mangle agar tidak melebihi jalur.
*fault injection*	Sengaja membuat kesalahan terkontrol untuk mempelajari gejalanya.

🔧 Praktik: Menguji dan Menjatuhkan Terowongan

Lab ini melanjutkan topologi artikel Mikrotik : VPN WireGuard Site-to-Site. Kalau terowonganmu belum ada, buat dulu dengan ringkasan berikut.

• **Kantor A** — LAN `10.1.202.0/24`, WAN `192.0.2.10/24`, ujung tunnel `10.255.255.1/30`.
• **Kantor B** — LAN `10.1.101.0/24`, WAN `198.51.100.10/24`, ujung tunnel `10.255.255.2/30`.
• **Interface** — `wg-kantor`, `listen-port=13231`. Semua alamat memakai blok dokumentasi RFC 5737.

# ringkasan minimum jika terowongan belum ada (sesuaikan arah di tiap router)
/interface/wireguard add name=wg-kantor listen-port=13231
/interface/wireguard/peers add interface=wg-kantor public-key="<kunci-lawan>" \
    allowed-address=10.1.101.0/24,10.255.255.2/32 \
    endpoint-address=198.51.100.10 endpoint-port=13231 persistent-keepalive=25s
/ip/address add address=10.255.255.1/30 interface=wg-kantor
/ip/route add dst-address=10.1.101.0/24 gateway=wg-kantor
/ip/firewall/filter add chain=input action=accept protocol=udp dst-port=13231 place-before=0
/ip/firewall/filter add chain=forward action=accept in-interface=wg-kantor
/ip/firewall/filter add chain=forward action=accept out-interface=wg-kantor

🧪 Uji cepat: Pastikan RouterOS v7 dan interface berflag `R` lewat `/interface/wireguard print`.

🔹 Langkah 1: kumpulkan baseline sebelum merusak

Tanpa baseline, kamu tidak punya pembanding saat gejala muncul. Jalankan berurutan dan simpan hasilnya.

/interface/wireguard/peers print detail
/ping 10.255.255.2 count=3
/ping 10.1.101.1 src-address=10.1.202.1 count=3
/tool traceroute 10.1.101.1 src-address=10.1.202.1
/ping 10.255.255.2 do-not-fragment size=1300 count=3
/ping 10.255.255.2 do-not-fragment size=1400 count=3

Catat lima hal: `last-handshake`, `rx`/`tx`, hasil ping tunnel, hasil ping LAN, dan ukuran paket terbesar yang lolos.

💡 Tips: Foto layar atau salin output ke catatan. Saat uji gagal, kamu membandingkan angka, bukan menebak.

🔹 Langkah 2: Uji A — kunci publik tidak cocok

Ubah `public-key` peer di Kantor A menjadi kunci sembarang. Jangan hapus peer, cukup ubah.

/interface/wireguard/peers set [find interface=wg-kantor] \
    public-key="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="

Tunggu 30 detik, lalu periksa `/interface/wireguard/peers print detail` dan `/log print where topics~"wireguard"`.

Yang muncul: `last-handshake` tetap `never`, `tx` terus naik, `rx` tidak bergerak. Paket keluar, tetapi lawan menolak karena kuncinya tidak dikenal.

⚠️ Hati-hati: Tempel dulu public key asli di notepad sebelum diganti, karena nilai lama tidak bisa dilihat lagi dari baris itu.

🔹 Langkah 3: Uji B — handshake hidup, LAN mati

Hapus subnet LAN lawan dari `allowed-address`, sisakan alamat ujung tunnel.

/interface/wireguard/peers set [find interface=wg-kantor] allowed-address=10.255.255.2/32
/ping 10.255.255.2 count=3
/ping 10.1.101.1 src-address=10.1.202.1 count=3

Hasil yang diharapkan: ping ujung tunnel berhasil, ping LAN lawan gagal. Paket ke LAN tetap masuk interface karena rute ada, tetapi WireGuard tidak menemukan peer yang mengklaim alamat itu.

🧪 Uji cepat: `/interface wireguard print stats` — kalau `tx-byte` naik tetapi `rx-byte` diam, paket keluar tanpa balasan.

🔹 Langkah 4: Uji C — firewall menahan satu arah

Matikan sementara aturan `input` UDP 13231 di Kantor A.

/ip/firewall/filter disable [find comment~"WireGuard"]
/ip/firewall/filter print stats

Ping masih sesekali berhasil beberapa saat karena sesi lama belum kedaluwarsa. Setelah sekitar tiga menit tanpa handshake baru, koneksi mati total.

Ini pelajaran penting: **kegagalan konfigurasi bisa tertunda**. Jangan menyimpulkan "sudah benar" dari satu ping yang masih lolos. Aktifkan kembali aturan setelah selesai.

🔹 Langkah 5: Uji D — cari MTU yang benar-benar muat

Naikkan ukuran paket bertahap dengan tanda *do not fragment*.

/ping 10.255.255.2 do-not-fragment size=1300 count=3
/ping 10.255.255.2 do-not-fragment size=1400 count=3
/ping 10.255.255.2 do-not-fragment size=1420 count=3

Kalau `1400` gagal tetapi `1300` lolos, MTU efektif jalur ada di antaranya. Catat batas aman tertinggi.

Untuk jalur 1400 byte, turunkan MTU tunnel ke 1340 lalu pasang MSS clamp.

/interface/wireguard set [find name=wg-kantor] mtu=1340
/ip/firewall/mangle
add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1301-65535 \
    new-mss=1300 action=change-mss passthrough=yes comment="MSS clamp tunnel"

📊 Angka penting: Bawaan RouterOS `mtu=1420`. Aman untuk jalur 1500 byte; turunkan ke sekitar 1340 untuk jalur 1400 byte. MSS clamp tidak menggantikan MTU yang benar, keduanya berlapis.

⚠️ Hati-hati: Jangan turunkan MTU tanpa alasan. Terlalu kecil membuat efisiensi turun karena header memakan porsi lebih besar tiap paket.

Uji dengan transfer nyata beberapa megabyte, bukan hanya ping.

🔹 Langkah 6: Uji E — keepalive dan mapping NAT

Di sisi di belakang NAT, ubah `persistent-keepalive` menjadi `0`, lalu biarkan menganggur beberapa menit.

/interface/wireguard/peers set [find interface=wg-kantor] persistent-keepalive=0
/ip/firewall/connection print where dst-port=13231

Perhatikan kolom timeout pada entri UDP. Tanpa keepalive, nilainya menurun sampai mapping ditutup. Setelah itu paket dari luar tidak menemukan router di balik NAT. Kembalikan ke `25s` dan lihat timeout disegarkan berkala.

💡 Tips: Cukup satu sisi yang memakai keepalive, yaitu sisi di belakang NAT.

🔹 Langkah 7: Uji F — endpoint berubah dan roaming

Ubah `endpoint-address` ke alamat salah, lalu amati handshake yang berhenti.

/interface/wireguard/peers set [find interface=wg-kantor] endpoint-address=203.0.113.99
/interface/wireguard/peers print detail

Perhatikan dua kolom berbeda: `endpoint-address` adalah yang kita tuju, `current-endpoint-address` adalah sumber terakhir yang lolos autentikasi. WireGuard bisa berpindah alamat kalau peer mengirim paket terautentikasi dari alamat baru.

Kembalikan endpoint yang benar. Pada sisi yang hanya melayani, tambahkan `responder=yes` agar router tidak terus mencoba alamat lama.

🔹 Langkah 8: Uji G — dua peer mengklaim subnet sama

/interface/wireguard/peers add interface=wg-kantor \
    public-key="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=" \
    allowed-address=10.1.101.0/24

RouterOS menolak karena satu subnet tidak boleh dimiliki dua peer pada interface yang sama. Ini pengaman alami terhadap salah tempel konfigurasi.

🔹 Langkah 9: Uji H — ukur throughput dan latensi

/tool bandwidth-server print
/tool bandwidth-test 10.1.101.1 direction=both duration=10s
/system resource print

Bandingkan dengan pengukuran antar-LAN langsung, lalu lihat `cpu-load`. Pada router kecil, enkripsi WireGuard bisa memenuhi satu inti CPU sehingga throughput mentok di situ.

📊 Angka penting: Catat hasil apa adanya. Router kelas rumah dan kantor memberi angka berbeda; yang penting perbandingan sebelum dan sesudah perbaikan.

🔹 Langkah 10: bersih-bersih dan lembar hasil

/ip/firewall/mangle remove [find comment~"MSS clamp tunnel"]
/interface/wireguard/peers remove [find public-key~"BBBB"]
/interface/wireguard set [find name=wg-kantor] mtu=1420
/interface/wireguard/peers set [find interface=wg-kantor] persistent-keepalive=25s
/ip/firewall/filter enable [find comment~"WireGuard"]

Uji	Perubahan	Gejala	Bukti	Perbaikan
A	Public key salah	Handshake tidak terjadi	`tx` naik, `rx` nol	Kembalikan kunci lawan
B	`allowed-address` hanya `/32`	Tunnel hidup, LAN mati	Ping tunnel OK, ping LAN gagal	Tambahkan subnet LAN lawan
C	Firewall input dimatikan	Putus setelah beberapa menit	`last-handshake` membesar	Aktifkan UDP 13231
D	Paket melebihi MTU jalur	Transfer menggantung	Ping 1300 lolos, 1400 gagal	MTU turun + MSS clamp
E	Keepalive nol di belakang NAT	Mati saat menganggur	Timeout conntrack menurun	`persistent-keepalive=25s`
F	Endpoint salah	Handshake berhenti	`current-endpoint-address` kosong	Perbaiki endpoint, pakai `responder`
G	Dua peer satu subnet	Peer kedua ditolak	Pesan overlap	Satu subnet satu peer

🏭 Dipakai di dunia kerja

• **Sekolah:** lab CBT di gedung terpisah mengunggah jawaban lewat terowongan. Tanpa uji MTU, unggahan besar menggantung dan panitia menyalahkan server.
• **Kantor cabang:** kasir memakai aplikasi pusat lewat WireGuard. Saat lambat, tim IT harus memisahkan masalah ISP, handshake, atau MTU.
• **ISP dan managed service:** penyedia jasa memantau terowongan pelanggan dan butuh bukti `last-handshake` serta counter, bukan laporan "jaringan lambat".
• **Industri dan pabrik:** telemetri sensor kecil aman, tetapi transfer log harian bisa gagal kalau MTU salah.
• **Vendor IT:** teknisi maintenance jarak jauh. Mendiagnosis terowongan lebih berharga daripada sekadar memasangnya.
• **Koperasi dan BUMDes:** kios memakai modem seluler; perpindahan IP publik membuat pemahaman endpoint jadi wajib.

✅ Verifikasi

Pemeriksaan	Perintah	Hasil yang diharapkan
Interface hidup	`/interface/wireguard print`	Flag `R` pada `wg-kantor`
Handshake segar	`/interface/wireguard/peers print detail`	`last-handshake` jauh di bawah 180 detik
Counter bergerak	`/interface wireguard print stats`	`rx-byte` dan `tx-byte` bertambah
Ujung tunnel	`/ping 10.255.255.2 count=3`	Tanpa packet loss
LAN lawan	`/ping 10.1.101.1 src-address=10.1.202.1 count=3`	Tanpa packet loss
MTU aman	`/ping 10.255.255.2 do-not-fragment size=1300 count=3`	Lolos tanpa fragmentasi

🧪 Uji cepat: Transfer satu file beberapa megabyte lewat terowongan. Kalau selesai tanpa menggantung, MTU dan MSS sudah benar.

⚠️ Kesalahan umum & troubleshooting

Gejala	Yang dicek	Penyebab dan perbaikan
`never`, `tx` diam	`/ip route print`, status interface	Endpoint tidak terjangkau, interface mati, atau rute WAN hilang
`never`, `tx` naik	`public-key` peer, aturan `input` lawan	Kunci salah, port beda, atau firewall lawan menahan UDP
Handshake hidup, ping tunnel gagal	Alamat ujung tunnel dan `/30`	Alamat tertukar, prefix salah, atau IP bentrok
Handshake hidup, ping LAN gagal	`allowed-address`, rute balik, `forward`	Subnet lawan tidak ada di `allowed-address` atau tidak ada rute balik
Ping kecil lancar, transfer besar hang	Ping `do-not-fragment` bertahap	MTU terlalu besar, PMTUD diblokir, MSS belum di-clamp
Mati setelah menganggur	`persistent-keepalive`, entri conntrack	Mapping NAT tertutup; pasang keepalive 25 detik
Pulih sendiri berkala	`endpoint-address`, `responder`	Kedua sisi memanggil alamat lama; perbaiki endpoint
Ping dari router OK, dari PC gagal	Gateway PC, NAT, `forward`	PC tidak memakai router sebagai gateway, atau `forward` menahan
Throughput rendah	`cpu-load`, MTU, bandwidth-test	Fragmentasi atau enkripsi memenuhi satu inti CPU

⚠️ Hati-hati: Mengubah `mtu` bisa memutus koneksi yang sedang berjalan sebentar. Lakukan di jam sepi untuk perangkat produksi.

🔐 Catatan keamanan & etika

• **Private key tidak pernah dibagikan.** Yang dikirim hanya `public-key`. Kalau bocor, buat ulang kunci interface dan perbarui semua peer.
• **Batasi sumber UDP.** Jangan buka `13231` untuk semua alamat; batasi `src-address` ke IP publik peer.
• **Periksa log, bukan hanya counter.** Log topik WireGuard memperlihatkan percobaan handshake berulang dari alamat asing.
• **Lab hanya di perangkat sendiri.** Uji *fault injection* hanya dengan izin pengelola. Jangan pernah mencobanya pada jaringan orang lain.
• **Jangan menangkap trafik orang lain.** Metadata koneksi tetap sensitif walau isinya terenkripsi.
• **Perbarui RouterOS.** Perbaikan keamanan WireGuard dan NAT datang lewat pembaruan rutin.

📌 Kesimpulan

Terowongan sehat punya empat syarat: paket UDP sampai, kunci cocok, alamat serta rute benar, dan ukuran paket muat. Kegagalan di lapis mana pun memberi gejala berbeda, dan `last-handshake`, `rx`, `tx` adalah alat utama membedakannya.

Kebiasaan paling berharga dari lab ini bukan hafal perintah, melainkan **mencatat baseline sebelum mengubah apa pun**. Dengan begitu setiap gejala punya pembanding.

Langkah berikutnya: setelah bisa membangun dan mendiagnosis WireGuard, bandingkan dengan **IPsec** untuk melihat kapan masing-masing lebih tepat dipakai.

🔗 Materi terkait

• Mikrotik : VPN WireGuard Site-to-Site — artikel konsep dan lab pemasangan yang menjadi dasar praktikum ini.
• Mikrotik : Firewall Filter Dasar — chain `input` dan `forward` yang menahan atau meloloskan terowongan.
• Mikrotik : Praktikum Cek Firewall Filter dengan Counter dan Log — membaca counter dan log saat handshake gagal.
• Mikrotik : Static Route Dasar — dasar rute antar subnet yang dipakai terowongan.
• Mikrotik : Praktikum Cek Static Route dengan Route Check dan Traceroute — memeriksa jalur dan rute balik.
• Mikrotik : NAT Masquerade agar Client Bisa Internet — memahami NAT yang memengaruhi keepalive.
• Mikrotik : Tabel Routing dan Manajemen Rute di RouterOS v7 — membaca FIB dan rute aktif.

📚 Referensi

• MikroTik Documentation — *WireGuard*: https://help.mikrotik.com/docs/spaces/ROS/pages/69664792/WireGuard
• MikroTik Documentation — *Mangle, Change MSS*: https://help.mikrotik.com/docs/spaces/ROS/pages/48660587/Mangle
• WireGuard — *Protocol & Cryptography*: https://www.wireguard.com/protocol/
• RFC 5737 — *IPv4 Address Blocks Reserved for Documentation*: https://www.rfc-editor.org/rfc/rfc5737