obsidian/history/2026-04-24-cf-pseudo-ipv4-discovery.md at main

Files

kaffa 102da9c2fe cloudflare: Pseudo IPv4 (Class E 240/4) 정리 — Netbis 관찰 기반

- infra/security/cloudflare.md: Pseudo IPv4 섹션 신규 (동작 원리·모드·함의·오해 주의)
- services/netbis.md: client_ip 의미에서 부정확한 '254.x 범위' → '240.0.0.0/4' 정정, CF docs 링크
- history: 2026-04-24 CF Pseudo IPv4 정체 규명 (CGNAT 오진 교훈 포함)

2026-04-24 08:11:44 +09:00

4.9 KiB

Raw Permalink Blame History

title, updated, tags

title

updated

배경

Netbis NPM → zlambda → VictoriaLogs 로그 파이프라인이 2026-04-23 구축 + 실 client IP 추출 VRL transform 정비 완료 직후, VL top client_ip 집계에서 **240.0.0.0/4 (클래스 E, "Reserved for Future Use") 대역이 전체 트래픽의 45%**를 차지하는 현상 관찰.

초기 오진

처음에는 "한국 모바일 통신사의 CGNAT 240/4 활용" 으로 추정하고 답변
근거로 UA 95%+ 모바일 + KR 앱 브랜드(KakaoTalk/Daum/NAVER)
이 추정은 틀렸음. 공식 문서·RFC·APNIC/IETF 검색 결과 KR 통신사가 240/4를 CGNAT에 사용한다는 기록 없음

실제 원인 — CF Pseudo IPv4

Cloudflare 공식 Pseudo IPv4 문서 및 Support 문서 확인:

"Cloudflare uses Class E IP space (240.0.0.0 - 255.255.255.255) for these addresses. The Pseudo IPv4 service uses a hashing algorithm applied to top 64 bits of the connecting IPv6 address" "overwrite the existing Cf-Connecting-IP and X-Forwarded-For headers with a Pseudo IPv4 address"

즉:

IPv6 클라이언트 → CF 엣지
  → IPv6 상위 64비트 MD5 해시 → 240/4 매핑
  → CF-Connecting-IP 및 X-Forwarded-For 헤더 값 overwrite
  → NPM의 real_ip_header CF-Connecting-IP 설정 → $remote_addr에 240/4 기록
  → Vector VRL → VL의 client_ip 필드에 240/4 저장

Netbis 조건과 완벽 일치:

백엔드 Apache 2.4.38 + PHP 5.6.40 (IPv6 지원 미흡한 레거시)
모바일 트래픽 비율 높음 (모바일 = IPv6 비율 높음)
CF 대시보드에서 Pseudo IPv4 Overwrite headers 모드 활성 상태

검증 증거

로그 필드 샘플 5건 공통 패턴:

client_ip       = 240/4 범위 값
xff_chain       = 동일 값 (CF가 두 헤더 모두 overwrite)
cf_edge_ip      = 172.70.x 등 CF 대역
client_ip_source = remote_addr

UA 분포 (1h, 240/4 IP 한정):

Android (Chrome):   15,469 (67%)
iPhone (Safari):     4,694 (20%)
Daum/Kakao 앱:       1,512
KakaoTalk:             962
NAVER:                 573
Windows:               591 (2.6%)
Mac:                     3 (0.01%)

데스크톱 2.6%뿐 — 모바일 IPv6 비율 높음과 부합.

함의

차단 영향 범위

240/4 IP 하나 = 단일 IPv6 /64 prefix 전체의 해시 결과
한 가정 IPv6 /64는 수십~수백 디바이스·수년 SLAAC 주소 포함
따라서 240/4 IP ban = 한 가정/기업의 모든 IPv6 디바이스 장기간 차단 위험
CGNAT(수천 유저)보다는 좁지만 단일 IP로 간주하면 오탐 증폭

봇 탐지 관점

역설적으로 현재 Overwrite 모드가 IPv6 봇넷 탐지에 유리
IPv6 프라이버시 확장으로 수천 주소 돌리는 봇도 같은 /64면 같은 240/4 하나로 collapse
진짜 IPv6를 받았다면 매번 다른 주소라 탐지 훨씬 어려웠을 것
단 /64 차단 = 해당 prefix의 정상 유저 동반 차단 → ban duration을 짧게(10~30분) 유지 권장

시나리오/ML feature

240/4 IP를 "가상 식별자"로 그대로 사용 가능 (결정적 해시이므로)
CGNAT 플래그로 분류 금지 — 잘못된 분류로 처리 로직 왜곡됨
필요 시 Pseudo IPv4 모드를 "Add header"로 전환해 실 IPv6 확보 가능 (백엔드 IPv6 처리 여부 선행 확인 필수)

대안 경로 (추후 결정사항)

조치	효과	리스크
현상 유지 (Overwrite)	레거시 백엔드 호환 유지	240/4 해석·ban 설계에 주의 필요
Add header 모드 전환	CF-Connecting-IP에 실 IPv6, 별도 헤더에 240/4	PHP 5.6 IPv6 주소 문자열 처리 검증 필요
백엔드 IPv6 업그레이드	근본 해결	애플리케이션 호환 작업 대규모

정본 반영

infra/security/cloudflare.md — Pseudo IPv4 (Class E 240/4) 섹션 신규
services/netbis.md — client_ip 의미 설명 정정 (254.x → 240/4, 메커니즘 링크)

참고 자료

오진 교훈

UA 분포만으로 "CGNAT"로 단정 금지 — Pseudo IPv4가 모바일 IPv6 해시 결과이므로 같은 시그널이 나옴
예약 대역 IP 관찰 시 먼저 CF 엣지 기능(Pseudo IPv4, IP anonymization 등) 가능성부터 확인
공식 벤더 문서 확인이 UA·트래픽 패턴 추론보다 선행되어야 함

4.9 KiB Raw Permalink Blame History

배경