[Network] 10. 가는 길이 있으면 돌아오는 길도 있는 것일까?

TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

라우터는 Destination IP와 Routing Table을 비교해 다음 경로를 선택한다.

한 라우터가 내린 결정은 다음 라우터에 전달되는 여행 계획이 아니다.

각 라우터는 자신에게 도착한 패킷의 목적지를 보고 독립적으로 다음 홉을 고른다.

요청 패킷이 서버에 도착했다고 생각해 보자.

Client ── R1 ── R2 ── Server
          요청 도착 성공

이제 서버가 응답하면 요청이 지나온 길을 거꾸로 돌아갈 것처럼 보인다.

하지만 IP 패킷에는 “지나온 라우터 목록”이 일반적으로 기록되지 않는다.

응답 패킷은 Client의 IP 주소를 새로운 Destination으로 삼고 다시 Routing Table Lookup을 거친다.

 

가는 길과 오는 길은 서로 다른 두 번의 결정이다.

요청이 도착했다는 사실은 응답이 돌아갈 경로까지 존재한다는 뜻이 아니다.

이번 글에서는 Forward Path, Return Path, Missing Route, Asymmetric Routing을 살펴보고,

Stateless한 IP 전달에서는 가능한 비대칭 경로가 Stateful Firewall과 NAT를 만나면 왜 장애가 될 수 있는지 알아본다.

---

ㅁ 편지에는 지나온 우체국 목록이 적히지 않는다

민수가 다른 지역의 영희에게 편지를 보냈다고 생각해 보자.

편지는 여러 우체국을 거쳐 영희에게 도착한다.

민수 → 우체국 A → 우체국 B → 영희

영희가 답장을 쓸 때 원래 봉투를 뒤집어 같은 길로 보내는 것은 아니다.

새 봉투의 받는 사람에 민수의 주소를 적고 자신의 동네 우체국에 맡긴다. 답장을 받은 우체국들은 민수의 주소를 기준으로 각자의 배송표를 조회한다.

영희 → 우체국 C → 우체국 D → 민수

요청과 답장의 경로가 같을 수도 있고 다를 수도 있다.

IP Routing도 같은 원리다.

• Client에서 Server로 가는 경로를 Forward Path라고 한다.
• Server에서 Client로 돌아오는 경로를 Return Path라고 한다.

두 경로는 각 방향의 Destination IP와 Routing Table에 의해 별도로 결정된다.

TCP가 연결 상태를 관리하더라도 라우터가 요청 경로를 기억해 응답을 되돌려 주는 것은 아니다.

TCP의 상태와 IP Routing의 경로 선택은 서로 다른 계층의 문제다.

---

ㅁ 요청은 도착했는데 응답은 길을 잃을 수 있다

다음 네트워크를 살펴보자.

Client LAN              Transit              Server LAN
10.1.0.0/24          192.0.2.0/30           10.2.0.0/24

Client ── R1 ───────────────── R2 ── Server
10.1.0.10  .1   .1             .2   .1  10.2.0.20

 

주소를 조금 더 명확히 적으면 다음과 같다.

Client       : 10.1.0.10/24, Gateway 10.1.0.1
R1 Client IF : 10.1.0.1/24
R1 Transit IF: 192.0.2.1/30
R2 Transit IF: 192.0.2.2/30
R2 Server IF : 10.2.0.1/24
Server       : 10.2.0.20/24, Gateway 10.2.0.1

 

R1에는 Server LAN으로 가는 경로가 있다.

R1: 10.2.0.0/24 via 192.0.2.2

 

Forward Path는 성립한다.

Client 10.1.0.10
  → Gateway R1
  → R2
  → Server 10.2.0.20

 

Server는 요청을 받고 응답을 만든다.

Source IP      : 10.2.0.20
Destination IP : 10.1.0.10

 

 

Client는 다른 네트워크에 있으므로 Server는 응답을 Gateway R2에 보낸다.

그런데 R2에 10.1.0.0/24로 가는 경로가 없다고 하자.

R2 Routing Table
├─ 10.2.0.0/24 dev server-if
├─ 192.0.2.0/30 dev transit-if
└─ 10.1.0.0/24 경로 없음

 

