네트워크 장애 분석과 패킷 분석 실전 완벽 가이드
네트워크 장애 분석과 패킷 분석 실전 완벽 가이드
1. 네트워크 장애 분석은 어디서부터 시작해야 할까?
시스템 엔지니어가 운영 환경에서 자주 접하는 장애는 다음과 같습니다.
- 서버에 Ping은 되지만 SSH 접속이 되지 않는다.
- 서버 IP로는 접속되지만 도메인으로 접속되지 않는다.
- 특정 포트만 접속되지 않는다.
- TCP 연결은 성공하지만 웹 페이지에 HTTP 502 오류가 발생한다.
- 서버에서 요청 패킷을 보내지만 응답 패킷이 돌아오지 않는다.
- 방화벽을 변경했는데도 서비스가 정상화되지 않는다.
- 특정 네트워크에서만 접속이 실패한다.
이러한 상황에서 무작정 서버를 재부팅하거나 방화벽 설정을 변경하면 원인을 찾기 어려워지고 장애 범위가 확대될 수 있습니다.
중요한 것은 장애를 계층별로 분리하고, 각 단계에서 확인한 증거를 바탕으로 원인을 좁혀 가는 것입니다.
네트워크 장애 분석은 다음 순서로 접근할 수 있습니다.
1. 물리 링크와 NIC 상태
|
v
2. IP 주소와 Subnet 확인
|
v
3. ARP와 Gateway 확인
|
v
4. Routing 경로 확인
|
v
5. TCP/UDP 포트와 연결 상태 확인
|
v
6. 방화벽 및 접근 제어 확인
|
v
7. DNS 확인
|
v
8. TLS/HTTP 및 애플리케이션 확인
|
v
9. tcpdump로 패킷 흐름 분석
이 순서는 기본적인 진단 흐름입니다. 실제로는 장애 증상에 따라 DNS나 애플리케이션부터 확인할 수도 있으며, 여러 검사를 병행할 수도 있습니다.
2. 1단계: NIC와 IP 주소 확인
네트워크 통신이 되지 않는다면 먼저 서버의 네트워크 인터페이스부터 확인합니다.
2-1. NIC 상태 확인
ip -br link
예시:
lo UNKNOWN ens160 UP ens192 DOWN
여기서 ens160은 UP 상태이고 ens192는 DOWN 상태입니다.
단, Linux의 인터페이스 상태에는 관리 상태와 실제 물리 링크 상태가 관련됩니다. UP이라는 표시만으로 네트워크가 완전히 정상이라고 판단해서는 안 됩니다.
상세 정보는 다음과 같이 확인합니다.
ip link show ens160 ethtool ens160
ethtool 결과에서 다음 항목을 살펴봅니다.
Speed: 1000Mb/s Duplex: Full Link detected: yes
Link detected: no라면 케이블, 스위치 포트, 가상 스위치, NIC 드라이버 등 링크 계층의 문제를 확인해야 합니다.
가상머신에서는 물리 케이블 대신 하이퍼바이저의 가상 NIC와 가상 스위치 설정을 확인해야 할 수 있습니다.
2-2. IP 주소와 Subnet 확인
ip -br addr
예시:
ens160 UP 192.168.10.10/24
서버에 192.168.10.10/24가 설정되어 있다면 네트워크 주소는 192.168.10.0/24입니다.
다음 항목을 확인합니다.
- IP 주소가 설계 문서와 일치하는가?
- Subnet Mask 또는 CIDR이 올바른가?
- 중복 IP가 존재하지 않는가?
- 서비스가 사용하는 NIC에 IP가 설정되어 있는가?
- VLAN이 올바르게 연결되어 있는가?
예를 들어 서버의 IP가 192.168.10.10/24여야 하는데 실수로 /16이 설정되었다면, 서버가 원격 네트워크를 같은 네트워크로 오인하여 잘못된 경로를 선택할 수 있습니다.
3. 2단계: Routing과 Gateway 확인
IP 주소가 정상이라면 목적지까지 어떤 경로를 사용하는지 확인합니다.
3-1. 라우팅 테이블 확인
ip route
예시:
192.168.10.0/24 dev ens160 proto kernel scope link src 192.168.10.10 default via 192.168.10.1 dev ens160
이 설정은 다음과 같은 의미입니다.
192.168.10.0/24네트워크는ens160을 통해 직접 연결된다.- 그 밖의 목적지에는 기본 게이트웨이
192.168.10.1을 사용한다.
3-2. 목적지에 대한 실제 경로 확인
ip route get 192.168.20.50
예시:
192.168.20.50 via 192.168.10.1 dev ens160 src 192.168.10.10
이 명령으로 다음 홉, 출력 인터페이스, 출발지 IP를 확인할 수 있습니다.
서버에 NIC가 여러 개 있다면 특히 중요합니다. 관리망과 서비스망을 함께 사용하는 서버에서는 목적지에 따라 의도하지 않은 NIC가 선택될 수 있습니다.
3-3. Gateway의 ARP 확인
ip neigh show
예시:
192.168.10.1 dev ens160 lladdr 00:11:22:33:44:55 REACHABLE
Gateway의 MAC 주소를 정상적으로 확인한 상태입니다.
반면 다음과 같은 상태라면 추가 점검이 필요합니다.
192.168.10.1 dev ens160 INCOMPLETE
INCOMPLETE는 해당 이웃의 링크 계층 주소를 확인하는 과정이 아직 완료되지 않았음을 의미합니다. 일정 시간 후 FAILED로 바뀔 수도 있습니다.
이때는 VLAN, 스위치 연결, IP 중복, Gateway 상태 등을 확인합니다.
4. 3단계: Ping과 TCP 연결 테스트는 다르다
네트워크 장애 분석에서 가장 흔한 실수는 Ping이 성공하면 모든 통신이 정상이라고 판단하는 것입니다.
Ping은 일반적으로 ICMP Echo Request와 Echo Reply를 사용합니다. 반면 SSH는 TCP 22번, HTTPS는 TCP 443번 포트를 사용합니다.
따라서 Ping이 성공하더라도 특정 TCP 포트가 차단되었거나 서비스가 실행되지 않았다면 접속할 수 없습니다.
4-1. Ping 테스트
ping -c 4 192.168.20.50
이 결과는 ICMP 기반 통신 여부를 확인하는 데 도움이 됩니다. 다만 ICMP 차단 정책이 있으면 서비스가 정상이어도 Ping이 실패할 수 있습니다.
4-2. TCP 포트 테스트
예를 들어 원격 서버의 SSH 포트를 확인하려면 다음 명령을 사용합니다.
nc -zv -w 3 192.168.20.50 22
HTTPS 포트는 다음과 같이 확인할 수 있습니다.
nc -zv -w 3 192.168.20.50 443
성공적으로 TCP 연결이 이루어지면 해당 포트에서 연결을 수락하는 경로가 존재한다는 의미입니다. 단, 이것만으로 애플리케이션 전체가 정상이라고 판단할 수는 없습니다.
4-3. 서버에서 서비스가 대기 중인지 확인
접속 대상 서버에서 다음 명령을 실행합니다.
sudo ss -lntp
예시:
State Recv-Q Send-Q Local Address:Port LISTEN 0 128 0.0.0.0:22 LISTEN 0 128 127.0.0.1:8080
여기서 127.0.0.1:8080은 루프백 인터페이스에서만 대기한다는 의미입니다. 다른 서버에서 서버IP:8080으로 접속하려면 서비스의 바인딩 주소를 확인해야 합니다.
반면 0.0.0.0:22는 IPv4의 모든 로컬 인터페이스 주소에서 해당 포트를 수신하도록 설정되었다는 뜻입니다. 실제 접속 가능 여부는 방화벽과 네트워크 정책에도 영향을 받습니다.
5. 4단계: 방화벽 확인
서비스가 실행 중이고 포트도 대기 중인데 외부에서 접속할 수 없다면 방화벽을 확인합니다.
Rocky Linux 또는 RHEL 계열에서 firewalld를 사용하는 경우 다음 명령으로 상태를 확인할 수 있습니다.
sudo firewall-cmd --state sudo firewall-cmd --get-active-zones sudo firewall-cmd --list-all
nftables 규칙도 확인할 수 있습니다.
sudo nft list ruleset
방화벽이 활성화되어 있다는 사실만으로 해당 포트가 차단되었다고 단정할 수는 없습니다. 실제 규칙과 패킷 처리 경로를 함께 확인해야 합니다.
또한 서버 내부 방화벽 외에도 다음과 같은 장비나 정책이 존재할 수 있습니다.
- 네트워크 방화벽
- 클라우드 보안 그룹
- 네트워크 ACL
- 로드밸런서의 접근 정책
- Kubernetes NetworkPolicy
서버 내부의 방화벽이 정상이어도 상위 네트워크 장비에서 차단하면 접속이 실패할 수 있습니다.
운영 서버에서는 원인 확인 없이 방화벽 전체를 중지하거나 광범위하게 포트를 개방하지 않는 것이 원칙입니다.
6. 핵심 도구: tcpdump로 패킷 분석하기
명령어만으로 원인을 찾기 어렵다면 패킷을 직접 확인해야 합니다.
tcpdump는 네트워크 인터페이스를 통과하는 패킷을 캡처하고 분석하는 도구입니다.
6-1. 인터페이스에서 패킷 확인
sudo tcpdump -nn -i ens160
옵션의 의미는 다음과 같습니다.
옵션의미-n주소와 포트를 이름으로 변환하지 않음-nn주소와 포트 모두 이름 변환하지 않음-i ens160지정한 인터페이스에서 캡처-c 100최대 100개 패킷 캡처 후 종료-s 0가능한 전체 패킷 길이를 캡처-w file.pcap패킷을 파일로 저장
운영 서버에서는 우선 인터페이스와 필터를 지정하고, 캡처 범위와 시간을 제한하는 것이 좋습니다.
6-2. 특정 서버와 통신하는 패킷 확인
sudo tcpdump -nn -i ens160 \ 'host 192.168.20.50'
특정 포트만 확인하려면 다음과 같이 실행합니다.
sudo tcpdump -nn -i ens160 \ 'host 192.168.20.50 and tcp port 443'
TCP SYN 패킷만 확인할 수도 있습니다.
sudo tcpdump -nn -i ens160 \ 'tcp port 443 and (tcp[tcpflags] & tcp-syn != 0)'
이 필터는 SYN 플래그가 설정된 TCP 패킷을 보여 줍니다. SYN만으로는 연결 성공 여부를 판단할 수 없으므로 SYN-ACK와 후속 ACK도 함께 확인해야 합니다.
6-3. 패킷을 파일로 저장
sudo tcpdump -nn -i ens160 -s 0 \ -c 1000 \ -w /tmp/network-debug.pcap \ 'host 192.168.20.50 and tcp port 443'
저장한 파일은 Wireshark 등 패킷 분석 도구에서 열어 확인할 수 있습니다.
운영 환경에서 캡처 파일에는 내부 IP, DNS 질의, 인증 정보 또는 애플리케이션 데이터가 포함될 수 있습니다. 파일 접근 권한을 제한하고, 승인된 범위에서 캡처한 뒤 보관 정책에 따라 삭제해야 합니다.
7. TCP 패킷으로 연결 장애 구분하기
TCP 연결 과정은 다음과 같습니다.
Client Server | | |-------- SYN ----------------->| | | |<------- SYN, ACK --------------| | | |-------- ACK ----------------->| | | | 연결 성립 |
이 과정을 이용하면 장애 유형을 구분하는 데 도움이 됩니다.
상황 A. SYN을 보냈지만 응답이 없다
클라이언트에서 다음과 같은 패킷이 반복적으로 보인다고 가정하겠습니다.
192.168.10.10.52000 > 192.168.20.50.443: Flags [S] 192.168.10.10.52000 > 192.168.20.50.443: Flags [S] 192.168.10.10.52000 > 192.168.20.50.443: Flags [S]
클라이언트가 SYN을 전송했지만 관찰한 구간에서는 응답이 보이지 않습니다.
가능한 원인은 다음과 같습니다.
- 목적지 서버까지 패킷이 도달하지 않음
- 중간 방화벽에서 패킷이 차단됨
- 목적지 서버가 응답하지 않음
- 응답 패킷이 다른 경로로 전달됨
- 캡처 위치나 인터페이스가 적절하지 않음
이 결과만으로 차단 장비를 확정할 수는 없습니다. 클라이언트와 서버 양쪽에서 동시에 캡처하면 원인을 더 빠르게 좁힐 수 있습니다.
상황 B. 서버에서 RST를 반환한다
192.168.10.10.52000 > 192.168.20.50.443: Flags [S] 192.168.20.50.443 > 192.168.10.10.52000: Flags [R.]
RST는 TCP 연결을 거부하거나 기존 연결을 초기화할 때 나타날 수 있습니다.
해당 포트에 서비스가 대기 중이지 않거나, 방화벽이 명시적으로 연결을 거부하는 경우 등을 확인해야 합니다.
상황 C. SYN-ACK가 돌아온다
192.168.10.10.52000 > 192.168.20.50.443: Flags [S] 192.168.20.50.443 > 192.168.10.10.52000: Flags [S.] 192.168.10.10.52000 > 192.168.20.50.443: Flags [.]
TCP 3-Way Handshake가 완료되는 일반적인 흐름입니다.
그러나 연결이 성립했다는 사실만으로 HTTPS 인증서, HTTP 응답, 애플리케이션 처리까지 정상이라는 뜻은 아닙니다. 다음 단계로 TLS와 HTTP 응답을 확인해야 합니다.
8. 실제 장애 사례 1 — Ping은 되지만 HTTPS 접속이 안 된다
다음 상황을 가정하겠습니다.
Client
192.168.10.10
|
| ICMP 성공
|
Web Server
192.168.20.50
TCP 443 접속 실패
8-1. TCP 연결 확인
nc -zv -w 3 192.168.20.50 443
연결이 실패했다면 서버에서 포트가 대기 중인지 확인합니다.
sudo ss -lntp
8-2. 서버에서 패킷 확인
sudo tcpdump -nn -i ens160 \ 'host 192.168.10.10 and tcp port 443'
결과에 따른 판단은 다음과 같습니다.
패킷 관찰 결과우선 확인할 사항서버에서 SYN이 보이지 않음중간 경로, 방화벽, VLAN, 캡처 인터페이스SYN은 보이나 SYN-ACK가 없음서비스 상태, 서버 방화벽, 로컬 TCP 처리SYN과 SYN-ACK가 모두 보임응답 경로, 클라이언트 측 방화벽TCP 연결이 완료됨TLS 인증서, 웹 서버, HTTP 응답
여기서 중요한 점은 서버에서 SYN이 보이지 않는다고 해서 반드시 네트워크 방화벽 문제인 것은 아니라는 것입니다. 잘못된 NIC를 캡처하고 있거나, 목적지 IP가 다르거나, 패킷이 다른 인터페이스로 들어올 수도 있습니다.
9. 실제 장애 사례 2 — IP 접속은 되지만 도메인 접속이 안 된다
IP 주소로는 접속되지만 도메인으로 접속되지 않는다면 DNS를 확인합니다.
9-1. DNS 조회
dig example.com
특정 DNS 서버를 사용해 확인하려면 다음과 같이 실행합니다.
dig @192.168.10.53 example.com
도메인에 대한 IP 주소가 올바르게 반환되는지, 조회가 타임아웃되는지, NXDOMAIN이 반환되는지 구분합니다.
9-2. DNS 패킷 확인
sudo tcpdump -nn -i ens160 'port 53'
DNS는 일반적으로 UDP 53번 포트를 사용하지만, TCP 53번도 사용합니다. 패킷이 보이지 않는다면 실제 질의 인터페이스, DNS 설정, 로컬 캐시, 방화벽 및 캡처 위치를 확인합니다.
DNS 응답이 정상인데 웹 접속이 실패한다면 DNS 문제로 단정하지 말고 TCP, TLS, HTTP 단계로 분석을 이어갑니다.
10. 실제 장애 사례 3 — HTTP 502 Bad Gateway
웹 서비스에서 HTTP 502가 발생한다면 네트워크가 완전히 끊긴 것이 아니라 프록시와 백엔드 사이의 통신 또는 백엔드 처리에 문제가 있을 수 있습니다.
예를 들어 다음과 같은 구조입니다.
Client | | HTTPS :443 v Nginx Reverse Proxy | | HTTP :8000 v FastAPI Backend
Nginx가 요청을 받았더라도 FastAPI 백엔드에 연결하지 못하면 502가 발생할 수 있습니다.
10-1. Nginx에서 백엔드 연결 확인
Nginx 서버에서 다음 명령을 실행합니다.
nc -zv -w 3 127.0.0.1 8000
백엔드가 다른 서버에 있다면 해당 백엔드 IP와 포트를 지정합니다.
nc -zv -w 3 192.168.20.60 8000
10-2. 백엔드 서비스 상태 확인
sudo ss -lntp | grep ':8000'
애플리케이션 로그도 확인합니다.
sudo journalctl -u fastapi --since "10 minutes ago"
서비스 이름은 실제 시스템에 맞게 변경해야 합니다.
10-3. Nginx 로그 확인
sudo tail -n 100 /var/log/nginx/error.log sudo tail -n 100 /var/log/nginx/access.log
이 단계에서 Connection refused, upstream timed out, 잘못된 백엔드 주소 등 구체적인 단서를 찾을 수 있습니다.
502 오류가 발생했다고 해서 무조건 네트워크 방화벽 문제는 아닙니다. 백엔드 프로세스 종료, 잘못된 포트, 애플리케이션 오류, 타임아웃 등도 원인이 될 수 있습니다.
11. 패킷 분석 시 주의할 점
tcpdump는 매우 유용하지만 캡처 결과를 해석할 때 주의해야 합니다.
11-1. 서버에서 패킷이 보이지 않는 경우
패킷이 보이지 않는다는 사실만으로 네트워크에 패킷이 전혀 없었다고 단정할 수 없습니다.
다음 항목을 확인합니다.
- 올바른 인터페이스에서 캡처했는가?
- 필터에 목적지 IP와 포트가 정확하게 지정되었는가?
- IPv4와 IPv6 중 실제 통신에 사용하는 주소가 무엇인가?
- 패킷이 다른 NIC나 네트워크 네임스페이스로 전달되는가?
- 캡처 권한이나 인터페이스 오프로드 설정의 영향을 받는가?
11-2. 패킷 손실처럼 보이는 경우
서버에서 패킷을 캡처하면 체크섬 오류나 세그먼트 크기와 관련된 특이한 표시가 나타날 수 있습니다.
NIC의 체크섬 오프로드나 TSO/GSO/GRO 등의 기능 때문에 실제 회선에서 보이는 패킷과 호스트 내부 캡처 결과가 다르게 보일 수 있습니다.
따라서 캡처 결과만으로 물리 네트워크의 패킷 오류라고 단정하지 말고, 필요하면 반대편 장비에서도 캡처하거나 스위치·NIC 통계와 함께 확인해야 합니다.
11-3. 운영 서버에서 안전하게 캡처하기
장시간 전체 패킷을 캡처하면 저장 공간과 CPU 자원을 사용하고 민감한 정보가 기록될 수 있습니다.
다음 원칙을 지키는 것이 좋습니다.
- 필요한 IP와 포트만 필터링한다.
- 캡처 시간을 제한한다.
- 필요한 경우
-c옵션으로 패킷 수를 제한한다. - 저장 파일의 권한을 제한한다.
- 캡처 전후의 시간과 장애 증상을 기록한다.
- 분석이 끝나면 승인된 보관 정책에 따라 파일을 처리한다.
12. 시스템 엔지니어용 네트워크 장애 분석 실전 명령어 모음
아래는 Linux 서버에서 자주 사용하는 명령어를 목적별로 정리한 것입니다.
확인 목적명령어NIC 상태ip -br linkIP 주소ip -br addr라우팅 테이블ip route목적지별 경로ip route get 192.168.20.50ARP/이웃 정보ip neigh showTCP/UDP 포트ss -lntupTCP 연결 상태ss -antTCP 포트 테스트nc -zv -w 3 192.168.20.50 443DNS 조회dig example.comHTTP 응답curl -v https://example.com경로 추적traceroute 192.168.20.50패킷 캡처tcpdump -nn -i ens160방화벽 규칙sudo nft list rulesetfirewalld 규칙sudo firewall-cmd --list-all
실제 장애 분석에서는 이 명령어를 한꺼번에 실행하는 것이 아니라, 앞 단계의 결과를 근거로 다음 점검 항목을 선택해야 합니다.
13. 네트워크 장애 분석의 핵심 원칙
네트워크 장애를 해결할 때 가장 중요한 것은 증상과 원인을 구분하는 것입니다.
예를 들어 다음은 서로 다른 의미를 갖습니다.
- Ping 실패: ICMP 응답이 없다는 의미
- TCP 연결 실패: TCP 연결이 성립하지 않았다는 의미
- DNS 조회 실패: 이름을 IP 주소로 해석하지 못했다는 의미
- TLS 오류: TLS 협상이나 인증서 검증 등에 문제가 있다는 의미
- HTTP 502: 프록시 또는 게이트웨이가 백엔드 응답을 정상적으로 처리하지 못했다는 의미
이러한 결과는 장애 원인을 좁히는 단서이지, 각각 하나의 원인을 확정하는 증거는 아닙니다.
시스템 엔지니어는 명령어 결과와 패킷 흐름, 서버 로그, 네트워크 장비의 상태를 종합해 판단해야 합니다.
마무리
이번 편에서는 네트워크 장애를 분석하는 전체 흐름과 실무에서 자주 사용하는 Linux 명령어, tcpdump를 활용한 패킷 분석 방법을 살펴봤습니다.
네트워크 장애 분석의 핵심은 다음 세 가지입니다.
- 계층별로 분리해서 확인한다. 물리 링크, IP, 라우팅, TCP, DNS, TLS, HTTP를 구분합니다.
- 패킷의 흐름을 확인한다. 요청이 어디까지 도달하고 응답이 어디서 사라지는지 추적합니다.
- 증거를 바탕으로 원인을 좁힌다. Ping 실패나 502 오류만으로 원인을 단정하지 않습니다.
네트워크 시리즈 1편부터 20편까지 학습했다면 이제 기본 개념을 넘어 실제 서버 장애를 체계적으로 분석하기 위한 기초를 갖춘 것입니다.
다음 학습 단계에서는 Linux 네트워크 네임스페이스, 가상 브리지, Docker 네트워크, Kubernetes CNI와 Service 네트워크를 연결해 컨테이너 환경에서 네트워크가 어떻게 구성되고 장애가 발생하는지 학습하는 것을 추천합니다.
네트워크 20편 시리즈를 마무리했습니다. 다음 단계로는 Docker 네트워크 → Linux Bridge와 Network Namespace → Kubernetes CNI와 Service → 실제 컨테이너 통신 장애 분석 순서로 확장하면 시스템 엔지니어 실무에 자연스럽게 연결됩니다.
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.