Linux 네트워크 트러블슈팅: DNS부터 TCP·TLS·HTTP까지

네트워크 장애에서 command를 많이 아는 것보다 중요한 것은 실패한 계층을 순서대로 좁히는 일이다. ping 하나가 성공하거나 실패했다는 사실만으로 서비스 상태를 결론 내릴 수 없다. 이 글은 Linux server에서 설정을 바꾸지 않고 증거를 모으는 순서를 DNS → route → TCP → TLS → HTTP로 정리한다.

0단계: 증상을 한 문장으로 고정한다

먼저 ‘네트워크가 안 된다’는 표현을 관찰 가능한 문장으로 바꾼다.

• 어느 client와 server 사이에서 발생하는가
• hostname과 port, protocol은 무엇인가
• timeout, connection refused, TLS error, HTTP status 중 무엇인가
• 모든 요청인지 특정 zone·pod·user만의 문제인지
• 최초 발생 시각과 직전 변경은 무엇인지

그다음 client와 server 양쪽의 시각이 맞는지 확인한다. DNS cache, connection reuse, load balancer 때문에 한 번의 결과가 전체 경로를 대표하지 않을 수 있으므로 정상 host의 결과도 같은 시각에 비교한다.

1단계: 이름이 어떤 주소로 해석되는가

애플리케이션이 실제 사용하는 name service 경로는 getent로 먼저 본다.

getent ahosts example.com

getent 결과에는 DNS뿐 아니라 /etc/hosts 등 Name Service Switch 설정이 반영될 수 있다. authoritative DNS 또는 특정 resolver의 응답을 분리해서 볼 때는 dig를 사용한다.

dig +short A example.com
dig +short AAAA example.com
dig @192.0.2.53 example.com A

192.0.2.53은 문서 예시용 주소이므로 실제 환경의 승인된 resolver 주소로 바꿔야 한다. A와 AAAA가 여러 개라면 한 주소만 시험하고 전체가 정상이라고 결론 내리지 않는다. DNS 응답 구조는 재귀·반복 DNS resolver의 차이에서 더 자세히 볼 수 있다.

2단계: local address와 route를 확인한다

interface와 route를 보기 위해 설정을 내리거나 속도를 강제로 바꿀 필요는 없다.

ip -brief address show
ip route show
ip route get 203.0.113.10

ip route get은 현재 routing rule을 기준으로 선택될 egress interface, source address와 next hop을 보여 준다. 실제 packet delivery를 보장하는 명령은 아니지만, 잘못된 source address나 VPN·policy routing을 찾는 데 유용하다.

server가 기대한 port를 listen 중인지도 확인한다.

ss -lntp

process 정보는 권한에 따라 일부 보이지 않을 수 있다. 0.0.0.0:8080, [::]:8080, 127.0.0.1:8080은 노출 범위가 다르므로 주소까지 읽는다. 이 단계에서 ifconfig eth0 down이나 ethtool -s처럼 상태를 바꾸는 명령은 진단 절차에 섞지 않는다.

3단계: 경로와 TCP 연결을 분리한다

ICMP echo가 허용된 환경에서는 짧게 왕복 여부를 볼 수 있다.

ping -c 4 203.0.113.10
tracepath 203.0.113.10

ping 실패는 service 장애의 충분조건이 아니다. firewall이 ICMP만 막을 수 있다. traceroute·tracepath의 중간 hop이 응답하지 않거나 RTT가 높다고 해서 그 router가 end-to-end 병목이라는 뜻도 아니다. control-plane 응답 우선순위와 forward path는 다를 수 있다.

필요한 TCP port는 직접 connection을 시도한다.

nc -vz -w 3 example.com 443

결과를 대략 다음처럼 읽는다.

• connection refused: 목적지까지 도달했지만 해당 주소·port에서 거부 응답을 받았을 가능성이 크다.
• timed out: packet drop, 경로 문제, firewall, 응답 손실 등 범위가 넓다.
• connect 성공: TCP handshake가 됐다는 뜻이지 TLS와 HTTP가 정상이라는 보장은 아니다.

TCP handshake 자체는 TCP 연결 흐름에서 이어서 볼 수 있다.

4단계: TLS와 HTTP를 따로 확인한다

TLS server name과 인증서 검증까지 보려면 SNI를 명시한다.

timeout 8 openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  </dev/null

배포판에 timeout이 없다면 운영 환경의 표준 timeout 도구를 사용한다. CA trust store, protocol version, hostname mismatch와 만료 여부를 구분한다. TLS handshake 구조는 TLS 1.3 handshake와 인증서 검증에서 볼 수 있다.

마지막으로 애플리케이션 응답을 확인한다.

curl -v \
  --connect-timeout 3 \
  --max-time 10 \
  https://example.com/health

curl -v에는 request header와 TLS 정보가 출력될 수 있다. 운영 token이나 cookie를 넣은 채 terminal 공유·ticket 첨부를 하지 않는다. 자동 확인에는 -v 대신 status, remote IP와 시간만 제한해 출력하는 편이 안전하다.

curl -sS -o /dev/null \
  --connect-timeout 3 \
  --max-time 10 \
  -w 'remote=%{remote_ip} code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' \
  https://example.com/health

5단계: packet capture는 마지막에, 범위를 좁혀서 한다

앞 단계로 방향이 잡히지 않을 때만 승인된 interface와 host·port를 한정해 capture한다.

sudo tcpdump -ni any -s 96 -c 100 \
  'host 203.0.113.10 and tcp port 443'

-c는 packet 수, -s는 capture 길이를 제한한다. header만 필요해도 IP, domain, timing 같은 metadata가 남으며 평문 protocol은 payload가 노출될 수 있다. 본인이 관리하거나 명시적으로 허가받은 traffic만 수집하고 file 권한·보관 기간을 정한다. 무제한 tcpdump -i any를 장시간 실행하는 것은 기본 진단법이 아니다.

결과를 계층별로 묶는다

관찰	다음 확인
hostname이 기대와 다른 IP로 해석됨	NSS, resolver, zone record, cache
route가 잘못된 interface·source를 선택함	policy rule, VPN, subnet과 gateway
TCP timeout	양쪽 firewall, security policy, path와 listen 상태
TCP 성공·TLS 실패	SNI, certificate chain, hostname, protocol 정책
TLS 성공·HTTP 오류	reverse proxy, route, authentication, application log
한 IP만 실패	load balancer backend, address family, zone별 경로

이 순서는 원인을 단정하는 공식이 아니라 가설을 한 계층씩 줄이는 방법이다. 네트워크 설정을 바꾸기 전에 command, 시각, 실행 host와 결과를 남기면 다른 사람이 같은 증거를 재현할 수 있다.

기존의 네트워크 명령어 빠른 참조는 Windows·macOS를 포함한 command 이름 비교용으로 남기고, 이 글은 Linux server의 incident workflow에 집중한다. 두 글의 제목과 목적을 이 경계에 맞춰 유지해야 검색 의도가 겹치지 않는다.

참고 자료

• iproute2: ip(8)
• iproute2: ss(8)
• BIND 9: dig manual
• curl 공식 manual
• OpenSSL: s_client
• tcpdump 공식 manual