Failover Dual-WAN MikroTik untuk ISP

Ringkasan Failover dual-WAN MikroTik menjaga sebuah situs tetap online dengan memindahkan trafik secara otomatis ke uplink cadangan saat link primer gagal. RouterOS memberi Anda tiga blok bangunan — recursive routing dengan check-gateway, Netwatch, dan NAT per WAN — dan kombinasi yang tepat bergantung pada seberapa cepat dan seberapa cerdas deteksi yang Anda perlukan. Untuk armada ISP, masalah yang lebih sulit bukanlah potongan konfigurasinya, melainkan memastikan, di ratusan situs jarak jauh di balik CGNAT, bahwa failover benar-benar berfungsi. Panduan ini mencakup keduanya.

Apa Itu Failover Dual-WAN MikroTik?

Failover dual-WAN MikroTik adalah konfigurasi RouterOS yang memberi sebuah router dua uplink internet — satu primer dan satu cadangan — dan secara otomatis memindahkan trafik ke cadangan ketika primer berhenti meneruskan paket, lalu memindahkannya kembali saat pulih. Ini tidak sama dengan load balancing: failover membiarkan satu link menganggur sebagai asuransi, sementara load balancing menyebarkan trafik ke keduanya. Tujuannya adalah kontinuitas, bukan bandwidth ekstra, itulah sebabnya ini menjadi pola redundansi default untuk situs yang sama sekali tidak boleh padam.

Mekanismenya bertumpu pada pemilihan rute. RouterOS memilih rute default aktif berdasarkan administrative distance terendah, jadi Anda memberi primer distance lebih kecil dan cadangan lebih besar. Seluruh desain kemudian menyusut menjadi satu pertanyaan: bagaimana router memutuskan bahwa primer “mati” dan menurunkan rutenya? Buat keputusan itu dengan benar — cukup cepat, tetapi tidak gugup — dan failover akan andal. Salah, dan Anda akan failover terlalu lambat atau terombang-ambing antar link pada setiap paket yang hilang.

Langkah 1 — Petakan kedua WAN sebelum menyentuh rute apa pun

Mulailah dengan mencatat apa sebenarnya setiap uplink itu. Primer fiber tetap atau PPPoE dengan gateway statis atau yang diberikan PPP berperilaku berbeda dari cadangan Starlink atau LTE yang berada di balik Carrier-Grade NAT dan memberi Anda alamat dinamis. Ini penting karena recursive routing hanya bekerja dengan gateway IP yang stabil, bukan dengan tipe antarmuka dinamis seperti PPPoE atau DHCP di mana alamatnya dapat berubah (Dokumentasi MikroTik — Failover (WAN Backup)). Tentukan link mana yang primer, mana yang cadangan, dan apakah salah satunya mengubah IP saat menyambung ulang — satu fakta itu menentukan metode deteksi mana yang dapat Anda gunakan.

Langkah 2 — Tambahkan rute default rekursif dengan check-gateway

Pendekatan klasik menggunakan recursive routing: alih-alih mengarahkan rute default langsung ke next hop, Anda mengarahkannya ke target probe (misalnya resolver publik terkenal) dan menambahkan rute statis yang memberi tahu RouterOS untuk menjangkau target itu hanya melalui gateway WAN tertentu. Anda kemudian membuat dua rute default yang diselesaikan secara rekursif melalui target tersebut — primer dengan distance lebih kecil dan check-gateway=ping diaktifkan, cadangan dengan distance lebih besar (Scoop — Basic ISP Failover with MikroTik).

Perilaku yang perlu direncanakan adalah waktu. Check-gateway menonaktifkan sebuah rute setelah dua pemeriksaan gagal berturut-turut, dan pemeriksaan berjalan kira-kira setiap 10 detik, jadi peralihan nyata mendarat sekitar 20 hingga 30 detik — dan ia tidak bereaksi terhadap kehilangan paket intermiten, hanya terhadap gateway yang benar-benar mati (Dokumentasi MikroTik — Failover (WAN Backup)). Untuk banyak situs pelanggan ISP itu dapat diterima. Untuk terminal suara atau pembayaran sering kali tidak, dan di situlah Langkah 4 berperan.

Langkah 3 — Konfigurasikan NAT untuk kedua uplink

