로그인 | 회원가입 (뉴스레터신청) | SITEMAP
   
  개발   플랫폼   시스템   매니지먼트   전체기사  
인기검색어:   비스타 | 블로그 | IPTV | UCC |
자바
닷넷
C/C++
DB
모델링
웹개발
기타
유닉스/리눅스
윈도우
기타
서버
네트워크
보안
기타
BM
PM
기타
 
기사저장
0
 
마이 스크랩
Home > 빌더 > 시스템 > 네트워크
[네트워크 트러블 슈팅 ①] 사례별 트러블 해결법

김윤권,장성근(네트워크 엔지니어)   2007/09/10
1부 | 네트워크 사용자의 영원한 숙제 트러블 사례별 해결법
2부 | 네트워크 보안을 위한 호스트 간 트러블 해결법
3부 | 보이지 않는 트러블 찾기 단계별 라우터 트러블 점검하기
4부 | 네트워크 트러블의 뿌리를 찾아서 네트워크 장비별 트러블 슈팅
5부 | 새로 드러난 네트워크 골칫거리 무선 네트워크 트러블
라우터
[지디넷코리아]늘 사용하고 있다고는 하지만 네트워크는 그 개념이나 설비 자체가 광범위하기 때문에 개발자나 프로그래밍을 공부하고 있는 학생들이라 해도 그리 쉬운 분야가 아니다. 1부에서는 먼저 우리가 업무를 처리하거나 컴퓨터를 이용하면서 쉽게 접하는 몇 가지 네트워크 트러블 사례에 대해 알아보고, 그 해결책을 찾아보는 시간이다. 누구나 한번쯤 겪어 보았을 메일 전송이나 메신저 접속 차단 등의 짜증스런 기억을 해소할 방법들에 대해 알아보자.

매일 사용하는 자동차도 갑자기 멈춰버리면 막막하기 그지없다. 보닛을 열어본다 해도 그저 복잡하게 뒤엉킨 기계들뿐이니 쉽게 이해할 수 있을 리 없다. 이런 문제는 네트워크에서도 마찬가지다.

언제나 일상 속에서 사용하고 있는 인터넷이지만 막상 메일이 안 되거나 웹 페이지가 안 열리면 그렇게 난감할수가 없다. 때론 컴퓨터를 잘 아는 개발자라도 이런 문제에서 예외일 수 없다.

만약 자동차의 부속이 망가져서 차가 멈춘 것이라면 당연히 정비소로 차를 견인해야겠지만, 볼트가 헐거워 졌거나 기름이 떨어진 것 등의 가벼운 문제라면 누구나 손쉽게 문제를 해결할 수 있을 것이다.

네트워크도 마찬가지다. 장비나 서버에서 생긴 심각한 문제만 아니라면 대부분 쉽게 문제를 해결할 수 있다. 이제부터 흔히 만나는 몇 가지 사례와 그 해결법들에 대해 살펴보자.

  굳게 잠긴 메신저 열기

이메일은 편지를 죽이고, 휴대전화 문자 메시지는 다시 이메일을 시들게 했다. 이 휴대전화의 문자 메시지에 필적할 만큼 사용자들의 사랑을 받고 있는 것이 하나 더 있으니 바로 메신저이다. 필요한 내용을 바로 주고받을 수 있는 데다가 공짜여서 더 좋다.

그 덕에 메신저는 업무상 필요한 대화나 친구들과의 약속 또 아주 아주 가끔(?)은 수다도 떨 수 있도록 해주는 중요한 도구가 된 지 오래다. 그런데 이토록 중요한 메신저가 갑자기 되지 않는다면 어떨까? 상상하기조차 싫은 이런 상황이 생각보다 자주 그리고 흔하게 발생하고 있다.

먼저 이 글은 시스템 상의 문제가 전혀 없다는 걸 전제로 하고있다. 따라서 프로그램의 설치나 O/S 상의 문제로 인한 인터넷 문제는 다루지 않는다는 점을 양해해 주기 바란다. 메신저뿐 아니라 인터넷 익스플로러, 온라인 게임 등 인터넷을 이용하는 애플리케이션들이 동작 조차 하지 않을 때는 우선의 시스템 상에 문제가 없는지 확인해야 한다.

