ISP를 위한 MikroTik 듀얼 WAN 페일오버

요약 MikroTik 듀얼 WAN 페일오버는 기본 링크가 실패할 때 트래픽을 자동으로 백업 업링크로 이동시켜 사이트를 온라인 상태로 유지합니다. RouterOS는 세 가지 구성 요소 — check-gateway를 사용한 재귀 라우팅, Netwatch, WAN별 NAT — 를 제공하며, 올바른 조합은 감지가 얼마나 빠르고 얼마나 똑똑해야 하는지에 달려 있습니다. ISP 플릿의 경우 더 어려운 문제는 설정 코드 조각이 아니라, CGNAT 뒤에 있는 수백 개의 원격 사이트 전반에서 페일오버가 실제로 작동했는지 확인하는 것입니다. 이 가이드는 둘 다 다룹니다.

MikroTik 듀얼 WAN 페일오버란 무엇인가?

MikroTik 듀얼 WAN 페일오버는 라우터에 두 개의 인터넷 업링크 — 기본과 백업 — 를 제공하는 RouterOS 구성으로, 기본 링크가 패킷을 더 이상 전달하지 않으면 트래픽을 자동으로 백업으로 전환하고, 복구되면 다시 되돌립니다. 이것은 로드 밸런싱과 같지 않습니다. 페일오버는 한 링크를 보험처럼 유휴 상태로 유지하는 반면, 로드 밸런싱은 트래픽을 두 링크에 분산합니다. 목표는 추가 대역폭이 아니라 연속성이며, 그래서 절대 멈출 수 없는 사이트의 기본 이중화 패턴입니다.

이 메커니즘은 경로 선택에 기반합니다. RouterOS는 가장 낮은 관리 거리값으로 활성 기본 경로를 선택하므로, 기본에는 더 작은 거리값을, 백업에는 더 큰 거리값을 부여합니다. 그러면 전체 설계는 하나의 질문으로 귀결됩니다. 라우터는 어떻게 기본이 “다운”되었다고 판단하고 그 경로를 강등할까요? 이 결정을 올바르게 — 충분히 빠르게, 그러나 예민하지 않게 — 내리면 페일오버는 신뢰할 수 있습니다. 잘못 내리면 너무 느리게 전환되거나 모든 패킷 손실마다 링크 사이를 오갑니다.

1단계 — 경로를 건드리기 전에 두 WAN을 파악하라

각 업링크가 실제로 무엇인지 적어두는 것부터 시작하세요. 정적 또는 PPP 할당 게이트웨이를 가진 고정 광섬유 또는 PPPoE 기본 링크는 Carrier-Grade NAT 뒤에 위치하며 동적 주소를 부여하는 Starlink 또는 LTE 백업과 다르게 동작합니다. 이것이 중요한 이유는 재귀 라우팅은 안정적인 IP 게이트웨이에서만 작동하며, 주소가 바뀔 수 있는 PPPoE나 DHCP 같은 동적 인터페이스 유형에서는 작동하지 않기 때문입니다 (MikroTik 문서 — Failover (WAN Backup)). 어느 링크가 기본이고 어느 것이 백업인지, 그리고 어느 쪽이 재연결 시 IP를 바꾸는지 결정하세요 — 이 하나의 사실이 사용할 수 있는 감지 방법을 결정합니다.

2단계 — check-gateway를 사용한 재귀 기본 경로 추가하기

고전적인 접근법은 재귀 라우팅을 사용합니다. 기본 경로를 다음 홉에 직접 가리키는 대신, 프로브 대상(예: 잘 알려진 공인 리졸버)을 가리키고, RouterOS에게 그 대상을 특정 WAN 게이트웨이를 통해서만 도달하도록 지시하는 정적 경로를 추가합니다. 그런 다음 이 대상들을 통해 재귀적으로 해석되는 두 개의 기본 경로를 만듭니다 — 기본은 더 작은 거리값과 check-gateway=ping을 활성화하고, 백업은 더 큰 거리값으로 (Scoop — Basic ISP Failover with MikroTik).

계획해야 할 동작은 타이밍입니다. Check-gateway는 두 번 연속 실패한 체크 후에 경로를 비활성화하며, 체크는 약 10초마다 실행되므로 실제 전환은 약 20~30초에 일어납니다 — 그리고 간헐적인 패킷 손실에는 반응하지 않고 완전히 죽은 게이트웨이에만 반응합니다 (MikroTik 문서 — Failover (WAN Backup)). 많은 ISP 고객 사이트에서는 이것이 허용됩니다. 음성이나 결제 단말기에는 종종 그렇지 않으며, 바로 여기에서 4단계가 등장합니다.

3단계 — 두 업링크에 대한 NAT 구성하기