Sebuah router dual-WAN membutuhkan aturan masquerade (atau src-nat) terpisah per antarmuka WAN agar link mana pun yang aktif menerjemahkan trafik keluar dengan benar; satu aturan yang terikat ke satu antarmuka akan diam-diam merusak konektivitas begitu failover memindahkan trafik ke link lain. Tambahkan satu aturan masquerade pada chain srcnat untuk out-interface primer dan yang kedua untuk cadangan. Jika Anda mempublikasikan layanan masuk apa pun, ingat bahwa aturan dst-nat yang terikat ke alamat primer berhenti bekerja saat link itu — dan IP publiknya — hilang. Kerapuhan masuk itu adalah jebakan arsitektur yang sama yang dibahas dalam kasus perubahan IP Starlink kami, dan itulah sebabnya akses berbasis keluar menskala lebih baik daripada port forwarding. Untuk dasar-dasar NAT, lihat panduan mengonfigurasi NAT di MikroTik kami.

Langkah 4 — Gunakan Netwatch saat Anda butuh deteksi lebih cepat atau lebih cerdas

Ketika 20–30 detik terlalu lambat atau Anda perlu bertindak atas link yang terdegradasi-tetapi-hidup, Netwatch adalah alat yang lebih fleksibel. Di RouterOS v7, Netwatch mendapat parameter type yang dapat memeriksa dengan icmp, tcp-conn, http-get, https-get, atau simple, dan Anda dapat menetapkan interval pemeriksaan Anda sendiri alih-alih hidup dengan irama tetap check-gateway (Dokumentasi MikroTik — Failover (WAN Backup)). Setiap host memiliki skrip up dan down, jadi Anda dapat menonaktifkan rute default primer, memunculkan peringatan, atau mencatat peristiwa saat transisi.

Banyak operator menggabungkan keduanya: recursive routing menangani kematian link yang bersih, sementara Netwatch mencakup kasus yang lebih berantakan dan mengirim notifikasi. Sebuah utas komunitas yang berjalan lama memperdebatkan trade-off ini secara persis dan layak dibaca sebelum Anda menstandarkan satu metode di seluruh armada (Forum MikroTik — netwatch instead of recursive routing). Apa pun yang Anda pilih, jaga konfigurasi tetap identik di setiap situs — armada skrip failover khusus adalah pemadaman tersendiri yang menunggu untuk terjadi.

Langkah 5 — Verifikasi failover di setiap situs jarak jauh

Inilah bagian yang dilewati tutorial konfigurasi. Menambahkan rute pada satu router uji itu mudah; membuktikan bahwa failover bekerja di ratusan CPE yang terpasang adalah masalah ISP yang sebenarnya — dan menjadi lebih sulit ketika link cadangan adalah Starlink atau LTE di balik CGNAT, karena perangkat sering kali tidak memiliki IP publik yang dapat dijangkau untuk mengelolanya setelah failover. Jika Anda hanya dapat memastikan failover dengan menunggu pelanggan menelepon, Anda sebenarnya tidak memiliki failover; Anda memiliki skrip yang Anda harap berjalan.

Di sinilah manajemen terpusat mengubah ekonominya. MKController menjaga setiap router tetap dapat dijangkau melalui tunnel keluar yang terautentikasi, sehingga Anda dapat memastikan jalur cadangan membawa trafik, mengamati transisi failover dalam pemantauan, dan mendorong konfigurasi yang dikoreksi — tanpa bergantung pada IP publik yang mungkin tidak ada di link cadangan. Pasangkan itu dengan telemetri: panduan kami tentang memantau MikroTik dari jarak jauh dengan Zabbix dan pemantauan SNMP untuk MikroTik menunjukkan cara memberi peringatan atas peristiwa failover itu sendiri, sehingga peralihan diam-diam ke link cadangan yang mahal tidak pernah luput dari perhatian.

Tips

• Jaga probe check-gateway link cadangan mengarah ke target yang Anda jangkau melalui link itu, bukan melalui primer, atau pengujian Anda tidak ada artinya.
• Tandai transisi failover di pemantauan Anda agar situs yang berjalan berhari-hari di uplink cadangannya memunculkan tiket — failover yang tak seorang pun sadari adalah biaya berulang, bukan penyelamatan.
• Uji kabel yang sebenarnya, bukan hanya rutenya: cabut konektor primer dan ukur waktu peralihan nyata.

Bawa failover ke dalam satu control plane

Failover dual-WAN pada satu MikroTik adalah masalah yang sudah terpecahkan. Melakukannya dengan andal di seluruh armada — dengan konfigurasi konsisten dan kemampuan untuk membuktikan cadangan bekerja pada router yang tidak dapat Anda jangkau lewat IP publik — adalah tempat sebagian besar operator kehilangan uang. Manajemen terpusat berbasis keluar menutup celah itu.

Mulai uji coba gratis MKController Anda