Failover WAN w MikroTik – dlaczego DNS jest wąskim gardłem i jak to obejść w praktyce
Konfiguracja failoveru WAN w MikroTik na pierwszy rzut oka rozwiązuje problem dostępności. Router wykrywa awarię łącza, przełącza trasę domyślną i ruch wychodzący zaczyna działać drugim interfejsem. W praktyce jednak bardzo szybko okazuje się, że usługi wystawione na zewnątrz przestają działać, mimo że sam mechanizm przełączania funkcjonuje poprawnie.
Problem nie leży w routingu, tylko w tym, jak użytkownik trafia do Twojej infrastruktury. I tutaj kluczową rolę odgrywa DNS.
---
Jak działa poprawnie skonfigurowany failover w MikroTik
Rozważmy prosty, realistyczny setup:
- WAN1: `203.0.113.10` – łącze główne
- WAN2: `198.51.100.20` – łącze zapasowe
- serwer WWW w LAN: `10.0.0.10`
- NAT na routerze przekierowuje ruch z WAN → LAN
Trasy w MikroTik:
```bash /ip route add dst-address=0.0.0.0/0 gateway=203.0.113.1 distance=1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=2 ```
W takim układzie:
- dopóki WAN1 odpowiada → cały ruch idzie przez WAN1
- gdy WAN1 przestaje odpowiadać → MikroTik przełącza się na WAN2
To działa poprawnie. Jeśli teraz zrobisz test z samego routera:
```bash ping 8.8.8.8 ```
zobaczysz, że po awarii WAN1 pakiety wychodzą przez WAN2. Routing jest więc rozwiązany.
---
Gdzie pojawia się problem – perspektywa użytkownika
Załóżmy, że masz domenę:
``` example.pl → 203.0.113.10 ```
Użytkownik wchodzi na stronę. Jego system wykonuje zapytanie DNS i zapisuje wynik:
``` example.pl = 203.0.113.10 ```
Ten wynik trafia do cache – na przykład na 3600 sekund.
Teraz następuje awaria WAN1.
Router przełącza się na WAN2 i wszystko działa… z wyjątkiem jednego elementu: użytkownik nadal próbuje połączyć się z adresem `203.0.113.10`.
Efekt końcowy:
- serwer działa
- NAT działa
- WAN2 działa
- użytkownik widzi timeout
To jest moment, w którym widać, że failover WAN nie rozwiązuje problemu dostępności usług.
---
Dlaczego DNS blokuje failover
DNS działa w modelu cache. Oznacza to, że odpowiedź raz uzyskana nie jest odświeżana przy każdym połączeniu.
Przykład:
``` example.pl → 203.0.113.10 (TTL = 3600) ```
Jeśli użytkownik dostał ten rekord:
- przez godzinę NIE zapyta ponownie DNS
- nawet jeśli IP zmieni się po 5 minutach
Dodatkowo trzeba uwzględnić kilka warstw cache:
- system operacyjny (Windows, Linux)
- przeglądarka
- router użytkownika
- resolver ISP
W efekcie rzeczywisty czas propagacji zmiany IP jest nieprzewidywalny.
---
Próba rozwiązania – obniżenie TTL
Często stosuje się podejście:
``` TTL = 60 sekund ```
Teoretycznie oznacza to, że po minucie klient pobierze nowy adres.
W praktyce:
- część resolverów ignoruje niskie TTL
- cache po stronie klienta może trzymać wpis dłużej
- przeglądarki często nie odświeżają wpisów natychmiast
Efekt jest taki, że zamiast godziny masz kilka minut przerwy, ale nadal nie masz ciągłości działania.
---
Dynamic DNS – pierwszy krok, ale nie rozwiązanie końcowe
Można zmienić podejście i zamiast wpisywać IP w DNS, użyć dynamicznego rekordu aktualizowanego przez router.
Konfiguracja MikroTik:
```bash /ip cloud set ddns-enabled=yes update-time=yes ```
Router generuje nazwę typu:
``` myrouter.sn.mynetname.net ```
Następnie w DNS:
``` example.pl → CNAME → myrouter.sn.mynetname.net ```
W momencie przełączenia WAN:
- MikroTik aktualizuje rekord DDNS
- domena zaczyna wskazywać na nowy adres
To działa lepiej niż statyczny rekord A, ale nadal zależy od cache DNS. Użytkownik, który ma zapisany stary adres, nadal będzie próbował połączenia z nieaktywnym IP.
---
Podejście właściwe – reverse proxy jako stały punkt wejścia
Aby całkowicie wyeliminować problem DNS, trzeba sprawić, żeby użytkownik zawsze łączył się z jednym, niezmiennym adresem IP.
Najprostszy sposób to reverse proxy na zewnętrznym serwerze.
Załóżmy:
- VPS: `192.0.2.50`
- domena: `example.pl → 192.0.2.50`
- backend: Twój serwer za MikroTik
Konfiguracja Nginx:
```nginx upstream backend { server 203.0.113.10 max_fails=2 fail_timeout=5s; server 198.51.100.20 backup; }
server { listen 80; server_name example.pl;
location / { proxy_pass http://backend; } } ```
Co się dzieje w praktyce:
- użytkownik zawsze trafia na `192.0.2.50`
- proxy próbuje wysłać ruch na WAN1
- jeśli WAN1 nie odpowiada → używa WAN2
DNS przestaje mieć znaczenie, bo adres widoczny dla użytkownika się nie zmienia.
---
Alternatywa – Cloudflare jako warstwa pośrednia
Zamiast własnego proxy można użyć platformy typu CDN.
Mechanizm działania:
- domena wskazuje na Cloudflare
- Cloudflare przekazuje ruch do Twojego serwera
- Ty zmieniasz adres backendu (ręcznie lub automatycznie)
W tym modelu użytkownik nigdy nie widzi Twojego IP. Zmiana backendu nie wymaga propagacji DNS po stronie klienta, bo DNS wskazuje na infrastrukturę Cloudflare, a nie bezpośrednio na Twój router.
---
Dlaczego dwa rekordy A nie są rozwiązaniem
Można spróbować:
``` example.pl → 203.0.113.10 example.pl → 198.51.100.20 ```
To jednak nie daje kontrolowanego failoveru.
Zachowanie klienta jest różne:
- część wybierze pierwszy adres i nie spróbuje drugiego
- część spróbuje obu
- brak mechanizmu sprawdzania dostępności
Efekt jest losowy i trudny do przewidzenia.
---
Jak wygląda poprawna architektura
W praktyce działający setup wygląda tak:
1. MikroTik obsługuje failover WAN 2. serwer działa w LAN 3. ruch przychodzi przez stały punkt wejścia:
- reverse proxy albo CDN
4. backend zmienia się dynamicznie w zależności od dostępności
Dzięki temu:
- routing działa na poziomie sieci
- failover działa na poziomie aplikacji
- użytkownik nie widzi przerwy
---
Wniosek końcowy
Failover WAN w MikroTik działa dokładnie tak, jak został zaprojektowany, ale rozwiązuje tylko część problemu. Zapewnia ciągłość połączeń wychodzących, natomiast nie gwarantuje dostępności usług publikowanych na zewnątrz.
Ograniczeniem jest DNS, który działa w oparciu o cache i nie reaguje natychmiast na zmiany adresów IP. Dopóki użytkownik trafia do Twojej infrastruktury przez rekord A wskazujący bezpośrednio na WAN, dopóty każda awaria będzie skutkowała przerwą w dostępie.
Rozwiązanie polega na wprowadzeniu stałego punktu wejścia, który przejmie odpowiedzialność za kierowanie ruchu. Może to być reverse proxy, load balancer albo zewnętrzna usługa typu CDN. Dopiero wtedy failover zaczyna działać tak, jak jest oczekiwany w środowisku produkcyjnym.