듀얼 WAN 라우터는 WAN 인터페이스마다 별도의 masquerade(또는 src-nat) 규칙이 필요하여, 어느 링크가 활성화되든 아웃바운드 트래픽을 올바르게 변환합니다. 하나의 인터페이스에 바인딩된 단일 규칙은 페일오버가 트래픽을 다른 링크로 이동시키는 순간 연결을 조용히 끊습니다. 기본 out-interface에 대해 srcnat 체인에 masquerade 규칙 하나를, 백업에 대해 두 번째 규칙을 추가하세요. 인바운드 서비스를 게시하는 경우, 기본의 주소에 묶인 dst-nat 규칙은 그 링크 — 그리고 그 공인 IP — 가 사라지면 작동을 멈춘다는 점을 기억하세요. 이 인바운드 취약성은 우리의 Starlink IP 변경 사례에서 다룬 것과 동일한 아키텍처적 함정이며, 그래서 아웃바운드 기반 접근이 포트 포워딩보다 더 잘 확장됩니다. NAT 기초는 MikroTik에서 NAT 구성 가이드를 참조하세요.

4단계 — 더 빠르거나 똑똑한 감지가 필요할 때 Netwatch 사용하기

20~30초가 너무 느리거나 저하되었지만 살아있는 링크에 대응해야 할 때는 Netwatch가 더 유연한 도구입니다. RouterOS v7에서 Netwatch는 icmp, tcp-conn, http-get, https-get, 또는 simple로 프로브할 수 있는 type 매개변수를 얻었고, check-gateway의 고정 주기를 따르는 대신 자신만의 체크 간격을 설정할 수 있습니다 (MikroTik 문서 — Failover (WAN Backup)). 각 호스트에는 up 스크립트와 down 스크립트가 있어 전환 시 기본 기본 경로를 비활성화하거나 알림을 발생시키거나 이벤트를 기록할 수 있습니다.

많은 운영자가 둘을 결합합니다. 재귀 라우팅은 깨끗한 링크 사망을 처리하고, Netwatch는 더 지저분한 경우를 다루며 알림을 보냅니다. 오래 진행된 커뮤니티 스레드가 바로 이 트레이드오프를 논의하며, 플릿 전반에 한 가지 방법을 표준화하기 전에 읽어볼 가치가 있습니다 (MikroTik 포럼 — netwatch instead of recursive routing). 무엇을 선택하든 모든 사이트에서 구성을 동일하게 유지하세요 — 맞춤형 페일오버 스크립트의 플릿은 그 자체로 발생을 기다리는 장애입니다.

5단계 — 모든 원격 사이트에서 페일오버 검증하기

여기가 바로 설정 튜토리얼이 건너뛰는 부분입니다. 하나의 벤치 라우터에 경로를 추가하는 것은 쉽습니다. 배포된 수백 개의 CPE에서 페일오버가 작동함을 증명하는 것이 진짜 ISP 문제이며 — 백업 링크가 CGNAT 뒤의 Starlink나 LTE일 때 더 어려워집니다. 페일오버 후 장치를 관리할 도달 가능한 공인 IP가 종종 없기 때문입니다. 고객이 전화할 때까지 기다려야만 페일오버를 확인할 수 있다면, 실제로는 페일오버가 없는 것입니다. 실행되기를 바라는 스크립트가 있을 뿐입니다.

여기에서 중앙 집중식 관리가 경제성을 바꿉니다. MKController는 인증된 아웃바운드 터널을 통해 각 라우터를 도달 가능한 상태로 유지하므로, 백업 경로가 트래픽을 처리하는지 확인하고, 모니터링에서 페일오버 전환을 관찰하며, 백업 링크에 존재하지 않을 수도 있는 공인 IP에 의존하지 않고 수정된 구성을 푸시할 수 있습니다. 이를 텔레메트리와 결합하세요. Zabbix로 MikroTik 원격 모니터링과 MikroTik용 SNMP 모니터링에 대한 가이드는 페일오버 이벤트 자체에 대해 알림을 보내는 방법을 보여주므로, 비싼 백업 링크로의 조용한 전환이 결코 눈에 띄지 않는 일이 없습니다.

팁

• 백업 링크의 check-gateway 프로브를 기본 링크가 아니라 그 링크를 통해 도달하는 대상으로 향하게 하세요. 그렇지 않으면 테스트가 무의미합니다.
• 모니터링에서 페일오버 전환에 태그를 지정하여 백업 업링크로 며칠씩 실행되는 사이트가 티켓을 발생시키도록 하세요 — 아무도 알아채지 못하는 페일오버는 구원이 아니라 반복되는 비용입니다.
• 경로뿐 아니라 실제 케이블을 테스트하세요. 기본의 커넥터를 뽑고 실제 전환 시간을 측정하세요.

페일오버를 하나의 컨트롤 플레인 아래로

단일 MikroTik에서의 듀얼 WAN 페일오버는 해결된 문제입니다. 플릿 전반에서 신뢰성 있게 — 일관된 구성과 공인 IP로 도달할 수 없는 라우터에서 백업이 작동함을 증명할 수 있는 능력과 함께 — 수행하는 것이 대부분의 운영자가 돈을 잃는 지점입니다. 중앙 집중식, 아웃바운드 기반 관리가 그 격차를 메웁니다.

무료 MKController 체험판 시작하기