패킷은 어떻게 길을 고르나

한 줄 요약

호스트는 목적지가 내 서브넷 안이면 직접, 밖이면 기본 게이트웨이로 보낸다. 라우팅 테이블은 그 판단 규칙의 목록이고, 가장 긴 프리픽스가 이긴다.

왜 이게 필요했나

"핑은 되는데 접속이 안 된다", "어떤 대역만 안 된다" 같은 신고는 대부분 라우팅에서 나온다. 그런데 라우팅 테이블을 읽을 줄 모르면 무엇을 봐야 할지조차 모른다.

어떻게 동작하나

ip route# default via 192.168.219.1 dev eth0# 10.244.0.0/16 dev cilium_host scope link# 192.168.219.0/24 dev eth0 proto kernel scope link src 192.168.219.50

세 줄의 뜻은 이렇다.

192.168.219.0/24 dev eth0 — 이 대역은 직접 붙어 있다. ARP 로 상대 MAC 을 찾아 바로 보낸다.
10.244.0.0/16 dev cilium_host — 파드 대역은 cilium 인터페이스로.
default via 192.168.219.1 — 나머지 전부는 게이트웨이에게 맡긴다.

목적지가 여러 줄에 걸리면 가장 긴 프리픽스가 이긴다. 10.244.1.5 는 default(/0)와 10.244.0.0/16 둘 다에 맞지만 /16 이 더 길어서 이긴다. 이걸 최장 접두사 일치(longest prefix match)라 한다.

특정 목적지의 실제 경로는 물어보면 된다.

ip route get 8.8.8.8ip route get 10.244.1.5

이 명령은 커널에게 "이 주소로 보내면 어디로 나가나" 를 직접 묻는다. 테이블을 눈으로 읽고 추론하는 것보다 정확하다.

흔한 착각

게이트웨이가 같은 서브넷에 있어야 한다. 기본 게이트웨이는 ARP 로 찾아야 하므로 반드시 직접 붙은 대역 안에 있어야 한다. 다른 대역의 주소를 게이트웨이로 넣으면 Network is unreachable 이 난다.

핑이 되면 네트워크가 정상이라는 착각. 핑은 ICMP 이고 서비스는 TCP 다. 방화벽이 ICMP 만 열어 두면 핑은 되고 접속은 안 된다. 반대로 ICMP 만 막아 두면 핑은 안 되는데 서비스는 멀쩡하다.

실무에서 진짜 중요한 것

컨테이너 안에서 ip route 를 보면 대개 이렇게 단순하다.

default via 10.244.1.1 dev eth010.244.1.0/24 dev eth0

파드는 자기 노드의 게이트웨이만 안다. 다른 노드의 파드로 가는 길은 노드가 안다. 그래서 파드 간 통신이 안 될 때는 파드 안이 아니라 노드의 라우팅과 CNI 를 봐야 한다.

리눅스에는 테이블이 여러 개 있고 ip rule 이 어느 테이블을 볼지 정한다. VPN 이나 다중 회선 환경에서 "라우팅 테이블은 맞는데 안 나간다" 면 ip rule 을 봐야 한다.