LFCS 네트워킹 실습

IPv4/IPv6부터 reverse proxy/load balancer까지 8개 networking competency 기반 독립 연습 시나리오

이 과제는 공개된 기출문제나 실제 시험문제가 아니다. LFCS 공식 Networking 범위를 기준으로 독자적으로 만든 연습 시나리오이다. 네트워크를 변경하기 전 hypervisor snapshot·콘솔 접근·복구 경로를 먼저 확보하고, 대상 VM은 반드시 복원 가능한 상태에서 진행한다.

작성·검증 상태: AI가 문제·풀이 구조화를 보조했다. 예시 address·interface·connection·zone은 fixture와 대조했으며 전체 시나리오는 console이 있는 격리 VM에서 검증해야 한다.

DNS·NTP·HTTP backend와 원격 client가 필요한 문제는 2노드 실습 서비스를 먼저 준비한다. interface·connection 이름은 환경에서 확인하고 예시의 eth1, lab0을 실제 값으로 치환한다.

시나리오 원칙

각 과제는 단일 변경 단위로 실행하고, 변경 전/후 증거를 남긴다.

  • ip, ss, journalctl, systemctl, getent 등의 상태를 먼저 기록한다.
  • 운영 데이터 경로나 다른 실습 환경과 겹치면 다른 VM 또는 별도 네트워크 네임스페이스를 사용한다.
  • 임시 실습에만 적용하고 운영 SSH 정책·경로·방화벽은 별도 승인/변경관리 없이 적용하지 않는다.

공통 목표

  1. 변경 전 date, hostname, ip link, ip route, ss -lntp를 기록한다.
  2. 각 competency별 완료 조건을 텍스트로 증빙한다.
  3. 안전 주의 항목을 충족한 뒤에만 문제 해결 단계로 이동한다.

1) IPv4/IPv6와 hostname resolution 구성

문제

콘솔로 접근할 수 있는 격리된 eth1에 NetworkManager profile lab0을 만들고 IPv4 192.168.56.11/24, IPv6 2001:db8:56::11/64, gateway와 node2 DNS를 영구 설정하라. 실습 DNS에는 app.lab.example entry가 준비되어 있다고 가정한다.

완료 조건

  • IPv4·IPv6 주소와 기본 라우트가 각각 존재한다.
  • getent hosts가 이름 해석 결과를 반환한다.
  • ss -lntp로 의도한 서비스 포트가 리스닝 중이다.

안전 주의

  • 기존 인터페이스명을 먼저 확인하고, 다른 라우트와 충돌하지 않게 ip route 기반으로 설정한다.
  • 인터페이스를 재시작하면 연결이 끊길 수 있으므로 콘솔 연결 채널을 유지한다.
풀이 예시 
nmcli device status
nmcli connection show
nmcli connection add type ethernet ifname eth1 con-name lab0 \
  ipv4.method manual \
  ipv4.addresses 192.168.56.11/24 \
  ipv4.gateway 192.168.56.12 \
  ipv4.dns 192.168.56.12 \
  ipv4.route-metric 500 \
  ipv6.method manual \
  ipv6.addresses 2001:db8:56::11/64 \
  ipv6.gateway 2001:db8:56::12 \
  ipv6.dns 2001:db8:56::12 \
  ipv6.route-metric 500
nmcli connection up lab0
ip -br address show dev eth1
ip -4 route
ip -6 route
nmcli device show eth1
getent hosts app.lab.example
ss -lntp

2) 시간 동기화 구성

문제

NTP 동기화 동작을 점검하고, chrony 상태가 정상인지를 sources/tracking으로 확인한다.

완료 조건

  • timedatectl에서 NTP가 활성 상태다.
  • chronyc sources와 chronyc tracking에서 source 상태 및 오차가 확인된다.
  • 시간대가 기준값(예: Asia/Seoul)과 일치한다.

안전 주의

  • VM 시간이 심하게 어긋난 경우 인증서 검증/로그 분석 단계에 먼저 영향이 있으므로 먼저 기준 시간을 정리하고 시작한다.
  • 서비스 종료가 불가한 환경에서는 데몬 재시작 대신 상태 변경만 검증한다.
풀이 예시 
timedatectl status
timedatectl set-timezone Asia/Seoul
timedatectl set-ntp true
chronyc sources -v
chronyc tracking

service 상태는 배포판에 맞는 이름으로 확인한다.

# Rocky/RHEL
systemctl status chronyd

# Debian/Ubuntu
systemctl status chrony

3) 네트워크 모니터링/트러블슈팅

문제

서비스 접속이 안 되는 가상의 장애 상황에서, 링크→주소→라우트→DNS→socket→application 순으로 원인 후보를 1개 이상 도출한다.

