Gateway와 Routing 완벽 이해
시스템 엔지니어를 위한 네트워크 6편
Gateway와 Routing 완벽 이해
서버 운영을 하다 보면 다음과 같은 장애를 자주 만나게 됩니다.
- 서버에서는 IP가 정상적으로 설정되어 있는데 외부 서버와 통신이 되지 않는다.
- 같은 네트워크의 서버는 접속되는데 다른 네트워크의 서버는 접속되지 않는다.
- 인터넷은 안 되는데 Gateway에는 Ping이 된다.
- 특정 서버만 접속되지 않는다.
- 서버에 NIC가 2개 있는데 통신이 엉뚱한 인터페이스로 나간다.
- Routing Table을 수정했더니 일부 서비스만 장애가 발생한다.
ping은 되는데 애플리케이션 접속은 되지 않는다.- 네트워크 장비에서는 정상이라고 하는데 서버에서는 계속 Timeout이 발생한다.
이런 문제를 분석하려면 단순히 IP 주소만 볼 것이 아니라 Gateway와 Routing Table을 이해해야 합니다.
이번 글에서는 시스템 엔지니어가 실제 서버 장애를 분석할 수 있도록 Gateway와 Routing을 처음부터 살펴보겠습니다.
1. Gateway란 무엇인가?
Gateway를 가장 간단하게 설명하면 다음과 같습니다.
자신이 속한 네트워크를 벗어나 다른 네트워크로 통신할 때 사용하는 출구
입니다.
예를 들어 서버가 다음과 같이 설정되어 있다고 가정해 보겠습니다.
Server IP : 192.168.10.100 Subnet : 255.255.255.0 Gateway : 192.168.10.1
서버가 192.168.10.200과 통신한다고 생각해 보겠습니다.
두 IP를 비교하면:
192.168.10.100 192.168.10.200
둘 다 192.168.10.0/24 네트워크에 있습니다.
따라서 서버는 Gateway를 거치지 않습니다.
Server
192.168.10.100
|
| 직접 통신
|
192.168.10.200
그런데 다음 서버와 통신한다면 어떨까요?
192.168.20.100
서버의 네트워크는:
192.168.10.0/24
목적지는:
192.168.20.0/24
서로 다른 네트워크입니다.
따라서 Gateway를 사용해야 합니다.
192.168.10.100
|
| Gateway
v
192.168.10.1
|
v
Router
|
v
192.168.20.100
즉 Gateway는 서버 입장에서 **다른 네트워크로 나가기 위한 다음 홉(Next Hop)**이라고 생각하면 이해하기 쉽습니다.
2. Default Gateway란 무엇인가?
실제 서버에서는 모든 목적지에 대해 Routing을 하나씩 설정하지 않습니다.
예를 들어 인터넷에는 수많은 네트워크가 존재합니다.
8.8.8.8 1.1.1.1 10.10.10.10 172.16.20.30 192.168.50.100 ...
서버가 모든 네트워크에 대한 Route를 가지고 있다면 Routing Table이 매우 복잡해질 것입니다.
그래서 대부분의 서버에는 다음과 같은 Default Route가 존재합니다.
default via 192.168.10.1 dev ens160
이 의미는 다음과 같습니다.
특별히 일치하는 Routing 정보가 없으면 192.168.10.1 Gateway를 통해 전송한다.
즉:
목적지 네트워크를 정확히 알고 있음
|
v
해당 Route 사용
목적지 네트워크를 모름
|
v
Default Route 사용
|
v
Default Gateway
3. Gateway와 Router는 같은 것인가?
비슷하지만 관점이 다릅니다.
Router
Router는 서로 다른 네트워크를 연결하고 IP Routing을 수행하는 장비 또는 기능입니다.
Network A
192.168.10.0/24
|
v
Router
|
v
Network B
192.168.20.0/24
Gateway
Gateway는 특정 시스템 입장에서 다른 네트워크로 나가기 위해 사용하는 장치를 의미합니다.
예를 들어:
Server 192.168.10.100 Gateway 192.168.10.1
서버 입장에서는 192.168.10.1이 Gateway입니다.
실제 장비가 Router일 수도 있고 L3 Switch일 수도 있습니다.
중요한 것은 서버 입장에서 다른 네트워크로 나가기 위한 다음 홉이라는 점입니다.
4. Routing이란 무엇인가?
Routing은 쉽게 말하면 다음과 같습니다.
목적지 IP 주소를 보고 어느 방향으로 패킷을 보낼지 결정하는 과정
입니다.
예를 들어 서버가 다음과 같이 설정되어 있다고 가정하겠습니다.
IP : 192.168.10.100 Subnet : /24 Gateway : 192.168.10.1
서버가 다음 목적지로 패킷을 보내려고 합니다.
192.168.10.200
서버는 자신의 Routing 정보를 확인합니다.
192.168.10.0/24
목적지:
192.168.10.200
해당 네트워크에 포함됩니다.
따라서 직접 통신합니다.
Server
192.168.10.100
|
| 직접 전송
v
192.168.10.200
반대로:
192.168.20.100
이라면:
192.168.10.0/24
에 포함되지 않습니다.
따라서 Gateway를 사용합니다.
Server
192.168.10.100
|
v
Gateway
192.168.10.1
|
v
192.168.20.100
5. Linux 서버의 Routing Table
Linux에서 Routing Table을 확인하는 가장 중요한 명령어는 다음입니다.
ip route
예를 들어:
default via 192.168.10.1 dev ens160 192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.100
하나씩 살펴보겠습니다.
5.1 Default Route
default via 192.168.10.1 dev ens160
의미:
default
모든 목적지
via 192.168.10.1
Gateway는 192.168.10.1
dev ens160
ens160 인터페이스를 사용한다는 의미입니다.
즉:
모르는 목적지
|
v
192.168.10.1
|
v
ens160
6. Connected Route
다음 정보를 보겠습니다.
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.100
이것은 서버의 IP와 Subnet Mask를 기반으로 Linux Kernel이 자동으로 만든 Route입니다.
서버가:
IP = 192.168.10.100 Subnet = /24
이면 자신이 속한 네트워크는:
192.168.10.0/24
입니다.
따라서 Linux는 다음과 같은 Route를 가지고 있습니다.
192.168.10.0/24
|
v
ens160
이것이 중요한 이유는 같은 네트워크에 있는 목적지는 Gateway를 거치지 않기 때문입니다.
7. 실제 패킷 전달 과정
이제 실제 상황을 생각해 보겠습니다.
서버:
IP : 192.168.10.100 Subnet : /24 Gateway : 192.168.10.1 NIC : ens160
목적지:
192.168.20.100
입니다.
서버는 먼저 목적지가 자신의 네트워크인지 확인합니다.
Server Network 192.168.10.0/24 Destination 192.168.20.100
다른 네트워크입니다.
따라서 Gateway를 사용합니다.
그런데 여기서 중요한 부분이 있습니다.
서버가 Gateway의 IP만 알고 있다고 해서 바로 Ethernet Frame을 만들 수 있는 것은 아닙니다.
Gateway의 MAC Address가 필요합니다.
따라서 먼저 ARP를 수행합니다.
Who has 192.168.10.1?
Gateway:
192.168.10.1 is-at AA:BB:CC:DD:EE:01
그러면 서버는 다음과 같은 Ethernet Frame을 생성합니다.
Source MAC Server MAC Destination MAC Gateway MAC
그런데 IP Header는:
Source IP 192.168.10.100 Destination IP 192.168.20.100
입니다.
이 부분이 매우 중요합니다.
8. Gateway를 거칠 때 MAC과 IP는 어떻게 변하는가?
패킷이 Router를 통과하면 L2 Ethernet Header와 L3 IP Header를 구분해서 생각해야 합니다.
처음 서버에서:
Ethernet SRC MAC = Server MAC DST MAC = Gateway MAC IP SRC IP = 192.168.10.100 DST IP = 192.168.20.100
Router에 도착하면 Router는 IP Header를 확인합니다.
그리고 다음 네트워크로 전달하기 위해 새로운 Ethernet Frame을 만듭니다.
Ethernet SRC MAC = Router MAC DST MAC = Next Hop MAC IP SRC IP = 192.168.10.100 DST IP = 192.168.20.100
즉 기본적으로:
MAC Address 홉마다 변경 IP Address 최종 목적지까지 유지
라고 이해하면 됩니다.
단, NAT가 적용되는 경우에는 IP 주소도 변경될 수 있습니다.
9. Linux에서 내가 어떤 Route를 사용하는지 확인하기
Routing Table 전체를 보는 것도 중요하지만 실제 장애 분석에서는 다음 명령어가 매우 중요합니다.
ip route get 8.8.8.8
예:
8.8.8.8 via 192.168.10.1 dev ens160 src 192.168.10.100
이 결과는:
Destination 8.8.8.8 Gateway 192.168.10.1 Interface ens160 Source IP 192.168.10.100
을 의미합니다.
즉 Linux Kernel이 실제로 어떤 경로를 선택하는지 바로 확인할 수 있습니다.
10. NIC가 2개 이상인 서버에서 Routing이 중요한 이유
실제 서버에는 NIC가 하나만 있는 경우도 있지만 다음과 같이 여러 NIC가 연결된 서버도 많습니다.
Server
+---------------+
| |
ens160 | | ens192
| | | |
| +---------------+ |
| |
Network A Network B
192.168.10.0/24 10.10.10.0/24
예를 들어:
ens160 192.168.10.100/24 ens192 10.10.10.100/24
Routing Table:
default via 192.168.10.1 dev ens160 192.168.10.0/24 dev ens160 10.10.10.0/24 dev ens192
이 경우:
192.168.10.200
으로 가는 패킷은:
ens160
을 사용합니다.
반면:
10.10.10.200
으로 가는 패킷은:
ens192
을 사용합니다.
이것이 바로 Routing입니다.
11. Routing에서 가장 중요한 개념 — Longest Prefix Match
Routing Table에는 여러 Route가 존재할 수 있습니다.
예를 들어:
10.0.0.0/8 10.10.0.0/16 10.10.10.0/24
목적지가:
10.10.10.100
이라면 세 Route 모두 해당될 수 있습니다.
10.0.0.0/8 10.10.0.0/16 10.10.10.0/24
그러면 어떤 Route를 사용할까요?
가장 구체적인 Route를 사용합니다.
/24
입니다.
즉:
10.10.10.0/24
가 선택됩니다.
이것을 Longest Prefix Match라고 합니다.
쉽게 표현하면:
가장 좁고 구체적인 네트워크 경로를 우선한다.
입니다.
12. Routing 장애에서 자주 발생하는 문제
장애 1. Default Route가 없다
다음과 같은 서버를 생각해 보겠습니다.
ip route
결과:
192.168.10.0/24 dev ens160
Default Route가 없습니다.
서버는:
192.168.10.0/24
내부에서는 통신할 수 있습니다.
하지만:
8.8.8.8
같은 외부 네트워크로 갈 방법이 없습니다.
따라서:
ping 192.168.10.1
은 성공할 수 있지만:
ping 8.8.8.8
은 실패할 수 있습니다.
확인은:
ip route
로 합니다.
13. 장애 2. 잘못된 Default Gateway
예를 들어 서버가:
IP : 192.168.10.100/24 Gateway : 192.168.20.1
으로 설정되어 있다고 가정하겠습니다.
Gateway가 서버의 동일 네트워크에 존재하지 않습니다.
Server
192.168.10.100/24
|
X
192.168.20.1
정상적인 경우라면 Gateway는 일반적으로 서버가 직접 도달할 수 있는 네트워크에 있어야 합니다.
예:
Server
192.168.10.100/24
|
v
Gateway
192.168.10.1
잘못된 Gateway를 설정하면 ARP 단계부터 문제가 발생할 수 있습니다.
14. 장애 3. Gateway는 Ping되는데 외부 통신이 안 된다
이 경우 매우 중요한 장애 분석 포인트가 있습니다.
ping 192.168.10.1
성공
하지만:
ping 8.8.8.8
실패
라면 서버에서 Gateway까지의 통신은 정상일 가능성이 높습니다.
구조는:
Server | | 정상 v Gateway | X | External Network
이 경우 다음 영역을 확인해야 합니다.
1. Gateway Routing 2. 상위 Router 3. Firewall 4. NAT 5. Return Path
즉 서버의 문제라고 단정하면 안 됩니다.
15. 장애 4. 특정 서버만 접속되지 않는다
예를 들어:
Server A → 192.168.20.100 성공 Server A → 192.168.30.100 실패
라면 무조건 Gateway 장애라고 생각하면 안 됩니다.
Routing Table을 확인해야 합니다.
ip route
그리고:
ip route get 192.168.30.100
을 실행합니다.
예:
192.168.30.100 via 192.168.10.1 dev ens160 src 192.168.10.100
이 결과라면 현재 해당 목적지에 대한 경로가:
Gateway 192.168.10.1 Interface ens160
임을 확인할 수 있습니다.
16. 장애 5. 잘못된 Static Route
예를 들어 다음과 같은 Routing Table이 있다고 가정하겠습니다.
default via 192.168.10.1 dev ens160 10.10.0.0/16 via 192.168.10.1 dev ens160 10.10.20.0/24 via 192.168.10.200 dev ens192
목적지가:
10.10.20.100
이면 두 Route가 해당될 수 있습니다.
10.10.0.0/16 10.10.20.0/24
하지만 /24가 더 구체적입니다.
따라서:
10.10.20.0/24 via 192.168.10.200 dev ens192
가 선택됩니다.
잘못된 Static Route가 존재하면 특정 네트워크만 장애가 발생할 수 있습니다.
이런 장애가 실제 운영 환경에서 매우 찾기 어렵습니다.
17. Linux에서 Route 추가하기
임시로 Route를 추가하려면:
ip route add 10.20.30.0/24 via 192.168.10.1 dev ens160
확인:
ip route
또는:
ip route get 10.20.30.100
삭제:
ip route del 10.20.30.0/24
주의할 점은 ip route add로 추가한 설정은 일반적으로 재부팅 후 유지되지 않는다는 것입니다.
운영 서버에서는 NetworkManager 등의 네트워크 설정에 영구적으로 등록해야 합니다.
18. Rocky Linux / RHEL 계열에서 Static Route 확인
최근 Rocky Linux와 RHEL 계열에서는 NetworkManager를 사용하는 것이 일반적입니다.
현재 연결 확인:
nmcli connection show
예:
NAME UUID TYPE ens160 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet
Route 확인:
nmcli connection show ens160
특정 Route를 추가하려면:
nmcli connection modify ens160 +ipv4.routes "10.20.30.0/24 192.168.10.1"
적용:
nmcli connection up ens160
확인:
ip route
운영 환경에서는 변경 전에 반드시 기존 네트워크 설정과 관리 콘솔/접속 경로를 확인해야 합니다.
특히 원격 SSH 환경에서 잘못된 Route를 적용하면 현재 SSH 세션이 끊길 수 있습니다.
19. ip route와 ip route get의 차이
두 명령어의 차이를 정확하게 이해하는 것이 중요합니다.
전체 Routing Table
ip route
목적:
서버가 어떤 Routing 정보를 가지고 있는지 확인
예:
default via 192.168.10.1 dev ens160 192.168.10.0/24 dev ens160 10.10.0.0/16 via 192.168.10.1 dev ens160
특정 목적지의 실제 경로
ip route get 10.10.20.100
목적:
실제로 이 목적지로 패킷을 보내면 어떤 Route를 선택하는지 확인
예:
10.10.20.100 via 192.168.10.1 dev ens160 src 192.168.10.100
장애 분석에서는 ip route get이 매우 강력합니다.
20. Gateway의 MAC Address 확인
Gateway로 패킷을 보내려면 Gateway의 MAC Address가 필요합니다.
다음 명령어로 확인할 수 있습니다.
ip neigh
예:
192.168.10.1 dev ens160 lladdr aa:bb:cc:dd:ee:01 REACHABLE
의미:
Gateway IP 192.168.10.1 Gateway MAC aa:bb:cc:dd:ee:01 Interface ens160
즉:
192.168.10.1
|
v
aa:bb:cc:dd:ee:01
로 연결되어 있다는 것을 확인할 수 있습니다.
21. Gateway 통신 장애 분석
Gateway:
192.168.10.1
확인:
ping -c 4 192.168.10.1
ARP 상태:
ip neigh show 192.168.10.1
정상 예:
192.168.10.1 dev ens160 lladdr aa:bb:cc:dd:ee:01 REACHABLE
문제 예:
192.168.10.1 dev ens160 INCOMPLETE
INCOMPLETE라면 ARP 응답을 제대로 받지 못하고 있을 가능성이 있습니다.
이 경우 다음을 확인합니다.
1. NIC 상태 2. IP/Subnet 3. VLAN 4. Switch Port 5. Gateway 상태 6. ARP
22. tcpdump로 Gateway 통신 확인
이제 실제 패킷을 확인해 보겠습니다.
다음 명령어를 사용할 수 있습니다.
tcpdump -e -nn -i ens160 'arp or icmp'
Gateway에 Ping:
ping 192.168.10.1
정상적인 경우 ARP 과정이 보일 수 있습니다.
ARP, Request who-has 192.168.10.1 tell 192.168.10.100 ARP, Reply 192.168.10.1 is-at aa:bb:cc:dd:ee:01
이후 ICMP가 발생합니다.
IP 192.168.10.100 > 192.168.10.1: ICMP echo request IP 192.168.10.1 > 192.168.10.100: ICMP echo reply
이것을 보면:
ARP 정상 ↓ Gateway MAC 확인 ↓ ICMP Request 전달 ↓ ICMP Reply 수신
과정을 확인할 수 있습니다.
23. Gateway로 ARP Request만 나가고 Reply가 없다면?
예를 들어:
ARP, Request who-has 192.168.10.1 tell 192.168.10.100 ARP, Request who-has 192.168.10.1 tell 192.168.10.100 ARP, Request who-has 192.168.10.1 tell 192.168.10.100
그런데:
ARP Reply
가 없습니다.
이 경우 서버가 Gateway를 찾지 못하고 있는 것입니다.
가능한 원인:
서버 | X | Switch | X | Gateway
원인은 다양할 수 있습니다.
- 잘못된 VLAN - Switch Port 문제 - Gateway 인터페이스 Down - 잘못된 IP/Subnet - ARP 문제 - 네트워크 장비 문제
따라서 단순히 ping만 보고 판단하지 말고 tcpdump를 통해 패킷 흐름을 확인해야 합니다.
24. traceroute와 tracepath
Routing 문제에서는 경로를 확인하는 것도 중요합니다.
Linux에서는:
tracepath 8.8.8.8
또는:
traceroute 8.8.8.8
을 사용할 수 있습니다.
예를 들어:
1: 192.168.10.1 2: 192.168.20.1 3: 10.10.0.1 4: ...
처럼 패킷이 어느 Router를 거쳐 가는지 확인할 수 있습니다.
다만 중간 장비가 ICMP나 TTL Exceeded 응답을 차단하는 경우 정상적으로 표시되지 않을 수 있습니다.
따라서 traceroute 결과만 가지고 장애를 단정하면 안 됩니다.
25. 실제 서버 장애 분석 사례
다음 상황을 가정해 보겠습니다.
서버:
IP : 192.168.10.100 Subnet : /24 Gateway : 192.168.10.1 NIC : ens160
문제:
ping 192.168.10.1
실패
ping 8.8.8.8
실패
이때 바로 Gateway 장애라고 판단하지 않습니다.
1단계. NIC 확인
ip link show ens160
정상:
state UP
2단계. IP 확인
ip -4 addr show ens160
정상:
inet 192.168.10.100/24
3단계. Routing 확인
ip route
정상:
default via 192.168.10.1 dev ens160 192.168.10.0/24 dev ens160
4단계. 실제 경로 확인
ip route get 8.8.8.8
정상:
8.8.8.8 via 192.168.10.1 dev ens160 src 192.168.10.100
5단계. Gateway ARP 확인
ip neigh
문제:
192.168.10.1 dev ens160 INCOMPLETE
이제 의심할 수 있는 범위가 좁아집니다.
6단계. tcpdump
tcpdump -e -nn -i ens160 'arp or icmp'
그리고:
ping 192.168.10.1
실행합니다.
패킷:
ARP Request who-has 192.168.10.1 ARP Request who-has 192.168.10.1 ARP Request who-has 192.168.10.1
Reply가 없습니다.
이제 다음과 같이 판단할 수 있습니다.
NIC 정상 IP 정상 Routing 정상 ARP Request 발생 ARP Reply 없음
따라서 문제는 서버의 애플리케이션이나 TCP Port가 아닙니다.
L2 구간 또는 Gateway 접근 단계에서 문제를 찾는 것이 맞습니다.
26. 또 다른 장애 — Gateway는 정상인데 특정 네트워크만 안 된다
다음 상황을 생각해 보겠습니다.
ping 192.168.10.1
성공
ping 8.8.8.8
성공
하지만:
ping 10.20.30.100
실패
이 경우 Gateway 자체는 정상일 가능성이 높습니다.
먼저:
ip route get 10.20.30.100
확인합니다.
예:
10.20.30.100 via 192.168.10.1 dev ens160
서버는 정상적으로 Gateway로 보내고 있습니다.
그렇다면 이제 확인 범위는:
Server | | 정상 v Gateway | | ? v 중간 Router | | ? v Destination
으로 이동합니다.
이것이 시스템 엔지니어가 해야 하는 장애 분석입니다.
27. 비대칭 Routing(Asymmetric Routing)
실제 운영 환경에서 매우 중요한 개념입니다.
정상적인 경우:
Client | v Router A | v Server
응답:
Server | v Router A | v Client
그런데 다음과 같이 구성될 수 있습니다.
Client | v Router A | v Server | v Router B | v Client
이것을 Asymmetric Routing, 즉 비대칭 Routing이라고 합니다.
경로가 서로 다르기 때문에 방화벽이나 상태 기반 장비에서 문제가 발생할 수 있습니다.
특히:
Firewall Load Balancer NAT Multi-Homing Server
환경에서는 매우 중요한 장애 원인입니다.
28. Multi-NIC 서버의 Routing 장애
예를 들어 서버에 NIC가 두 개 있다고 가정합니다.
ens160 192.168.10.100 ens192 192.168.20.100
그리고 두 네트워크에 모두 Default Gateway가 존재한다고 생각해 보겠습니다.
default via 192.168.10.1 dev ens160 default via 192.168.20.1 dev ens192
이런 구성은 매우 주의해야 합니다.
서버가 어떤 목적지로 패킷을 보낼 때 예상과 다른 Interface를 선택할 수 있기 때문입니다.
확인은:
ip route
그리고 반드시:
ip route get <목적지>
로 확인하는 것이 좋습니다.
예:
ip route get 10.10.10.100
결과:
10.10.10.100 via 192.168.20.1 dev ens192
이런 식으로 실제 선택된 경로를 확인할 수 있습니다.
29. Routing 장애 분석의 핵심 명령어
실제 현장에서 다음 명령어를 순서대로 사용하는 습관을 들이는 것이 좋습니다.
NIC
ip link
IP
ip -4 addr
Routing Table
ip route
특정 목적지 Routing
ip route get <destination>
Gateway MAC
ip neigh
Gateway 통신
ping -c 4 <gateway>
경로 확인
tracepath <destination>
포트 확인
ss -lntp
패킷 확인
tcpdump -e -nn -i ens160 'arp or icmp'
30. 실제 장애 분석 순서
Gateway 또는 Routing 문제가 발생했다면 다음 순서로 접근하면 좋습니다.
① NIC ↓ ② IP ↓ ③ Subnet ↓ ④ Routing Table ↓ ⑤ Default Gateway ↓ ⑥ ARP ↓ ⑦ Gateway Ping ↓ ⑧ 목적지 Routing ↓ ⑨ Tracepath ↓ ⑩ TCP Port ↓ ⑪ Application ↓ ⑫ tcpdump
좀 더 실무적으로 표현하면:
"네트워크가 안 된다"
|
v
NIC가 살아 있는가?
|
v
IP가 올바른가?
|
v
Subnet이 올바른가?
|
v
Routing Table이 올바른가?
|
v
Gateway가 올바른가?
|
v
Gateway MAC을 찾는가?
|
v
Gateway까지 통신되는가?
|
v
목적지까지 Route가 존재하는가?
|
v
TCP Port가 열려 있는가?
|
v
Application이 정상인가?
이렇게 범위를 하나씩 좁혀 나가야 합니다.
31. Gateway와 Routing을 이해하면 장애 분석 방법이 달라진다
초보자는 다음과 같이 생각하기 쉽습니다.
Ping이 안 된다 → 네트워크 장애
하지만 시스템 엔지니어는 이렇게 생각해야 합니다.
Ping 실패 | +-- NIC? | +-- IP? | +-- Subnet? | +-- ARP? | +-- Gateway? | +-- Routing? | +-- Firewall? | +-- Destination?
그리고 명령어로 하나씩 검증합니다.
ip link ip addr ip route ip route get ip neigh ping tracepath tcpdump
결국 중요한 것은 추측이 아니라 패킷이 실제로 어디까지 도달하는지를 확인하는 것입니다.
32. Gateway와 Routing 핵심 정리
이번 내용을 하나의 그림으로 정리하면 다음과 같습니다.
Server
192.168.10.100/24
|
|
+------v------+
| Routing |
| Table |
+------+------+
|
+-------+--------+
| |
v v
192.168.10.0/24 Other Network
| |
| v
| Default Gateway
| 192.168.10.1
| |
v v
Direct Traffic Router
|
v
Destination
핵심 개념은 다음과 같습니다.
Gateway
다른 네트워크로 나가기 위한 출구입니다.
Default Gateway
특정 Route가 없을 때 사용하는 기본 Gateway입니다.
Routing
목적지 IP를 기준으로 패킷을 어느 방향으로 보낼지 결정하는 과정입니다.
Routing Table
Linux Kernel이 패킷의 경로를 결정하기 위해 사용하는 정보입니다.
Longest Prefix Match
여러 Route가 일치하면 가장 구체적인 Route를 우선 선택합니다.
Next Hop
패킷을 최종 목적지까지 보내기 위해 다음으로 전달해야 하는 Router입니다.
33. 시스템 엔지니어가 반드시 기억해야 할 명령어
Gateway와 Routing 장애가 발생하면 우선 다음 명령어부터 확인합니다.
# IP 확인 ip -4 addr # Routing Table ip route # 특정 목적지의 실제 경로 ip route get 8.8.8.8 # Gateway MAC 확인 ip neigh # Gateway 통신 확인 ping -c 4 192.168.10.1 # 목적지까지 경로 확인 tracepath 8.8.8.8 # 패킷 확인 tcpdump -e -nn -i ens160 'arp or icmp'
특히 다음 세 가지는 반드시 익숙해져야 합니다.
ip route ip route get <destination> ip neigh
이 세 명령어만 제대로 활용해도 상당수의 서버 Routing 장애를 빠르게 좁힐 수 있습니다.
마무리
Gateway와 Routing은 네트워크에서 단순히 외워야 하는 개념이 아닙니다.
실제 서버가 패킷을 전송할 때:
목적지 IP 확인
↓
내 네트워크인가?
↓
Yes ─────────→ 직접 전달
|
No
↓
Routing Table 검색
↓
가장 적합한 Route 선택
↓
Next Hop 확인
↓
Gateway MAC 확인
↓
Ethernet Frame 생성
↓
Gateway로 전달
↓
Router가 다음 네트워크로 전달
이라는 과정을 거칩니다.
따라서 시스템 엔지니어가 네트워크 장애를 분석할 때는 단순히 ping 하나만 실행해서는 안 됩니다.
다음과 같은 순서로 확인해야 합니다.
NIC ↓ IP ↓ Subnet ↓ Routing ↓ Gateway ↓ ARP ↓ Packet ↓ TCP ↓ Application
이 흐름을 이해하면 서버에서 발생하는 대부분의 네트워크 장애를 계층별로 분리해서 분석할 수 있습니다.
특히 ip route, ip route get, ip neigh, tcpdump를 함께 사용하면 "네트워크가 안 된다"라는 막연한 장애를 어느 구간에서 패킷이 사라지는지까지 좁혀갈 수 있습니다.
다음 편에서는 Gateway와 Routing 과정에서 반드시 등장하는 **ARP(Address Resolution Protocol)**를 집중적으로 다뤄보겠습니다.
다음 주제에서는 단순히 "ARP는 IP를 MAC으로 변환한다" 정도에서 끝내지 않고,
IP 주소 ↓ ARP Request ↓ Broadcast ↓ ARP Reply ↓ MAC Address 확인 ↓ Ethernet Frame 생성 ↓ 실제 통신
과정을 Linux의 ip neigh와 tcpdump로 직접 확인하면서 ARP 장애, ARP INCOMPLETE, 중복 IP, 잘못된 VLAN, Gratuitous ARP까지 실무 관점에서 분석해 보겠습니다.
중복 설명을 줄이고 핵심만 남겨줘장애 분석 사례를 표로 재구성해줘
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.