Default Route도 없다면 R2는 응답을 전달할 수 없다. Return Path가 끊어진 것이다.

Forward Path : Client → R1 → R2 → Server  성공
Return Path  : Server → R2 → ?             실패

서버의 네트워크 로그나 패킷 캡처에는 요청 패킷이 들어온 흔적이 남을 수 있다.

하지만 Client는 응답을 받지 못해 타임아웃을 경험한다.

---

ㅁ TCP에서는 어떤 모습으로 보일까?

Client가 Server의 TCP Port에 접속한다고 하자.

첫 번째 SYN은 Forward Path를 따라 Server에 도착한다.

Client → Server : SYN

Server는 SYN을 받고 SYN-ACK을 보낸다.

Server → Client : SYN-ACK

하지만 Return Path가 없으면 SYN-ACK은 Client에 도착하지 않는다.

Client는 서버가 SYN을 받았는지 알 수 없으므로 일정 시간 뒤 SYN을 재전송한다.

Client → Server : SYN
Client → Server : SYN 재전송
Client → Server : SYN 재전송
...
Client           : Connection timeout

 

 

관찰 위치에 따라 서로 다른 장면이 보인다.

관찰 위치	보이는 패킷
Client	반복되는 SYN, SYN-ACK 없음
Server	SYN 수신, SYN-ACK 전송 반복
R1의 Client 방향	SYN 통과, SYN-ACK 없음
R2의 Server 방향	SYN과 SYN-ACK 모두 보일 수 있음

 

Client의 캡처만 보면 서버나 방화벽이 SYN을 버린 것처럼 보일 수 있다.

Server의 캡처를 함께 보면 요청이 도착했고 응답도 생성되었다는 사실을 알 수 있다.

 

두 지점의 증거를 맞춰야 Return Path 문제로 범위를 좁힐 수 있다.

UDP처럼 연결 설정과 재전송을 프로토콜이 보장하지 않는 통신은 단순히 응답 없는 타임아웃으로 보일 수 있다.

ICMP Echo Request가 도착해도 Echo Reply의 Return Path가 없으면 ping은 실패한다.

ping 성공 여부는 단방향 도달이 아니라 왕복이 모두 성립했는지를 보여준다.

---

ㅁ 경로가 없으면 항상 오류를 돌려줄까?

R2가 목적지 경로를 찾지 못하면 ICMP Destination Unreachable 메시지를 생성할 수 있다.

그런데 이 오류 메시지도 IP 패킷이다.

 

Client에게 도착하려면 R2에서 10.1.0.10으로 가는 경로가 필요하다.

문제의 원인이 Return Route 부재라면 오류조차 Client에게 돌아가지 못할 수 있다.

방화벽이 ICMP를 차단하거나 장비가 오류 생성을 제한하는 경우도 있다.

 

그래서 Client에서는 명확한 “경로 없음” 오류 대신 조용한 Timeout만 보일 수 있다.

네트워크가 실패 이유를 알고 있어도, 그 이유를 알려 줄 돌아오는 길이 없으면 사용자는 침묵만 보게 된다.

---

ㅁ 왕복 경로가 꼭 같아야 할까?

Forward Path와 Return Path가 다른 것을 Asymmetric Routing이라고 한다.

Forward Path : Client → R1 → R3 → Server
Return Path  : Server → R2 → R4 → Client

 

비대칭 경로 자체는 IP Routing에서 잘못이 아니다.

인터넷에서는 각 네트워크의 정책과 연결 상태가 다르므로 요청과 응답이 서로 다른 사업자와 라우터를 지날 수 있다.

 

다음 조건을 만족하면 비대칭 경로에서도 통신할 수 있다.

• Forward Path의 모든 라우터가 Server 방향 경로를 안다.
• Return Path의 모든 라우터가 Client 방향 경로를 안다.
• 양쪽 경로의 MTU와 정책이 트래픽을 허용한다.
• 중간 장비가 반대 방향 트래픽을 반드시 같은 장비에서 보도록 요구하지 않는다.

 

따라서 다음 두 상황을 구분해야 한다.

Asymmetric Routing + 양방향 경로와 정책 정상 → 통신 가능
Asymmetric Routing + Return Route/State 누락 → 통신 실패

