WAF는 CGNAT로 인해 고객을 차단합니다: 모바일 IP로 6번의 검사

모바일 트래픽의 전환율이 갑자기 떨어지고, 실제 고객이 등록 또는 결제 양식에서 403 오류를 받는다면, 그 원인은 해커가 아니라 귀하의 WAF일 가능성이 높습니다. 방화벽은 하나의 모바일 통신사 IP 주소에서 수천 개의 요청을 감지하고 이를 DDoS 또는 브루트포스 공격으로 간주합니다. 실제로는 이 IP 뒤에 수백 또는 수천 명의 일반 사용자가 있습니다 — 이것이 CGNAT 기술입니다. 이를 발견하고 수정하는 방법을 알아보겠습니다. 실제 공격에 대한 구멍을 열지 않으면서 말입니다.

CGNAT란 무엇이며 왜 문제가 되는가

CGNAT (Carrier-Grade NAT)는 모바일 통신사들이 IPv4 주소 부족으로 인해 사용하는 기술입니다. 각 가입자에게 고유한 공용 IP를 할당하는 대신, 통신사는 수천 명의 사용자를 하나 또는 여러 개의 공용 주소 뒤에 "숨깁니다". 웹사이트에서는 하나의 IP에서 수백 명의 다양한 사람들이 동시에 트래픽을 보내는 것처럼 보입니다 — 다양한 장치, 다양한 브라우저, 다양한 행동, 그러나 동일한 외부 주소입니다.

일반 웹 서버에게는 문제가 되지 않습니다 — 요청을 처리하기만 하면 됩니다. 그러나 IP에서 시간당 요청 수를 계산하는 보안 시스템에게는 이것이 이상 현상으로 보입니다. 상상해 보세요: 1분 동안 하나의 주소에서 로그인 페이지에 200개의 요청이 들어옵니다. WAF에게는 이것이 전형적인 브루트포스 또는 스크래핑 패턴입니다. 그러나 실제로는 귀하의 지역에 있는 한 모바일 통신사의 150명의 실제 고객이 광고 메일이나 소셜 미디어 게시물 후에 동시에 웹사이트를 열었을 수 있습니다.

특히 모바일 인터넷 밀도가 높은 국가에서는 이 문제가 더욱 두드러집니다 — 통신사들은 최소한의 외부 IP로 대량의 가입자를 통합합니다. 따라서 웹사이트의 행동을 테스트할 때는 일반 데이터 센터 IP가 아니라 모바일 프록시를 사용해야 합니다. 이는 실제로 통신사의 CGNAT 인프라를 통과하는 트래픽을 통해 WAF가 실제 사용자에게서 보는 것과 동일한 패턴을 재현할 수 있습니다.

WAF가 CGNAT를 위협으로 보는 이유

대부분의 WAF 솔루션 — Cloudflare, AWS WAF, Imperva, Nginx/ModSecurity의 내장 모듈 — 는 IP 주소에 대한 비율 제한을 기본적인 봇 및 DDoS 방어 메커니즘으로 사용합니다. 논리는 간단합니다: 하나의 IP에서 N개의 요청이 T초 동안 발생하면 — 차단하거나 CAPTCHA를 표시합니다. 이 규칙은 전형적인 장치에서의 공격에 대해 잘 작동하지만 CGNAT 트래픽에서는 완전히 무너지게 됩니다.

다음은 이러한 상황에서 발생할 수 있는 몇 가지 전형적인 시나리오입니다:

IP에 대한 비율 제한. "하나의 IP에서 분당 100개의 요청" 제한은 데이터 센터 트래픽에는 정상적이지만, 하나의 주소 뒤에 백만 명의 가입자가 있는 모바일 지역에서는 재앙적입니다.
행동 점수 매기기. 시스템이 요청 기록을 기반으로 IP의 "평판"을 축적하는 경우, CGNAT 뒤의 하나의 "나쁜" 사용자가 수천 명의 이후 정직한 고객을 위한 주소의 평판을 망칠 수 있습니다.
지리적 휴리스틱. WAF는 때때로 "일반적인" 사용자에게 적합하지 않은 활동의 급격한 증가를 감지하면 IP를 의심스럽게 표시합니다 — CGNAT 주소의 행동이 바로 그러합니다: 사용자 활동 시간대의 피크 부하.
운영자 ASN에 따른 차단. 일부 WAF 규칙은 이전에 공격이 있었던 모바일 운영자의 전체 ASN 범위를 차단합니다 — 이로 인해 해당 국가의 모든 운영자 고객이 피해를 입습니다.

