/24はなぜ254台なのか
한국어 원문으로 표시합니다.
한 줄 요약
CIDR 은 IP 주소의 앞쪽 몇 비트가 네트워크인지를 적는 표기입니다. 이 숫자 하나가 그 네트워크에 몇 대가 들어갈 수 있는지를 정합니다.
왜 이게 필요했나
VPC 를 만들 때 10.0.0.0/16 을 넣으라는 안내를 그대로 따라 하면 당장은
됩니다. 문제는 2년 뒤입니다.
- 다른 팀 VPC 와 주소가 겹쳐 피어링이 안 된다
- 온프레미스 대역과 겹쳐 VPN 연결이 안 된다
- 인수한 회사와 겹쳐 통합이 막힌다
주소 대역은 나중에 못 바꿉니다. 자원을 전부 새로 만들어 옮겨야 합니다. 그래서 처음에 계획을 세우는 값이 다른 어떤 결정보다 큽니다.
비트로 세는 법
IPv4 주소는 32비트입니다. /24 는 앞 24비트가 네트워크라는 뜻이고,
남은 8비트가 호스트 자리입니다.
10.0.1.0/24
└─ 네트워크 24비트 ─┘└ 호스트 8비트 ┘
호스트 자리 = 32 − 24 = 8비트 → 2^8 = 256개 주소
256개인데 왜 254대일까요. 첫 주소는 네트워크 주소, 마지막은 브로드캐스트 주소라 쓸 수 없습니다. 그래서 254.
클라우드는 여기서 더 뺍니다. AWS 는 서브넷마다 5개를 예약합니다
(네트워크, VPC 라우터, DNS, 예비, 브로드캐스트). 그래서 /24 서브넷의
실제 가용 IP 는 251개입니다. 이걸 모르고 250대를 계획하면 아슬아슬해집니다.
| CIDR | 전체 주소 | AWS 가용 |
|---|---|---|
| /28 | 16 | 11 |
| /27 | 32 | 27 |
| /26 | 64 | 59 |
| /24 | 256 | 251 |
| /22 | 1,024 | 1,019 |
| /20 | 4,096 | 4,091 |
| /16 | 65,536 | — (VPC 최대) |
외우는 요령: /24 가 256이고, 프리픽스가 1 줄어들 때마다 두 배입니다.
/23 = 512, /22 = 1,024. 반대로 1 늘면 절반입니다.
사설 대역
RFC 1918 이 정한 세 구간만 사내에서 씁니다.
| 대역 | 크기 | 흔한 용도 |
|---|---|---|
10.0.0.0/8 |
1,677만 | 큰 조직. 클라우드 VPC 대부분 |
172.16.0.0/12 |
104만 | 도커 기본 브리지가 여기 |
192.168.0.0/16 |
6.5만 | 가정용 공유기 |
172.17.0.0/16 이 도커의 기본 브리지 대역이라는 사실이 실무에서 자주
사고를 냅니다 — 사내망을 172.17.x.x 로 쓰면 컨테이너 안에서 그 주소로
못 갑니다.
계획을 세우는 순서
- 전체 예산을 크게 잡는다 — 조직 전체에
10.0.0.0/8을 배정해 두고 시작합니다. 주소는 공짜입니다. 아끼는 것이 이득이 아닙니다. - 환경별로 자른다 — 운영
10.0.0.0/12, 스테이징10.16.0.0/12, 개발10.32.0.0/12처럼 겹치지 않게. - 리전별로 자른다 — 리전마다 다른 대역. 나중에 리전 간 연결이 쉬워집니다.
- VPC 는 넉넉하게 —
/16이 기본값처럼 쓰입니다. 6.5만 주소면 대개 충분합니다. - 서브넷은 용도별로 — 아래에서 다룹니다.
- 온프레미스·파트너 대역을 문서에 적는다 — 나중에 연결할 대역과 겹치면 안 됩니다.
겹치면 무슨 일이 생기나
두 VPC 가 같은 10.0.0.0/16 을 쓰면 피어링이 불가능합니다. 라우팅
테이블이 같은 목적지를 두 곳으로 보낼 수 없기 때문입니다. 해결책은 한쪽을
새 대역으로 옮기는 것뿐이고, 그건 사실상 재구축입니다.
그래서 조직에 IP 대역 대장이 있어야 합니다. 스프레드시트 한 장이면 충분하고, 없으면 반드시 사고가 납니다.
계산을 빨리 하는 법과 실수하는 자리
CIDR 계산은 손에 익으면 몇 초면 되고, 안 익으면 매번 계산기를 찾게 된다. 외울 것은 두 줄뿐이다.
주소 수는 2^(32-prefix). /24 는 256개, /23 은 512개, /25 는 128개다.
프리픽스가 1 줄면 두 배가 된다.
경계는 그 크기의 배수에서만 시작한다. /24 는 셋째 옥텟이 아무 값이나 되지만,
/23 은 셋째 옥텟이 짝수여야 하고, /22 는 4의 배수여야 한다.
10.0.3.0/23 은 잘못된 표기이고 실제로는 10.0.2.0/23 을 뜻하게 된다. 이것이
가장 흔한 실수다.
| 프리픽스 | 주소 수 | 셋째 옥텟이 될 수 있는 값 |
|---|---|---|
| /24 | 256 | 아무 값 |
| /23 | 512 | 0, 2, 4, … |
| /22 | 1024 | 0, 4, 8, … |
| /20 | 4096 | 0, 16, 32, … |
클라우드는 앞뒤로 몇 개를 가져간다. 대부분의 클라우드가 서브넷마다 5개를
예약한다(네트워크 주소, 게이트웨이, DNS, 예비, 브로드캐스트). /28 은 16개인데
쓸 수 있는 것은 11개다. 작은 서브넷을 쪼갤수록 이 손실 비율이 커진다.
겹치는지 보려면 큰 쪽의 프리픽스로 자른다. 10.1.0.0/16 과
10.1.128.0/17 이 겹치는지는, 뒤의 것을 /16 으로 잘라 10.1.0.0 이 나오는지
보면 된다. 나오면 겹친다.
python3 -c "
import ipaddress as ip
a = ip.ip_network('10.1.0.0/16'); b = ip.ip_network('10.1.128.0/17')
print(a.overlaps(b), list(a.subnets(new_prefix=18))[:2])"
계획서에 남길 것은 대역이 아니라 규칙이다. "어느 팀이 어느 대역을 쓴다" 는 표는 곧 낡는다. "리전마다 /16, AZ 마다 /20, 용도마다 /24" 처럼 다음 사람이 스스로 고를 수 있는 규칙을 적어 두면 표를 안 봐도 충돌하지 않는다.
현장에서 만나는 모습
- 두 팀이 각자
10.0.0.0/16으로 VPC 를 만들었고, 1년 뒤 두 서비스를 붙여야 할 때 피어링이 거부됐습니다. 한쪽을 새 대역으로 재구축했습니다. - 사내망을
172.17.x.x로 쓰는 회사에서 컨테이너 안에서만 사내 API 가 안 됐습니다. 도커 기본 브리지와 겹친 것이었고, 증상이 컨테이너에서만 나타나 원인을 찾는 데 며칠이 걸렸습니다. - 서브넷을
/28로 잘게 잘라 두었다가 파드가 늘면서 IP 가 말랐습니다. 16개처럼 보였지만 실제로 쓸 수 있는 것은 11개였습니다. - 인수한 회사와 대역이 겹쳐 시스템 통합이 반년 밀렸습니다. 스프레드시트 한 장만 있었으면 처음부터 피했을 일입니다.
다음에 볼 것
VPC 안을 서브넷으로 쪼개고, 무엇을 어디에 놓을지 정합니다.