서버 내부에서 프로세스가 잘 돌아가고 로그가 깨끗한데도 서비스 접속이 안 된다면, 이제는 시야를 밖으로 돌려야 할 때입니다. “내 서버는 준비됐는데, 왜 클라이언트는 못 들어올까?” 혹은 “우리 서버는 왜 저 외부 API 서버랑 말을 못 할까?” 같은 상황 말이죠.
오늘은 Rocky Linux의 표준 고정 IP 설정법과 더불어, 네트워크 장애의 범인을 끝까지 추적해 내는 nc, mtr 활용법을 정리해 보겠습니다.
1. Rocky Linux 고정 IP 부여: .nmconnection 방식
사실 예전엔 /etc/sysconfig/network-scripts/ 폴더 안의 ifcfg- 파일을 고치는 게 국룰이었죠. 하지만 Rocky Linux 8/9 버전부터는 NetworkManager의 keyfile(nmconnection) 형식이 표준이 되었습니다. CLI 환경에서 가장 깔끔하게 IP를 고정하는 방법입니다.
① 설정 파일 수정 (vi)
먼저 내 네트워크 카드 이름이 뭔지 ip addr 명령어로 확인한 뒤(보통 ens192 등), 해당 파일을 엽니다.
sudo vi /etc/NetworkManager/system-connections/ens192.nmconnection파일 안에서 [ipv4] 섹션을 찾아 아래처럼 고쳐주세요.
[ipv4]
method=manual
address1=192.168.1.100/24,192.168.1.1
dns=8.8.8.8;8.8.4.4;
② 설정 적용 (reload & up)
파일을 저장했다고 끝이 아닙니다. NetworkManager에게 “바뀐 내용을 읽어라”라고 시킨 뒤, 인터페이스를 다시 살려야 합니다.
# 1. 파일 변경 사항을 메모리에 로드
sudo nmcli connection reload
# 2. 인터페이스 활성화 (이때 실제 IP가 변경됩니다)
sudo nmcli con up ens192
2. 내 서버 문은 열려 있나? ss와 lsof
IP를 맞게 설정했다면, 이제 내 서비스가 포트에서 제대로 기다리고 있는지(Listen) 확인할 차례입니다.
ss -tulnp: 현재 열려 있는 모든 TCP/UDP 포트를 보여줍니다. 예전에 쓰던netstat보다 훨씬 빠르고 정확한 최신 표준 명령어입니다.
lsof -i :80: “내 80번 포트 누가 쓰고 있지?”라고 궁금할 때 씁니다. 범인(프로세스)을 콕 집어낼 때 아주 유용하죠.
3. 통신 장애 수사관: nc (Netcat)
상대방 서버에 접속이 안 될 때, 백날 ping만 날려봐야 소용없을 때가 많습니다. 보안상 ping은 막아둬도 서비스 포트는 열어두는 경우가 많거든요. 이때 **nc**는 “저쪽 서버 80번 문 열렸니?”라고 물어보는 가장 확실한 도구입니다.
- 포트 오픈 확인
# 상대방 서버(192.168.1.50)의 80번 포트가 열려 있는지 확인nc -zv 192.168.1.50 80-z: 데이터를 보내지 않고 스캔만 수행-v: 상세 결과 출력 (성공하면Succeeded혹은Connected가 뜹니다)
4. 경로 추적의 끝판왕: mtr (My Traceroute)
“중간에 패킷이 새나?”라는 의심이 들 때, 우리는 보통 traceroute를 씁니다. 하지만 **mtr**을 한 번 써보면 다시는 예전으로 못 돌아갑니다. ping과 traceroute를 합쳐서 실시간으로 보여주기 때문이죠.
- 사용법:
mtr 8.8.8.8 - 왜 좋은가? 내 서버부터 목적지까지 거치는 모든 구간(Hop)을 실시간으로 계속 핑을 날리며 보여줍니다. 어떤 지점에서 **Loss(손실)**가 발생하는지, 지연시간이 어디서 튀는지 한눈에 보입니다. 인프라 팀에 “우리 문제가 아니라 중간 경로인 이 업체 망에서 패킷이 빠집니다”라고 증거를 제시할 때 최고입니다.
5. [실습] 네트워크 연결성 검증 루틴
새 서버를 세팅했다면 아래 4단계를 습관처럼 해보세요.
# 1. 내 IP가 제대로 설정됐는지 확인
ip addr show ens192
# 2. 내 서버의 서비스 포트가 살아있나?
ss -tulnp | grep :80
# 3. 외부까지 나가는 길은 깨끗한가?
mtr -c 10 -r 8.8.8.8
# 4. 상대방 서버의 특정 포트로 통신이 가능한가?
nc -zv google.com 443
💡 엔지니어의 참견: “데이터는 가장 확실한 방어 수단입니다”
현업에서 장애가 발생하면 기술적 해결만큼이나 중요한 게 있습니다. 바로 **’책임 소재 파악’**이죠. 협업 과정에서 “이게 서버 문제냐, 네트워크 망 문제냐”를 가리는 일은 생각보다 비일비재합니다.
상대 팀에서 “서버 접속이 안 돼요”라고 할 때, 아무 근거 없이 “우리 쪽은 멀쩡한데요?”라고 답하면 감정 섞인 핑퐁 게임만 시작됩니다. 이때 오늘 배운 명령어들이 여러분의 강력한 무기가 됩니다. **
ss**로 우리 서비스가 살아있음을 보여주고, **nc**로 통신에 문제가 없음을 확인한 뒤,mtr결과값을 들이밀며 “보세요, 중간 경로인 외부 구간에서 패킷이 빠지고 있습니다”라고 말하는 거죠.이건 단순히 남 탓을 하려는 게 아닙니다. 정확한 데이터로 문제의 경계선을 그어주는 것입니다. 그래야 엉뚱한 곳에서 시간을 낭비하지 않고 진짜 원인을 찾아 빠르게 움직일 수 있습니다. 리눅스 실무에서 네트워크 명령어를 잘 다룬다는 건, 결국 불필요한 오해로부터 우리 팀의 결백을 증명하고 리소스를 지켜내는 기술이기도 합니다.
“이 글의 영문 버전은 [이곳]에서 확인하실 수 있습니다.”