MikroTik Çift WAN Failover: Yedekli İnternet Kurulumu

Kısa cevap: MikroTik’te güvenilir çift WAN failover, iki default route + distance farkı + recursive route ile gerçek internet hedefini izlemek demektir. Yaygın kurulan “check-gateway’li iki rota” düzeni, en sık yaşanan arıza tipini (modem ayakta, internet yok) göremez. Bu yazıda ikisini de kuruyor, farkı test ediyoruz.

Senaryo: birincil hat fiber (ether1, ISS gateway 10.0.0.1), yedek hat LTE veya ikinci ISS (ether2, gateway 192.168.8.1). LAN 192.168.10.0/24.

Önce zayıf yöntem: neden yetmez?

/ip route add dst-address=0.0.0.0/0 gateway=10.0.0.1 distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=192.168.8.1 distance=2

Bu çalışır gibi görünür: birincil gateway ping’e cevap vermezse trafik distance=2’ye kayar. Sorun şu: 10.0.0.1 sizin ISS modeminiz/ilk hop’unuzdur ve fiber kopmalarının çoğunda modem ping’e cevap vermeye devam eder. Kablo şehir tarafında kopar, ISS omurgasında arıza olur; modem yerelde ayaktadır, RouterOS “hat sağlam” der, kullanıcılar internetsiz kalır. Sahada gördüğüm failover şikayetlerinin büyük kısmı bu kurulumdur.

Doğru yöntem: recursive route ile gerçek hedef izleme

Mantık: “İnternette uzak bir hedefe (örn. 1.1.1.1) yalnız birincil hat üzerinden giden sabit bir yol tanımla; default route’un gateway’i o hedef olsun.” Böylece check-gateway ping’i modeme değil, gerçek internete gider.

/ip route add dst-address=1.1.1.1/32 gateway=10.0.0.1 scope=10 comment="izleme hedefi, sadece WAN1"
/ip route add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 check-gateway=ping target-scope=10 comment="birincil default"
/ip route add dst-address=0.0.0.0/0 gateway=192.168.8.1 distance=2 comment="yedek default"

Ne oluyor:

• İlk satır: 1.1.1.1’e giden trafik her zaman WAN1’den çıkar (host route, scope=10).
• İkinci satır: default route’un gateway’i bir IP komşusu değil, 1.1.1.1’in kendisi. RouterOS bunu recursive çözer (target-scope=10 ilk satırı kullanmasına izin verir) ve check-gateway ping’i internetin ta kendisine atılır.
• 1.1.1.1 cevap vermediği anda (modem ayakta olsa bile) birincil default düşer, trafik 192.168.8.1’e kayar. Hat düzelince otomatik geri döner.

İki ayrıntı:

• İzleme hedefini DNS olarak kullanmayın. 1.1.1.1 artık yedek hattayken bile WAN1’e yönlenir; birincil koptuğunda o IP erişilmez olur. DNS’e 9.9.9.9 ve 8.8.8.8 gibi farklı çözücüler verin.
• Tek hedefe güvenmek istemiyorsanız ikinci bir izleme rotası (1.0.0.1 gibi) ekleyip iki recursive default tanımlayabilirsiniz; tek hedefin kendi arızası yanlış failover tetiklemesin.

NAT: iki hat için de hazır olmalı

Failover anında NAT da yedek hatta çalışmalı. En temizi interface list:

/interface list add name=WAN
/interface list member add list=WAN interface=ether1
/interface list member add list=WAN interface=ether2
/ip firewall nat add chain=srcnat out-interface-list=WAN action=masquerade

Tek masquerade kuralı iki hattı da kapsar. Firewall input/forward kurallarınızda in-interface=ether1 gibi tekil arayüz varsa onları da in-interface-list=WAN’a çevirin; yoksa yedek hatta geçince koruma delik açar veya trafik kesilir.

Test: kabloyu çekmek gerçek test değil

Kabloyu çekmek link’i düşürür; onu check-gateway’siz kurulum bile yakalar. Asıl test upstream kopması simülasyonudur:

1. İzleme host rotasını geçici devre dışı bırakın: /ip route disable [find comment="izleme hedefi, sadece WAN1"] → default route’un recursive çözümü bozulur, failover tetiklenir.
2. /ip route print where dst-address=0.0.0.0/0 ile aktif rotayı, /tool traceroute 8.8.8.8 ile çıkış yolunu doğrulayın.
3. Rotayı geri açın, failback’i izleyin.

Geçiş anında mevcut TCP oturumları kopar ve yeniden kurulur; bu normaldir. Kalıcı tüneller (ör. WireGuard) yeni hat üzerinden kendiliğinden yeniden el sıkışır.

Ne zaman failover, ne zaman load balancing?

Yedek hat kotalı/dar ise (tipik 4G senaryosu) failover doğru mimaridir: ikinci hat yalnız gerektiğinde yanar. İki hat da genişse ve kapasite birleştirmek istiyorsanız PCC load balancing’e bakın; onun kurulumu SiberKale’deki load balancing rehberinde ayrıntılı anlatılıyor. İkisi birlikte de kurulabilir: PCC + her hatta recursive sağlık izleme.

Çok şubeli bir yapıda failover’ı tünel ve VPN sürekliliğiyle birlikte tasarlamak isterseniz MikroTik destek hizmetim üzerinden ulaşabilirsiniz.