시스템 엔지니어를 위한 네트워크 실전 교육
시스템 엔지니어를 위한 네트워크 실전 교육
이론 → Linux 명령어 → 실제 장애 상황 → tcpdump 패킷 확인
네트워크를 처음 공부할 때는 보통 다음과 같은 내용을 배운다.
OSI 7계층 TCP/IP Ethernet MAC Address IP Address Subnet Gateway Routing TCP UDP DNS
하지만 시스템 엔지니어에게 중요한 것은 이러한 개념을 단순히 암기하는 것이 아니다.
실제 서버 장애가 발생했을 때 다음과 같은 질문에 답할 수 있어야 한다.
서버의 네트워크 카드가 정상인가? IP Address가 정상적으로 설정되어 있는가? 같은 네트워크에 있는 서버와 통신할 수 있는가? Gateway까지 통신할 수 있는가? 목적지까지 Routing이 존재하는가? TCP 연결이 만들어지고 있는가? 방화벽이 패킷을 차단하고 있는가? 서버까지 패킷이 실제로 도착하고 있는가? 서버가 응답 패킷을 보내고 있는가? Application이 정상적으로 응답하고 있는가?
이 질문에 답하기 위해서는 네트워크 이론과 Linux 명령어, 그리고 실제 패킷을 확인하는 능력이 필요하다.
이번 글에서는 네트워크를 다음과 같은 방식으로 학습한다.
네트워크 이론
↓
Linux 네트워크 명령어
↓
실제 장애 상황
↓
tcpdump 패킷 확인
↓
장애 원인 판단
↓
장애 해결
이것이 시스템 엔지니어가 네트워크를 공부하는 최종적인 목적이다.
1. 네트워크 장애 분석의 기본 원칙
네트워크 장애가 발생하면 가장 먼저 해야 할 일은 장애를 작은 문제로 분리하는 것이다.
예를 들어:
"서버에 접속이 안 됩니다."
라는 요청을 받았다고 하자.
이것만 가지고는 아무것도 판단할 수 없다.
먼저 다음과 같이 나눈다.
Client | v Network | v Server | v Port | v Application
그리고 각각을 확인한다.
1. Client 문제인가? 2. Network 문제인가? 3. Server NIC 문제인가? 4. IP/Subnet 문제인가? 5. Routing 문제인가? 6. Firewall 문제인가? 7. TCP Port 문제인가? 8. Application 문제인가?
이렇게 문제를 분해하는 것이 네트워크 장애 분석의 시작이다.
2. 첫 번째 단계 — NIC 확인
서버의 네트워크 통신은 NIC(Network Interface Card)에서 시작한다.
Linux에서는 다음 명령어를 사용한다.
ip link
예:
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP>
여기서 중요한 값은:
UP LOWER_UP
이다.
일반적으로:
UP
은 인터페이스가 활성화되어 있다는 의미이고,
LOWER_UP
은 하위 링크 계층에서 링크가 올라와 있다는 것을 나타낸다.
물론 이것만으로 물리 네트워크 전체가 정상이라고 단정할 수는 없다.
3. NIC 상세 정보 확인
다음 명령어도 자주 사용한다.
ethtool ens160
예:
Settings for ens160:
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
여기서 특히 중요한 부분은:
Link detected: yes
이다.
반대로:
Link detected: no
라면 다음 영역을 확인해야 한다.
Server NIC ↓ Network Cable ↓ Switch Port ↓ Switch
가상머신 환경이라면:
Virtual NIC ↓ Hypervisor ↓ Virtual Switch ↓ Physical NIC
까지 확인 범위를 넓혀야 한다.
4. 두 번째 단계 — IP Address 확인
NIC가 정상이라면 IP Address를 확인한다.
ip addr
예:
2: ens160:
inet 192.168.10.100/24
여기서 확인해야 할 것은 다음과 같다.
IP Address Subnet Prefix Interface
예를 들어 서버가 다음과 같이 설정되어 있다고 하자.
IP : 192.168.10.100 Subnet : /24
그러면 서버가 속한 네트워크는:
192.168.10.0/24
이다.
5. IP Address만 보면 안 되는 이유
네트워크 장애를 분석할 때 다음처럼 IP만 보는 것은 부족하다.
192.168.10.100
반드시 다음까지 함께 봐야 한다.
192.168.10.100/24
왜냐하면 /24가 네트워크 범위를 결정하기 때문이다.
예를 들어:
Server A 192.168.10.100/24 Server B 192.168.10.200/24
이면 같은 네트워크다.
하지만:
Server A 192.168.10.100/24 Server B 192.168.20.200/24
이면 다른 네트워크다.
따라서 서로 다른 네트워크 간 통신에는 Routing이 필요하다.
6. 세 번째 단계 — Routing 확인
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
이를 해석하면:
192.168.10.0/24
↓
ens160으로 직접 연결
그 외의 네트워크
↓
192.168.10.1 Gateway로 전달
이라는 의미다.
7. 특정 목적지의 Routing 확인
실무에서 매우 유용한 명령어가 있다.
ip route get 10.10.20.50
예:
10.10.20.50 via 192.168.10.1 dev ens160 src 192.168.10.100
이 명령어를 통해 Linux가 특정 목적지로 패킷을 보낼 때:
Destination Gateway Interface Source IP
를 어떻게 선택하는지 확인할 수 있다.
장애 분석에서 상당히 유용하다.
8. 네 번째 단계 — Gateway 확인
기본 Gateway가:
192.168.10.1
이라면:
ping 192.168.10.1
을 실행한다.
정상:
64 bytes from 192.168.10.1: 64 bytes from 192.168.10.1: 64 bytes from 192.168.10.1:
이 경우 서버에서 Gateway까지 기본적인 IP 통신이 가능하다는 것을 확인할 수 있다.
하지만 이것 역시 전체 네트워크가 정상이라는 의미는 아니다.
Server | | OK v Gateway | X | Destination
일 수도 있기 때문이다.
9. 다섯 번째 단계 — ARP/Neighbor 확인
같은 네트워크의 장치와 통신할 때는 상대방 MAC Address를 알아야 한다.
Linux에서는:
ip neigh
를 사용한다.
예:
192.168.10.1 dev ens160 lladdr 00:11:22:33:44:55 REACHABLE
여기서:
IP ↓ MAC
매핑을 확인할 수 있다.
즉:
192.168.10.1
↓
00:11:22:33:44:55
이다.
10. ARP 장애의 특징
예를 들어:
ping 192.168.10.1
이 실패한다고 하자.
그런데:
ip addr
는 정상이고:
ip route
도 정상이다.
이 경우 Layer 2 영역을 의심할 수 있다.
IP ↓ ARP ↓ MAC ↓ Switch ↓ NIC
ip neigh를 확인했을 때:
192.168.10.1 dev ens160 INCOMPLETE
처럼 나타날 수 있다.
이는 Neighbor 정보를 정상적으로 확인하지 못하고 있음을 의미한다.
이때는 다음 영역을 확인한다.
VLAN Switch Port ARP NIC Network Cable
환경에 따라 원인은 달라질 수 있으므로 INCOMPLETE 하나만으로 특정 장비를 원인이라고 단정해서는 안 된다.
11. 여섯 번째 단계 — Port 확인
이제 서버 자체의 TCP Port를 확인한다.
ss -lntp
예:
LISTEN 0 128 0.0.0.0:22 LISTEN 0 128 0.0.0.0:80 LISTEN 0 128 0.0.0.0:443
여기서:
22 80 443
이 서버에서 LISTEN 중인 Port다.
예를 들어 사용자가 HTTPS 접속을 할 수 없다면:
443
이 실제로 LISTEN 중인지 확인한다.
12. Port가 LISTEN 중이라고 접속 가능한 것은 아니다
매우 중요한 부분이다.
다음과 같이 되어 있다고 하자.
Application
|
| LISTEN
v
0.0.0.0:443
그런데 서버 방화벽에서 443을 차단할 수 있다.
Client | | TCP 443 v Firewall | X | Server
따라서:
ss
에서 Port가 보인다는 것과 외부에서 접속 가능하다는 것은 다른 문제다.
13. 일곱 번째 단계 — nc를 이용한 Port 테스트
다른 서버에서:
nc -zv 192.168.10.100 443
예:
Connection to 192.168.10.100 443 port [tcp/https] succeeded!
정상이다.
반대로:
Connection timed out
또는:
Connection refused
등이 발생할 수 있다.
여기서 중요한 것은 timeout과 refused를 같은 문제로 보면 안 된다는 것이다.
14. Connection refused와 timeout의 차이
예를 들어:
Connection refused
라면 TCP 연결 요청에 대해 상대 측에서 거부 응답이 돌아오는 상황을 생각할 수 있다.
대표적으로:
Client | | SYN v Server | | RST v Client
와 같은 흐름이 나타날 수 있다.
반면:
Connection timed out
은 응답 자체가 돌아오지 않는 상황일 수 있다.
예:
Client | | SYN v Firewall | X | Server
또는 서버/경로상의 문제 등 다양한 원인이 가능하다.
따라서 오류 메시지를 통해 어느 정도 범위를 좁힐 수 있지만, 최종 판단은 패킷과 구성 정보를 함께 확인해야 한다.
15. 여덟 번째 단계 — Application 확인
네트워크가 정상이고 Port도 열려 있다면 Application을 확인한다.
예를 들어 Nginx:
systemctl status nginx
Apache:
systemctl status httpd
SSH:
systemctl status sshd
PostgreSQL:
systemctl status postgresql
MariaDB:
systemctl status mariadb
Redis:
systemctl status redis
그리고 실제 Listen Port도 확인한다.
ss -lntp
16. 실제 장애 상황 1 — 서버가 완전히 네트워크에서 사라진 경우
이제 실제 장애를 분석해보자.
상황:
사용자 | X | Server 192.168.10.100
SSH 접속이 되지 않는다.
서버 콘솔에서:
ip link
확인한다.
결과:
ens160: <BROADCAST,MULTICAST,DOWN>
문제 발견이다.
이 경우 Application을 확인할 필요가 없다.
Application
↓
TCP
↓
IP
↓
Ethernet
↓
NIC
X
장애가 아래쪽 계층에서 발생했기 때문이다.
17. 실제 장애 상황 2 — IP가 잘못 설정된 경우
NIC는 정상이다.
ens160 UP LOWER_UP
하지만:
ip addr
결과:
192.168.20.100/24
실제로 서버가 있어야 하는 네트워크는:
192.168.10.0/24
이다.
그러면:
Network 192.168.20.0/24
에 연결되어 있는 것이다.
서버 자체의 네트워크 설정 오류일 가능성을 확인해야 한다.
18. 실제 장애 상황 3 — Gateway 설정 오류
서버:
IP: 192.168.10.100/24
Gateway가:
192.168.20.1
로 잘못 설정되어 있다고 하자.
그러면 서버의 네트워크와 Gateway가 동일한 직접 연결 네트워크에 속하지 않을 수 있다.
이런 경우 외부 네트워크 통신에 문제가 발생할 수 있다.
따라서:
ip addr ip route
를 항상 함께 확인하는 습관이 중요하다.
19. 실제 장애 상황 4 — Routing 문제
서버에서:
ping 192.168.10.1
은 성공한다.
하지만:
ping 10.10.20.50
은 실패한다.
이때 바로 Application을 의심하면 안 된다.
먼저:
ip route
그리고:
ip route get 10.10.20.50
을 확인한다.
예를 들어:
RTNETLINK answers: Network is unreachable
가 나온다면 서버에 목적지 네트워크로 가는 적절한 Routing이 없을 가능성이 있다.
20. 실제 장애 상황 5 — 방화벽 문제
서버:
IP 정상 Routing 정상 Port LISTEN
그런데 외부에서 접속이 안 된다.
이 경우 Firewall을 확인한다.
RHEL/Rocky 계열에서는:
firewall-cmd --state firewall-cmd --list-all
또는:
nft list ruleset
환경에 따라 확인 방법은 달라질 수 있다.
핵심은:
Application ↓ LISTEN ↓ Firewall ↓ Network
이라는 흐름을 이해하는 것이다.
21. 이제 tcpdump를 사용한다
여기까지 확인했는데도 원인을 모르겠다면 이제 패킷을 직접 확인한다.
tcpdump는 네트워크 인터페이스를 통과하는 패킷을 캡처하고 분석할 수 있는 도구다.
기본 사용법:
tcpdump -i ens160
특정 Port:
tcpdump -i ens160 port 443
특정 Host:
tcpdump -i ens160 host 192.168.10.50
특정 IP와 Port:
tcpdump -i ens160 host 192.168.10.50 and port 443
22. tcpdump의 기본 출력 이해하기
예를 들어:
tcpdump -i ens160 port 22
를 실행했을 때:
IP 192.168.10.50.53000 > 192.168.10.100.22: Flags [S]
와 같은 패킷이 보일 수 있다.
이를 단순화하면:
192.168.10.50:53000
|
| SYN
v
192.168.10.100:22
이다.
Client가 Server의 TCP 22번 Port로 연결을 요청하고 있는 것이다.
23. TCP 3-Way Handshake와 tcpdump
TCP 연결은 기본적으로 다음 과정으로 시작한다.
Client Server | | | -------- SYN --------------> | | | | <------ SYN-ACK ------------ | | | | -------- ACK --------------> | | | | Connection |
tcpdump에서도 이러한 흐름을 관찰할 수 있다.
24. 정상적인 TCP 연결
예:
Client → Server [S] Server → Client [S.] Client → Server [.]
일반적으로:
[S]
는 SYN,
[S.]
는 SYN과 ACK,
[.]
는 ACK를 의미한다.
정상적인 경우:
SYN ↓ SYN-ACK ↓ ACK ↓ Established
로 진행된다.
25. 장애 상황 — SYN만 반복되는 경우
다음과 같은 패킷이 반복된다고 하자.
Client → Server SYN Client → Server SYN Client → Server SYN
그런데:
Server → Client SYN-ACK
가 보이지 않는다.
이 경우 서버 측에서 다음 가능성을 조사해야 한다.
Client | | SYN v Network | X | Server
또는 패킷이 서버에 도착했지만 응답이 정상적으로 나가지 않는 경우도 있을 수 있다.
따라서 서버에서 tcpdump를 실행했을 때 SYN이 보이는지부터 확인해야 한다.
26. 장애 상황 — SYN이 서버에 도착하지 않는 경우
서버에서:
tcpdump -i ens160 port 443
을 실행한다.
Client가 접속을 시도한다.
그런데 아무것도 보이지 않는다.
그러면 적어도 해당 캡처 지점에서는 Client의 SYN이 서버 인터페이스까지 도달하는 것이 관찰되지 않는 것이다.
이때 확인 범위를 서버 애플리케이션에서 네트워크 경로 쪽으로 이동한다.
Client ↓ Client NIC ↓ Switch ↓ Firewall ↓ Load Balancer ↓ Routing ↓ Server NIC
이런 방식으로 범위를 확장한다.
27. 장애 상황 — SYN은 도착하지만 SYN-ACK이 없다
이번에는 서버에서:
Client → Server SYN
이 보인다.
그런데:
Server → Client SYN-ACK
가 보이지 않는다.
이 경우 서버의 다음 영역을 확인할 수 있다.
TCP/IP Stack Firewall Application Routing
예를 들어 Port가 LISTEN 중인지:
ss -lntp | grep ':443'
확인한다.
Firewall도 확인한다.
nft list ruleset
또는 환경에 따라:
firewall-cmd --list-all
을 확인한다.
28. 장애 상황 — SYN-ACK은 나가는데 Client가 ACK를 보내지 않는다
서버에서:
Client → Server SYN Server → Client SYN-ACK
까지 확인된다.
그런데:
Client → Server ACK
가 보이지 않는다.
이 경우 서버 자체보다는 응답 경로를 포함한 네트워크 경로를 조사해야 할 가능성이 있다.
예:
Server | | SYN-ACK v Firewall | X | Client
또는 비대칭 Routing 등의 문제를 확인해야 할 수 있다.
29. tcpdump는 어디에서 실행해야 하는가?
이것도 매우 중요하다.
서버에서 실행한 tcpdump는 서버 인터페이스에서 관찰되는 패킷을 보여준다.
따라서:
Client | | Firewall | | Server
에서 Server에서 캡처했다고 해서 Firewall에서 패킷이 어떻게 처리되었는지 직접 볼 수 있는 것은 아니다.
필요하면 여러 위치에서 확인한다.
Client | tcpdump | Switch | Firewall | Server | tcpdump
이런 방식으로 양쪽을 비교하면 패킷이 어느 구간에서 사라지는지 좁힐 수 있다.
30. tcpdump를 파일로 저장하기
장시간 패킷을 분석하거나 다른 담당자에게 전달해야 한다면 파일로 저장할 수 있다.
tcpdump -i ens160 -w capture.pcap
특정 Port:
tcpdump -i ens160 port 443 -w https.pcap
파일을 확인할 때:
tcpdump -r https.pcap
와 같이 읽을 수 있다.
이렇게 저장한 PCAP 파일은 Wireshark 같은 패킷 분석 도구로 분석할 수도 있다.
31. tcpdump에서 너무 많은 패킷이 나올 때
실제 운영 서버에서는 패킷이 매우 많이 발생할 수 있다.
따라서 Filter를 사용하는 것이 중요하다.
예:
tcpdump -i ens160 host 192.168.10.50
특정 Port:
tcpdump -i ens160 port 443
특정 Source:
tcpdump -i ens160 src host 192.168.10.50
특정 Destination:
tcpdump -i ens160 dst host 192.168.10.100
특정 TCP:
tcpdump -i ens160 tcp
특정 UDP:
tcpdump -i ens160 udp
실무에서는 필요한 범위만 필터링하는 것이 매우 중요하다.
32. 실제 장애 분석 예제
다음 환경을 가정해보자.
Client
192.168.10.50
|
|
Network
|
|
Server
192.168.10.100
|
|
HTTPS :443
사용자가:
https://192.168.10.100
에 접속할 수 없다고 신고했다.
Step 1. NIC
ip link
결과:
ens160 UP LOWER_UP
정상.
Step 2. IP
ip addr show ens160
결과:
192.168.10.100/24
정상.
Step 3. Routing
ip route
결과:
192.168.10.0/24 dev ens160 default via 192.168.10.1 dev ens160
정상.
Step 4. ARP
ip neigh
결과:
192.168.10.50 dev ens160 lladdr AA:BB:CC:DD:EE:FF REACHABLE
정상.
Step 5. Port
ss -lntp | grep ':443'
결과:
LISTEN 0 128 0.0.0.0:443
정상.
Step 6. Client에서 Port 테스트
nc -zv 192.168.10.100 443
결과:
Connection timed out
여기서 문제가 발생했다.
33. tcpdump로 확인
서버에서:
tcpdump -i ens160 host 192.168.10.50 and port 443
실행한다.
Client가 다시 접속한다.
다음과 같은 결과가 나온다고 가정하자.
192.168.10.50.52000 > 192.168.10.100.443: Flags [S] 192.168.10.50.52000 > 192.168.10.100.443: Flags [S] 192.168.10.50.52000 > 192.168.10.100.443: Flags [S]
SYN은 서버에 도착한다.
그런데 서버의 SYN-ACK이 보이지 않는다.
이제 범위를 좁힌다.
Client | | SYN v Server | X | SYN-ACK 없음
다음 확인:
ss -lntp | grep ':443'
Port가 LISTEN 중이다.
그러면 Firewall, Kernel, Routing 등의 영역을 추가로 조사한다.
이처럼 tcpdump는 장애를 단순히 "네트워크 문제"라고 표현하는 것이 아니라 실제 패킷의 상태로 문제를 구체화하는 도구다.
34. 장애 분석은 "정상"을 하나씩 증명하는 과정이다
네트워크 장애 분석에서 중요한 사고방식이 있다.
무조건 원인을 추측하지 말고 하나씩 정상임을 증명하는 것이다.
예:
NIC ↓ 정상 IP ↓ 정상 Subnet ↓ 정상 Gateway ↓ 정상 Routing ↓ 정상 TCP Port ↓ 문제
그러면 장애 범위는 상당히 좁아진다.
다시:
NIC ↓ 정상 IP ↓ 정상 Routing ↓ 정상 Port ↓ 정상 HTTP ↓ 문제
라면 네트워크보다는 Application Layer에 집중하면 된다.
35. OSI 계층과 장애 분석 연결
이제 전체 내용을 OSI 계층과 연결해보자.
Layer 7 Application | | HTTP / SSH / DNS ↓ Layer 4 Transport | | TCP / UDP / Port ↓ Layer 3 Network | | IP / ICMP / Routing ↓ Layer 2 Data Link | | Ethernet / MAC / ARP / VLAN ↓ Layer 1 Physical | | NIC / Cable / Fiber
장애가 발생하면:
Application 장애
↓
TCP Port 확인
↓
IP 통신 확인
↓
Routing 확인
↓
MAC/ARP 확인
↓
NIC/Link 확인
과 같이 범위를 좁혀나갈 수 있다.
36. 시스템 엔지니어가 반드시 익혀야 할 명령어
네트워크 실무에서 다음 명령어는 매우 중요하다.
인터페이스
ip link ip addr ethtool ens160
Routing
ip route ip route get 10.10.10.10
ARP / Neighbor
ip neigh
연결 테스트
ping tracepath traceroute
Port
ss -lntp nc -zv
Packet
tcpdump
Firewall
firewall-cmd nft
환경에 따라 명령어와 방화벽 구성은 달라질 수 있지만, 어떤 정보를 확인해야 하는가는 동일하다.
37. 네트워크 장애 분석 표준 절차
실제 현장에서 사용할 수 있도록 하나의 절차로 정리해보자.
[장애 접수]
|
v
어디에서 어디로 통신하는가?
|
v
출발지 IP 확인
|
v
목적지 IP 확인
|
v
목적지 Port 확인
|
v
Server NIC 확인
|
v
IP/Subnet 확인
|
v
Gateway 확인
|
v
Routing 확인
|
v
ARP 확인
|
v
Firewall 확인
|
v
Port LISTEN 확인
|
v
tcpdump
|
v
TCP Handshake 확인
|
v
Application 확인
이 순서를 기본 틀로 가지고 있으면 장애 상황에서 불필요한 추측을 줄일 수 있다.
38. 장애 분석에서 절대 하지 말아야 할 것
네트워크 장애가 발생했을 때 다음과 같은 방식은 피하는 것이 좋다.
"아마 방화벽 문제일 겁니다." "아마 서버 문제일 겁니다." "Ping이 안 되니까 네트워크가 문제입니다." "Port가 열려 있으니까 네트워크는 정상입니다."
이런 판단은 근거가 부족하다.
대신:
NIC 상태 확인 → 정상 IP 확인 → 정상 Routing 확인 → 정상 TCP SYN 확인 → 서버 도착 SYN-ACK 확인 → 없음 Firewall 확인 → 차단 Rule 발견
처럼 관찰한 사실을 기반으로 결론을 만들어야 한다.
이것이 전문적인 장애 분석이다.
39. 시스템 엔지니어의 네트워크 장애 분석 수준
네트워크를 공부하면서 다음과 같이 단계가 올라간다고 생각하면 된다.
Level 1
ping이 되는지 확인
Level 2
IP Subnet Gateway Routing Port
을 확인한다.
Level 3
ss ip route ip neigh nc
를 이용해서 통신 상태를 분석한다.
Level 4
tcpdump
로 실제 패킷을 확인한다.
Level 5
TCP Handshake ARP Routing Firewall MTU VLAN NAT
등을 패킷 수준에서 분석한다.
Level 6
Packet + Log + Metrics + Application + Network Device
를 함께 분석한다.
실제 시스템 엔지니어에게 필요한 것은 최소한 Level 4 이상의 능력이다.
40. 최종적으로 만들어야 하는 사고방식
네트워크 장애를 보면 다음과 같이 생각할 수 있어야 한다.
사용자 접속 실패
|
v
어디에서?
|
v
출발지 → 목적지
|
v
IP는?
|
v
Subnet은?
|
v
Gateway는?
|
v
Routing은?
|
v
ARP/MAC은?
|
v
TCP Port는?
|
v
SYN은 도착하는가?
|
v
SYN-ACK은 나가는가?
|
v
ACK가 돌아오는가?
|
v
Application 응답은?
이렇게 사고할 수 있다면 단순히 네트워크 명령어를 알고 있는 수준을 넘어선다.
패킷이 실제로 어떻게 이동하고 어디에서 문제가 발생했는지 추적할 수 있는 시스템 엔지니어가 되는 것이다.
41. 이번 교육의 핵심 정리
이번 교육의 가장 중요한 내용은 다음 네 단계다.
1. 이론
↓
OSI / TCP-IP / Ethernet / IP / TCP
2. Linux
↓
ip / ss / ping / ip route / ip neigh
3. 장애 상황
↓
NIC / IP / Routing / Firewall / Port / Application
4. Packet
↓
tcpdump / TCP Handshake / ARP
그리고 최종적인 장애 분석은:
"네트워크가 안 됩니다."
에서 끝나는 것이 아니라,
"Client의 TCP SYN은 Server의 ens160까지 도착한다." "하지만 Server에서 SYN-ACK이 발생하지 않는다." "443 Port는 LISTEN 중이다." "Firewall Rule에서 해당 Source Network가 차단되어 있다."
처럼 구체적인 사실로 표현할 수 있어야 한다.
이것이 시스템 엔지니어에게 필요한 네트워크 장애 분석 능력이다.
다음 네트워크 교육
다음 단계에서는 Layer 2를 더욱 깊게 들어간다.
시스템 엔지니어를 위한 네트워크 3편
Ethernet과 MAC Address 완벽 이해
다음 내용을 실제 Linux와 연결해서 다룬다.
Ethernet Frame
↓
MAC Address
↓
Switch
↓
MAC Address Table
↓
Broadcast
↓
ARP
↓
VLAN
↓
Linux ip neigh
↓
tcpdump로 ARP Packet 확인
↓
실제 ARP 장애 분석
특히 다음과 같은 실제 장애를 직접 분석하는 방식으로 진행한다.
IP는 정상인데 통신이 안 된다
↓
ARP 확인
↓
ip neigh
↓
ARP Request 확인
↓
ARP Reply 확인
↓
tcpdump 확인
↓
MAC Address 확인
↓
VLAN / Switch 확인
이 과정을 익히면 **"IP는 정상인데 왜 서버끼리 통신이 안 되는가?"**라는 현장 장애를 Layer 2 수준에서 분석할 수 있게 된다.
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.