문제는 경로가 다르다는 사실이 아니라, 돌아오는 경로가 없거나 중간 장비의 상태와 맞지 않는다는 점이다.

---

ㅁ Stateful Firewall은 왜 양방향을 함께 보려 할까?

Stateless Router는 각 패킷의 Destination IP를 보고 독립적으로 전달할 수 있다.

하지만 Stateful Firewall은 요청과 응답을 하나의 연결로 묶어 판단한다.

Client의 SYN이 Firewall A를 지나면 A는 다음과 같은 상태를 만든다.

Client IP:Port → Server IP:Port, TCP SYN 관찰

SYN-ACK이 같은 Firewall A로 돌아오면 기존 연결에 대한 정상 응답으로 허용할 수 있다.

그러나 Return Path가 Firewall B를 지나고 A와 B가 상태를 공유하지 않는다면

B는 SYN-ACK에 대응하는 요청을 본 적이 없다.

Forward : Client → Firewall A → Server  상태는 A에 생성
Return  : Server → Firewall B → Client  B에는 상태 없음

 

Firewall B는 이 패킷을 비정상적인 새 연결이나 Invalid State로 판단해 차단할 수 있다.

경로는 양쪽 모두 존재하지만 Stateful Policy 때문에 통신이 실패한 것이다.

고가용성 방화벽은 상태 동기화를 사용하기도 하지만 동기화 범위와 장애 전환 동작은 제품과 구성에 따라 다르다.

---

ㅁ NAT를 지나간 응답은 왜 같은 번역소로 돌아와야 할까?

NAT도 요청을 보면서 주소와 포트의 변환 관계를 기억한다.

내부 10.1.0.10:50000
       ↓ NAT A에서 변환
공인 203.0.113.10:40000

Server의 응답이 NAT A로 돌아오면 저장된 변환 정보를 사용해 원래 내부 주소로 복원할 수 있다.

하지만 응답이 상태를 공유하지 않는 NAT B로 가면 B는 203.0.113.10:40000을 어느 내부 연결로 되돌려야 하는지 모른다.

Forward : Client → NAT A → Server  변환 상태는 A에 있음
Return  : Server → NAT B → Client  B에는 변환 상태 없음

이 때문에 Stateful Firewall, NAT, Load Balancer가 있는 구간에서는 Path Symmetry가 중요한 설계 조건이 될 수 있다.

항상 물리적으로 같은 모든 링크를 거쳐야 한다는 뜻은 아니다.

필요한 연결 상태를 가진 장비 또는 상태가 동기화된 장비를 Return Traffic이 지나야 한다는 뜻이다.

NAT의 주소 변환 과정은 뒤의 Part에서 자세히 다룬다.

---

ㅁ Source Validation도 비대칭 경로를 막을 수 있다

일부 시스템은 패킷이 들어온 인터페이스가 Source IP로 돌아갈 최적 경로와 맞는지 확인한다.

 

Linux의 Reverse Path Filtering(rp_filter)이 대표적인 예다.

엄격한 검사에서는 다음과 같이 판단할 수 있다.

패킷 Source IP로 돌아가는 최적 경로는 eth0
그런데 패킷은 eth1으로 들어옴
→ 비정상 Source로 판단해 Drop 가능

이는 Source Address Spoofing을 줄이는 데 도움이 되지만 정상적인 Asymmetric Routing 환경에서는 올바른 패킷을 차단할 수 있다.

 

Reverse Path 검사에는 엄격한 방식과 느슨한 방식이 있으며 운영체제와 설정에 따라 동작이 다르다.

비대칭 경로를 사용하는 환경에서는 라우팅 정책과 Source Validation 설정을 함께 확인해야 한다.

Linux에서 현재 값을 읽을 수 있다.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

인터페이스별 값도 별도로 존재할 수 있다.

보안 의미를 이해하지 않고 이 값을 끄는 것은 적절한 진단 방법이 아니다.

---

ㅁ ECMP는 응답도 같은 길로 보내 줄까?

ECMP는 같은 비용의 여러 Next Hop 사이에 트래픽을 분산한다.

라우터는 보통 Source/Destination IP와 Port 같은 Flow 정보를 해시해 하나의 방향에서

같은 Flow가 같은 Next Hop을 사용하도록 한다.

 

