윈도우 netstat와 telnet을 이용한 트러블 슈팅 방법

윈도우 netstat와 telnet을 이용한 트러블 슈팅 방법에 대해서 알려드릴께요.

IT에 계신 분들은 업무를 하다보면 서버나 기타IT장비의 장애가 나는 경우가 종종 발생하는데요.

일단 원인은 크게 2가지로 나눌수 있습니다. 

첫째, 하드웨어 적인 원인. 둘째, 소프트웨어 적인 원인.

먼저로는, 하드웨어 적인 이유는 예를 들자면 (ex. 랜선 빠짐, 장비 파워 다운)를 들수 있구요.

둘째로는, 소프트웨어 적인 이유는 셀 수도 없을 정도로 매우 다양한 원인을 들수 있습니다....

하지만 만약 소프트웨어 적인 이유로 장비(또는 서버)가 접속이 되지 않는다면 빨리 그 원인을 파악해야 하는데요

그때는 윈도우 커맨드창 2개만 띄워놓고 각각의 커맨드 창에 아래의 명령어만 치면 간단하게 해결 됩니다.

command 1> netstat -an 1 | findstr <목적지IP>

command 2> telnet <목적지IP> <목적지Port>

먼저 HTTP 서비스 제공하지 않는 KT DNS(168.126.63.1)를 대상으로 테스트를 진행 하겠습니다.

커맨드 창을 하나 열고 "netstat -an 1 | findstr <목적지IP>" 명령어를 칩니다.

위 명령어는 "<목적지IP>" 문자열을 검색해서 "netstat -an" 명령어를 1초마다 갱신하겠다는 의미 입니다.

또 하나의 커맨드 창을 하나 열고 "telnet <목적지IP> <목적지Port>" 명령어를 칩니다.

그러면 netstat 명령어를 쳤던 커맨드 창에서 아래와 같은 SYN_SENT 결과를 볼 수 있습니다.

TCP/IP에서 TCP 통신규약인 3-Way Handshaking을 아시겠지만 

SYN_SENT는 클라이언트가 서버에게 연결요청(SYN) 패킷을 보냈다는 것을 의미 합니다. 

여기서!! SYN_SENT는 2가지의 중요한 의미를 내포하고 있습니다!!!

첫째. 서버(또는 장비)의 파워가 꺼짐 / 물리적으로 접속 제한(ex, Lan cable 빠짐)이 발생함

둘째. 방화벽 정책에 의해 패킷이 차단되고 있음

만약 자신이 서버(또는 장비)에 물리적으로 직접 접근해서 확인해보니 이상이 없다면

둘째이유인 방화벽에 의한 패킷 차단을 의심해보는 것이 가능성이 높고

만약 자신이 IT정보보안팀이라서 방화벽에 접속하여 차단된 패킷이 있는지 검색하여 보니 특이사항이 없었다면...

첫째 이유인 물리적인 이유에 의한 접속 불가를 의심해보는 것이 정확한 발생 원인을 찾을 수 있는 지름길 입니다.

참고로 서버와 연결이 잘 될 때에는 아래와 같이 연결 수립이 잘 되었다는 메시지인 

"ESTABLISHED"라는 문구를 확인 할 수 있습니다.

(예를 들기 위해 아래에 있는 목적지 IP는 NAVER IP 를 대상으로 하였습니다)