시스템에 전혀 문제가 없는 데도 메신저와 인터넷을 사용하는 애플리케이션이 제대로 실행되지 않는다면 인터넷 자체가 안 되는 것이며 이에 대한 해결 방법들은 3부에서 자세히 다룬다. 여기에서는 인터넷은 잘 되면서 메신저 로그인만 되지 않는 경우의 해결법에 대해 알아볼 것이다.

어떤 서버와 포트로 통신 하는가?
인터넷을 이용하는 애플리케이션들은 각각의 특정한 방법을 이용해 인터넷에 접속을 시도한다. 메신저 등 인터넷을 사용하는 애플리케이션의 로그인 문제를 해결하려면 먼저 이 접속 방법들에 대해 알고 있어야 한다. 늘 그런 것은 아니지만 메신저는 대부분 다음과 같은 세 가지 구성요소로 이루어져 있다.

- 접속 클라이언트 (사용자)
- 메신저 서버 (로그인과 사용자 정보에 관계)
- 상대 사용자

메신저를 실행하고 로그인 하면 가장 먼저 해당 메신저 서버에 접속하여 사용자의 아이디와 패스워드에 대하여 인증을 받는다. 인증이 되면 사용자의 개인 정보(친구목록, 대화 명 등)를 전송하며 로그인이 되고 이렇게 로그인 과정을 마치고 나야 비로소 다른 사용자와 대화를 할 수 있게 되는 것이다.

대부분의 메신저 프로그램들은 접속이 안 되는 상황이 되면 해당 원인을 표시해 주기도 하지만, 메시지 조차 표시되지 않는 경우라면 로그인 서버까지의 통신이 가능한지 확인해 보아야 한다. <표 1>은 많이 사용하는 메신저들의 통신 포트 번호 목록이다.


대부분의 메신저들은 사용하는 포트 번호는 일정하지만 접속하는 서버의 IP 주소는 모두 제 각각이다. 이는 메신저의 통신을 위해 사용하는 서버가 한 대가 아니라 여러 대인 탓이다. 때문에 바로 옆자리의 메신저는 잘 되는데 내 컴퓨터만 메신저가 되지않는 경우가 발생하는 것이다.

내 컴퓨터에 설치된 메신저가 접속하는 서버의 IP 주소를 확인하는 방법에 대해 알아보자. 커맨드 창을 연 뒤에‘netstat ?a’를 입력한다.

텔넷으로 메신저 IP에 접속하기
이렇게 패킷을 캡처하면 현재 통신중인 패킷에 대해 자세한 정보를 확인할 수 있다. 이렇게 해서 메신저가 사용하는 포트와 IP 주소를 확인했다면 수동으로 접속을 시도해 볼 수 있다. 필자가 사용중인 iman 메신저의 서버인 211.41.64.224의 10020 포트로 접속해보자. 먼저 커맨드 창을 열고 텔넷 명령을 입력하고 키를 누른다.

일반적으로 쓰이는 Telnet 명령 뒤에 숫자를 넣으면 그 숫자에 해당하는 포트로 텔넷을 시도하겠다는 뜻이 된다. Telnet 은 23번 포트를 주로 사용하므로 보통은 23 이라는 숫자가 생략되어 있는 것이다. 이렇게 텔넷을 시도하면 커맨드 창이 잠깐 깜박이며 화면이 전환되는데 이것은 접속이 이루어 졌음을 뜻한다.

실제로 화면에는 아무 것도 보이지 않는 경우가 대부분이지만(이는 해당 서버가 제공하는 Text 전송 방식이 맞지 않은 탓이다) 그건 중요하지 않다. 화면이 갱신되어 커서가 깜박인다면 이것은 접속에 성공했다는 뜻이다.

