CGNAT 환경의 MikroTik 원격 접속

요약 CGNAT(Carrier-Grade NAT)는 ISP가 하나의 공인 IPv4 주소를 여러 가입자가 공유하도록 해 부족한 주소를 절약하지만, 인바운드 연결을 차단합니다. 그래서 그 뒤에 있는 MikroTik 라우터로의 포트 포워딩은 단순히 동작하지 않습니다. 라우터에 도달 가능한 공인 주소가 없기 때문에, 확실한 해결책은 방향을 뒤집는 것입니다. 즉 라우터가 여러분이 제어하는 랑데부 지점으로 직접 접속하도록 하는 것입니다. 이 가이드는 CGNAT가 무엇인지, 어떻게 감지하는지, 그리고 아웃바운드 터널을 이용해 그 뒤의 MikroTik 라우터를 관리하는 방법을 설명합니다.

CGNAT란 무엇인가?

CGNAT는 ISP 네트워크 내부에서 실행되는 두 번째 계층의 네트워크 주소 변환으로, 여러 고객을 소수의 공유 공인 IPv4 주소 풀에 매핑하며, 일반적으로 각 가입자에게 실제 공인 IP 대신 100.64.0.0/10 캐리어 대역의 사설 주소를 부여합니다. 이것이 존재하는 이유는 세계가 여러 해 전에 사용 가능한 IPv4 블록을 모두 소진했기 때문입니다. 점점 비싸지는 주소를 구매하는 대신, 대부분의 고정 무선, 모바일, 광, 위성 사업자는 이제 가입자를 공유 게이트웨이 뒤에 둡니다. 여러분의 MikroTik는 여전히 인터넷에 접속할 수 있고 정상적으로 아웃바운드 연결을 시작할 수 있지만, 공용 인터넷의 관점에서 보면 라우터에는 자기 자신의 주소가 없습니다. (Carrier-grade NAT — Wikipedia)

CGNAT는 어떻게 MikroTik로의 인바운드 접속을 차단하는가?

일반적인 포트 포워딩은 WAN 인터페이스가 인터넷의 나머지 부분이 도달할 수 있는 공인 IP를 가지고 있다고 가정합니다. CGNAT 환경에서는 그 가정이 두 가지 면에서 실패합니다. 첫째, WAN 주소가 사설(흔히 100.64.x.x)이므로, MikroTik에서 포워딩한 포트는 캐리어 외부의 누구도 라우팅할 수 없는 주소를 가리킵니다. 둘째, 실제 공인 IP는 ISP의 마스터 NAT 장비에 있으며, 이는 수십 명의 다른 가입자와 공유되고 임의의 인바운드 포트를 여러분에게 포워딩해 주지 않습니다. 여러분이 그것을 제어하지 못하기 때문입니다. (Open Port Checkers — Why port forwarding fails with CGNAT)

라우터 장비군을 운영하는 사람에게 실질적인 결과는 심각합니다. 인바운드 경로가 없기 때문에 사무실에서 고객의 MikroTik에 Winbox, WebFig, SSH 또는 API로 접속할 수 없습니다. 동적 DNS 호스트명도 도움이 되지 않습니다. 그것은 여러분의 라우터가 아니라 공유 캐리어 IP로 해석되기 때문입니다. 이것은 Starlink 사용자가 부딪히는 것과 같은 벽이며, 자세한 내용은 Starlink IP 변경 사례 연구에서 다룹니다.

MikroTik가 CGNAT 뒤에 있는지 어떻게 알 수 있는가?

WAN 인터페이스의 주소를 확인하고, 그 연결이 실제로 인터넷에 보여주는 공인 IP와 비교하세요. Winbox 또는 WebFig 터미널에서:

/ip address print

WAN 인터페이스가 100.64.0.0 – 100.127.255.255(공유 대역 100.64.0.0/10), 10.0.0.0/8, 또는 다른 RFC1918 사설 대역 내부의 주소를 가지고 있다면, 거의 틀림없이 CGNAT 뒤에 있는 것입니다. 그 주소를 외부 “내 IP 확인” 서비스가 보고하는 것과 비교해 확인하세요. 둘이 다르다면 캐리어 NAT가 여러분과 인터넷 사이에 있는 것입니다. 첫 번째 공인 홉 이전에 하나 이상의 사설 홉을 보여주는 traceroute도 또 하나의 강력한 신호입니다. (oneuptime — How to detect if you are behind CGNAT)

CGNAT 뒤의 MikroTik 라우터를 어떻게 관리하는가?

지속 가능한 해결책은 안으로 접속하려는 시도를 멈추고, 대신 라우터가 안정적인 공인 주소를 가진 랑데부 지점으로 밖으로 접속하게 하는 것입니다. 아웃바운드 연결은 CGNAT 뒤에서 시작되므로, 캐리어의 NAT는 이를 기꺼이 허용합니다. 여러분의 브라우저가 어떤 웹사이트에든 도달하는 것과 같은 방식입니다. 그 터널이 일단 수립되면, 그것을 통해 다시 라우터에 도달합니다. 이를 구축하는 일반적인 방법은 네 가지가 있으며, 각각 별도의 가이드에 문서화되어 있습니다:

