[3A편] 공유기·NAT·DHCP — 와이파이 비번 입력 후 5초 동안 일어나는 일
마이클의 두 번째 카페
마이클은 그날 평소 가던 카페에 들어가지 않고 길 건너 새 카페에 들어갔다. 자리에 앉아 노트북을 열고, 와이파이 목록에서 카페 SSID 를 골라 비밀번호 한 번 입력했다. 약 4초 후 와이파이 표시가 들어왔고 ChatGPT 가 열렸다.
평소 같으면 그냥 그뿐이었다. 그런데 마이클은 1편에서 5단 동심원을, 2편에서 IP·MAC·패킷 4겹 양파와 TCP·UDP·HTTP 의 진화까지 풀어낸 사람이었다. 그 4초가 갑자기 이상했다.
“내가 비밀번호 한 번만 입력했는데, 노트북이 어떻게 IP 주소를 받았지?”
같은 카페에 다른 손님 노트북도 수십 대 와이파이를 잡고 있었다. 그 IP 들이 어떻게 안 부딪히는지, 누가 정해주는지, 마이클이 직접 IP·서브넷·DNS 같은 숫자를 한 번도 입력한 적이 없는데 어떻게 인터넷이 되는지가 한꺼번에 안 풀렸다.
그날 마이클이 던진 질문은 이거였다.
“와이파이 비번 입력 후 그 4초 동안 무슨 일이 일어나는가.”
마이클은 검색해봤다. 답이 세 단어로 돌아왔다.
“공유기가 NAT·DHCP·ARP 를 처리한다.”
세 단어 다 처음 듣는 단어였다. NAT 는 1편에서 윤곽만 짚고 미뤄둔 자리였고, DHCP·ARP 는 그날 처음 듣는 단어였다. 마이클은 한 단어씩 풀어가기로 했다.
이 의문에서 3A편이 시작한다.
- 공유기 한 대 안에 작은 Linux 컴퓨터가 들어 있다는 사실, 그리고 그 안의 본업 3가지가 무엇인지 손에 잡힌다
- NAT·DHCP·ARP 라는 세 단어가 와이파이 첫 1분에 한꺼번에 작동하는 풍경이 풀린다
- iPhone 의 Private Wi-Fi 가 학교·회사 와이파이에서 안 잡히는 진짜 이유를 자기 입에서 답할 수 있게 된다
공유기의 정체 — 그 검은 박스 안에 무엇이 있는가
마이클이 가장 먼저 던진 의문은 단순했다. 카페·집·사무실 어디에나 있는 그 검은 박스, 안테나가 솟은 그 작은 기기가 정확히 무엇이냐는 거였다.
분해하면 나오는 부품
마이클이 자기 사무실 공유기 (ipTIME BE5100M) 의 스펙 페이지를 열어봤다. 그 안에 박힌 부품은 다음이었다.
[공유기 한 대 안의 풍경]
CPU ARM 1~4 코어, 800MHz~2GHz
RAM 64MB ~ 1GB
플래시 저장소 16MB ~ 256MB (펌웨어 + 설정 저장)
Wi-Fi 칩 2.4GHz / 5GHz / 6GHz 안테나
Ethernet 컨트롤러 WAN 1포트 + LAN 4포트
전력 관리 칩
LED·버튼
마이클은 한 번 더 이상했다. 자기 노트북을 분해했을 때 나오는 부품들과 거의 같았다. CPU·RAM·저장소·통신 칩.
다른 자리는 세 가지였다.
| 부품 | 노트북 | 공유기 |
|---|---|---|
| CPU 클럭 | 2~4 GHz | 800MHz~2GHz |
| RAM | 8~64 GB | 64MB~1GB |
| 저장소 | 256GB~2TB SSD | 16~256MB 플래시 |
성능이 약 수십~수백 배 작았다. 같은 부품, 작게 박힌 풍경. 마이클은 이 한 줄을 잡고 나서 한 가지를 깨달았다.
“공유기는 작은 컴퓨터다.”
지금까지 공유기를 “와이파이 박스” 정도로만 봐왔는데, 사실 작은 PC 한 대가 24시간 켜져 있는 거였다. 그 안에 OS 가 돌고 있어야 한다는 결론이 자연스럽게 따라왔다. 그런데 어떤 OS 인가.
그 안에 도는 OS — 임베디드 Linux
마이클이 검색해봤다. 답이 의외였다. 공유기 안에 Linux 가 돌고 있었다. 스마트폰의 Android 가 Linux 기반인 것과 같은 자리였다.
[공유기 OS]
- 베이스: 임베디드 Linux (커널 4.x ~ 5.x)
- 파일시스템: SquashFS (읽기 전용) + JFFS2 (설정 저장)
- 펌웨어: 제조사가 만든 Linux 배포판
- ASUS: AsusWRT (Linux 기반)
- 넷기어: NETGEAR firmware
- ipTIME: ipTIME OS (Linux 기반)
- 오픈소스: OpenWrt·DD-WRT·Tomato
마이클의 사무실 공유기가 ipTIME BE5100M 이라면, 그 안에 ipTIME 의 Linux 가 돌고 있다. ASUS·NETGEAR·TP-Link 도 다 같은 Linux. 마이클이 가정용 공유기마다 SSH 가 막혀 있어 직접 들어갈 수는 없지만, 일부 모델 (ASUS·OpenWrt 펌웨어) 은 SSH 를 켤 수 있다.
$ ssh admin@192.168.0.1
admin@router:~$ uname -a
Linux router 4.14.180 #1 SMP ... arm
admin@router:~$ ps
PID USER COMMAND
1 root init
234 root hostapd (Wi-Fi 인증 데몬)
456 root dnsmasq (DHCP·DNS 서버)
789 root iptables (방화벽·NAT)
1023 root pppd (ISP 연결)
마이클이 자기 PC 에서 평소 보는 명령어 (ps·uname -a) 가 그대로 통한다. 공유기 안이 진짜 Linux 인 자리.
본업 3가지
공유기 안의 Linux 가 도는 일 중 핵심 세 가지가 있었다.
1. 라우팅 (Routing)
"이 패킷의 다음 hop 은 어디인가" 결정.
Linux 커널의 routing table 이 그 자리.
2. NAT (Network Address Translation)
사설 IP ↔ 공인 IP 변환.
1편의 5단 동심원에서 [2] LAN ↔ [3] ISP 경계의 일.
iptables 가 처리.
3. DHCP (Dynamic Host Configuration Protocol)
새 기기에 IP 자동 부여.
와이파이 비번 입력 후 4초의 안쪽.
dnsmasq 가 처리.
마이클은 이 세 단어가 처음 듣는 단어가 아니었다. NAT 는 1편에서 5단 동심원을 풀 때 윤곽으로 짚었다. DHCP·ARP 는 새 단어였지만, 어쨌든 세 가지 다 한 검은 박스 안에서 동시에 도는 일이었다.
마이클의 작은 깨달음
마이클은 이 시점에서 한 가지를 깨달았다. 자기 사무실 공유기 BE5100M 을 살 때 “Wi-Fi 7” 이라는 단어만 보고 골랐는데, 사실 그 안에 박힌 진짜 자리는 ARM CPU + Linux + 본업 3가지였다. 공유기는 작은 Linux 컴퓨터이고, 본업이 라우팅·NAT·DHCP 다. 이 한 줄을 잡고 나서 다음 자리가 자연스럽게 따라왔다.
“그러면 NAT 가 정확히 어떻게 IP 를 변환하지?”
NAT 정공법 — 사설 IP 와 공인 IP 사이의 변환
마이클이 2A편에서 사설 IP 와 공인 IP 의 차이는 짚었다. 호텔 객실 번호와 호텔 주소의 비유로 풀었다. 그런데 정확히 어떻게 변환되는지, 외부에서 들어오는 응답이 어떻게 다시 자기 노트북으로 돌아오는지, 같은 집의 노트북·아이폰이 같은 공인 IP 인데 어떻게 안 부딪히는지는 미뤄둔 자리였다.
NAT 의 진짜 이름
NAT = Network Address Translation (네트워크 주소 변환)
다만 정확한 이름:
PAT = Port Address Translation
NAPT = Network Address Port Translation
→ NAT 의 본업은 IP 변환만이 X
→ 포트 번호로 어느 기기인지 구분
→ 그래서 NAPT 가 더 정확한 이름
→ 보통 줄여서 NAT 로 부름
마이클이 짚을 자리는 한 줄이었다. NAT 가 단순히 IP 만 바꾸는 게 X. 포트 번호로 어느 기기인지 구분한다. 이 한 줄이 안 풀리면 같은 집의 여러 기기가 어떻게 한 공인 IP 로 동시에 인터넷을 쓰는지 안 풀린다.
마이클이 OpenAI 호출하는 풍경
노트북 (192.168.0.10:52341) 이 공유기 NAT 를 거쳐 공인 IP (211.234.56.78:60001) 로 변환되어 OpenAI 도착. 응답은 같은 길을 역순으로.
마이클이 ChatGPT 에 메시지 보낼 때 패킷의 풍경.
[1단계 — 노트북에서 출발]
src IP: 192.168.0.10 (사설, 노트북)
src 포트: 52341 (노트북이 임의로 정함)
dst IP: 142.250.71.46 (OpenAI)
dst 포트: 443 (HTTPS)
→ 공유기로 흘러감
[2단계 — 공유기 NAT 변환]
공유기가 src 자리만 갈아끼움:
src IP: 211.234.56.78 ← 공인 IP 로 변환
src 포트: 60001 ← 공유기가 임의로 정한 새 포트
dst IP: 142.250.71.46 (그대로)
dst 포트: 443 (그대로)
→ 인터넷으로 나감
[3단계 — OpenAI 가 받음]
OpenAI 가 보는 자리:
"211.234.56.78:60001 에서 요청 옴"
→ 노트북 192.168.0.10 의 자리를 모름
→ 사설 IP 가 외부에 안 노출됨
여기서 마이클은 한 가지가 자연스럽게 이상했다.
“OpenAI 가 응답을 보낼 때, 같은 집의 다른 기기 (아이폰·아이패드) 와 어떻게 안 부딪히지?”
같은 집의 모든 기기가 외부에서 보면 같은 공인 IP (211.234.56.78). 응답이 그 공인 IP 로 돌아오는데, 어느 기기에 가야 하는지 어떻게 정해지는가.
응답이 돌아오는 풍경 — NAT 테이블
답은 공유기 안의 NAT 테이블이었다.
[공유기 안의 NAT 테이블]
| 내부 (사설) | 외부 (공인) | 목적지 |
|------------------------|---------------------|--------------------|
| 192.168.0.10:52341 | 211.234.56.78:60001 | 142.250.71.46:443 |
| 192.168.0.11:48372 | 211.234.56.78:60002 | 142.250.71.46:443 |
| 192.168.0.10:52342 | 211.234.56.78:60003 | 8.8.8.8:53 |
OpenAI 가 응답 보낼 때.
[OpenAI 가 응답 보냄]
src IP: 142.250.71.46
src 포트: 443
dst IP: 211.234.56.78 (공유기 공인 IP)
dst 포트: 60001 (NAT 가 매핑한 포트)
→ 공유기에 도착
[공유기가 NAT 테이블 검색]
"60001 으로 온 응답?"
→ 테이블에서 60001 찾음
→ "192.168.0.10:52341 의 자리"
dst 자리만 갈아끼움:
dst IP: 192.168.0.10 (노트북 사설 IP)
dst 포트: 52341 (노트북이 처음 정한 포트)
→ 노트북으로 흘러감
포트 번호가 결정적이었다. NAT 가 단순히 IP 변환만 하는 게 아니라 포트로 어느 기기인지 구분한다. 그래서 NAPT (Port Translation) 가 더 정확한 이름.
호텔 객실 비유 회수 — 2A 의 자리
마이클이 2A 에서 박은 호텔 객실 비유를 여기서 한 번 더 굴렸다.
호텔 주소 = 공인 IP (호텔 한 채에 하나)
객실 번호 = 사설 IP (방마다 다름)
프론트 = NAT (공유기)
손님이 외부에 우편 보낼 때:
"305호 김씨" → 프론트가 "신라호텔 + 임시 추적 번호" 로 갈아끼움
외부에서 답장 옴 → 추적 번호로 305호 김씨 찾아 전달
→ NAT 테이블 = 프론트의 손님 명부
마이클은 호텔 비유의 결정적 한 자리를 알게 됐다. 비유의 “추적 번호” 가 진짜로는 포트 번호였다는 것. 2A 에서는 윤곽만 잡고 미뤄뒀던 자리가 여기서 풀렸다.
NAT 의 본체 — Linux netfilter
마이클이 “그러면 NAT 가 정확히 어디서 일어나는가” 를 한 번 더 던졌다. 답은 자기 사무실 공유기 안의 Linux 커널이었다.
[공유기 Linux 안의 풍경]
Linux 커널
└─ netfilter (네트워크 패킷 처리)
└─ iptables 또는 nftables (룰 박는 도구)
└─ NAT 룰 박힘 (POSTROUTING 자리)
→ 매 패킷마다 자동 변환
자기 공유기 안에서:
$ iptables -t nat -L POSTROUTING
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.0.0/24 anywhere
이 한 줄이 모든 NAT 의 자리였다. “192.168.0.0/24 (사설 LAN) 에서 나가는 모든 패킷의 src 를 공인 IP 로 갈아끼워라” 라는 명령. 마이클은 이 한 줄을 보고 공유기 = 작은 Linux 컴퓨터 의 의미가 비로소 손에 잡혔다. NAT 의 본체는 Linux 의 netfilter 라는 작은 모듈이었다.
OpenAI 의 결정적 자리 — 한 IP·한 포트로 수백만 명
마이클이 학습 도중에 던진 의문이 있었다.
“OpenAI 가 443 포트 하나로 전 세계 수백만 명을 받나?”
답은 그렇기도 하고 아니기도 했다. 한 IP·한 포트 로 받는 건 맞지만, 그 뒤에 수천 개의 실제 서버가 있다.
[OpenAI 서버 142.250.71.46:443 의 한 순간]
전 세계 사용자 수백만 명이 같은 IP·같은 포트에 접속.
연결 #1: 한국 사용자 A (211.x.x.x:60001) → 142.250.71.46:443
연결 #2: 미국 사용자 B (72.x.x.x:48372) → 142.250.71.46:443
연결 #3: 일본 사용자 C (133.x.x.x:39845) → 142.250.71.46:443
...
연결 #N: 마이클 (211.234.56.78:60001) → 142.250.71.46:443
→ dst 는 다 같음 (142.250.71.46:443)
→ src 가 다 다름
→ 서버가 (src IP, src 포트, dst IP, dst 포트) 4개로 각 연결 구분
이게 4-tuple (네 튜플) 의 결정적 자리였다. TCP 연결 한 개를 식별하는 4개 자리. 하나라도 다르면 다른 연결.
TCP 연결의 식별 자리:
1. src IP
2. src 포트
3. dst IP
4. dst 포트
→ 이 4개가 다 같은 연결은 인류에 단 하나
→ 하나라도 다르면 다른 연결
→ 서버는 한 IP·한 포트로 받아도 4-tuple 로 수백만 동시 처리
다만 142.250.71.46 은 단 한 서버가 아니다. 부하 분산기 (Load Balancer) 의 가상 IP 다. 뒤에 수천 개의 실제 서버가 있고, Load Balancer 가 들어오는 연결을 분배한다.
마이클이 142.250.71.46:443 호출
↓
Load Balancer 가 받음
↓
뒤의 서버 중 하나로 분배 (#1·#2·... #5000 중 하나)
↓
그 서버가 응답
마이클의 ChatGPT 한 번 호출 = 한 IP·한 포트 뒤의 5000+ 서버 중 하나가 일. AI 시대의 결정적 자리.
NAT 의 한계 — 외부에서 직접 접근
NAT 의 결정적 약점이 있었다. 외부에서 마이클의 노트북에 직접 접근할 수가 없다.
외부에서 ssh user@211.234.56.78 시도:
→ 공유기에 도착
→ NAT 테이블에 22 포트 매핑 없음
→ 어느 기기로 보낼지 모름 → 폐기
→ 마이클의 노트북에 안 도달
해결은 포트 포워딩.
[포트 포워딩의 자리]
공유기 관리 페이지에서 수동으로 박음:
"외부 포트 8080 으로 오는 모든 요청을 192.168.0.10:8080 으로"
박은 후:
외부 → 211.234.56.78:8080 → 공유기 → 192.168.0.10:8080
→ 노트북에 도달
자기 서버 운영·SSH 외부 접속·라즈베리 파이 노출·CCTV 외부 접근 같은 자리에서 결정적이다.
UPnP — 자동 포트 포워딩
좌측: 사용자가 직접 공유기 관리 페이지에서 포트 박음. 우측: 게임 (CS:GO) 이 공유기에 자동 부탁. 둘 다 외부 친구 접속 가능.
[UPnP (Universal Plug and Play)]
수동 포트 포워딩 X. 자동.
앱이 공유기에게 자동으로 부탁:
"내가 27015 포트 쓸게, 외부에서 들어올 수 있게"
→ 공유기가 자동으로 포트 매핑
자리:
- 게임 (CS:GO·Valorant·배틀그라운드)
- VoIP (Skype·Discord)
- 토렌트
- IoT 기기
UPnP 자체엔 인증이 X. 악성 코드도 부탁 가능. 그래서 보안 자리에서 디폴트 OFF 권장하기도 한다. 다만 게임·통신 앱 결로는 켜두는 게 편하다. UPnP 가 한 포트만 외부에 열어주고, 들어온 사람의 자리는 그 앱 (게임 서버·SSH 데몬) 의 인증을 거치니까.
마이클이 짚을 자리. UPnP 는 공유기에 한 포트만 여는 일. 그 포트로 들어온 사람이 노트북 전체에 접근 X. 그 포트의 앱이 받는다.
CGNAT — ISP 가 한 번 더 NAT 하는 자리
마이클이 5G 모바일이나 일부 알뜰 인터넷에서 외부 SSH 가 안 되는 이유를 검색하다가 만난 단어가 있었다. CGNAT (Carrier-Grade NAT).
[보통 NAT — 마이클 집 1번 변환]
마이클 노트북 (192.168.0.10)
↓ 공유기 NAT 1번
공유기 (공인 IP: 211.234.56.78)
↓ ISP
인터넷
[CGNAT — ISP 가 2번 변환]
마이클 노트북 (192.168.0.10)
↓ 공유기 NAT 1번
공유기 (사설 ISP IP: 100.64.0.5) ← 공인 X, ISP 사설
↓ ISP NAT 2번
ISP 거대 NAT 박스
↓
공인 IP (211.234.56.78, 수백 명과 공유)
↓
인터넷
100.64.0.0/10 = 특별 ISP 사설 대역 (RFC 6598). 공유기에 박힌 IP 가 100.64.x.x 면 CGNAT.
CGNAT 의 결정적 한계는 외부에서 직접 접속이 X.
보통 NAT — 마이클이 공인 IP 1개:
외부에서 ssh user@211.234.56.78
→ 공유기 도달 → 노트북
CGNAT — ISP 가 한 공인 IP 를 수백 명과 공유:
외부에서 ssh user@211.234.56.78
→ ISP NAT 도착
→ 어느 가입자? 모름 → 폐기
→ 외부 직접 접속 X
→ 포트 포워딩도 X (마이클이 공유기에 박아도 ISP 가 안 받음)
마이클이 자기 환경 확인하는 자리.
$ curl ifconfig.me
211.234.56.78
공유기 관리 페이지 → WAN IP:
100.64.0.5 ← ISP 사설
→ curl 의 IP 와 공유기 WAN IP 가 다르면 CGNAT
→ 같으면 보통 NAT
CGNAT 면 외부 SSH·게임 호스팅 X. ISP 에 “공인 IP 줘” 요청 (월 5,000~10,000 원) 하거나 IPv6 로.
마이클의 작은 깨달음
마이클은 이 단원을 닫으면서 한 가지를 깨달았다. NAT 가 IPv4 부족 안에서 인류 인터넷이 살아남게 한 메커니즘이라는 것. 1990년대 초에 IP 부족이 예상됐고, 1994년 RFC 1631 로 NAT 가 등장했다. 한 공인 IP 로 수백 기기 공유 가능해지면서 IPv6 전환이 30년 미뤄졌다.
“NAT 가 일종의 임시방편이었구나. 그런데 30년 가까이 잘 돌아갔네.”
이 한 줄을 잡고 나서 다음 자리가 자연스럽게 따라왔다. NAT 가 IP 변환을 한다는 것까지는 풀렸다. 그런데 새 기기가 LAN 에 처음 들어왔을 때 IP 자체를 누가 정해주는지가 아직 안 풀렸다. 마이클이 비번 한 번 입력했을 때 4초 안에 IP 가 박히는 자리. 그게 다음 단원이었다.
“DHCP 라는 게 그 일을 하는 거 아닌가.”
DHCP DORA — 와이파이 비번 입력 후 4초의 안쪽
마이클이 자기 노트북·아이폰에서 IP 주소·DNS·서브넷 마스크 같은 숫자를 직접 입력한 적이 한 번도 없었다. 그런데 카페·공항·집·사무실 어디든 와이파이가 잡히는 즉시 인터넷이 됐다. 누가 그 숫자들을 박아주는가.
답은 DHCP 였다.
DHCP 의 정체
DHCP = Dynamic Host Configuration Protocol (동적 호스트 설정 프로토콜)
DHCP 가 하는 일:
새 기기가 LAN 에 들어옴
↓
공유기가 자동으로:
- IP 주소 부여
- 서브넷 마스크
- 기본 게이트웨이 (= 공유기 자기 IP)
- DNS 서버 IP
- 임대 시간
→ 마이클이 아무것도 안 해도 인터넷이 되는 자리의 정체
DORA — 4 단계의 의식
DHCP 의 결정적 자리는 4 번의 메시지였다.
D — Discover (탐색)
O — Offer (제안)
R — Request (요청)
A — Acknowledge (확인)
→ 앞글자 따서 DORA
이게 와이파이 비번 입력 후 4초 안쪽의 풍경.
4 단계의 메시지가 약 1~5초 안에 오감. 끝나면 노트북이 IP·서브넷·게이트웨이·DNS 를 모두 받아 인터넷 사용 가능.
단계 1 — Discover (탐색)
마이클의 노트북이 카페 와이파이에 처음 연결.
[Discover 풍경]
노트북: "여기 누가 IP 좀 주실래요?"
src IP: 0.0.0.0 (아직 IP 없음)
src 포트: 68 (DHCP 클라이언트 포트)
dst IP: 255.255.255.255 (브로드캐스트, LAN 모든 기기)
dst 포트: 67 (DHCP 서버 포트)
메시지:
"DHCP DISCOVER"
"내 MAC: 14:7D:DA:11:22:33"
"IP 좀 주세요"
→ LAN 의 모든 기기가 받음
→ 다만 DHCP 서버 (= 공유기) 만 응답
→ 다른 노트북·아이폰은 무시
마이클이 짚을 세 자리.
- 0.0.0.0 = “IP 없음”. 2A 에서 본 특수 주소.
- 255.255.255.255 = LAN 의 모든 기기에게 보내는 브로드캐스트.
- 포트 67·68 = DHCP 의 표준 짝.
단계 2 — Offer (제안)
공유기가 노트북의 Discover 받고 응답.
[Offer 풍경]
공유기: "이 IP 어떠세요?"
메시지:
"DHCP OFFER"
"당신 MAC (14:7D:DA:11:22:33) 에게"
"IP: 192.168.0.10 어떠세요?"
"서브넷 마스크: 255.255.255.0"
"게이트웨이: 192.168.0.1"
"DNS: 168.126.63.1, 168.126.63.2"
"임대 시간: 86400 초 (24 시간)"
여기서 결정적 자리. 공유기가 노트북에 직접 못 보낸다. 아직 IP 가 없으니까. 그래서 다시 브로드캐스트로 모든 기기에게. “당신 MAC 에게” 라고 명시. MAC 으로 식별한다는 자리. 2A 에서 박았던 MAC 의 자리가 살아 있다.
마이클이 잡을 한 줄. DHCP 의 식별자가 IP 가 아니라 MAC. IP 가 없는 자리에서 시작하니까.
단계 3 — Request (요청)
노트북이 Offer 받고 “그 IP 쓸게요” 응답.
[Request 풍경]
노트북: "192.168.0.10 그거 주세요"
메시지:
"DHCP REQUEST"
"내 MAC: 14:7D:DA:11:22:33"
"공유기 (192.168.0.1) 가 제안한 192.168.0.10 쓸게요"
마이클이 자연스럽게 던진 의문 — “왜 또 브로드캐스트?”. LAN 안에 DHCP 서버가 여러 대 있을 수 있다 (드물지만). “어느 서버의 Offer 를 받아들였는지” 다른 서버에게도 알려야 그들이 자기 Offer 의 IP 를 비워둔다.
단계 4 — Acknowledge (확인)
공유기가 “OK” 마지막 답.
[ACK 풍경]
공유기: "확정. 192.168.0.10 당신 자리"
메시지:
"DHCP ACK"
"당신 MAC (14:7D:DA:11:22:33) 에게"
"192.168.0.10 확정"
"임대 시간 86400 초 시작"
이 메시지를 받는 순간 노트북이 IP·서브넷·게이트웨이·DNS 다 박는다. 인터넷 사용 가능.
마이클이 보는 풍경 — 와이파이 표시가 들어오고 ChatGPT 가 열림. 4 단계가 약 1~5 초 안에 끝남.
자기 환경에서 직접 보기
마이클이 자기 맥북에서 DHCP ACK 의 안쪽을 직접 봤다.
Mac 의 터미널에서 자기 노트북이 마지막으로 받은 ACK 의 안쪽을 그대로 본다. yiaddr (자기 IP), siaddr (공유기 IP), chaddr (자기 MAC), 임대 시간, 서브넷, 라우터, DNS 까지.
$ ipconfig getpacket en0
op = BOOTREPLY
yiaddr = 192.168.0.10 (노트북 IP)
siaddr = 192.168.0.1 (공유기 IP)
chaddr = 14:7d:da:11:22:33 (노트북 MAC)
options:
dhcp_message_type (5): ACK
server_identifier: 192.168.0.1
lease_time: 86400
subnet_mask: 255.255.255.0
router: 192.168.0.1
domain_name_server: 168.126.63.1, 168.126.63.2
이 한 줄이 마이클 노트북이 마지막에 받은 ACK 의 안쪽. 매 24 시간마다 갱신.
임대 갱신 — 50% 시점에서
24 시간 임대인데 24 시간 후 한꺼번에 사라지면 위험. DHCP 의 결정적 자리.
0% 첫 DORA → 50% Renewal (REQUEST 만) → 87.5% Rebinding (브로드캐스트) → 100% 만료 (DORA 다시).
임대 시간 86400 초 (24 시간) 의 풍경:
0% — 첫 DORA 4 단계로 IP 받음
50% (12 시간 후) — Renewal
노트북이 공유기에게 "IP 더 쓸게요" REQUEST 만 보냄
Discover 없음. 같은 공유기에 같은 IP.
공유기 ACK → 임대 24 시간 다시 시작
87.5% (21 시간 후) — Rebinding
Renewal 응답 없으면 LAN 의 모든 DHCP 서버에게 브로드캐스트
"누구든 이 IP 임대 갱신해줘"
100% (24 시간 후) — 만료
재시작. DORA 처음부터 다시.
마이클의 노트북이 사무실에 24 시간 켜져 있어도 IP 가 안 바뀌는 이유. 50% 시점마다 자동 갱신.
마이클의 작은 깨달음
마이클은 이 단원을 닫으면서 한 가지를 깨달았다. 자기가 비번 한 번 입력했을 때 4초 안에 4 번의 메시지가 오갔다. 자기는 한 번도 IP·서브넷·DNS 를 입력한 적이 없는데, 노트북이 그 모든 숫자를 자동으로 받았다. 30년 가까이 모든 와이파이에서 같은 4 단계가 도는 자리.
“와이파이 비번 입력 = DHCP DORA 4 단계의 시작이구나.”
그런데 마이클은 한 가지가 더 이상했다. iPhone 의 Private Wi-Fi 가 와이파이마다 다른 랜덤 MAC 을 송출한다고 2A 에서 짚었는데, 그게 DHCP 와 어떻게 만나는지가 안 풀렸다. 매번 랜덤 MAC 이면 매번 새 IP 받는가.
“iPhone Private Wi-Fi 가 같은 와이파이엔 같은 랜덤 MAC 이라고 했는데, 그게 왜 그런 거지?”
MAC·DHCP·Private Wi-Fi 의 정합 — 옷 갈아입기 비유 회수
마이클이 2A 에서 박은 비유가 있었다. iPhone 이 같은 카페엔 같은 옷·모자, 다른 카페엔 다른 옷·모자를 입는 것. 추적 방지의 자리. 그런데 그 옷이 실제로는 MAC 주소라는 자리, 그리고 DHCP 와 어떻게 만나는지는 미뤄둔 자리였다.
DHCP 의 식별자는 MAC
공유기 안의 DHCP 임대 표.
[공유기 안의 DHCP 임대 표]
| MAC 주소 | IP 주소 | 임대 만료 |
|---------------------|---------------|--------------|
| 14:7D:DA:11:22:33 | 192.168.0.10 | 24h 후 |
| 18:65:90:AA:BB:CC | 192.168.0.11 | 12h 후 |
| 7E:91:42:DD:EE:FF | 192.168.0.12 | 18h 후 |
→ 공유기가 MAC 으로 식별
→ 같은 MAC 으로 다시 접속하면 같은 IP 다시 줌
마이클이 잡은 한 줄. DHCP 의 식별자가 MAC. IP 는 아직 없으니까, MAC 만이 영구 식별자.
iPhone Private Wi-Fi 의 정합
마이클이 자연스럽게 던진 의문 — 매 와이파이마다 랜덤 MAC 이면 매번 새 IP 받는가.
답: 같은 와이파이엔 같은 랜덤 MAC. 그래서 같은 IP.
집 와이파이 처음·24h 후·한 달 후 모두 같은 랜덤 MAC. 스타벅스 와이파이는 다른 랜덤 MAC.
[마이클 iPhone 의 풍경]
집 와이파이 (SSID: "Tailor_Home"):
iPhone 이 만든 랜덤 MAC: 16:23:5F:AA:BB:CC
이 MAC 으로 DHCP 받음 → 192.168.0.20
집에서 24 시간 후 다시 와이파이:
같은 SSID → 같은 랜덤 MAC (16:23:5F:AA:BB:CC)
공유기 임대 표 검색 → "이 MAC 본 적 있다"
→ 같은 IP (192.168.0.20) 다시 줌
집에서 한 달 후 다시:
같은 SSID → 여전히 같은 16:23:5F:AA:BB:CC
→ 같은 IP
스타벅스 와이파이 (SSID: "Starbucks_Free"):
새 SSID → 다른 랜덤 MAC (7E:91:42:DD:EE:FF)
→ 새 IP
같은 와이파이엔 일관 MAC 의 두 가지 이유.
1. DHCP 임대의 안정성
매번 다른 MAC 으로 접속하면 공유기가 매번 새 IP 임대 발급.
같은 노트북인데 매번 새 사람으로 인식. 충돌·낭비.
2. MAC 화이트리스트와의 호환
회사·학교·공유기에서 "이 MAC 만 허용" 정책을 쓰는 자리.
매번 랜덤이면 그 정책이 깨짐.
마이클은 2A 의 옷 갈아입기 비유에 한 결을 더 박을 수 있었다.
같은 카페에선 같은 옷·모자. 직원이 단골 손님 알아봄 (DHCP 임대 표).
다른 카페에선 다른 옷·모자. 광고망이 매장 너머로 못 잇는 자리.
Static Reservation — MAC 바인딩
마이클이 자기 노트북에 SSH 외부 접속을 박을 때 알게 된 자리.
[Static Reservation 의 자리]
공유기 관리 페이지에서 수동으로 박음:
"MAC 14:7D:DA:11:22:33 에게는 항상 192.168.0.50 부여"
→ DHCP 임대가 만료되어도 같은 IP
→ 자리:
- 자기 노트북에 항상 같은 IP 박고 싶을 때
- 포트 포워딩 박은 IP 가 안 바뀌게
- NAS·프린터·CCTV 같은 자리 (IP 자주 바뀌면 X)
마이클이 SSH 외부 접속 박는 자리.
공유기에 Static Reservation: 노트북 MAC → 192.168.0.10
공유기 포트 포워딩: 외부 22 → 192.168.0.10:22
→ 노트북 IP 안 바뀌니 SSH 외부 접속 늘 작동
MAC 화이트리스트의 자리
학교·회사가 “MAC 등록된 학생만 허용” 정책을 쓰는 자리. 마이클이 학교 와이파이 처음 잡을 때 자주 막힌 자리.
[충돌 풍경]
학교 와이파이: "MAC 등록된 학생만 허용"
마이클이 자기 iPhone 의 진짜 MAC (14:7D:DA:AA:BB:CC) 등록.
마이클이 학교 와이파이 잡으려 함:
Private Wi-Fi ON → iPhone 이 랜덤 MAC (7E:91:42:DD:EE:FF) 송출
학교 공유기: "이 MAC 등록 안 됨" → 거부
→ 와이파이 안 잡힘
해결:
설정 → Wi-Fi → 그 SSID → "프라이빗 Wi-Fi 주소" OFF
→ 진짜 MAC (14:7D:DA:AA:BB:CC) 송출
→ 학교 공유기 허용
→ 와이파이 잡힘
iOS 14 이후 Private Wi-Fi 가 디폴트 ON 이라 학교·회사에서 처음 와이파이 잡을 때 자주 막힌다.
마이클의 작은 깨달음
마이클은 이 단원을 닫으면서 한 가지를 깨달았다. MAC 이 옷이라는 비유가 살짝 빈약했다. 옷은 매장이 보고 같은 사람이라고 알아채는 정도지만, MAC 은 DHCP 와 결합해서 진짜로 같은 IP 를 다시 받는 영구 식별자였다. 옷보다는 회원 카드 에 더 가까운 자리.
“같은 카페엔 같은 회원 카드. 직원이 단골로 인식해서 같은 자리 (= 같은 IP) 다시 안내.”
이 한 줄을 잡고 나서 다음 의문이 자연스럽게 따라왔다. DHCP 가 IP 를 부여한 후, 마이클의 노트북이 그 IP 로 패킷을 보낼 때 진짜로 어디까지 흘러가는지. 패킷 4겹 양파의 가장 바깥 라벨인 MAC 이 어떻게 정해지는지. 그게 ARP 였다.
“ARP 가 IP 를 MAC 으로 바꾼다고 했는데, 정확히 어떻게?”
이번 주 AI 흐름
ARP 본격 — IP 를 MAC 으로 바꾸는 마지막 단계
마이클이 2B 에서 ARP 라는 단어를 짚었지만 좌표만 잡고 미뤄둔 자리였다. DNS 가 도메인 → IP, ARP 가 IP → MAC. 같은 LAN 안에서만 작동. 그런데 정확히 어떻게 작동하는지, 왜 같은 LAN 안에서만 되는지가 안 풀렸다.
ARP 가 일어나는 자리
마이클의 노트북이 패킷을 보내려면 다음 hop 의 MAC 이 필요했다. 2A 의 패킷 4겹 양파에서 가장 바깥 라벨이 MAC 이었으니까.
[패킷 4겹 양파 회수 — 2A]
가장 바깥 (Ethernet): MAC src + MAC dst ← 다음 hop 의 MAC 필요
한 겹 안 (IP): IP src + IP dst ← 전체 여정
또 한 겹 (TCP): 포트
가장 안쪽 (Payload): 진짜 내용
→ 마이클 노트북이 google.com 패킷 보낼 때:
IP dst = 142.250.71.46 (구글)
MAC dst = ???
→ google.com 서버의 MAC 이 X
→ 다음 hop 인 공유기의 MAC
여기가 결정적 자리. MAC dst 가 google.com 서버의 MAC 이 아니다. 다음 hop 인 공유기의 MAC. 2A 에서 박았던 “MAC 매 hop 갈아끼움” 의 자리가 여기서 진짜로 작동한다.
ARP Request·Reply 의 풍경
마이클이 자기 노트북이 처음 공유기에 패킷 보낼 때를 풀어봤다.
[처음 패킷 보낼 때]
상황: IP (192.168.0.1) 만 알고 MAC 모름
[ARP Request — 브로드캐스트]
src MAC: 14:7D:DA:11:22:33 (노트북)
dst MAC: FF:FF:FF:FF:FF:FF (브로드캐스트, LAN 모든 기기)
메시지: "192.168.0.1 의 MAC 누구?"
[LAN 의 모든 기기가 받음]
- 192.168.0.10 (다른 노트북): "내 IP 아님, 무시"
- 192.168.0.11 (아이폰): "내 IP 아님, 무시"
- 192.168.0.1 (공유기): "내 IP 다. 응답"
[ARP Reply — 공유기만 응답]
src MAC: A4:5E:60:AA:BB:CC (공유기)
dst MAC: 14:7D:DA:11:22:33 (노트북에 직접)
메시지: "192.168.0.1 의 MAC = A4:5E:60:AA:BB:CC"
→ 노트북이 알게 됨
→ 패킷의 가장 바깥 라벨에 공유기 MAC 박을 수 있음
마이클이 자연스럽게 던진 의문이 있었다.
“매 패킷마다 ARP Request 를 보내면 너무 비효율 아닌가?”
답은 ARP Cache 였다.
ARP Cache — 매번 묻지 않는 자리
[마이클 노트북의 ARP Cache]
$ arp -a
? (192.168.0.1) at a4:5e:60:aa:bb:cc on en0 [ethernet]
? (192.168.0.11) at 18:65:90:11:22:33 on en0 [ethernet]
? (192.168.0.12) at 7c:c3:a1:88:99:00 on en0 [ethernet]
→ 노트북이 한 번 ARP 한 결과를 캐시
→ TTL 약 60 초 ~ 10 분 (OS 마다 다름)
→ 그 동안 같은 IP 에 패킷 보낼 땐 ARP X
여기서 마이클이 자기 자기 환경에서 매일 보던 풍경이 풀렸다. 사무실 프린터에 처음 ping 칠 때 약간 멈춘 후 응답이 온다. 두 번째 ping 부터 즉시 응답. 그 미세한 차이의 정체가 ARP Cache 였다.
처음 ping:
ARP Request → 1~5 ms → ARP Reply → 그 다음 ping 패킷 보냄
→ 약간 멈춤
두 번째부터:
ARP cache hit → 즉시 ping 패킷
→ 즉시 응답
마이클이 자기 환경에서 직접 확인.
$ arp -d 192.168.0.11 # 캐시 비우기
$ ping 192.168.0.11 # 첫 번째 — 약간 멈춤
$ ping 192.168.0.11 # 두 번째 — 즉시
마이클은 이 순간 한 가지를 깨달았다. 자기가 평소 인식조차 못 하던 그 미세한 멈춤이 사실 ARP Request·Reply 1~5 ms 였다. 1편에서 5단 동심원의 [1] → [2] 사이의 작은 풍경이었다.
Gratuitous ARP — 자기 알리는 자리
마이클이 다음 의문을 던졌다 — 그러면 공유기는 자기 IP·MAC 을 어떻게 알리는가.
[Gratuitous ARP 의 풍경]
공유기가 켜질 때:
스스로 ARP 한 번 보냄 (자기 IP 의 MAC 을 자기가 묻기)
"192.168.0.1 의 MAC 누구?"
"내가 192.168.0.1, MAC = A4:5E:60:AA:BB:CC"
→ LAN 의 모든 기기가 받고 ARP Cache 에 박음
→ 마이클 노트북이 처음 ARP 안 묻고도 공유기 MAC 알게 됨
자리:
– 공유기 켤 때
– IP 가 바뀐 자리 (Static IP 변경)
– 공유기를 새 모델로 갈아끼울 때
ARP 의 결정적 자리 — 한 LAN 만
마이클이 자연스럽게 던진 의문. ARP 가 어디까지 작동하는가. google.com 의 MAC 도 ARP 로 찾을 수 있는가.
답은 X. ARP 는 같은 LAN 안에서만.
마이클이 google.com 칠 때 패킷이 흘러가는 화살표 순서. 서브넷 마스크 검사 → LAN 밖 판정 → 기본 게이트웨이 MAC 으로 → 공유기 → 다음 hop MAC 갈아끼움.
마이클이 google.com 칠 때 패킷의 흐름을 화살표로 풀어봤다.
IP dst = 142.250.71.46 (구글)
↓
"같은 LAN 안인가?" (서브넷 마스크 검사)
↓
"192.168.0.0/24 의 안인가?"
↓
142.250.71.46 은 LAN 밖
↓
ARP 안 함 (LAN 밖이니 의미 X)
↓
"기본 게이트웨이 (192.168.0.1) 의 MAC 으로 보냄"
↓
ARP cache 에서 192.168.0.1 의 MAC 찾음
↓
패킷의 가장 바깥 라벨에 공유기 MAC 박음 (2A 의 4겹 양파)
↓
공유기 도달
↓
공유기가 패킷의 가장 바깥 MAC 을 다음 hop 의 MAC 으로 갈아끼움
↓
ISP → 백본 → ... → 구글 서버
ARP 는 한 hop 만 풀어준다. 다음 hop 은 다음 라우터가 풀어준다. 2A 의 “MAC 매 hop 갈아끼움” 의 자리가 여기서 정확히 일치.
ARP Spoofing — 보안의 자리
마이클이 카페 와이파이를 자주 쓰면서 한 번 짚어둔 자리. ARP 의 결정적 약점이 보안이었다.
정상 ARP Cache 의 풍경 + 공격자가 가짜 Reply 박을 때 마이클 트래픽이 공격자에게 흘러가는 자리.
[ARP Spoofing 의 풍경]
공격자가 LAN 안에 있음 (카페 와이파이).
공격자가 가짜 ARP Reply 보냄:
"192.168.0.1 (공유기) 의 MAC = 공격자 MAC"
마이클 노트북이 그걸 ARP Cache 에 박음 (검증 X).
→ 마이클의 인터넷 패킷이 공격자에게 흘러감
→ 공격자가 마이클 트래픽 가로챔 (HTTPS 면 일부 보호)
ARP 가 검증 없이 받는 게 결정적 약점. 카페 와이파이의 위험이 여기서 풀린다. ARP Spoofing·MITM 공격의 본격은 보안 트랙에서 통째 다룬다. 여기는 윤곽만.
마이클의 작은 깨달음
마이클은 이 단원을 닫으면서 한 가지를 깨달았다. 2A 에서 패킷 4겹 양파를 외울 때, MAC 이 매 hop 갈아끼워진다는 자리가 그냥 외워야 할 사실이었다. 그런데 그 갈아끼움이 진짜로는 ARP 라는 작은 작업이 매 hop 마다 도는 결과였다. 한 hop = 한 LAN. 그 LAN 안에서 ARP 가 다음 사람의 MAC 을 찾고, 그 MAC 으로 패킷을 박아 보낸다.
“패킷 4겹 양파의 가장 바깥 라벨이 ARP 의 결과물이구나.”
이 한 줄을 잡고 나서 마이클은 마지막 풍경이 보고 싶었다. NAT·DHCP·MAC·ARP 가 한 카페 안에서 한꺼번에 작동하는 풍경. 자기가 카페 들어가서 ChatGPT 호출하는 첫 1 분의 안쪽.
“이 모든 게 한 자리에서 동시에 도는 풍경을 보고 싶다.”
카페 첫 1 분 — 모든 자리가 한꺼번에 작동하는 풍경
마이클이 카페 들어가 와이파이 비번을 입력하고 ChatGPT 호출까지의 첫 1 분. 이 한 풍경에 1편·2편·3편의 모든 자리가 한꺼번에 작동한다.
00:00 카페 도착 → 00:01 DHCP DORA → 00:03 Private Wi-Fi → 00:04 DNS+ARP → 00:05 패킷 박음 → 00:06 NAT → 00:08 ChatGPT 답.
00:00 마이클 카페 도착, iPhone 와이파이 켜기
SSID 선택, 비번 입력
00:01 [DHCP DORA 4 단계]
Discover → Offer → Request → ACK
iPhone 이 IP·게이트웨이·DNS 받음
iPhone IP: 10.0.5.42 (카페의 사설 대역)
00:03 [iPhone Private Wi-Fi]
이 카페 SSID 에 처음이라 새 랜덤 MAC 만듦
그 MAC 으로 DHCP 받음
카페 공유기 임대 표에 박힘
00:04 마이클이 ChatGPT 앱 열기
앱이 chatgpt.com 도메인 호출
[DNS] chatgpt.com → 104.18.32.47
[라우팅] 104.18.32.47 은 LAN 밖 → 게이트웨이 (10.0.5.1) 로
[ARP] 10.0.5.1 의 MAC 모름 → ARP Request 브로드캐스트
[ARP Reply] 카페 공유기 MAC 받음
00:05 iPhone 이 패킷 박음:
MAC dst: 카페 공유기 MAC
IP dst: 104.18.32.47
포트: 443
Payload: HTTPS 요청
00:06 카페 공유기 받음:
NAT 변환 (10.0.5.42 → 카페 공인 IP)
NAT 테이블에 박음
다음 hop 의 MAC 으로 갈아끼움
00:07 카페 공유기 → ISP → 백본 → Cloudflare → ChatGPT 응답
00:08 마이클 화면에 ChatGPT 답
이 첫 1 분 안에 마이클이 1편·2편·3편에서 학습한 모든 자리가 한꺼번에 작동한다.
[작동한 자리 — 1 분 안에]
5단 동심원 (1편): iPhone [1] → 카페 LAN [2] → ISP [3] → 백본 [4] → Cloudflare [5]
IP 주소 (2A): 사설 10.0.5.42, 공인 (카페의 한 공인 IP)
MAC (2A): Private Wi-Fi 의 랜덤 MAC
패킷 4겹 양파 (2A): MAC + IP + 포트 + Payload, 매 hop MAC 갈아끼움
TCP·HTTPS (2B): 3-way handshake + TLS + HTTP
HTTP/2 (2B): ChatGPT 가 HTTP/2 서버
DHCP (3A): DORA 4 단계
ARP (3A): 기본 게이트웨이 MAC 찾기
NAT (3A): 카페 공유기의 NAPT
DNS (5편 자리): 도메인 → IP, 본격은 다음 자리
이 한 풍경 안에서 카페 첫 1 분이 마법이 아니다. 한 풍경의 정밀한 연쇄.
마이클의 큰 깨달음
마이클은 이 풍경을 보고 한 가지를 깨달았다. 자기가 1편에서 5단 동심원을 배우기 시작했을 때부터 지금까지의 모든 자리가 다 같은 한 풍경의 부분들이었다. IP 주소·MAC·패킷·TCP·HTTP·NAT·DHCP·ARP — 다 따로 있는 단어들 같았는데, 사실은 카페 들어가 ChatGPT 호출하는 한 클릭 안에서 동시에 도는 한 시스템의 부품들이었다.
“내가 비번 한 번 입력했을 때 8초 안에 이게 다 도는 거였구나.”
그날 밤 마이클은 자기 사무실 BE5100M 공유기를 다시 봤다. 109,000 원짜리 검은 박스. 그 안에 ARM CPU + 임베디드 Linux + Wi-Fi 7 SoC 가 박혀 있고, 그 위에서 라우팅·NAT·DHCP·ARP·방화벽·DNS 캐싱 같은 일이 24시간 돌고 있었다. 자기가 평소 “와이파이 박스” 라고 부르던 그 작은 기기가 사실 작은 슈퍼컴퓨터였다.
핵심 3가지 — 이 편을 닫는 한 장
1. 공유기 = 작은 Linux 컴퓨터
ARM CPU + RAM + 플래시 + Wi-Fi 칩 위에 임베디드 Linux 가 돌면서 본업 3가지 (라우팅·NAT·DHCP) 를 처리. 노트북의 축소판. 마이클의 BE5100M 도 같은 자리.
2. NAT = 사설·공인 IP 변환 + 포트로 기기 구분
정확한 이름 NAPT. 공유기의 NAT 테이블에 매핑 박힘. 응답이 포트로 검색해 정확한 기기로. IPv4 부족 안에서 인류 인터넷이 살아남는 메커니즘. 본체는 Linux 의 netfilter.
3. DHCP·MAC·ARP — 와이파이 첫 1 분의 세 단어
DHCP DORA 4 단계로 IP·서브넷·게이트웨이·DNS 자동 부여. MAC 이 DHCP 의 식별자. ARP 가 같은 LAN 안 IP → MAC 변환. iPhone Private Wi-Fi 의 일관 MAC 도 DHCP 와 만나는 자리. 마이클이 매일 카페 들어갈 때마다 이 셋이 한꺼번에 작동.
외워둘 한 문장.
공유기는 작은 Linux 컴퓨터. NAT 는 포트로 기기 구분. DHCP·MAC·ARP 가 와이파이 첫 1 분에 한꺼번에 작동.
다음 편 예고 — 3B편 비싼 공유기는 뭐가 다른가
3A 가 닫혔다. 공유기의 본업 3가지·NAT·DHCP·MAC·ARP 가 한 묶음으로 박혔다.
3B 편에서는 마이클이 자기 사무실 BE5100M 을 살 때 본 스펙 페이지의 모든 단어가 풀린다. 그리고 학교·카페 와이파이의 진짜 풍경.
[3B편 — 비싼 공유기는 뭐가 다른가 + 카페·학교 와이파이의 진짜 풍경]
- 공유기 = 집 비유 5축 (마이클 자생 비유 통째)
· 집의 크기 = 동시 접속 기기 수 (싸구려 10대 / 비싼 250대)
· 문 크기 = NAT 처리 속도 (WAN 처리량 1Gbps·2.5Gbps·10Gbps)
· 문 보안 = 방화벽·VPN·WPA3
· 역에서 가까움 = Wi-Fi 신호 강도·MIMO 안테나
· 엘리베이터 세대 = Wi-Fi 표준 (5·6·6E·7)
- 학교 와이파이 6단계 (KU WIFI 같은 자리)
인증 → DHCP → IP 부여 → 사용 → 자리 옮기면 재인증 → 만료
- 카페 와이파이 끊김의 3타이머
캡티브 포털 (1시간) · Idle 타임아웃 · DHCP 임대
- NAS — 사이드 (집·사무실의 작은 자기 클라우드)
3B 가 닫히면 N1~N3 (네트워크 입문 3부작) 가 통째로 닫힌다. 그 다음 한 박자 쉬고 4편 (인터넷 우체국 — 패킷·ISP·백본) 으로.
FAQ
Q1. 공유기 RAM 64MB 면 노트북 RAM 64GB 와 1000배 차이인데 어떻게 인터넷이 도나요?
공유기는 패킷을 통과시키기만 한다. 영상·사진·문서를 저장하지 않는다. NAT 테이블·DHCP 임대표·라우팅 테이블 같은 작은 자리만 메모리에 박는다. 한 패킷이 들어오면 변환·전달하고 메모리에서 비운다. 그래서 64MB 면 충분.
Q2. 공유기에 SSH 로 들어갈 수 있나요?
모델에 따라 다르다. ASUS·OpenWrt·DD-WRT 펌웨어는 SSH 를 디폴트로 지원하거나 옵션으로 켤 수 있다. ipTIME·일반 가정용은 보통 막혀 있다. SSH 들어가면 진짜 Linux 명령어 (ls·ps·iptables) 가 다 통한다.
Q3. DHCP DORA 가 4 단계인데 카페에서 1~5 초 걸리는 이유가 뭐죠?
DORA 자체는 약 100 ms 안에 끝난다. 다만 그 전에 Wi-Fi 인증 (WPA2/WPA3 핸드셰이크), DNS 설정, 운영체제의 네트워크 스택 초기화 같은 자리가 더 들어간다. 그게 합쳐서 1~5 초.
Q4. 같은 카페에 다시 가면 IP 가 같은가요?
24 시간 이내면 같은 IP 받을 가능성이 높다 (임대 살아 있음). 그 이후엔 카페 공유기에 따라 다르다. 풀이 가득 차서 다른 IP 받을 수도 있고, MAC 으로 식별해서 같은 IP 다시 줄 수도 있다.
Q5. iPhone Private Wi-Fi 가 디폴트 ON 이라는데 끄는 게 좋나요?
집·카페·공항 같은 일반 자리는 디폴트 ON 으로 두는 게 좋다 (추적 방지). 학교·회사처럼 MAC 등록이 필요한 자리에서만 그 SSID 의 설정을 OFF 로. iOS 설정 → Wi-Fi → 그 와이파이의 (i) → “프라이빗 Wi-Fi 주소” 토글.
Q6. NAT 테이블이 가득 차면 어떻게 되나요?
새 연결이 안 만들어진다. 새 사이트가 안 열리거나 끊긴다. 가정용 공유기는 보통 5,000~10,000 줄, 비싼 모델은 50,000+ 줄. 평소엔 거의 안 차지만 P2P·토렌트·게임 호스팅 같은 자리에서 차는 경우가 있다.
Q7. ARP 가 LAN 안에서만 작동한다면 ISP 백본·구글 서버는 어떻게 패킷이 가나요?
매 hop 마다 그 hop 의 라우터가 ARP 를 한다. 노트북 → 집 공유기 (노트북이 ARP), 집 공유기 → ISP 라우터 (집 공유기가 ARP), ISP 라우터 → 백본 (ISP 가 ARP), … 매 단계의 ARP 가 한 LAN 안에서만 작동. 합쳐서 출발지부터 도착지까지 패킷이 흘러간다.
Q8. 공유기를 끄고 켜면 기기들이 다 끊기나요?
그렇다. 공유기가 NAT 테이블·DHCP 임대표를 메모리에 박고 있어서 전원 끊어지면 다 사라진다. 다시 켜면 모든 기기가 DHCP DORA 부터 다시. 이 과정이 30 초~1 분.
Q9. CGNAT 인지 어떻게 확인하나요?
자기 노트북에서 curl ifconfig.me 친 IP 와 공유기 관리 페이지의 WAN IP 비교. 둘이 같으면 보통 NAT (자기 공인 IP 직접 받음). 다르면 CGNAT (공유기 WAN 이 100.64.x.x 같은 ISP 사설). 5G 모바일·일부 알뜰 인터넷이 자주 CGNAT.
Q10. SSH 로 들어가면 노트북 전체에 접근하나요?
22 포트가 입구. sshd 라는 데몬이 그 입구의 자물쇠 (인증). 인증 성공하면 셸 (bash·zsh) 이 열려 노트북 안의 명령 전부 가능 (사용자 권한 안에서). 그래서 SSH 의 인증 (비밀번호 X, 공개키 O) 이 결정적. 본격은 N7 (포트·프로세스) 와 보안 트랙에서.
소스 리스트
책
- 진혜진, 『네트워크 개론 3판』, 한빛아카데미, 2023 — 메인 교재 (Ch.6 ARP·DHCP·NAT)
- 오키타 토시야, 『한 권으로 끝내는 네트워크 기초』, 길벗, 2022 — 보조 교재
RFC
- RFC 1631 — NAT 첫 정의 (1994)
- RFC 2131 — DHCP
- RFC 826 — ARP (1982)
- RFC 6598 — Carrier-Grade NAT (CGNAT)
- RFC 1918 — 사설 IP 대역
도구
ipconfig getpacket en0(Mac) — DHCP ACK 직접 보기arp -a— ARP Cache 확인iptables -t nat -L— 공유기의 NAT 룰 확인- Wireshark·tcpdump — 패킷 캡처
- 공유기 관리 페이지 (
http://192.168.0.1/)
시리즈 안
- [2B편 — TCP·UDP·HTTP 진화·웹 동작] (post 4170)
- [2A편 — IP 주소·MAC 주소·패킷 4겹 양파] (post 4159)
- [1편 — 인터넷·5단 동심원] (post 4110)
- [0편 — 네트워크를 알아야 하는 이유] (post 4109)
- 다음: 3B편 (비싼 공유기·학교/카페 와이파이·NAS)