완료 조건

  • ip link, ip addr, ip route, getent hosts, ss -lntp, ping 또는 nc 결과를 수집한다.
  • 장애 후보를 최소 2단계 이상 줄이고, 로그에서 시간축으로 근거를 남긴다.
  • 적용 가설(예: DNS 누락, 라우트 오기입, 서비스 미리스닝)을 문장으로 정리한다.

안전 주의

  • 장애 시뮬레이션이 과도하면 원격 접속이 끊길 수 있어 먼저 콘솔 경로를 확보한다.
  • 동시 변경은 금지하고 한 항목씩 되돌릴 수 있게 한다.
풀이 예시 
ip link show
ip -4 addr show
ip -4 route
ip route get 8.8.8.8
getent hosts api.internal
ss -lntp
ping -c 3 8.8.8.8
nc -vz 172.20.10.10 443
journalctl -u NetworkManager --since "15 min ago" --no-pager

4) OpenSSH client/server 설정

문제

node1 client에서 node2의 deploy 사용자로 키 로그인한 뒤, node2에서 root 직접 로그인과 비밀번호 인증을 제한하라. 기존 session을 유지한 채 새 키 session에서 최종 동작을 확인한다.

완료 조건

  • sshd -t와 배포판별 OpenSSH service 상태 확인이 통과한다.
  • sshd_config의 핵심 항목(PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, MaxAuthTries)이 정책대로 설정된다.
  • ssh 접속 테스트에서 예상 사용자/키 기반 동작과 host key 확인 동작이 기록된다.

안전 주의

  • 실습 전에 현재 관리자 계정의 키/로그인 경로를 기록하고 잠금 가능성을 줄인다.
  • PasswordAuthentication no 적용 전 임시로 기존 키를 검증한 뒤 적용한다.
풀이 예시

먼저 node2 콘솔에서 host key fingerprint를 확인하고 node1이 수집한 값과 비교한다. 확인되지 않은 host key를 무조건 신뢰하지 않는다.

# node2
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# node1
install -d -m 700 ~/.ssh
ssh-keyscan -t ed25519 node2 > /tmp/node2.hostkey
ssh-keygen -lf /tmp/node2.hostkey
# 위 두 fingerprint가 일치한 뒤에만 등록한다.
cat /tmp/node2.hostkey >> ~/.ssh/known_hosts
chmod 600 ~/.ssh/known_hosts
ssh-keygen -t ed25519 -f ~/.ssh/lfcs_deploy
ssh-copy-id -i ~/.ssh/lfcs_deploy.pub deploy@node2
ssh -i ~/.ssh/lfcs_deploy -o IdentitiesOnly=yes deploy@node2 id

node2에서 정책을 적용한다.

install -d -m 755 /etc/ssh/sshd_config.d
cat > /etc/ssh/sshd_config.d/lfcs.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 4
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2
EOF
sshd -t
sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries|logingracetime'

# node1의 별도 새 session
ssh -i ~/.ssh/lfcs_deploy -o IdentitiesOnly=yes deploy@node2 id

구문 검사가 통과한 뒤 배포판에 맞는 service를 reload하고 로그를 확인한다.

# Rocky/RHEL
systemctl reload sshd
journalctl -u sshd -n 20 --no-pager

# Debian/Ubuntu
systemctl reload ssh
journalctl -u ssh -n 20 --no-pager

5) packet filtering, port redirection, NAT

문제

node2의 8080/tcp 요청을 이미 동작 중인 fixture backend 8081/tcp로 redirection하라. runtime과 permanent 규칙을 일치시키고 node1의 실제 요청으로 검증한다.

완료 조건

  • 룰 확인 시 NAT/포워딩 규칙이 의도대로 존재한다.
  • 80/tcp 요청이 8080/tcp 서비스의 응답으로 연결된다.
  • nft(또는 firewalld) 변경 전후 상태를 비교한다.

안전 주의

  • 외부 접근 테스트는 임시 전용 포트/허용 IP로 범위를 제한한다.
  • 룰을 영구/런타임 모두 일치시키되, 적용 직후 즉시 복구 명령을 준비한다.
풀이 예시 
private_connection='PRIVATE_CONNECTION'
firewall-cmd --state
firewall-cmd --get-active-zones
firewall-cmd --list-all
ss -lntp | grep ':8081'
nmcli connection modify "$private_connection" connection.zone public
nmcli connection up "$private_connection"
firewall-cmd --permanent --zone=public --add-forward-port=port=8080:proto=tcp:toport=8081
firewall-cmd --reload
firewall-cmd --zone=public --list-forward-ports
nft list ruleset
# node1에서 실행: curl http://192.168.56.12:8080/