만약, 인터넷이 잘 동작되는 상태에서 호스트에 연결할 수 없다면 메신저가 안 되는 원인을 두 가지 정도로 유추해 볼 수 있다. 그 중 하나는 메신저 서버에 문제가 생겨서 접속되지 않는 경우이고 다른 하나는 메신저에 접속하기 위해 사용하는 포트가 막힌 탓이다.

서버의 문제라면 사실상 기다리는 방법밖에 없다. 해당 메신저 홈페이지에 공지된 사항이 없다면 우선 해당 서버까지 핑 테스트를 해보고 이상 없다면 방화벽 등에서 해당 포트를 막은 탓이다. 회사의 정책상 방화벽이나 라우터에서 해당 포트를 막은 것인지 네트워크 관리자를 통해 확인해 보자.

라우터에서 차단된 메신저 해결하기
회사에서 정책상 혹은 네트워크 관리자의 실수로 메신저를 차단할 수 있는 것은 라우터와 방화벽 그리고 메신저를 차단하는 솔루션 들이다. 다른 문제는 전혀 없이 메신저만 접속되지 않는 상황이라면 먼저 라우터를 의심해 봐야 한다. 라우터의 ACL(Access Control List)로 특정 메신저를 막을 수 있는 탓이다.

다음은 시스코 라우터를 이용해 MSN 메신저를 차단할 때 사용하는 명령이다..

access-list 100 deny?? tcp any 207.46.0.0 0.0.0.255 eq 1863
access-list 100 deny tcp any 207.46.0.0 0.0.0.255 eq 443

라우터를 통해 메신저 포트가 잠긴 상태라면 우회 포트를 열어 사용하는 방법 등 몇 가지 방법이 해결방법이 있지만, 대부분 회사의 보안 정책을 위반하는 방법이기에 여기에서는 설명하지 않는다. 업무를 위해서 필히 관련 메신저를 사용해야 한다면 전산 담당자나 보안 담당자에게 사용 승인을 받는 것이 가장 합리적인 방법일 것이다.

또 다른 방법으로 웹 메신저를 사용하는 것이 있다. 메신저 사용 포트가 차단된 상태라 하더라도 80 포트를 사용하는 웹용 MSN 메신저 등을 사용할 수 있기 때문이다. 대부분의 기업이 메신저들이 사용하는 포트는 닫더라도 웹 서비스를 사용할 수 있도록 하기 위해 80포트를 열어두는 덕에 이 메신저만은 사용할 수 있다.

