리눅스에서 네트워크 문제가 생기면 가장 먼저 필요한 것은 감이 아니라 순서다.
서비스가 느린지, DNS가 꼬였는지, 라우팅이 잘못됐는지, 포트가 열리지 않았는지 뒤섞여 보이기 쉽다.
이번 글은 목요일 주제인 네트워킹에 맞춰, 실무에서 자주 쓰는 기본 점검 루틴을 정리한 것이다.
이미 넓게 다루는 로드맵형 글과 겹치지 않도록,
이번에는 문제가 생겼을 때 바로 써먹을 수 있는 네트워크 확인 흐름에 집중한다.
왜 점검 순서가 중요한가
네트워크 장애는 증상이 비슷해 보여도 원인이 전혀 다를 수 있다.
예를 들어 다음 세 경우는 모두 “접속이 안 된다”로 보일 수 있다.
- NIC 자체가 비활성화된 경우
- DNS만 깨져서 도메인 해석이 안 되는 경우
- 서비스는 살아 있지만 특정 포트만 차단된 경우
그래서 아래처럼 낮은 계층부터 하나씩 확인하는 루틴이 효율적이다.
- 인터페이스가 살아 있는가
- IP와 라우팅이 정상인가
- 외부와 통신이 되는가
- DNS 해석이 되는가
- 서비스 포트가 실제로 열려 있는가
1. 인터페이스와 IP 상태부터 본다
가장 먼저 확인할 것은 네트워크 인터페이스와 IP 주소다.
ip addr ip -br addr ip link
특히 ip -br addr는 한눈에 보기 좋아서 초기에 자주 쓴다.
예상 포인트:
- 인터페이스가 UP 상태인지
- 기대한 IP가 붙어 있는지
- 의도치 않게 DHCP 주소가 바뀌지 않았는지
- 서버에 NIC가 여러 개인데 다른 인터페이스를 보고 있지는 않은지
짧게 볼 때는 이 명령도 좋다.
ip -br addr show up
이 단계에서 이미 문제를 찾는 경우가 많다. 예를 들어 운영 중인 서버인데 DOWN 상태거나,
사설망 대역이 잘못 붙어 있으면 이후 DNS나 방화벽을 봐도 소용이 없다.
2. 라우팅 테이블을 확인한다
IP가 있다고 끝이 아니다. 어디로 나가는지 확인해야 한다.
ip route ip route get 8.8.8.8
여기서 확인할 것:
- 기본 게이트웨이(default route)가 존재하는지
- 특정 목적지로 나갈 때 예상한 인터페이스를 타는지
- 멀티 NIC 환경에서 잘못된 경로 우선순위가 잡히지 않았는지
예를 들어 ip route get 8.8.8.8 결과가 엉뚱한 인터페이스를 가리키면,
외부 접속 문제는 방화벽보다 라우팅 우선순위 문제일 가능성이 크다.
3. 통신이 되는지 ICMP로 먼저 자른다
이제 실제로 통신이 되는지 확인한다.
ping -c 4 8.8.8.8
ping -c 4 1.1.1.1
도메인이 아니라 IP로 먼저 확인하는 이유는 DNS 변수를 빼기 위해서다.
판단 기준은 단순하다.
- IP ping도 안 된다 → 회선, 게이트웨이, 라우팅, 방화벽 쪽 가능성
- IP ping은 되는데 도메인만 안 된다 → DNS 가능성 높음
내부망이라면 게이트웨이도 같이 찍어본다.
ping -c 4
게이트웨이조차 닿지 않으면 로컬 네트워크 구간부터 다시 봐야 한다.
4. 경로가 어디서 막히는지 traceroute로 본다
중간 어디쯤에서 끊기는지 보고 싶다면 traceroute가 유용하다.
traceroute 8.8.8.8
설치되지 않았다면 배포판에 따라 traceroute 패키지를 추가해야 할 수 있다.
이 명령이 도움 되는 상황:
- 외부 특정 구간까지만 도달하고 이후 끊길 때
- VPN 경로가 기대와 다를 때
- 사내망/클라우드 라우팅 정책 충돌을 의심할 때
다만 ICMP 응답을 막는 구간도 흔하므로, traceroute 결과만으로 장애를 단정하면 안 된다.
경향을 보는 보조 도구로 쓰는 편이 안전하다.
5. DNS 문제는 dig 또는 nslookup으로 분리한다
대부분의 “사이트 접속 불가”는 실제 네트워크보다 DNS 문제인 경우도 많다.
dig google.com dig google.com @8.8.8.8
이렇게 보면 현재 시스템 기본 DNS와 외부 지정 DNS 결과를 비교할 수 있다.
점검 포인트:
- 응답 자체가 오는지
- 의도한 IP가 맞는지
- 사설 DNS가 오래된 레코드를 주는지
- /etc/resolv.conf가 예상과 다른 값으로 바뀌지는 않았는지
빠르게 확인하려면:
cat /etc/resolv.conf
getent hosts google.com
ping google.com
하나만 보고 DNS를 판단하면 오해가 생길 수 있다. 가능하면 dig로 질의 결과를 직접 보는 편이 낫다.
6. 서비스 포트는 ss로 본다
네트워크가 정상이어도 애플리케이션이 포트를 열지 않았으면 접속은 실패한다.
ss -tulpn ss -tulpn | grep :80 ss -tulpn | grep :443
여기서 볼 것:
- 프로세스가 실제로 LISTEN 중인지
- 예상 포트가 맞는지
- 127.0.0.1에만 바인딩돼 외부 접속이 안 되는지
- 서비스 재시작 후 포트가 내려가 있지는 않은지
예를 들어 Nginx가 실행 중이어도 127.0.0.1:8080에만 물려 있으면 외부에서 80/443 접속이 되지 않는다. 이럴 때는 방화벽보다 서비스 바인딩 설정을 먼저 봐야 한다.
7. 방화벽 확인은 마지막이 아니라 중간중간 같이 본다
실무에서는 방화벽이 원인인 경우가 많다. 다만 무조건 첫 번째는 아니다. 인터페이스, 라우팅, 포트 상태를 본 다음 확인하면 훨씬 빠르다.
배포판과 구성에 따라 아래를 참고한다.
sudo ufw status verbose sudo firewall-cmd --list-all sudo nft list ruleset sudo iptables -S
확인 포인트:
- 필요한 포트가 허용돼 있는지
- 특정 인터페이스/zone에만 정책이 적용돼 있지는 않은지
- 예전 iptables 룰과 nftables 설정이 혼재돼 있지는 않은지
특히 운영 서버에서는 “방화벽을 잠깐 꺼보고 확인” 같은 방식보다, 현재 정책을 읽고 필요한 포트만 정확히 확인하는 습관이 더 안전하다.
실무에서 자주 쓰는 점검 순서 예시
웹 서비스가 안 열린다고 가정하면 보통 이렇게 본다.
- ip -br addr로 인터페이스/주소 확인
- ip route로 기본 경로 확인
- ping으로 게이트웨이와 외부 IP 확인
- dig로 DNS 확인
- ss -tulpn으로 서비스 포트 확인
- 방화벽 정책 확인
- 필요하면 traceroute로 구간별 경로 확인
이 순서를 익혀두면 “아무것도 안 된다”는 막연한 상태를 빠르게 링크 문제 / 라우팅 문제 / DNS 문제 / 서비스 문제 / 방화벽 문제로 분해할 수 있다.
같이 보면 좋은 로그 포인트
명령어만 보고 끝내지 말고 로그도 함께 보면 좋다.
- journalctl -u NetworkManager
- journalctl -u systemd-networkd
- journalctl -u nginx
- dmesg | grep -i -E 'eth|enp|link|nic'
특히 NIC 드라이버 문제나 링크 flap 같은 건 패킷 캡처보다 로그에서 먼저 단서가 나오는 경우가 많다.
마무리
리눅스 네트워크 점검에서 중요한 것은 명령어를 많이 아는 것보다 어떤 순서로 원인을 줄여 가느냐다.
- ip로 인터페이스와 라우팅 확인
- ping으로 통신 가능 여부 확인
- traceroute로 경로 단절 구간 확인
- dig로 DNS 분리 확인
- ss로 서비스 포트 확인
이 다섯 가지만 익숙해져도 네트워크 장애 대응 속도가 꽤 빨라진다.
목요일용 리눅스 네트워킹 글로는, 넓은 개론보다 이런 즉시 사용 가능한 점검 루틴이 훨씬 실무적인 초안이 된다.