
IDC 환경에서 일을 하며, 가장 어려운 것은 네트워크 트러블 슈팅인 것 같습니다.
“통신이 안된다”라는 말이 네트워크의 문제인지 방화벽 문제인지 구분하기 어려웠습니다.
A. 기존 방법
네트워크 통신이 안되는 일이 있다면,
어디서 어디서부터 통신이 안되는건지 단계적으로 찾아갔습니다.
가장 정석적인 방법이고 정확한 방법인 것 같지만, 동시에 오래걸리는 것 같습니다.
curl -k https://naver.com
dig +short naver.com
nslookup naver.com
tcpdump -i eth0 port <port>
세상에는 더 나은 도구가 있을 것 같아서 찾아보고자 했습니다.
B. 요구 사항
별도의 도구를 설치해야 하는 비용이 발생하므로,
네트워크/방화벽 문제를 바로 구분하는 등의 명확한 이익이 있기를 원했습니다.
네트워크 연결이 안되어 있는 것과
방화벽 설정으로 막혀있는 것은 다르니
Target | Layer | Protocol | Port |
---|---|---|---|
ICMP | 4 | TCP + UDP | - |
DNS | 4 | UDP | 53 |
HTTP | 7 | TCP | 80 |
HTTPS | 7 | TCP | 443 |
방화벽 문제 중에서도 Default Deny/Allow 를 구분할 수 있으면 좋을 것 같습니다.
원래 되는데 따로 막은 것이 Default Allow, 그 반대가 Default Deny
C. 도구 파악
요구사항을 만족하면서 비용이 낮은 도구를 찾아봅시다.
C.1. mtr
mtr은 목적지까지 어떤 경로로 연결이 될 수 있는지 보는 도구입니다.
-r : report mode, 결과를 한 번만 출력하고 종료
-w : wide output, 출력 폭을 넓혀서 상세하게 보여줌
sudo mtr -rw example.com
sudo mtr -rw -T -P 443 example.com
sudo mtr -rw -u -p 53 example.com
traceroute와 본질적인 역할은 동일하다고 할 수 있습니다.
sudo traceroute example.com
sudo traceroute -P tcp -p 443 example.com
sudo traceroute -P udp -p 53 example.com
본래 목적*을 생각해보면 mtr을 사용하는 베네핏이 없는 것 같습니다.
(mtr은 패킷 로스를 추가적으로 볼 수 있으나 굳이?)
nmap
namp은 목적지까지의 방화벽을 체크할 수 있는 도구입니다.
sudo nmap example.com
sudo namep -sT -p 1-65535 example.comㅈ
네트워크 연결 유/무에 추가적으로 방화벽 개방 여부를 확인할 수 있습니다.
Starting Nmap 7.97 ( https://nmap.org ) at 2025-06-28 21:55 +0900
Nmap scan report for example.com (23.215.0.138)
Host is up (0.20s latency).
Other addresses for example.com (not scanned): ...
PORT STATE SERVICE
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds
본래 목적*과 가장 적합한 도구인 것 같습니다.
하지만 별도 도구를 설치할만큼의 가치가 있는지 잘 모르겠습니다.
D. 결론
역히 실버 불릿은 없다라는 생각이 듭니다.
nmap은 유용한 도구처럼 보이지만 설치할 만큼은 아니었습니다.
IDC, Cloud, VM, Kubernetes를 오가는 복잡한 환경에서는
항상 원하는 도구가 설치되어있을 거라는 보장이 없습니다.
따라서 최소한의 도구로 트러블 슈팅하는 것에 적응하는 것이 좋다는 생각이 들었고
nmap 또한 추가적인 도구가 되는 것의 이점을 크게 느끼지 못했습니다.
아래 다섯가지 도구 정도만 있어도 대부분의 문제 정의가 가능한 것 같습니다.
curl, dig, nslookup, traceroute, tcpdump