[Linux] Network에서 사용되는 주요 명령어

 

서버와 연관된 네트워크 장애 처리에는 몇 가지 필수적인 서버 네트워크 명령어를 알아두는 것이 효과적입니다. 장애 발생 시 이를 빠르게 진단하고 해결할 수 있도록 돕는 유용한 명령어를 소개하겠습니다. 또한, HTTP 상태 코드와 작업 후 서비스 상태를 확인할 수 있는 모니터링 툴에 대한 정보도 중요하다.

 

1. netstat 명령

서버 네트워크 장애 처리에서 netstat 명령어는 필수적인 도구이다. 이 명령어는 시스템의 네트워크 상태를 실시간으로 점검하고, 네트워크 연결 상태를 확인하는 데 유용하다. netstat를 사용하면 서버의 열린 포트, 현재의 네트워크 연결, 소켓 상태 등을 확인할 수 있으며, 장애 발생 시 문제를 진단하는 데 중요한 정보를 제공한다.

- netstat 주요 기능

연결된 포트와 IP 주소 확인	- netstat -an 명령어는 시스템에서 열려 있는 포트와 현재 연결된 IP 주소를 확인할 수 있게 함. 이 명령어는 ACTIVE 상태인 연결을 찾아내는데 유용함.
소켓 정보 확인	- netstat 명령어는 TCP/IP 프로토콜을 사용한 소켓의 상태도 점검할 수 있음. 예를 들어, netstat -tuln 명령어를 사용하면 서버에서 열린 TCP/UDP 포트를 확인할 수 있음.
네트워크 인터페이스와 라우팅 정보	- netstat -i 명령어는 네트워크 인터페이스에 대한 정보를 제공하고, netstat -r은 라우팅 테이블을 확인할 수 있게 함.
세션 상태 확인	- netstat -s 명령어는 네트워크 프로토콜별 통계를 제공함. 예를 들어, TCP 세션 수나 에러 발생 정보를 볼 수 있음.

 

- 연관된 명령어 활용

ss (Socket Stat)	- netstat과 비슷하게 소켓 연결 상태를 확인하는 명령어임. - ss는 더 빠르고 정확한 정보를 제공하며, 시스템에서 열린 포트와 연결된 IP 주소를 점검하는 데 유용함. - ss -tuln 명령어는 netstat -tuln과 비슷한 결과를 얻을 수 있음.
lsof (List Open Files)	- lsof 명령어는 시스템에서 열린 파일 정보를 제공하는 명령어임. - 네트워크 소켓 역시 파일로 다루어지므로, lsof -i 명령어를 사용하면 열린 네트워크 소켓을 확인할 수 있음.
ifconfig / ip a	- 네트워크 인터페이스의 상태를 확인하는 명령어임. - ifconfig는 더 이상 현대적인 시스템에서 많이 사용되지 않지만, 여전히 일부 환경에서 유용함. - ip a 명령어는 네트워크 인터페이스와 IP 주소를 관리하는 데 주로 사용됨.
네트워크 장비 캐시 정보 (Cisco 백본)	- 네트워크 장비에서 netstat를 통해 확인한 상태 값은 Cisco 백본 장비의 캐시 플로우(cache flow) 정보와 비교할 수 있음. - 캐시 플로우는 장비가 트래픽을 처리하면서 기록하는 정보를 의미함. - 이 값을 비교하면, 장애가 발생한 구간을 추적할 수 있음.
L4 스위치 세션 테이블	- L4 스위치의 세션 테이블은 시스템의 네트워크 상태와 일치하는지 확인하는 데 사용할 수 있음. - netstat의 세션 상태 값과 L4 스위치의 세션 테이블을 비교하면, 특정 연결에서 발생한 문제를 더욱 정확하게 파악할 수 있음.

 

(1) netstat 명령 형식

netstat [option]

-a	일반적 내용 외에 모든 소켓, 경로 테이블(경로 정보), 네트워크 인터페이스 정보까지도 표시
-i	네트워크 인터페이스 접속 상태에 관한 정보 표시
-r	경로 테이블(경로 정보) 표시
-n	네트워크 주소를 숫자로 표시
-s	각 프로토콜의 통계 정보 표시
-g	네트워크 인터페이스의 멀티캐스트 정보를 표시
-rv	라우팅 테이블의 추가 정보를 표시

 

(2) netstat -an

Server # netstat -an Active Internet connections (including servers) Proto Recv-Q  Send-Q   LocalAddress                Foreign Address         (state) tcp         0            0              *.901                                   *.*                      LISTEN  tcp         0            0         172.16.10.3.56590   192.168.239.68.49236     ESTABLISHED   tcp         0            0              *.1712                                 *.*                      LISTEN  tcp         0            0         172.16.10.3.80         211.222.225.164.4772     ESTABLISHED   tcp         0            0              *.382                                   *.*                      LISTEN  tcp         0            0              *.80                                     *.*                      LISTEN

