How to Troubleshoot Network Problems on Linux늘 네트워크를 활용하고 있기는 하지만 네트워크의 개념과 설비가 방대하기 때문에 전체적으로 이해하기는 쉽지 않은 분야이다. Show 아래에서 Network 관련 Linux Commands1. ping대상 호스트(호스명 or IP주소)로 ICMP(Internet Control Message Protocol)을 보낸다. 대상 호스트에 연결이 되어있는지 확인할 수 있는 가장 기본 커맨드이다. 예를 들면 Web 페이지가 표시되지 않을 때 소프트웨어가 다운되었는지, 호스트 자체가 다운 되었는지를 확인할 수 있다. Web 서버 소프트웨어가 다운되어도 호스트가 살아있으면 응답을 받을 수 있다. ping [host name or IP address] 2. netstatnetstat(Network Statistics)은 TCP-IP 커넥션 네트워크의 통계 정보를 제공해준다.
열려있는 포트와 동작하고 있는 소프트웨어도 확인할 수 있다. $ sudo netstat -tnlp
3. ifconfig네트워크 인터페이스 상태 표시 및 설정. IP 확인을 위해 주로 활용한다. ifconfig 4. hostnamehostname 표출 혹은 지정. 인자로 hostname을 넘기면 지정이고, 인자 없이 입력하면 현재 hostname을 표시한다. hostname [hostname] 5. traceroute지정된 호스트까지 패킷이 전달되는 경로를 표시. ping이 날라가지 않을 경우, traceroute을 통해 호스트 자체에 문제가 있는지, 호스트에 도달하기까지 네트워크 경로중에 문제가 있는지 알아볼 수 있다. traceroute는 IP 패킷의 Time to Live(TTL) 필드를 활용해 destination까지의 traffic path를 알아내는데 간단하게 그 방법을 정리해보면: traceroute [hostname or IP] 6. route기기의 라우팅 테이블을 반환한다. IP 네트워크에서 라우팅 테이블은 특정 서브넷에서 다른 서브넷으로 패킷을 보내기 위해 활용된다. Network Troubleshooting CaseTCP/IP Model먼저 TCP/IP 모델에 대해서
간단히 알아보자. TCP/IP 모델은 공식 네트워크 모델인 OSI Model보다 현대 네트워크에 사용되는 프로토콜군을 더 정확하게 표현하는, de facto 표준 모델이라고 할 수 있다. 만약 MySQL 서버로 SSH는 가능한데 MySQL DB에 접근이 안되는 상황을 가정한다면, 이 문제는 확실히 하단의 Data Link나 Physical Layer 관련 문제는 아닐 것이다. 그래서 일반적으로 위 모델 스택의 가장 상위에 있는 Application Layer로부터 차례로 아래로 내려가면서 트러블슈팅을 해나가는 것이 좋다. 아래에서는 각 Layer별 진단 방법에 대해서 Layer 1부터 Layer 4까지 한번 알아보자. Layer 1: The physical layer물리계층 이슈하면 케이블이 제대로 꽂혔는지 확인하는게 가장 먼저 떠오르는데, Linux command로도 문제가 있는지 간단히 확인해볼 수 있다. # ip link show 위 예시를 보면 eth0 인터페이스가 DOWN 되어있다. 1계층이 제대로 동작하고 있지 않다는 의미이다. 이 경우 보통 케이블이나 스위치 등의 문제를 점검한다. Layer 2: The data link layer데이터링크 계층은
local network 연결을 담당한다. 일반적인 상황은 ARP entry가 채워지지 않아서 localhost가 default 게이트웨이의 2계층 MAC주소를 얻지 못하는 상황이다. 그러면 호스트는 어떤 트래픽도 원격(remote) 게이트웨이로 내보낼 수 없게 된다. 이런 문제는 게이트웨이에 대해서 잘못된 IP주소를 갖고 있거나, 스위치 포트가 잘못 설정되어있거나 등의 원인으로 생길 수 있다. ARP table의 entry들은 # ip neighbor show 문제가 없는 경우 위의 FAILED 메시지가 REACHABLE로 표출될 것이다. Layer 3: The Network/internet layer3계층은 가장 익숙한 IP address를 포함하는 계층이다. IP 주소는 local network를 벗어나는 다른 외부의 호스트에 대한 주소를 제공한다. # ip -br address show 3계층 트러블슈팅에서 가장 기본적으로 많이 쓰이는 툴은 위의 Linux commands에서 소개한 # ping www.google.com 3계층 트러블슈팅에서 또 다른 많이 쓰이는 툴은 위에서 설명한 # traceroute www.google.com traceroute의 path 분석 시 주의사항을 하나 알아두자. Layer 4: The transport layer전송계층은 TCP와 UDP등의 프로토콜을 포함한다. 가장 먼저 체크해야하는 것은 localhost에서 listening중인 포트이다. 만약 머신에서 웹이나 SSH 등의 특정 서비스에 연결할 수 없는 상태라면 이 결과가 특히 유용할 수 있다. 다른 흔한 문제는 이미 특정 포트에서 listening중인 프로그램이 있어서 데몬이나 서비스가 시작되지 못하는 경우다. (바로 이 포트 충돌 문제로 이슈를 겪어서 지난 포스트
[AWS] EMR Trouble Shooting-Bootstrap Failure-Port conflicts에 정리한적이 있다.) # ss -tunlp4
위의 출력 결과를 보면 다른 케이스로 원격 연결 문제가 있을 수 있다. 로컬머신이 원격에 위치한 MySQL의 3306 포트에 접근하지 못하는 경우를 가정해보자. 이런 상황에 # telnet database.example.com 3306 위의 커맨드 결과, 강제로 킬하기 전까지 telnet이 hang되고 있는 상태였다. TCP 확인을 위해서는 telnet 명령으로 충분하지만, UDP 확인을 위해서는 # nc 192.168.122.1 -u 80 (netcat은 일반적으로 보안 리스크가 있는 유틸리티로 간주되므로, 트러블슈팅에 필요해서 활용하고 나면 삭제해두기를 권장한다.) Wrapping up기본적인 네트워크 이슈를 확인하기 위해, 위에서 소개한 명령어와 툴들이 좋은 출발점이 될 수 있을 것이다. 위의 방법들을 통해서, 최소한 네트워크 엔지니어에게 이슈에 대해서 리포팅할 때 가능한 한 디테일한 정보를 제공하는데 유용하게 쓰이기를 바란다. 마지막으로 잊지 말 것: The packets don’t lie! 위의 문제해결 사례는 Red Hat(www.redhat.com)의 A beginner’s guide to network troubleshooting in Linux의 내용을 참조하였습니다. Reference |