Maintenance script: Tambahkan kategori TKJ/Jaringan/Mikrotik

2026-10-17T09:02:28Z

Tambahkan kategori TKJ/Jaringan/Mikrotik

← Older revision		Revision as of 16:02, 17 October 2026
Line 449:		Line 449:
	* WireGuard — Protocol & Cryptography: https://www.wireguard.com/protocol/		* WireGuard — Protocol & Cryptography: https://www.wireguard.com/protocol/
	* RFC 5737 — IPv4 Address Blocks Reserved for Documentation: https://www.rfc-editor.org/rfc/rfc5737		* RFC 5737 — IPv4 Address Blocks Reserved for Documentation: https://www.rfc-editor.org/rfc/rfc5737

			[[Category:TKJ]]
			[[Category:Jaringan]]
			[[Category:Mikrotik]]

Maintenance script: Protected "Mikrotik : Praktikum Uji WireGuard Site-to-Site": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

2026-10-17T09:02:20Z

Protected "Mikrotik : Praktikum Uji WireGuard Site-to-Site": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

← Older revision	Revision as of 16:02, 17 October 2026
(No difference)

Maintenance script: Praktikum pendamping VPN WireGuard Site-to-Site: uji handshake, MTU, dan diagnosa

2026-10-17T09:02:17Z

Praktikum pendamping VPN WireGuard Site-to-Site: uji handshake, MTU, dan diagnosa

New page

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.

{| class="wikitable"
! 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 ===
{| class="wikitable"
! 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 ==
{| class="wikitable"
! 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.

<syntaxhighlight lang="text">
# 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
</syntaxhighlight>

🧪 '''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.

<syntaxhighlight lang="text">
/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
</syntaxhighlight>

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.

<syntaxhighlight lang="text">
/interface/wireguard/peers set [find interface=wg-kantor] \
public-key="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="
</syntaxhighlight>

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.

<syntaxhighlight lang="text">
/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
</syntaxhighlight>

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.

<syntaxhighlight lang="text">
/ip/firewall/filter disable [find comment~"WireGuard"]
/ip/firewall/filter print stats
</syntaxhighlight>

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*.

<syntaxhighlight lang="text">
/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
</syntaxhighlight>

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.

<syntaxhighlight lang="text">
/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"
</syntaxhighlight>

📊 '''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.

<syntaxhighlight lang="text">
/interface/wireguard/peers set [find interface=wg-kantor] persistent-keepalive=0
/ip/firewall/connection print where dst-port=13231
</syntaxhighlight>

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.

<syntaxhighlight lang="text">
/interface/wireguard/peers set [find interface=wg-kantor] endpoint-address=203.0.113.99
/interface/wireguard/peers print detail
</syntaxhighlight>

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 ===
<syntaxhighlight lang="text">
/interface/wireguard/peers add interface=wg-kantor \
public-key="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=" \
allowed-address=10.1.101.0/24
</syntaxhighlight>

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 ===
<syntaxhighlight lang="text">
/tool bandwidth-server print
/tool bandwidth-test 10.1.101.1 direction=both duration=10s
/system resource print
</syntaxhighlight>

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 ===
<syntaxhighlight lang="text">
/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"]
</syntaxhighlight>

{| class="wikitable"
! 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 ==
{| class="wikitable"
! 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 ==
{| class="wikitable"
! 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

Mikrotik : Praktikum Uji WireGuard Site-to-Site - Revision history

Maintenance script: Tambahkan kategori TKJ/Jaringan/Mikrotik

Maintenance script: Protected "Mikrotik : Praktikum Uji WireGuard Site-to-Site": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Maintenance script: Praktikum pendamping VPN WireGuard Site-to-Site: uji handshake, MTU, dan diagnosa