소개
네트워크 문제를 해결할 때는 한 번에 한 계층씩 확인하면 더 쉽습니다. 먼저 호스트의 정체성을 확인한 다음 인터페이스와 주소, 라우팅 선택, 기본 연결 가능성, 이름 해석, 수신 대기 소켓, 애플리케이션 응답, 마지막으로 로컬 방화벽 정책을 점검합니다.
이 실습에서는 Ubuntu 호스트에서 이 순서를 따릅니다. 미리 준비된 HTTP 서비스가 루프백 포트 8088에서만 수신 대기하므로 ss, curl, UFW 규칙을 안전하게 연습할 수 있습니다. 호스트의 인터페이스 설정, 기본 경로, DNS 설정 또는 SSH 서비스는 변경하지 않습니다. UFW 를 활성화하기 전에 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 옵션은 요청을 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 응답을 차례로 확인했습니다. 각 계층이 서로 다른 질문에 답하며, 한 경계에서 발생한 실패가 다음에 조사할 범위를 좁혀 준다는 점을 배웠습니다.
또한 SSH 액세스를 유지하고 실습 서비스 포트를 허용한 뒤 UFW 를 활성화했으며, 활성 정책과 애플리케이션 응답을 모두 확인했습니다. 이러한 습관을 익히면 광범위하고 중단을 일으킬 수 있는 변경 없이 네트워크 서비스를 진단하고 보호할 수 있습니다.
