IPv4 주소 변환기

사설 IP 대역 — 172 대역에서 자주 틀립니다

주소를 넣으면 사설·공인·루프백 같은 판정이 칩으로 표시됩니다. 사설 대역은 인터넷으로 라우팅되지 않는, 즉 누구나 자기 내부망에서 마음대로 쓸 수 있는 주소입니다.

CGNAT(100.64/10) — 접속자 IP를 믿으면 안 되는 이유

100.64.0.0/10 은 사설도 공인도 아닌 통신사 전용 공유 대역입니다. IPv4 주소가 고갈되어 통신사가 여러 가입자에게 공인 IP 하나를 나눠 쓰게 하면서 생겼습니다. 국내 모바일 데이터와 일부 인터넷 회선에서 실제로 이 대역을 받습니다.

실무에서 이게 왜 문제냐면, 접속자 IP 하나가 사람 한 명을 뜻하지 않게 되기 때문입니다. 어뷰징을 막겠다고 IP를 차단하면 같은 통신사 NAT를 쓰는 무고한 사용자 수백 명이 함께 막힙니다. 반대로 "같은 IP니까 같은 사람"이라는 판정도 틀립니다. 로그인 이력의 IP가 자꾸 바뀌는 것 역시 정상입니다 — 모바일에서는 NAT 세션이 바뀌면 IP가 바뀝니다.

• IP 기반 차단은 짧은 시간의 속도 제한 정도로만 쓰고, 영구 차단의 근거로 삼지 마세요.
• 중복 참여·어뷰징 판정은 IP가 아니라 계정·기기·전화번호 인증으로 하세요.
• CGNAT 뒤에서는 포트 포워딩이 불가능합니다. 집 서버에 외부 접속이 안 된다면 이 대역인지부터 확인하세요.
• 169.254 로 시작하는 주소가 보이면 DHCP를 못 받아 스스로 붙인 주소입니다. 즉 네트워크가 안 되고 있다는 신호입니다.

IP를 정수로 저장하는 이유 (DB 실무)

192.168.0.1 은 사람을 위한 표기이고 실체는 32비트 정수 3232235521 입니다. 이 도구가 두 표현을 오가는 이유는 DB에서 정수가 압도적으로 유리하기 때문입니다. VARCHAR(15)로 15바이트를 쓰는 대신 4바이트면 되고, 무엇보다 범위 검색이 인덱스를 탑니다. 문자열로 저장하면 "이 IP가 이 대역에 속하는가"를 LIKE로 흉내 내야 하는데 정확하지도 빠르지도 않습니다.

-- 반드시 UNSIGNED. 그냥 INT면 128.0.0.0 이상이 음수가 되어 조회가 조용히 틀어집니다
CREATE TABLE access_log (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  ip INT UNSIGNED NOT NULL,
  ts DATETIME NOT NULL,
  INDEX idx_ip_ts (ip, ts)
);

-- 저장 / 조회
INSERT INTO access_log (ip, ts) VALUES (INET_ATON('192.168.0.1'), NOW());
SELECT INET_NTOA(ip) FROM access_log WHERE id = 1;

-- 대역 검색이 인덱스를 탄다 (192.168.0.0/24 안의 접속)
SELECT COUNT(*) FROM access_log
 WHERE ip BETWEEN INET_ATON('192.168.0.0') AND INET_ATON('192.168.0.255');

0으로 시작하는 주소가 왜 위험한가

이 도구는 점 표기, 정수, 16진수, 2진수, 8진수를 자동으로 알아봅니다. 로그나 코드에서 3232235521 이나 0xC0A80001 같은 값을 마주쳤을 때 되돌려 보라고 만든 기능인데, 여기엔 알아둘 만한 함정이 하나 있습니다.

많은 시스템이 0으로 시작하는 숫자를 8진수로 해석합니다. 010.1.1.1 을 어떤 라이브러리는 10.1.1.1 로, 어떤 라이브러리는 8.1.1.1 로 읽습니다. 이 차이가 실제 보안 사고로 이어집니다 — 검증 코드는 "10.x 사설망이 아니니 통과"라고 판단했는데 실제 요청은 전혀 다른 곳으로 나가는 식입니다. 서버가 사용자에게 받은 주소로 요청을 보내는 기능(SSRF 방어)에서 이 불일치를 노린 우회가 알려져 있고, 널리 쓰이던 IP 파싱 라이브러리에 이 문제로 취약점이 보고된 적도 있습니다.

PTR 레코드와 클래스 표시에 대하여

결과에 나오는 in-addr.arpa 주소는 리버스 DNS(PTR) 조회에 쓰는 이름입니다. 옥텟을 거꾸로 뒤집는 게 규칙이라 헷갈리기 쉬운데 이 도구가 뒤집어 줍니다. 실무에서 이게 중요해지는 대표적인 곳이 자체 메일 서버입니다 — 발송 IP에 PTR이 없거나 도메인과 안 맞으면 수신 측이 스팸으로 처리하거나 아예 거부합니다. SPF·DKIM을 다 맞췄는데 메일이 안 들어간다면 PTR을 확인해 보세요. PTR은 IP를 할당한 쪽(호스팅 업체·통신사)에 요청해야 설정됩니다.

클래스 A/B/C 표시는 역사적 개념입니다. 1993년 CIDR이 도입되면서 실제 라우팅은 클래스가 아니라 프리픽스 길이로 결정됩니다. 옛 문서나 자격증 문제에 나오니 참고용으로 표시하지만, "이 주소는 클래스 C니까 /24"라는 추론은 지금 네트워크에서 성립하지 않습니다.

# PTR 조회 — 이 도구가 만든 이름을 그대로 확인
dig -x 8.8.8.8 +short
nslookup 8.8.8.8