결론: WAF가 "기본 설정"으로 더 엄격하게 설정될수록, 봇이 아닌 실제 모바일 청중을 차단할 가능성이 높아집니다 — 특히 비즈니스가 모바일 인터넷이 발전하고 CGNAT 트래픽 비율이 높은 국가를 대상으로 하는 경우에는 더욱 그렇습니다.

비즈니스에 미치는 영향: 잃어버린 고객과 돈

CGNAT 차단 문제는 표준 분석에서 잘 보이지 않습니다. Google Analytics와 Yandex.Metrica는 WAF 수준에서 403 오류를 받은 사용자를 기록하지 않습니다 — 이러한 방문은 종종 카운터에 도달하지도 않습니다. 결과적으로 마케팅 담당자는 전환율 하락을 보지만 그 원인을 이해하지 못하고, 문제는 인프라에 있음에도 불구하고 광고 소재와 랜딩 페이지를 최적화하기 시작합니다.

다양한 비즈니스 세그먼트에 대한 실제 결과는 다음과 같습니다:

전자상거래. 모바일 인터넷 사용자가 주문을 완료할 수 없습니다 — 결제 양식에서 오류가 발생하고, 장바구니가 사라집니다. TikTok Ads 또는 Facebook Ads에서 광고를 시작한 후 특히 눈에 띄는 직접적인 수익 손실이 발생합니다.
SaaS 및 등록. 사용자가 등록하거나 개인 계정에 로그인하려고 할 때, 매 단계마다 CAPTCHA를 받거나 차단됩니다 — 경쟁업체로 떠납니다.
콘텐츠 및 광고. 모바일 장치에서의 광고 트래픽이 랜딩 페이지에서 대량으로 "탈락"하고, 광고 예산이 소모되지만 전환이 없습니다 — 광고 플랫폼의 알고리즘은 이를 낮은 품질의 청중으로 해석하고 클릭 비용을 높입니다.
고객 지원. "귀하의 웹사이트가 열리지 않습니다", "등록할 수 없습니다"라는 문의가 증가합니다 — 그러나 기술 지원팀은 CGNAT 없이 사무실 Wi-Fi를 통해 데스크톱에서 접속하기 때문에 문제를 보지 못합니다.

가장 불쾌한 점은 이러한 차단을 사후에 진단하기 어렵다는 것입니다. WAF 로그는 수많은 요청을 가진 하나의 "의심스러운" IP를 보여주고, 관리자는 이를 차단의 정당성으로 확인하게 되며, 잘못된 경고로 인식하지 않습니다.

문제를 찾기 위한 모바일 IP로 6가지 점검

귀하의 WAF가 정직한 모바일 고객을 차단하는지 이해하려면 CGNAT의 실제 조건을 재현해야 합니다 — 즉, 다양한 운영자와 지역의 실제 모바일 IP로 웹사이트를 테스트해야 합니다. 다음은 6가지 점검의 실용적인 체크리스트입니다.

점검 1: 하나의 모바일 IP에서 대량 접속

하나의 모바일 IP를 통해 여러 개의 병렬 세션을 설정하고 (이는 CGNAT 운영자의 프록시에서 자연스럽습니다) 50-100개의 일반적인 작업을 수행합니다 — 페이지 열기, 장바구니에 추가, 섹션 간 전환. 특정 한계 이상에서 CAPTCHA 또는 403이 나타나기 시작하면 이는 문제의 첫 번째 신호입니다.

점검 2: 하나의 IP에서 User-Agent 변경

