02. 진단의 순서 — 소설처럼 읽는 데이터통신과 컴퓨터 네트워크

진단의 순서

"연결이 안 돼요"라는 말은 사실 원인이 수십 가지입니다. 케이블 문제일 수도 있고, IP 설정 문제일 수도 있고, DNS가 죽었을 수도, 서버 포트가 안 열렸을 수도 있습니다. 막연하게 이것저것 건드리면 원인을 찾는 데 시간이 배로 걸립니다.

효율적인 방법은 아래 계층부터 위로 올라가며 가능성을 하나씩 소거하는 것입니다. 낮은 계층의 문제를 해결하지 않으면 높은 계층 도구는 아무 의미 있는 정보를 줄 수 없기 때문입니다.

1단계. 물리·링크 연결 확인

유선이라면 랜 케이블이 꽂혀 있는지, 링크 LED가 켜져 있는지 확인합니다. 무선이라면 Wi-Fi가 연결된 상태인지 확인합니다. 아무것도 보이지 않으면 여기서 이미 끝입니다. ifconfig 또는 ip addr 명령으로 인터페이스 상태를 확인합니다.

# 파일: 터미널ifconfig

inet 항목에 IP 주소가 있어야 합니다. 없거나 169.254.x.x(링크-로컬)라면 DHCP에서 IP를 받지 못한 것입니다.

2단계. 게이트웨이 도달 확인

같은 네트워크 안의 게이트웨이(공유기 등)에 ping이 가는지 확인합니다. 게이트웨이 주소는 Linux에서는 ip route 명령, macOS에서는 netstat -rn 명령으로 확인합니다.

# 파일: 터미널ping -c 3 192.168.0.1

ping이 실패하면 로컬 네트워크 안의 문제입니다. 방화벽 설정, 스위치 포트 문제 등을 살펴봅니다.

3단계. 외부 IP 도달 확인

인터넷 어딘가로 나가는지 확인합니다. DNS를 건너뛰기 위해 IP 주소를 직접 씁니다.

# 파일: 터미널ping -c 3 8.8.8.8

게이트웨이는 살아 있는데 외부 IP가 안 된다면 ISP 회선 문제이거나 라우터에서 인터넷 포트가 연결되지 않은 것입니다.

4단계. DNS 동작 확인

외부 IP는 ping이 가는데 도메인 이름이 안 된다면 DNS 문제입니다. dig로 직접 조회합니다.

# 파일: 터미널dig google.com +short

IP가 반환되지 않거나 타임아웃이 나면 DNS 서버가 응답하지 않는 것입니다. /etc/resolv.conf의 DNS 서버 주소를 확인하고, 8.8.8.8로 직접 조회해 봅니다.

# 파일: 터미널dig @8.8.8.8 google.com +short

5단계. 대상 서버 포트 확인

DNS도 정상이고 IP도 닿는데 서비스가 안 된다면, 목적지 서버의 포트가 열려 있는지 확인합니다.

# 파일: 터미널curl -v http://example.com

또는 telnet으로 포트 연결만 확인합니다.

# 파일: 터미널telnet example.com 80

연결이 맺어지면 TCP 레벨은 정상입니다. 맺어지지 않으면 방화벽이 막고 있거나 서버 프로세스가 떠 있지 않은 것입니다.

6단계. 응용 프로토콜 확인

TCP 연결은 되는데 응답이 비정상이라면 curl -v로 HTTP 헤더와 응답 코드를 살펴봅니다. 여기서부터는 서버 코드, 설정, 인증서 문제일 가능성이 높습니다.

5단계에서 curl이 실패했을 때, 그 원인이 DNS인지 TCP인지 HTTP인지 바로 알 수 없습니다. 하지만 1단계부터 차례로 올라왔다면 "IP는 닿고 DNS도 정상이니 포트 문제"라고 빠르게 좁힐 수 있습니다. 순서가 논리입니다.

다음 절에서는 이 중 가장 낮은 수준에서 패킷을 들여다볼 수 있는 tcpdump와 Wireshark를 더 깊이 살펴봅니다.