하지만 반대 방향에서는 Source와 Destination이 서로 바뀐다.

장비의 해시 방식과 토폴로지에 따라 Return Path가 다른 링크나 장비를 선택할 수 있다.

 

Stateless한 네트워크에서는 문제가 없을 수 있지만 특정 Stateful Middlebox를 반드시 통과해야 한다면

정책 기반 라우팅, 상태 동기화, 대칭 해시 설계 같은 추가 고려가 필요하다.

ECMP가 곧 비대칭 장애를 뜻하지는 않는다. 여러 경로와 상태 의존 장비가 만날 때 설계를 확인해야 한다는 뜻이다.

---

ㅁ 어디에서 사라졌는지 어떻게 찾을까?

왕복 장애는 한 지점의 ping만으로 원인을 확정하기 어렵다.

패킷의 여정을 여러 지점에서 나누어 관찰해야 한다.

 

ㅇ Client에서 확인한다

Client가 요청을 실제로 내보내는지, 응답이 돌아오는지 본다.

sudo tcpdump -n -i eth0 host 10.2.0.20

 

ㅇ Server에서 확인한다

요청이 도착했는지, Server가 응답을 생성하는지 본다.

sudo tcpdump -n -i eth0 host 10.1.0.10

 

ㅇ 각 Router에서 양쪽 인터페이스를 확인한다

요청과 응답이 어느 인터페이스까지 보이는지 비교한다.

sudo tcpdump -n -i any 'host 10.1.0.10 and host 10.2.0.20'

-i any는 어느 인터페이스에서 관찰되었는지 출력과 캡처 형식이 환경에 따라 다를 수 있다. 정확한 입출력 구분이 필요하면 각 인터페이스에서 별도로 캡처한다.

 

ㅇ 양쪽에서 경로를 조회한다

Client에서 Server 방향을 확인한다.

ip route get 10.2.0.20

Server 또는 Return Router에서 Client 방향을 확인한다.

ip route get 10.1.0.10

한쪽의 ip route get만으로 왕복 경로를 증명할 수 없다. 방향마다 Destination과 Source가 달라지므로 양 끝과 관련 라우터에서 각각 확인해야 한다.

 

ㅇ Stateful 상태를 확인한다

Firewall과 NAT가 있다면 연결 상태가 어느 장비에 생성되었는지 확인한다. Linux 환경에서는 권한과 구성에 따라 conntrack 도구로 상태를 볼 수 있다.

sudo conntrack -L

이 명령은 연결 수가 많은 운영 장비에서 출력과 부하가 클 수 있다.

실제 환경에서는 주소와 프로토콜 필터를 사용하고 장비별 운영 절차를 따라야 한다.

---

ㅁ traceroute는 Return Path도 보여 줄까?

traceroute는 목적지 방향으로 TTL을 다르게 한 Probe를 보내고 중간 라우터가 돌려주는 ICMP 응답을 모아 경로를 추정한다.

화면에 표시되는 각 홉의 응답도 다시 관찰자에게 돌아와야 한다.

따라서 traceroute 결과는 순수하게 Forward Path만 복사해 보여 주는 기록이 아니다.

Probe가 나가는 길과 ICMP 응답이 돌아오는 길, 중간 장비의 응답 정책이 함께 영향을 준다.

어떤 홉이 *로 표시된다고 그 지점에서 Forwarding이 반드시 실패했다고 단정할 수 없다.

해당 라우터가 응답하지 않거나 Return Path에서 응답이 사라질 수도 있다.

traceroute는 유용한 단서지만 왕복 경로 전체를 한 번에 증명하는 도구는 아니다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
민수에서 영희로 가는 배달길	Forward Path	요청 패킷이 Source에서 Destination으로 가는 경로
영희에서 민수로 오는 답장길	Return Path	응답 패킷이 원래 Source로 돌아오는 경로
답장 주소에 대한 안내가 없음	Missing Return Route	응답 목적지로 가는 Route가 없는 상태
요청과 답장이 서로 다른 우체국을 지남	Asymmetric Routing	양방향 패킷이 서로 다른 네트워크 경로를 사용
요청을 본 경비실만 답장을 허용	Stateful Firewall	연결 상태를 기준으로 응답 트래픽을 판단하는 장비
번역표를 가진 우체국으로 답장이 돌아옴	NAT State	주소와 Port 변환 관계를 저장한 상태 정보
발신 지역과 들어온 문을 대조	Reverse Path Filtering	Source IP 경로와 수신 인터페이스를 검증하는 기능
여러 길에 같은 흐름을 나누어 배정	ECMP Hashing	Flow 정보를 사용해 여러 Next Hop을 선택하는 방식

 