하나의 CGNAT 주소는 다양한 장치를 처리합니다 — iPhone, Android, 다양한 브라우저. 하나의 IP를 통해 다양한 User-Agent 문자열로 요청을 실행하고, WAF 규칙 "하나의 주소에서 의심스러운 장치 변동성"이 활성화되지 않는지 확인합니다.

점검 3: 중요한 양식 테스트

고객의 전체 경로를 진행합니다 — 등록, 인증, 주문 완료, 결제 — 바로 모바일 운영자의 IP를 통해. WAF는 종종 데이터 입력이 있는 양식(로그인, 결제)에서 더 공격적으로 설정되어 있으며, 이는 실제 고객이 가장 먼저 잃어버리는 곳입니다.

점검 4: 다양한 운영자 및 지역에서의 점검

CGNAT의 행동은 다양한 운영자와 국가에 따라 다릅니다 — 어떤 곳에서는 하나의 IP 뒤에 50명의 가입자가 숨겨져 있고, 어떤 곳에서는 5000명이 숨겨져 있습니다. 비즈니스에 중요한 지역에서 여러 운영자의 모바일 IP로 웹사이트를 테스트하여 차단의 지역적 특성이 있는지 확인합니다.

점검 5: 코드 및 헤더에 따른 서버 응답 분석

단순히 차단 사실을 기록하는 것이 아니라, 정확한 HTTP 코드와 응답 헤더를 기록합니다 (예: cf-mitigated: challenge Cloudflare에서). 이는 어떤 방어 메커니즘이 작동했는지 이해하는 데 도움이 됩니다 — 비율 제한, 봇 감지 또는 지리적 규칙.

점검 6: IP 평판의 장기 모니터링

동일한 모바일 IP에서 여러 날 동안 테스트를 반복합니다. 시간이 지남에 따라 귀하의 측면에서 명백한 이유 없이 접근이 악화된다면 — 이는 누적 점수 시스템이 동일한 CGNAT 뒤의 다른 가입자의 활동으로 인해 주소의 평판을 "손상"시키고 있다는 것을 의미하며, 이는 일회성이 아닌 시스템적인 문제입니다.

중요한 점:

이러한 테스트에는 실제 모바일 IP가 필요하며, 데이터 센터 IP나 일반 거주지 주소가 아닙니다 — 통신사의 인프라를 통과한 트래픽만이 귀하의 WAF가 실제 사용자에게서 보는 CGNAT 패턴을 정확하게 재현합니다.

정직한 고객을 차단하지 않도록 WAF 설정하기

진단 후, 보안 수준을 잃지 않으면서 실제 모바일 사용자를 차단하지 않도록 방어 규칙을 조정해야 합니다. 다음은 주요 접근 방식입니다.

문제	WAF의 해결책
엄격한 IP 비율 제한	알려진 모바일 운영자의 ASN에 대한 제한을 높이거나 순수 IP 대신 세션/쿠키에 대한 제한으로 전환
IP 평판의 누적 점수 매기기	CGNAT 범위에 대한 평판 "기억" 시간을 줄이고, 알려진 운영자의 ASN에 대한 화이트리스트 추가
지리적/ASN 전체 차단	전체 차단을 403 대신 부드러운 챌린지(자바스크립트 검사)로 교체
로그인 양식에서의 엄격한 CAPTCHA	실제 브루트포스 징후(하나의 계정에서 여러 번의 실패한 시도)가 있을 때만 CAPTCHA를 활성화하여 CGNAT-IP에 따라 차단하지 않도록 설정

좋은 방법은 귀하의 주요 지역에 대한 알려진 모바일 운영자 범위의 자체 목록을 유지하고, 일반 인터넷 트래픽에 비해 더 부드러운 규칙을 제공하는 것입니다. 이는 설정에 시간이 걸리지만, 잘못된 차단 수를 크게 줄이는 데 도움이 됩니다.

모바일 프록시로 테스트할 도구들