6) 정적 라우팅

문제

NetworkManager profile lab0에 198.51.100.0/24의 next hop 192.168.56.12를 영구 추가하고 기본 경로와 충돌이 없는지 검증한다.

완료 조건

  • ip route에 대상 대역 라우트가 존재한다.
  • ip route get <목적지> 결과에서 기대 인터페이스/next hop이 표시된다.
  • 기존 기본 라우트와 충돌하지 않고, 정책이 정상 통과한다.

안전 주의

  • 기본 라우트(default)는 신중하게 추가하고, 변경 전후 route table을 캡처한다.
  • 동일 목적지에 duplicate route가 생기지 않도록 미리 확인한다.
풀이 예시 
ip route
nmcli connection modify lab0 +ipv4.routes '198.51.100.0/24 192.168.56.12'
nmcli connection up lab0
nmcli -f ipv4.routes connection show lab0
ip route get 198.51.100.1
ping -c 2 198.51.100.1

7) bridge·bond 구성

문제

추가 NIC eth2·eth3·eth4가 있는 격리 VM에서 NetworkManager로 bridge와 active-backup bond를 구성하고 각 논리 interface에 주소를 둔다.

완료 조건

  • 브릿지 인터페이스(br0)와 포트 멤버(eth2)가 확인된다.
  • bond0와 slave 인터페이스 상태가 연결되어 있고 carrier가 감지된다.
  • 주소는 브릿지 또는 bond 인터페이스에 할당되고, ip -br link에서 논리 인터페이스 상태를 확인한다.

안전 주의

  • 기존 VM NIC 이름이 다를 수 있어 대상 인터페이스명 확인이 필수다.
  • IP를 slave에 직접 설정하는 실수를 피하고, 논리 인터페이스에 주소를 둔다.
풀이 예시 
nmcli connection add type bridge ifname br0 con-name br0 \
  ipv4.method manual ipv4.addresses 192.0.2.50/24
nmcli connection add type ethernet ifname eth2 con-name br0-eth2 controller br0
nmcli connection modify br0 connection.autoconnect-ports 1
nmcli connection up br0
nmcli connection up br0-eth2
ip -br link show br0
ip -br link show eth2
ip -br address show br0
nmcli connection add type bond ifname bond0 con-name bond0 \
  bond.options 'mode=active-backup,miimon=100' \
  ipv4.method manual ipv4.addresses 198.51.100.50/24
nmcli connection add type ethernet ifname eth3 con-name bond0-eth3 controller bond0
nmcli connection add type ethernet ifname eth4 con-name bond0-eth4 controller bond0
nmcli connection modify bond0 connection.autoconnect-ports 1
nmcli connection up bond0
nmcli connection up bond0-eth3
nmcli connection up bond0-eth4
ip -br link show bond0
ip -br link show eth3
ip -br link show eth4
cat /proc/net/bonding/bond0

8) reverse proxy·load balancer

문제

Nginx를 reverse proxy로 두고 서로 다른 응답을 내는 두 backend에 대한 round-robin과 passive failure 처리를 점검한다.

완료 조건

  • nginx 문법 검사(nginx -t)가 통과한다.
  • 한 backend가 비정상일 때 다른 backend로 재시도되고, 둘 다 비정상이면 502 응답이 발생한다.
  • 설정 변경 전후 access/error log에서 상태 변화가 확인된다.

안전 주의

  • 운영 포트를 직접 변경하지 않는다.
  • 백엔드 주소/포트 오입력은 즉시 502로 이어질 수 있어 먼저 루프백 테스트로 검증한다.
풀이 예시 
upstream api_pool {
    server 192.168.56.12:8081 max_fails=1 fail_timeout=10s;
    server 192.168.56.12:8082 max_fails=1 fail_timeout=10s;
}

server {
    listen 8080;
    server_name _;

    location / {
      proxy_pass http://api_pool;
      proxy_set_header Host $host;
      proxy_next_upstream error timeout http_502 http_503;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
nginx -t
systemctl reload nginx
systemctl status nginx
journalctl -u nginx -n 40 --no-pager
curl http://192.168.56.12:8081/
curl http://192.168.56.12:8082/
curl -I http://localhost:8080/

공통 복구 포인트

문제 발생 시 다음 순서를 역순으로 점검한다.

  1. ip route, ip link, ip -br address로 핵심 상태 복원.
  2. systemctl과 journalctl로 데몬/로그 문제 확인.
  3. firewalld/nftables 정책은 원복 가능한 백업 규칙을 적용해 재적용.
  4. hypervisor 콘솔로 직접 접근해 서비스 접근성을 검증한 뒤 snapshot으로 복구.

참고