Menyatukan Jaringan Desa dan Kantor: Kisah Bongkar Pasang ZeroTier di MikroTik

Menyatukan Jaringan Desa dan Kantor: Kisah Bongkar Pasang ZeroTier di MikroTik

Halo teman-teman network enthusiast! Kali ini saya mau berbagi pengalaman seru (dan bikin deg-degan) saat mencoba menghubungkan server di kantor/rumah dengan jaringan desa menggunakan ZeroTier.

Tujuannya sederhana: Saya ingin memantau dan mengakses server dari jarak jauh. Kedua perangkat, yaitu Ubuntu Server di rumah dan MikroTik RB450x4 di desa, sudah saya hubungkan ke jaringan ZeroTier yang sama. Di dashboard ZeroTier, statusnya sudah hijau, online, dan mereka saling mengenali satu sama lain.

Tapi... Duh, kenyataannya tidak semanis yang dibayangkan.

🛑 Masalah Pertama: "Kok Ping-nya Gagal Terus?"

Awalnya, saya mencoba melakukan ping dari Ubuntu ke IP ZeroTier MikroTik. Hasilnya? Destination Host Unreachable. Dari MikroTik ke Ubuntu? Packet loss 100%.

Anehnya, kalau saya pakai koneksi seluler (4G) dari HP saya, koneksinya lancar jaya. Ini langsung mencurigakan. Berarti ada yang salah dengan cara ISP (Internet Service Provider) di rumah dan di desa menangani lalu lintas VPN kita.

Setelah bongkar sana-sini, saya menemukan dua fakta krusial:

  1. Firewall MikroTik Tertutup Rapat: Secara default, MikroTik tidak akan mengizinkan lalu lintas masuk dari antarmuka baru (termasuk ZeroTier) sebelum kita membuat aturan (rule) khusus.
  2. Sang Pengganggu: Symmetric NAT ISP: Ternyata ISP di desa menggunakan Symmetric NAT. Ini adalah "musuh bebuyutan" bagi VPN jenis Peer-to-Peer (P2P) seperti ZeroTier. NAT jenis ini membuang proses hole-punching (lubang koneksi) yang dilakukan oleh ZeroTier, sehingga koneksi selalu gagal atau putus-nyambung.

🛠️ Solusi 1: Membuka Pintu MikroTik

Langkah pertama, saya harus meyakinkan si MikroTik bahwa antarmuka ZeroTier itu aman. Saya menambahkan aturan accept di urutan paling atas agar tidak ditimpa aturan drop bawaan.

routeros/ip firewall filter add chain=input in-interface=zerotier1 action=accept place-before=0
/ip firewall filter add chain=forward in-interface=zerotier1 action=accept place-before=0

🛠️ Solusi 2: Mengakali ISP dengan "Full Cone NAT"

Karena masalah utamanya adalah Symmetric NAT dari ISP, saya harus mengubah perilaku NAT MikroTik agar lebih "ramah" terhadap ZeroTier. Caranya adalah dengan menggunakan aksi endpoint-independent-nat (yang secara efektif mirip dengan Full Cone NAT pada UDP).

routeros/ip firewall nat add chain=srcnat action=endpoint-independent-nat protocol=udp out-interface=ISP-ether5 place-before=0

(Catatan: Ganti ISP-ether5 dengan nama interface WAN yang sedang Anda gunakan).

Why it works? Dengan aturan ini, MikroTik akan mempertahankan port eksternal yang sama untuk setiap koneksi keluar. Ini memungkinkan proses hole-punching ZeroTier berhasil, sehingga koneksi P2P langsung antar dua lokasi bisa terbentuk dengan stabil!

🛠️ Solusi 3: Memaksa "Jalur Tikus" (TCP Fallback)

Selain NAT, beberapa ISP suka melakukan throttling atau memblokir UDP secara acak. Sebagai jaring pengaman, saya mengubah konfigurasi ZeroTier di container Docker Ubuntu untuk memaksa koneksi lewat TCP (port 443) jika UDP gagal.

json{
"settings": {
"allowTcpFallbackRelay": true,
"forceTcpRelay": true
}
}

File ini saya simpan di /var/lib/zerotier-one/local.conf, lalu saya restart kontainer ZeroTier-nya. Sekarang, jalur TCP Relay yang stabil (meskipun sedikit lebih lambat) akan otomatis aktif kalau jalur P2P gagal.


📱 Masalah Kedua: HP di Hotspot Desa Tidak Bisa Akses Server!

Setelah MikroTik dan Ubuntu bisa saling ping, muncul masalah baru. Laptop dan server bisa saling terhubung, tapi HP saya yang terhubung ke jaringan Hotspot Desa (IP 10.10.8.0/22) tidak bisa ping ke server rumah! Padahal HP tersebut bisa ping ke IP ZeroTier MikroTik.

Ternyata, ini ulah Sistem Hotspot MikroTik. Hotspot punya aturan dinamis yang sangat ketat. Sistem ini mencegat lalu lintas (terutama port 80 dan 443) untuk memastikan pengguna sudah login. Alhasil, paket data dari HP saya yang mau lewat jalur ZeroTier dianggap sebagai lalu lintas tak dikenal dan langsung dibuang (drop) sebelum sampai ke server tujuan.

Saya sempat coba menambahkan aturan bypass di firewall dan NAT, tapi hasilnya nihil.

💡 Trik "Whitelist" ala Admin Jaringan

Akhirnya, saya menemukan solusi pamungkas yang ternyata jauh lebih aman: Hotspot IP Binding (Bypassed).

Daripada memusingkan aturan firewall, saya langsung "mengeluarkan" HP saya dari sistem tracking Hotspot menggunakan MAC Address-nya.

routeros/ip hotspot ip-binding add mac-address=XX:XX:XX:XX:XX:XX type=bypassed

Hasilnya? BOOM! Langsung tembus! HP saya bisa ping ke server dengan latency stabil di kisaran 100ms, tanpa packet loss.

Justru ini menjadi silver lining (hal positif). Dengan metode bypassed ini, kita secara tidak langsung menerapkan prinsip Zero-Trust Access Control. Pengguna Hotspot biasa (yang tidak di-bypass) tetap aman dan tidak bisa melihat atau mengakses jaringan sensitif di rumah/kantor kita. Hanya perangkat yang kita daftarkan secara eksplisit (seperti HP admin) yang bisa menembus jaringan tersebut.


🎓 Pelajaran Berharga dari Kasus Ini

  1. Jangan Pernah Menyerah pada Symmetric NAT. Rule endpoint-independent-nat di MikroTik adalah penyelamat koneksi VPN kita.
  2. Hotspot MikroTik itu "Overprotective". Jika ada perangkat terpercaya yang butuh akses VPN atau routing khusus, jangan ragu untuk menggunakan bypassed di IP Binding.
  3. Jangan Tertipu Test src-address. Saat melakukan troubleshooting di terminal MikroTik, jangan pernah tes ping pakai src-address IP lokal. Kenapa? Karena traffic yang di-generate oleh router itu sendiri akan melewati rantai output dan melewati NAT (masquerade), sehingga tesnya selalu gagal dan menyesatkan. Selalu tes dari client (HP/PC) yang asli!

Sekarang, jaringan desa dan kantor sudah tersambung dengan sangat stabil. Semoga pengalaman bongkar-pasang ini bisa menjadi referensi buat teman-teman yang sedang berjuang dengan masalah serupa. Selamat ber-eksperimen dan happy networking! 🌐🚀