웹사이트 보안을 정기적으로 감사하기 위해서는 안티 감지 브라우저와 모바일 프록시의 조합을 사용하는 것이 편리합니다. 안티 감지 브라우저(Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser)는 다양한 장치의 지문을 가진 격리된 프로필을 생성할 수 있게 해주며, 모바일 프록시는 운영자로부터 실제 CGNAT 트래픽을 제공합니다.

테스트에 대한 단계별 접근 방식:

안티 감지 브라우저에서 다양한 장치 매개변수를 가진 여러 프로필을 생성합니다 (다양한 User-Agent, 화면 해상도, 시간대).
각 프로필에 모바일 프록시를 연결하여 실제 CGNAT 행동을 제공합니다.
주요 사용자 시나리오를 진행합니다: 등록, 로그인, 장바구니에 추가, 결제.
모든 CAPTCHA, 403 및 기타 차단 사례를 기록하고 WAF 설정과 비교합니다.
비교를 위해 거주지 프록시로 테스트를 반복합니다 — 이는 문제가 모바일 트래픽에 특화된 것인지 이해하는 데 도움이 됩니다.

다양한 지역에서의 병행 테스트를 위해 거주지 프록시도 유용합니다 — 이는 WAF가 일반 가정용 트래픽과 모바일 CGNAT에 대해 얼마나 동일하게 공격적인지를 평가하는 데 도움이 됩니다. 운영자와의 연결 없이 서버 인프라에서 부하 테스트를 계획하는 경우, CGNAT 효과 없이 제어 검사를 위해 데이터 센터 프록시를 연결할 수 있습니다 — 이는 모바일 네트워크의 왜곡 없이 깨끗한 기준선을 제공합니다.

이러한 포괄적인 접근 방식 — 모바일, 거주지 및 데이터 센터 IP를 하나의 테스트에서 사용하는 것 — 은 전체 그림을 제공합니다: 보호가 작동하는 정확한 위치와 어떤 유형의 트래픽에 대해 작동하는지를 명확하게 볼 수 있으며, 로그에서 간접적인 징후를 통해 추측하지 않아도 됩니다.

자주 묻는 질문

WAF 규칙에서 CGNAT 범위를 완전히 제외할 수 있나요?
권장되지 않습니다 — 이는 모바일 네트워크를 통해 발생할 수 있는 실제 공격에 대한 방어를 줄입니다. 더 나은 방법은 임계값을 완화하고 엄격한 차단 대신 부드러운 챌린지로 전환하는 것입니다.

이러한 점검을 얼마나 자주 수행해야 하나요?
최소한 한 달에 한 번, 그리고 WAF 규칙을 변경하거나 모바일 청중을 대상으로 하는 새로운 광고 캠페인을 시작한 후에는 반드시 수행해야 합니다.

이것이 SEO에 영향을 미치나요?
예 — 검색 봇이나 실제 모바일 사용자들이 403 오류를 받으면 이탈률이 증가하고, 이는 순위 메트릭에 부정적인 영향을 미칠 수 있습니다.

결론

CGNAT는 위협이 아니라 모바일 인터넷의 특성으로, 모바일 청중을 가진 거의 모든 비즈니스가 직면하는 문제입니다. 문제는 기술 자체에 있는 것이 아니라, 표준 WAF 설정이 처음부터 이 특성을 고려하지 않고 정직한 사용자를 일반 모바일 네트워크에서의 행동으로 처벌한다는 것입니다. 이 기사에서 제시한 여섯 가지 점검은 잘못된 차단으로 인해 고객을 잃고 있는지 신속하게 진단하는 데 도움이 되며, WAF 규칙의 세부 조정은 보호 수준을 낮추지 않고 전환율을 회복하는 데 도움이 됩니다.

웹사이트와 광고 퍼널의 행동을 실제 모바일 고객이 보는 것처럼 정기적으로 테스트할 계획이라면, 모바일 프록시를 사용하는 것이 좋습니다 — 이는 운영자의 실제 CGNAT 트래픽을 제공하며, 고객이 발견하기 전에 잘못된 차단을 찾는 데 도움이 됩니다.