VPS로의 자체 호스팅 VPN은 고전적인 방식입니다. 공인 IP를 가진 저렴한 Linux VPS가 만남의 지점 역할을 하고, 각 MikroTik가 여기에 접속합니다. WireGuard는 현대의 기본 선택입니다. 빠르고, CPU 사용이 적으며, CGNAT 및 동적 IP에 따르는 주소 변경에 잘 견딥니다. 더 폭넓은 VPS 기반 관리 가이드는 다른 터널 유형으로 같은 개념을 다룹니다.

관리형 메시 VPN은 대부분의 수작업을 제거합니다. Tailscale와 ZeroTier는 모두 NAT 통과와 키 배포를 대신 처리하는 컨트롤 플레인을 제공하므로, CGNAT 뒤의 라우터가 장비별 설정을 거의 하지 않고도 네트워크에 합류합니다.

TR-069 / ACS 플랫폼은 대규모로 운영할 때의 통신사 표준 옵션입니다. CPE가 자동 구성 서버로 아웃바운드 세션을 열면, 서버가 설정과 펌웨어를 푸시합니다. 이것은 캐리어 NAT 뒤에 있는 가입자 장비를 관리하기 위해 특별히 만들어졌습니다.

전용 관리 클라우드는 아웃바운드 터널 개념을 모니터링 및 접근 제어와 한곳에 결합하며, 이것이 MKController의 NATCloud가 사용하는 모델입니다.

팁

• IPv6는 흔히 CGNAT를 완전히 우회합니다. ISP가 라우팅 가능한 IPv6 프리픽스를 할당하면, IPv4가 캐리어 NAT 뒤에 갇혀 있는 동안에도 IPv6를 통해 라우터에 도달할 수 있을지도 모릅니다. 단, 관리 경로의 모든 홉도 IPv6를 갖추고 있어야 합니다.
• 아웃바운드 터널에는 항상 킵얼라이브를 설정하세요(예: WireGuard의 persistent-keepalive=25). 그래야 캐리어가 유휴 상태의 NAT 매핑을 조용히 끊지 않습니다.
• 일부 ISP는 유료 부가 옵션으로 고정 또는 공인 IPv4 주소를 판매합니다. 단일 중요 사이트의 경우 터널보다 더 간단할 수 있지만, 장비군에서는 비용 면에서 확장되지 않습니다.
• “임시방편”으로 Winbox, WebFig 또는 SSH를 인터넷에 직접 노출하지 마세요. CGNAT 뒤에서는 어차피 동작하지 않으며, 실제 공인 IP에서는 공격자에게 보내는 상시 초대장이 됩니다.

FAQ

동적 DNS 서비스가 CGNAT를 해결하나요? 아닙니다. 동적 DNS는 단지 호스트명을 여러분이 가진 공인 IP로 가리키도록 업데이트할 뿐입니다. CGNAT 뒤에서는 그 공인 IP가 캐리어에 속하고 공유되므로, 호스트명이 여러분의 라우터에 도달할 수 없습니다.

CGNAT가 내 라우터의 NAT와 같은 것인가요? 아닙니다. 여러분 라우터의 NAT는 사설 LAN을 WAN 주소로 변환하며, 여러분이 그 포트 포워드 규칙을 제어합니다. CGNAT는 여러분이 제어하지 못하는 두 번째 NAT를 ISP 내부에 추가하며, 이것이 인바운드 포워딩이 깨지는 이유입니다.

그냥 ISP에 끄라고 요청하면 되나요? 때때로요. 많은 사업자가 유료로 또는 요청 시 공인 또는 고정 IPv4 주소를 제공합니다. 가용성과 가격은 캐리어와 지역에 따라 크게 다릅니다.

다음 단계로 나아가기

라우터 하나에 대해 직접 터널을 구축하는 것은 간단합니다. 수십 또는 수백 대의 MikroTik에 걸쳐 — 각각이 서로 다른 CGNAT 캐리어 뒤에 있고, 회전시킬 키와 돌봐야 할 VPS 설정이 있는 상태에서 — 그것을 하는 것이 운영 비용이 쌓이는 지점입니다.

MKController의 NATCloud는 바로 이것을 위해 만들어졌습니다. 각 MikroTik는 컨트롤 플레인으로의 아웃바운드 터널을 통해 온라인이 되며, 공인 IP도, 포트 포워딩도, 장비별 VPS 편집도 필요하지 않습니다. 캐리어 NAT 깊숙이 묻혀 있는 라우터까지 포함해, 모든 라우터에 대한 중앙 집중식 모니터링과 안전한 원격 접속을 얻게 됩니다.

MKController 무료 체험 시작하기