DAY 07: 네트워크 네비게이터

LinuxBeginner
지금 연습하기

소개

네트워크 네비게이터가 되신 것을 환영합니다! 여러분은 이제 막 급성장 중인 기술 스타트업의 주니어 시스템 관리자로 채용되었습니다. 오늘 아침, 회사의 중요한 웹 서버가 다운되었습니다. 사용자들은 사내 포털에 접속할 수 없다고 보고하고 있습니다.

선임 관리자가 회의로 자리를 비운 사이, 여러분에게 초기 진단 업무가 맡겨졌습니다. 이제 여러분의 실력을 보여줄 때입니다! 여러분의 임무는 서버의 네트워크 상태를 체계적으로 조사하고, 근본 원인을 찾아내어 연결을 복구하는 것입니다. 서버를 다시 온라인 상태로 되돌려 봅시다!

중요 공지
이번 챌린지는 Quick Start with Linux 과정의 범위를 벗어날 수 있습니다.
챌린지 수행 중 어려움을 겪는다면:
  1. 잠시 챌린지를 건너뛰고 Linux 학습 경로의 다음 가이드 실습을 계속 진행하세요.
  2. Labby 와 상담하거나 솔루션을 확인하세요.

네트워크 인터페이스 상태 확인

네트워크 네비게이터로서의 첫 번째 단계는 기초 정보를 수집하는 것입니다. 네트워크 하드웨어가 제대로 인식되고 활성화되어 있는지 확인해야 합니다. 서버의 모든 네트워크 인터페이스 상태를 점검해 보세요. 이 작업에 가장 적합한 최신 도구는 ip 명령어입니다.

과제

  • ip 명령어를 사용하여 모든 네트워크 인터페이스의 상태와 구성을 표시하세요.

요구 사항

  • 이 점검을 수행하기 위해 반드시 ip addr 명령어를 사용해야 합니다.

예시

명령어를 실행하면 lo (루프백) 및 eth0 (또는 이와 유사한 이름) 와 같은 네트워크 인터페이스가 출력됩니다. 주 인터페이스의 상태를 확인하세요. 활성 상태임을 나타내는 UP이 표시되어야 합니다.

## 예상 출력 형식 (인터페이스 이름은 다를 수 있음)
1: lo: 65536 qdisc noqueue state UNKNOWN group default qlen 1000 < LOOPBACK,UP,LOWER_UP > mtu
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: 1500 qdisc mq state UP group default qlen 1000 < BROADCAST,MULTICAST,UP,LOWER_UP > mtu
link/ether 00:16:3e:04:b0:40 brd ff:ff:ff:ff:ff:ff
inet 172.16.50.108/24 metric 100 brd 172.16.50.255 scope global dynamic eth0
valid_lft 1892159216sec preferred_lft 1892159216sec

힌트

  • ip 명령어는 많은 하위 명령을 가진 강력한 도구입니다. 주소를 관리하는 하위 명령은 addr입니다.
  • ip addr show를 사용하거나 더 짧은 별칭인 ip addr을 사용할 수 있습니다.

IP 주소 설정 확인

인터페이스가 UP 상태인 것을 확인했습니다. 좋은 시작입니다. 하지만 IP 주소가 할당되어 있나요? IP 주소가 없는 인터페이스는 네트워크에서 통신할 수 없습니다. ip addr로도 확인할 수 있지만, 교차 검증을 위해 또 다른 고전적인 도구인 ifconfig를 사용해 봅시다. 동일한 작업을 위해 여러 도구를 익혀두는 것이 좋습니다.

과제

  • ifconfig 명령어를 사용하여 IP 주소 설정을 확인하세요.

요구 사항

  • 반드시 ifconfig 명령어를 사용해야 합니다.

예시

출력 결과에 네트워크 인터페이스와 해당 IP 주소가 표시되어야 합니다. 주 네트워크 인터페이스 (예: eth0) 아래의 inet 필드를 찾아 IP 설정이 되어 있는지 확인하세요.

## IP 설정이 표시된 예상 출력
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.50.108  netmask 255.255.255.0  broadcast 172.16.50.255
        ether 00:16:3e:04:b0:40  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0

힌트

  • ifconfig 명령어는 net-tools 패키지의 일부이며, 이미 설치되어 있습니다.
  • 인자 없이 ifconfig를 실행하면 활성화된 모든 인터페이스가 표시됩니다.

원격 호스트 연결 테스트

서버에 활성 인터페이스와 IP 주소가 있음을 확인했습니다. 다음 단계는 외부 세계와 통신이 가능한지 확인하는 것입니다. 여기서 실패한다면 게이트웨이나 DNS 설정에 문제가 있을 수 있습니다. ping 명령어는 이 테스트에 가장 완벽한 도구입니다.

과제

  • 구글의 공용 DNS 서버인 8.8.8.8로 정확히 3 개의 ICMP 패킷을 보내 서버의 인터넷 연결을 테스트하세요.

요구 사항

  • 반드시 ping 명령어를 사용해야 합니다.
  • 전송되는 패킷의 수를 3 개로 제한해야 합니다.
  • 대상 IP 주소는 8.8.8.8이어야 합니다.

예시

연결이 정상이라면 대상 IP 주소로부터 응답 시간 정보가 포함된 회신을 받게 됩니다. 마지막 요약 부분에는 3 개의 패킷이 전송되고 3 개가 수신되어 패킷 손실이 0% 로 표시되어야 합니다.

## 성공적인 출력 패턴 예시
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=4.33 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=4.30 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=4.30 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.298/4.309/4.329/0.014 ms

힌트

  • ping 명령어는 중단하지 않으면 무한히 실행됩니다.
  • -c 옵션을 사용하여 보낼 패킷의 횟수 (count) 를 지정하세요.