MSN 웹 메신저는 웹 메신저 홈페이지(http://webmessenger.msn. com/?mkt=ko-kr)에 접속하여 실행할 수 있다. 웹 메신저라 하더라도 80번 포트까지 막아놓은 곳에서는 사용할 수 없으니 참고하자.

방화벽에서 메신저를 차단한 경우
때로는 방화벽이 메신저 통신을 차단시키는 경우도 있는데, 이럴 때에는 별다른 해결책이 없다. 이때에는 방화벽 담당자와 상담하여 자신의 IP에 설정된 방화벽을 해제해 달라고 요청하는 방법뿐이다.

방화벽에서 정책 적용을 설정하는 절차는 다음과 같다. 방화벽의 설정은 방화벽마다 차이가 있어 일반적인 기준에서 작성하였으니 참고하자.

① 방화벽에 의해 보호되어야 할 네트워크 혹은 장비의 IP 주소를 결정한다.
② 보호할 네트워크나 장비에 접근을 허용할 대상을 결정한다.
③ 보호대상 장비의 허용 포트와 서비스를 결정한다.
④ 기존에 설정된 정책에 위배되는 사항이 있는지 확인한다.
⑤ 방화벽에 정책을 적용한 뒤에 정책에 반하는 항목은 모두 거부하는 정책이 적용되어 있는지 확인한다.
⑥ 실제로 접근제어가 되는지 접속해 보아 확인한다.

  FTP가 안 된다고?

FTP도 메신저와 크게 다르지 않다. FTP 또한 네트워크를 이용하는 애플리케이션이며 데이터를 송수신 하는 역할을 담당하는 탓이다. 메신저와는 다른 점이 있다면 통신에 사용하는 프로토콜과 전송되는 데이터 종류 정도이다.

FTP에 제대로 접속되지 않는다면 메신저 접속 문제를 해결할 때와 같은 방법으로 포트 번호와 IP 주소를 확인해 보면 된다. FTP를 위해 사용하는 포트 번호는 21번이다(네트워크 관리자에 따라 포트번호가 변경될 수 있으니 관리자에게 문의해 보는 것이 좋다).

FTP 서버에 접속되지 않는 것 못지 않게 발생하는 FTP 관련 트러블은 분명히 FTP 서버에 접속은 되었는데 서버의 내용이 전혀 보이지 않는 경우이다. FTP는 21번과 함께 20번 포트를 사용한다.

21번은 FTP 서버에 접속하여 디렉터리 간 이동, 파일의 복사,이동 등의 명령을 수행하는 포트이고 20번은 데이터를 전송하고 수신하는 포트 이다. 즉 명령은 21번 포트로 수행하지만 실제 데이터는 20번 포트로 전송되는 것이다. <그림 1>은 FTP가 데이터를 전송하는 순서이다.

<그림 1>과 같은 구성에서 클라이언트와 FTP 서버가 데이터 파일을 전송하기 위해 대화를 한다면 다음과 같을 것이다.


① 내가 지금부터 내 2821 포트를 사용해서 너의 20번 포트로 데이터를 전송한다! (라고 2080포트로 말한다)
② OK! (라고 21번 포트로 말한다)
③ 그럼 내 20번 포트와 너의 2081포트랑 세션을 맺자! (라고 21번 포트로 말한다)
④ OK! (세션이 맺어졌다)
⑤ 데이터가 전송된다.

클라이언트의 포트 2080과 2081는 접속과 함께 정해지는 포트이지만 FTP 서버의 20과 21번 포트는 미리 서버에 설정된 포트이다. 이제 우리가 직면한 문제인 접속은 되었는데 내용이 보이지 않는 현상이 왜 생기는지 알아보자.

이미 설명한 것처럼 Command는 21번 포트를 통해 데이터 전달 요청을 한다. FTP 서버의 21번 포트로 전달되고 FTP 서버가 명령을 받고 보내줘야 할 내용은 20번 포트로 전송이 된다. FTP서버에 접속되었는데도 내용이 보이지 않는 이유는 21번 포트에는 정상적으로 접속되었으나 20번 포트로는 연결되지 않는 탓이다.

20번 포트로 연결되지 않는 이유는 FTP 전송 방식의 차이 때문이다. 잘 알고 있는 것처럼 FTP의 전송 방식은 액티브 모드(Active Mode)와 패시브 모드(Passive Mode)로 나뉜다.

● 액티브 모드
액티브 모드란 데이터를 전송하는 포트인 20번 포트가 미리 예약 되어 항상 FTP 서버의 20번 포트로 전송하는 방식을 말한다. 위의 <그림 1> 에서와 같이 클라이언트가 세션을 맺을 때부터 20번으로 맺겠다고 요구 하는 방식이다.

● 패시브 모드
패시브 모드는 클라이언트가 FTP 서버에 접속하면 FTP 서버가 데이터를 전송할 포트를 클라이언트에게 지시해주는 방식이다. 이 경우 클라이언트는 ‘너의 20번 포트로 전송하겠다’고 하기 전에‘너의 몇 번 포트로 데이터를 전송하면 되겠니?’라고 묻게 된다.

그 뒤에 FTP 서버로부터‘나의 xxx 번 포트가 열려 있으니 이리로 보내라’는 지시를 받고 세션을 맺게 된다. 이처럼 FTP 서버가 지정한 포트로만 접속해야 하는 통신 방식이 액티브 모드이다. FTP 서버의 설정항목에도, 우리가 흔히 사용하는 FTP 접속 프로그램에도 이 두 가지 모드 중에 선택 할 수 있는 부분이 있다.

클라이언트와 서버 모두 같은 전송 박식으로 설정되어 있어야 통신이 제대로 되는 것이다.

액티브 모드로 접속했는데 접속은 되고 내용이 보이지 않는 경우라면 서버에서 패시브 모드로 설정되어 있는 것이니 접속방식을 바꿔 주면 된다. 사족을 달자면 혹 모든 조건이 맞는데도 안된다면 방화벽 관리자를 다시 한번 괴롭히자.

  메일 전송 에러 해결하기

이메일을 보내고 받는 방법은 간단하지만 복잡한 네트워크 상에서 우리가 쓴 메일을 정확하고 안전하게 보내기 위해 아주 많은 장비들이 사용된다. 사용되는 장비가 많고 복잡한 구성으로 되어 있다. 그만큼 문제가 될 수 있는 요소들도 많다.

메일 전송 에러를 해결하는 방법에 대해 알아보기 전에 메일 전송의 기본적인 송수신 과정에 대해 알아보자. <그림 2>는 한 사람이 다른 사람에게 메일을 보내는 과정을 도식화 한 것이다. 이 과정을 순서대로 살펴보면 다음과 같다.


① 우선 보내는 이가 메일 전송 애플리케이션을 이용해서 메일을 작성한다. 작성된 메일을 보내기 하면 보내는 사람의 컴퓨터에 셋팅 된 보내는 서버(SMTP Server) 주소를 통해 메일이 보내진다. 이때 사용되는 포트번호는 25번이다.
② 보내는 사람의 컴퓨터에 셋팅 된 보내는 서버는 전달받은 메일의 내용을 확인한 뒤에 어디로 보내야 하는지 확인한다.
③ 편지를 받을 사람에 대한 정보 중 메일 주소 부분에 있는 도메인을 DNS 서버로 보내서 해당 도메인의 IP 주소를 확인한다. 이때 도메인에 해당하는 메일 서버의 IP 주소를 확인하기 위해 보내는 쿼리를 MX(Mail Exchanger) 쿼리라고 부른다.
④ DNS로부터 받은 쿼리의 IP 주소에 해당하는 받는 서버(POP Server)로 메일을 보낸다.
⑤ 메일을 받는 사람은 자신의 받는 서버에 저장된 메일을 받아보게 된다. 이때 사용하는 포트 번호는 110번이다.
⑥ 답장을 보낼 때에도 마찬가지 과정을 거치게 된다.

보내는 메일 서버나 받는 메일 서버는 부하가 많지 않을 것으로 판단되는 경우 하나의 서버로 통합하여 운영하기도 하는데 이렇게 할 때에는 몇 가지 문제가 발생할 수 있다.

DNS에서 SMTP까지의 통신, 그리고 STMP와 DNS 간의 통신, 그리고 SMTP와 상대방 POP 서버 간의 통신에 약간의 문제가 발생하면 메일은 전송되지 않는다. 한 대의 서버가 두 가지 역할을 담당하게 되면 부하가 더 걸릴 뿐 아니라, 서버에 문제가 생길 경우 메일을 보낼 수도 받을 수도 없는 상황이 발생하는 탓이다.

만약 메일 전송에 문제가 발생했다면 핑 테스트를 하거나 포트를 이용한 텔넷으로 체크하여 어느 부분에서 문제가 생겼는지 확인할 수 있다.

사실, 메일이 완전히 안 되는 것 보다 보내기와 받기 중 어느 하나만 안 될 때가 문제를 파악하기 훨씬 어렵다. 이런 경우에는 대부분 메일을 보낸 사람에게 전송 실패 이유가 반송된다. 메일 전송 실패 시 표시되는 메시지들에 대해 알아보자. 복잡한 코드로 되어 있지만 일단 그 뜻을 알고 나면 원인과 해결방법을 찾을 수 있다.

 <리스트 1> 이메일 발송 실패 에러 메시지


에러 메시지를 살펴보는 것도 쉽지가 않다. 우선 그 양이 너무 많기 때문이다. 물론 이 많은 에러 메시지를 모두 외우는 것은 불필요한 일이다. 관련 내용을 잘 보관해 두었다가 필요할 때 찾아보는 정도이면 충분하다.

또한 에러 메시지의 내용을 살펴 보면 네트워크 문제와 서버 문제가 동시에 포함되어 있는데 네트워크의 문제라면 3부와 4부를 통해 문제 지점을 확인하는 방법을 알 수 있을 것이다. 서버의 문제는 메일 서버의 운영자가 아니라면 조치하기는 어렵겠지만 해당 에러 메시지와 함께 메일 서버 관리자에게 문의할 수 있을 것이다.

<표 3>은 이메일의 송신 장애가 발생했을 때 해 볼 수 있는 체크 항목 리스트이다. 만약 갑작스레 이메일이 되지 않는다면 <표3>을 이용해서 각 항목들을 체크해 보자.


애플리케이션을 사용하다 보면 여기에서 다룬 것들 이외의 문제들도 많이 마주치게 된다. 인터넷 사용과 인터넷 관련 애플리케이션을 사용하면서 중요한 것은 각각의 프로그램이 가지는 모든 원리를 알려고 할 것이 아니라 기본적인 네트워크와 인터넷 통신에 대해 이해하는 것이다.

필자가 설명한 Ping, Tracert, nslookup, Telnet 들은 아주 기본적인 수준의 명령이지만 이것만 가지고도 쉽고 빠르게 문제가 된 장비나 위치를 알아낼 수 있다. 실제로 이 명령어들은 네트워크 관리자들도 가장 많이 사용하고 있다. @


* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
독자의견 남기기 (로그인 후 독자 의견을 남기실 수 있습니다.)
아이디 비밀번호
 
  
[DDD ③] 스프링 프레임워크와...
[DDD ②] UI 프로토타이핑
[DDD ①] 도메인 주도 개발
가상화에 실패하는 10가지 이유
[책소개]프리젠테이션 젠: 생각을...
[기고]그린 스토리지로 가는길
[책소개] 웹 개발자를 위한 스프...
[서범근의 유쾌한 리뷰]'같으면서 다른' USB형 MP3 옙 'U4'-아이리버 'T7', 첫 맞대결 [00:04:38]
기획 류준영, 진행 서범근 리뷰어, 제작 유회현
[화이트보드]직장내 무선 통신 구축, "함부로 하지 마라" [00:04:25]
지디넷코리아 편집국
조중동, 다음에 뉴스공급 중단…"...
‘나홀로 액티브X’…세계 인터넷과...
‘윈도XP’시대 폐막, 사용자에게...
인터넷 뱅킹 브라우저는 따로 있다...
'위피 의무화' 폐지 분위기로…
다음 vs 조중동, 정면충돌로 치...
주니퍼, 애플리케이션 가속 솔루션...
엔비디아 CEO, 서울대서 특별 ...
삼성전자, 협력사와 상생한다
엑셈, 日 노무라종합연구소에 DB...
핸디소프트, 비정형 업무도 관리하...
 
Service: IT 채용정보 | 도메인 | 호스팅 | PDA 서비스 | NEWSLETTER 신청 | HELP DESK
회사소개 | 광고문의 | 제휴문의 | FAQ | 정보보호정책 | 정보이용약관 | 이메일 무단수집거부
GameSpot Korea | CNET Direct Service		  
The Korean edition of 'ZDNet' is published under license from CNET Networks, Inc., San Francisco, CA, USA. Editorial items appearing in 'ZDNet Korea' that were originally published in the US Edition of 'ZDNet', 'CNET', and 'CNET News.com' are the copyright properties of CNET Networks, Inc. or its suppliers.
Copyright ⓒ 2008 CNET Networks, Inc. All Rights Reserved. 'ZDNet', 'CNET' and 'CNET News.com' are trademarks of CNET Networks, Inc.