소개
네트워크 문제를 해결할 때는 한 번에 한 계층씩 확인하는 것이 가장 효율적입니다. 먼저 호스트의 식별 정보를 확인한 다음, 네트워크 인터페이스와 주소, 라우팅 경로, 기본 연결 상태, 이름 해석, 수신 대기 소켓, 애플리케이션 응답, 마지막으로 로컬 방화벽 정책을 점검합니다.
이 실습에서는 Ubuntu 호스트에서 이 순서대로 진단을 진행합니다. 미리 준비된 HTTP 서비스가 루프백 포트 8088에서만 수신 대기하므로 ss, curl, UFW 규칙을 안전하게 연습할 수 있습니다. 호스트의 인터페이스 설정, 기본 경로, DNS 설정 또는 SSH 액세스는 변경하지 않습니다.
호스트 식별하기
이 단계에서는 프로그램이 현재 시스템을 식별하는 데 사용하는 호스트 이름과 로컬 이름 레코드를 확인합니다.
실습 작업 공간으로 이동합니다.
cd /home/labex/project/network-lab
현재 호스트 이름을 출력합니다.
hostname
systemd 가 인식하는 정적 호스트 이름, 임시 호스트 이름 및 운영 체제 식별 정보를 표시합니다.
hostnamectl
Static hostname은 설정된 이름을 의미합니다. 클라우드 실습 환경에서는 부팅 중에 임시 호스트 이름이 지정될 수 있습니다.
로컬 호스트 매핑을 확인합니다.
cat /etc/hosts
루프백 이름인 localhost, 127.0.0.1, ::1은 외부 네트워크를 사용하지 않고도 동일한 호스트를 가리킵니다. 호스트에 할당된 IP 주소를 간결하게 표시합니다.
hostname -I
호스트 이름과 주소 목록을 저장합니다.
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
인터페이스와 IP 주소 확인하기
이 단계에서는 네트워크 인터페이스, 링크 상태, IPv4 주소, 접두사 및 주소 범위를 확인합니다.
간략한 링크 정보를 표시합니다.
ip -brief link
lo는 루프백 인터페이스입니다. 일반적으로 eth0 또는 ens...라는 이름을 가진 다른 인터페이스가 VM 을 네트워크에 연결합니다. UP은 인터페이스가 관리상 활성화되어 있음을 의미합니다.
주소 정보를 간결하게 표시합니다.
ip -brief address
192.0.2.10/24와 같은 주소는 IPv4 주소와 접두사 길이를 함께 나타냅니다. 접두사는 로컬 네트워크를 식별하는 선행 비트의 범위를 의미합니다.
루프백 인터페이스의 전체 정보를 확인합니다.
ip address show dev lo
IPv4 주소 127.0.0.1/8에는 scope host가 지정되어 있으므로 이 호스트 내부에서만 유효합니다. 기본 경로에 사용되는 인터페이스를 확인합니다.
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
ifconfig는 오래된 인터페이스 도구이지만 기존 운영 문서와 문제 해결 안내에서 여전히 자주 볼 수 있습니다. 방금 확인한 최신 ip 출력과 비교합니다.
ifconfig
기존 형식의 출력도 저장합니다.
ifconfig > ifconfig-addresses.txt
간략한 인터페이스 정보를 저장합니다.
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
라우팅 테이블 확인하기
이 단계에서는 기본 게이트웨이를 확인하고 Linux 가 특정 목적지에 도달할 때 사용할 경로를 조회합니다.
기본 라우팅 테이블을 표시합니다.
ip route
연결된 경로는 직접 연결된 네트워크를 나타냅니다. default via로 시작하는 행은 더 구체적인 경로가 없을 때 사용됩니다.
공용 목적지에 도달하기 위해 커널이 선택할 경로를 조회합니다. 이 명령은 패킷을 전송하지 않고 선택된 게이트웨이, 인터페이스 및 출발지 주소를 보여 줍니다.
ip route get 1.1.1.1
기본 게이트웨이와 인터페이스를 추출합니다.
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
라우팅 요약 정보를 저장합니다.
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
네트워크 연결성 테스트하기
이 단계에서는 ping을 사용해 점점 더 먼 네트워크 경계를 테스트하면서, 일부 네트워크가 진단 패킷을 차단할 수 있다는 점도 확인합니다.
먼저 루프백을 테스트합니다. -c 2 옵션은 요청을 두 번 보내고, -W 2 옵션은 각 응답을 최대 2 초 동안 기다립니다.
ping -c 2 -W 2 127.0.0.1
루프백 테스트가 성공하면 로컬 IP 스택이 정상적으로 응답한다는 뜻입니다. 다음으로 기본 게이트웨이를 확인하고 테스트합니다.
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
라우터가 트래픽을 전달하면서도 ping 에는 응답하지 않을 수 있으므로 대체 메시지도 중요합니다. DNS 에 의존하지 않고 공용 IP 주소를 테스트합니다.
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
외부 네트워크 정책에 영향을 받지 않는 안정적인 로컬 연결 결과를 저장합니다.
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
호스트 이름 해석 테스트하기
이 단계에서는 이름 해석기 설정을 확인하고 호스트 이름을 주소로 변환합니다.
표준 Linux 애플리케이션이 사용하는 이름 해석 설정 파일을 확인합니다.
cat /etc/resolv.conf
일반적으로 하나 이상의 nameserver 행이 포함되어 있습니다. systemd-resolved 를 사용하는 호스트에서는 이 주소가 외부 DNS 서버가 아니라 로컬 스텁 이름 해석기를 가리킬 수 있습니다.
시스템의 전체 이름 서비스 설정을 사용해 로컬 이름을 해석합니다.
getent hosts localhost
getent는 /etc/nsswitch.conf 설정을 따르므로 /etc/hosts, DNS 및 기타 구성된 소스를 함께 사용할 수 있습니다. 외부 이름을 해석하고 IPv4 소켓 주소를 요청합니다.
getent ahostsv4 example.com
IP 주소에 대한 ping 은 성공하지만 이 조회가 실패한다면 이름 해석기 설정 또는 DNS 연결성을 중점적으로 확인해야 합니다. 해석된 첫 번째 IPv4 레코드를 저장합니다.
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
수신 대기 포트와 HTTP 응답 확인하기
이 단계에서는 수신 대기 중인 TCP 소켓을 해당 프로세스와 연결하고 애플리케이션 프로토콜을 테스트합니다.
준비된 데모 서비스는 루프백 포트 8088에서 수신 대기합니다. ss를 사용해 수신 대기 중인 TCP 소켓을 확인합니다. -l, -t, -n, -p 옵션은 각각 수신 대기, TCP, 숫자 형식 주소, 프로세스 정보를 의미합니다.
sudo ss -ltnp | grep ':8088'
127.0.0.1:8088이 표시되는지 확인합니다. 루프백에 바인딩되어 있다는 것은 이 서비스가 현재 호스트에서만 접근 가능하다는 뜻입니다.
소켓을 사용하는 서비스 프로세스를 확인합니다.
systemctl status labex-network-demo.service --no-pager
curl -i를 사용해 HTTP 응답 헤더와 본문을 표시합니다.
curl -i http://127.0.0.1:8088/
HTTP 200 OK 상태는 포트가 열려 있다는 사실 이상을 의미합니다. 애플리케이션이 HTTP 요청을 받아 콘텐츠를 반환했다는 뜻입니다. 자동 출력 억제 모드인 -s를 사용해 응답 본문만 저장합니다.
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
접근을 유지하고 UFW 활성화하기
이 단계에서는 UFW 상태를 확인하고, 원격 관리 접근을 유지하며, 연습용 서비스 포트를 허용한 다음 방화벽을 활성화합니다.
UFW 는 Linux 패킷 필터링 규칙을 관리하는 프런트엔드입니다. 현재 상태를 확인합니다.
sudo ufw status verbose
준비 과정은 UFW 를 비활성 상태와 깨끗한 규칙 집합으로 둡니다. 호스트 방화벽을 원격으로 활성화하기 전에 사용 중인 관리 경로를 먼저 허용해야 합니다. 이 VM 은 SSH 에 TCP 포트 22를 사용합니다.
sudo ufw allow 22/tcp
이제 연습용 서비스 포트로 들어오는 TCP 트래픽을 허용합니다.
sudo ufw allow 8088/tcp
활성화하기 전에 준비된 변경 사항을 검토합니다.
sudo ufw show added
대화형 확인 없이 UFW 를 활성화합니다.
sudo ufw --force enable
방화벽이 활성 상태이고 두 허용 규칙이 모두 있는지 확인합니다.
sudo ufw status verbose
서비스는 루프백 주소에 바인딩되어 있으므로 방화벽 변경 후 로컬에서 테스트합니다.
curl -fsS http://127.0.0.1:8088/
활성 상태를 확인 가능한 결과로 저장합니다.
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
순서가 중요합니다. 관리 경로를 유지하고 필요한 서비스 규칙을 추가한 다음 방화벽을 활성화하고 정책과 애플리케이션 접근성을 즉시 확인하세요. 운영 호스트는 다른 SSH 포트를 사용할 수 있으므로 포트 22라고 가정하지 말고 실제 관리 경로를 확인해야 합니다.
요약
구조화된 Linux 네트워크 진단 절차를 따라 호스트 식별 정보, 인터페이스와 IP 주소, 경로 선택, 연결성, 이름 해석, 수신 대기 소켓 및 HTTP 응답을 차례로 확인했습니다. 각 계층이 서로 다른 질문에 답하며, 특정 경계에서 문제가 발생하면 다음에 조사할 범위를 좁힐 수 있다는 점도 배웠습니다.
또한 UFW 상태를 확인하고 원격 접속을 위험에 빠뜨리지 않으면서 루프백 범위로 제한된 규칙을 안전하게 관리했습니다. 이러한 습관은 광범위하고 중단을 일으킬 수 있는 변경 없이 네트워크 서비스를 진단하고 보호하는 데 도움이 됩니다.