Proto	프로토콜을 의미하며, 사용 중인 TCP, UDP 프로토콜을 표시
Recv-Q	전송받은 데이터 중 아직 처리하지 못하고 소켓 버퍼(Receive buffer)에 대기하고 있는 바이트 수를 표시
Send-Q	전송됐지만(Send buffer) 아직 전송되지 못하고 소켓 버퍼에 대기 중인 바이트 수를 표시
Local Address	로컬 IP 주소와 포트 번호, 콜론으로 분리
Foreign Address	로컬 시스템과 통신 중인 외부 시스템 IP 주소와 포트 번호
State	통신 상태를 표시

 

 정상적인 TCP 통신에서는 netstat -an 명령어를 통해 SYN_SENT, SYN_RECEIVED 상태를 자주 볼 기회가 드물다. 이는 TCP의 3-way handshaking 과정이 매우 빠르게 이루어지기 때문이다. 정상적인 통신에서는 이 단계들이 순식간에 지나가며, 대부분의 경우 그 과정을 볼 수 없다. 그러나 이러한 상태가 자주 나타난다면, TCP 통신에 문제가 있을 수 있다는 신호이다. 예를 들어, 네트워크 지연, 방화벽 설정, 서버의 응답 지연 등 여러 가지 문제가 있을 수 있다. 이럴 때는 문제의 원인을 정확히 파악하기 위해 추가적인 네트워크 분석이 필요하다.

 

- netstat -an 명령 결과 값의 의미

LISTEN	서버의 데몬이 떠서 접속 요청을 기다리는 상태(서버 애플리케이션에서 수동 적 열기로 연결 요청을 기다리고 있는 상태)
SYN-SENT	로컬의 클라이언트 애플리케이션이 원격 호스트에 연결을 요청한 상태(원격 호스트에 능동적인 개설 요청 - 수동적 열기)
SYN-RECEIVED	서버가 원격 클라이언트로부터 접속 요구를 받아 클라이언트에게 응답을 했지만 아직 클라이언트에게 확인 메시지는 받지 않은 상태(네트워크 통한 연결 요청 받음 - 수동적 열기)
ESTABLISHED	3-way handshaking이 완료된 후 서로 연결된 상태
FIN-WAIT1	능동적 닫기(Active close) 요청을 한 상태
CLOSE-WAIT	수동적 닫기를 하고 있는 상태로, FIN 종결 세그먼트를 수신하고 이에 대한 확인 메시지를 전송한 상태
FIN-WAIT2	로컬에서 종결(FIN) 세그먼트를 전송했고 원격 시스템에서 이에 대한 확인 메시지를 수신했지만 원격 애플리케이션이 작업을 종료하지 않아 원격 호스트의 종결 세그먼트를 기다리는 상태
LAST_ACK	FIN 종결 요청을 받고 로컬에서도 회선 종결에 합의해 종결을 요청(FIN)한 상태로, 이에 대한 확인 메시지가 수신되면 회선이 종결됨
TIME-WAIT	연결은 종료됐지만 분실됐을지 모를 느린 세그먼트를 위해 당분간 소켓을 열어놓은 상태
CLOSING	로컬 TCP는 FIN_WAIT_1에서 설명한 대로 FIN 종결 세그먼트를 전송했고 LAST_ACK에서 설명한 대로 원격 시스템의 종결 세그먼트도 수신했지만 FIN_WAIT_1 단계에서 전송한 세그먼트에 대한 확인 메시지(ACK)를 수신하지 못한 상태로, 보통 확인 메시지가 전송 도중 분실됐다는 것을 나타냄(흔하지 않지만 주로 확인 메시지가 전송 도중 분실된 상태)
UNKOWN	소켓의 상태에 대해서 확인이 안 되는 경우
CLOSED	완전히 종료, 가상 회선 종결

 

(3) netstat -nr

Server # netstat -nr Routing tables Destination         Gateway           Flags   Refs   Interface    Pmtu 127.0.0.1            127.0.0.1          UH       0        lo0              4136 172.16.30.10      172.16.30.10    UH       0        lan1            4136 172.16.30.50      172.16.30.50    UH       0        lan2            4136 127.0.0.0            127.0.0.1          U          0        l0                0 default                172.16.30.1      UG       0        lan2            0

Destination		목적지 네트워크 또는 호스트 라우팅일 경우 호스트가 됨
Gateway		Destination에 기술된 목적지에 도달하기 위한 다음 홉임
Flags		라우팅의 특징을 서술하기 위해 사용됨
	U	UP을 의미하며, 즉 루트가 UP돼 있고 동작하고 있음을 나타냄
	H	Host를 의미하며, 이 루트를 통해 단지 한 대의 호스트에만 도달 가능하다는 것을 의미함. 즉, 이 라우팅 정보가 32비트 호스트 라우팅을 말함
	G	Gateway를 의미하며, 현재 인터페이스가 속해 있지 않는 네트워크가 목적지인 패킷이 이용하는 다음 홉을 말함
	D	ReDirect를 의미하며, ICMP Redirect 메시지에 의해 만들어진 루트임을 말함