열린 네트워크 포트 조사

연결 상태는 양호합니다! 그런데 왜 사내 포털에 여전히 접속할 수 없을까요? 문제는 애플리케이션 자체에 있을 수 있습니다. 웹 서버 프로세스가 실제로 실행 중이며 올바른 포트에서 연결을 대기하고 있나요? ss (socket statistics) 명령어는 이를 조사하기 위한 현대적이고 빠른 도구입니다.

과제

  • 사내 포털은 8000번 포트에서 실행되어야 합니다. ss 명령어를 사용하여 8000번 포트에서 TCP 연결을 대기 (listening) 중인 프로세스가 있는지 확인하세요.

요구 사항

  • 반드시 ss 명령어를 사용해야 합니다.
  • 대기 중인 TCP 소켓을 표시하도록 명령어를 구성해야 합니다.

예시

8000 번 포트에서 대기 중인 프로세스가 있다면, 해당 소켓에 대한 정보가 포함된 출력이 나타납니다. Local Address 열에 8000 번 포트가 표시된 줄을 찾으세요.

## 8000번 포트에서 대기 중인 프로세스를 보여주는 예상 출력
LISTEN 0      5            0.0.0.0:8000       0.0.0.0:*    users:(("python3",pid=3765,fd=3))

힌트

  • ss 명령어에는 유용한 플래그들이 있습니다:
    • -t: TCP 소켓을 표시합니다.
    • -l: 대기 중인 (listening) 소켓을 표시합니다.
    • -n: 서비스 이름 대신 숫자로 된 포트 번호를 표시합니다.
    • -p: 소켓을 사용하는 프로세스 (process) 를 표시합니다.
  • 이 플래그들을 조합하여 ss -tlnp와 같이 사용할 수 있습니다.
  • 특정 포트를 찾으려면 ss의 출력을 grep 명령어로 전달 (pipe) 하면 됩니다. 예: ss -tlnp | grep 8000.

기본 방화벽 규칙 구성

모든 것을 확인했습니다. 인터페이스는 활성화되어 있고, IP 도 설정되었으며, 인터넷 연결도 작동하고, 애플리케이션도 올바른 포트에서 대기 중입니다. 이제 남은 용의자는 단 하나, 방화벽입니다. 방화벽이 포털로 들어오는 트래픽을 차단하고 있을 가능성이 큽니다. 마지막 과제는 포털에 대한 접근을 거부하도록 방화벽을 설정하는 것입니다. 방화벽 규칙 관리를 위한 사용자 친화적인 도구인 ufw (Uncomplicated Firewall) 를 사용하겠습니다.

과제

  1. 8000번 포트로 들어오는 트래픽을 거부 (deny) 하는 방화벽 규칙을 추가하세요.
  2. 들어오는 SSH 트래픽 (22 번 포트) 을 허용 (allow) 하는 방화벽 규칙을 추가하세요.
  3. 방화벽을 활성화하여 새로운 규칙을 적용하세요.

요구 사항

  • 모든 작업에 ufw 명령어를 사용해야 합니다.
  • 방화벽 규칙 수정에는 관리자 권한이 필요하므로 sudo를 사용해야 합니다.

예시

방화벽 규칙을 구성한 후 sudo ufw status를 실행하면 방화벽이 활성 상태이며 8000 번 포트는 거부되고 SSH(22 번 포트) 는 허용된 것으로 표시되어야 합니다.

## 8000번 포트 거부 및 SSH 허용 설정 후의 예상 출력
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
8000                       DENY        Anywhere
22 (v6)                    ALLOW       Anywhere (v6)
8000 (v6)                  DENY        Anywhere (v6)

규칙을 추가할 때 다음과 같은 메시지가 표시되어야 합니다:

Rules updated
Rules updated (v6)

방화벽을 활성화할 때 다음과 같은 메시지가 표시되어야 합니다:

Firewall is active and enabled on system startup

힌트

  • ufw 문법은 매우 직관적입니다. 특정 포트의 트래픽을 거부하려면 ufw deny <port>를 사용합니다.
  • ufw deny 8000을 사용하여 8000 번 포트의 트래픽을 거부할 수 있습니다.
  • ufw allow ssh 또는 ufw allow 22를 사용하여 SSH 트래픽을 명시적으로 허용할 수 있습니다.
  • 치명적 경고: SSH 포트 (22) 를 제대로 열지 않으면, 검증 시스템이 SSH 연결을 통해 작동하므로 검증에 실패하게 됩니다.
  • 중요 경고: 다른 포트의 방화벽 규칙을 임의로 수정하지 마세요. 온라인 가상 머신에 장애가 발생할 수 있습니다.
  • 규칙을 추가한 후에는 반드시 ufw enable로 방화벽을 활성화해야 합니다.

요약

훌륭합니다, 네비게이터님! 네트워크 인터페이스 점검, IP 설정 확인, 연결 테스트, 포트 조사, 그리고 마지막으로 방화벽 구성까지 체계적으로 수행하여 문제를 성공적으로 진단하고 해결했습니다. 이제 사내 포털이 다시 온라인 상태가 되었으며, 팀원들의 신뢰를 얻게 되었습니다.

여러분은 ip, ifconfig, ping, ss, ufw와 같은 리눅스 네트워크 기본 도구들을 능숙하게 다루는 모습을 보여주었습니다. 이러한 논리적이고 단계적인 트러블슈팅 과정은 시스템 관리자에게 필수적인 역량이며, 앞으로의 커리어에 큰 자산이 될 것입니다. 계속해서 실력을 갈고닦으세요!

✨ 솔루션 확인 및 연습✨ 솔루션 확인 및 연습✨ 솔루션 확인 및 연습✨ 솔루션 확인 및 연습✨ 솔루션 확인 및 연습