왕복 통신의 확인 순서는 다음과 같다.

1. Forward Path에서 요청이 각 구간을 통과하는지 확인한다.
2. Destination이 요청을 받고 응답을 생성하는지 확인한다.
3. Return Path의 각 장비가 Source Network로 가는 Route를 갖는지 확인한다.
4. Firewall, NAT, Load Balancer의 State가 Return Traffic과 일치하는지 확인한다.
5. Source Validation과 정책이 비대칭 경로를 허용하는지 확인한다.

---

ㅁ 직접 경로를 복원해 보기

다음 캡처 결과를 보고 패킷이 멈춘 위치를 추정해 보자.

Client capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request
10.1.0.10 → 10.2.0.20  ICMP Echo Request

Server capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request
10.2.0.20 → 10.1.0.10  ICMP Echo Reply

R2 transit-side capture
10.1.0.10 → 10.2.0.20  ICMP Echo Request

 

확인할 수 있는 사실은 다음과 같다.

1. Echo Request는 Server까지 도착했다.
2. Server는 Echo Reply를 생성했다.
3. Reply는 R2의 Server 쪽으로 나왔지만 Transit 쪽에서는 보이지 않는다.
4. R2의 Client Network Route, Forwarding Policy, Firewall을 우선 확인해야 한다.

이 증거만으로 R2의 Missing Route라고 단정할 수는 없다.

R2 내부의 Firewall이나 Source Validation이 Reply를 Drop했을 가능성도 있기 때문이다.

관찰은 범인을 바로 지목하는 일이 아니라 가능한 실패 범위를 줄이는 일이다.

---

ㅁ 핵심 정리

• Forward Path와 Return Path는 서로 독립적인 Routing Table Lookup 결과다.
• 요청이 Destination에 도착해도 Return Route가 없으면 통신은 완성되지 않는다.
• TCP에서는 SYN이 도착하고 SYN-ACK이 돌아오지 않아 Client가 SYN을 재전송할 수 있다.
• ICMP 오류 메시지도 돌아올 경로가 없으면 Client에 도착하지 않는다.
• Asymmetric Routing 자체는 IP 네트워크에서 정상적으로 동작할 수 있다.
• Stateful Firewall과 NAT는 요청을 본 장비에 상태가 있으므로 Return Path가 달라지면 Drop할 수 있다.
• Reverse Path Filtering은 Source Spoofing을 줄이지만 정상 비대칭 경로에 영향을 줄 수 있다.
• 양 끝과 중간 지점의 캡처 및 양방향 Route Lookup을 함께 봐야 패킷 여정을 복원할 수 있다.
• ping과 traceroute 한 가지 결과만으로 단방향 성공과 실패 위치를 확정할 수 없다.

 

핵심 용어: Forward Path, Return Path, Return Route, Missing Route, Asymmetric Routing, Path Symmetry, Stateful Firewall, NAT State, Reverse Path Filtering, rp_filter, ECMP Hashing, Multi-point Capture

 

통신은 요청이 도착하는 사건이 아니다. 서로 독립적으로 선택된 가는 길과 오는 길이 모두 이어지는 사건이다.

---

ㅁ 다음 이야기

경로가 없으면 패킷은 목적지에 도착하지 못한다.

그런데 잘못된 경로가 존재하면 더 이상한 일이 생길 수 있다.

R1은 R2를 가리키고 R2는 다시 R1을 가리키면 패킷은 두 라우터 사이를 계속 맴돈다.

IP 패킷은 이 순환에서 어떻게 빠져나올까?

다음 글에서는 「길을 잃은 편지가 영원히 돌면 어떻게 될까?」라는 질문을 통해

Routing Loop, TTL, ICMP Time Exceeded와 traceroute가 경로를 드러내는 원리를 살펴본다.