Ref		라우팅이 참조된 횟수를 말함
Use		이 루트를 이용한 패킷의 수(Solaris..)를 의미함
Interface		이 루트가 이용되는 네트워크 인터페이스의 이름을 의미함
Pmtu		Path MTU를 의미함

 

 서버에서 외부 통신이 되지 않을 경우, 가장 먼저 확인해야 할 사항은 디폴트 라우팅 경로이다. 또한, 특정 32비트 호스트 라우팅이 설정되어 있는지 여부도 점검해야 한다. 문제 해결을 위해 서버 관리자에게 netstat 로그 자료를 요청하는 것이 필요할 수 있다.

 

 서버 관리자 없이 인터페이스 설정과 라우팅을 추가해야 할 상황이 발생할 수 있으므로, 이를 대비해 관련 명령어를 숙지하는 것이 유용하다.

 

- ifconfig(인터페이스 설정과 확인)

#ifconfig	hme0	172.16.10.2	netmask	255.255.255.0	broadcast	172.16.10.255
	(1)	(2)	(3)	(4)	(5)	(6)

(1)	인터페이스 이름(Solaris의 경우 hme의 이름을 갖는다)
(2)	해당 인터페이스의 IP 설정
(3)	netmask 명령
(4)	넷마스크 값 설정
(5)	broadcast 명령
(6)	브로드캐스트 주소 설정

 

인터페이스 설정 후 ifconfig -a 명령을 실행하여 인터페이스의 상태를 확인하면, 다음과 같은 결과를 확인할 수 있다.

# ifconfig -a lo0: flag=849<UP, LOOPBACK, RUNNING, MULTICAST> mtu 8232           inet 127.0.0.1 netmask ff000000 hme0: flags=863<UP, BROADCAST, NOTRAILERS, RUNNINGS, MULTICAST> mtu 1500           inet 172.16.10.2 netmask ffffff00 broadcast 172.16.10.255           ether 8:0:20:a4:76:45

 

설정한 인터페이스(예: hme0)가 DOWN 상태로 표시된다면, 아래와 같은 명령을 사용하여 인터페이스를 활성화시킬 수 있다.

# ifconfig hme0 up

 

인터페이스를 활성화한 후, ifconfig -a hme0 명령을 사용하여 해당 인터페이스의 활성화 상태를 확인할 수 있다. 이를 통해 인터페이스가 정상적으로 작동하는지 확인할 수 있다.

 

- route(라우팅 추가, 삭제 명령)

#route	add	10.10.10.0	netmast 255.255.255.0	172.16.10.1	1
	(1)	(2)	(3)	(4)	(5)

(1)	add는 추가, delete는 삭제
(2)	목적지 네트워크나 32비트 호스트, 디폴트 게이트웨이를 정의할 때 default 명령 사용
(3)	목적지 네트워크의 netmask 값
(4)	목적지 네트워크로 향하기 위한 다음 홉 IP
(5)	라우팅 메트릭(Routing metric) 값

 

서버의 기본 게이트웨이 설정은 다음과 같다.

# route add default 172.16.10.1 1

 

 위 설정을 완료한 후, netstat -nr 명령을 실행하여 설정 내용을 확인할 수 있다. 인터페이스와 라우팅 설정은 시스템 재부팅 시 유실되므로, 설정을 저장하려면 시스템 설정 파일을 수정해야 한다. 이 부분은 시스템 관리자의 도움을 받는 것이 좋다.

 

 또한, arp -a 명령을 사용하여 설정된 라우팅 테이블의 ARP 정보가 정확히 캐시되는지 확인하면 서버의 네트워크 설정 과정이 완료된다.

 

(4) netstat -i

Name	Mtu	Net/Dest	Address	Ipkts	Ierrs	Opkts	Oerrs	Collis	Queue
lo0	8232	loopback	localhost	3012	0	3012	0	0	0
hme0	1500	10.1.1.0	jjang	321077	0	221307	0	0	0

Name	네트워크 인터페이스의 이름
Mtu	최대 전송 단위(바이트)
Net/Dest	네트워크 번호, /etc/inet/networks 파일을 참조
Address	인터페이스 IP 주소, /etc/inet/hosts 파일 참조
Ipkts/lerrs	입력되는 패킷의 수와 에러의 수
Opkts/Oerrs	출력되는 패킷의 수와 에러의 수
Collis	인터페이스상에서 발생한 충돌 프레임의 수
Queue	전송하기 위해 대기하고 있는 패킷의 수(항상 0, Zero가 정상이다)

 

 서버의 네트워크 상황을 충돌 비율(Collision Rate)로 판단할 수 있다. 충돌 비율은 네트워크 성능에 영향을 미치는 중요한 지표 중 하나로, 충돌이 빈번하게 발생하면 네트워크 성능이 저하될 수 있다. 충돌 비율을 계산하는 방법은 다음과 같다.

 

 충돌 비율(Collision Rate)의 상태에 따라 네트워크 성능을 평가할 수 있다. 충돌 비율이 02%이면 네트워크 상태가 양호한 것으로 간주되며, 35%이면 적당한 상태로 볼 수 있다. 그러나 5~10%의 충돌 비율은 네트워크에 문제가 발생하고 있음을 나타내며, 패킷 유실이 일어날 수 있다.