LFCS 네트워킹 핵심 정리

IPv4/IPv6 및 호스트네임 해석부터 reverse proxy/load balancer까지 Networking 8개 competency를 공식 범위 중심으로 정리한다

이 문서는 공식 Networking 8개 competency의 개념 층이다. management connection을 보존하면서 실제 client/server 동작을 확인하려면 2노드 실습 환경과 실습 fixture를 먼저 준비한다.

작성·검증 상태: AI가 구조화와 설명 초안을 보조했다. 현재 NetworkManager·firewalld upstream 문법과 대조했으며, interface·connection·zone 이름은 실습 VM의 실제 상태로 치환한다.

이 영역을 끝내는 순서

  1. 모든 장애를 link → address → route → name resolution → socket → application으로 좁힌다.
  2. 네트워킹 안내형 lab에서 console과 복구 snapshot을 확보한 채 변경한다.
  3. 환경을 초기화하고 영문 단계별 실전을 풀이 없이 수행한다.
  4. IPv4·IPv6, runtime·persistent, local redirect·DNAT, bridge·bond 조건을 바꿔 다시 푼다.

완료 기준은 profile이나 rule 존재가 아니라 별도 client의 positive·negative request, 선택 route, listening socket, backend failover와 management path 보존까지 확인하는 것이다.

공식 LFCS Networking 영역의 8개 competency는 IPv4/IPv6·hostname resolution, 시간 동기화, 네트워크 모니터링/트러블슈팅, OpenSSH client·server, packet filtering/port redirection/NAT, 정적 라우팅, bridge·bonding, reverse proxy/load balancer이다. 각 항목은 링크 → 주소 → route → 이름 해석 → socket → application 순서로 연결한다. 예시 주소·인터페이스 이름은 자신의 격리된 실습망에 맞게 바꾼다.

1) IPv4/IPv6 및 hostname resolution

LFCS 공식 목표는 주소를 할당하는 동작과 이름 해석이 단절되지 않게 유지하는 것이다.

핵심 개념

  • IPv4/IPv6 주소는 동일 인터페이스에서 독립적으로 관리되며, ip addr show로 현재 상태를 본다.
  • 게이트웨이(라우팅)는 ip route로 확인하고, ip -6 route로 v6 경로를 함께 점검한다.
  • hostname과 이름 해석은 hostnamectl, /etc/hosts, NSS 순서(/etc/nsswitch.conf), DNS 설정을 나눠 본다. 최종 결과는 getent hosts로 확인한다.
  • 운영 배포판은 NetworkManager 기본 여부와 영구 설정 방식이 달라서, 같은 구성도 작성 위치는 달라질 수 있다.

연결 플로우

문제 원인을 찾을 때는 다음 우선순위로 좁힌다.

  1. Link: 인터페이스 상태 (ip link)
  2. Address: IP 주소와 주소영역 (ip addr)
  3. Route: 기본 경로/도달 경로 (ip route, ip -6 route)
  4. DNS: 이름 해석 (getent hosts, resolvectl status)
  5. Socket: 서비스 바인딩 (ss -lntp)
  6. Application: 실제 응답 (curl, nc)

예시 구성(공식 범위 기반 예시)

ip -4 addr show
ip -6 addr show
ip -4 route
ip -6 route
hostnamectl status
getent hosts "$(hostname)"
resolvectl status
getent hosts example.net
ss -lntp

배포판 차이

  • Rocky/Alma/RHEL 계열은 기본적으로 NetworkManager가 일반적이어서 nmcli/nmtui 영구화가 편하다.
  • Debian 계열은 환경에 따라 NetworkManager 또는 /etc/network/interfaces 계열 구성이 쓰일 수 있다.

NetworkManager 예시:

nmcli connection show
nmcli connection modify "Wired connection 1" ipv4.addresses 192.168.10.20/24 ipv4.gateway 192.168.10.1 ipv4.method manual ipv6.method ignore
nmcli connection up "Wired connection 1"

2) 시간 동기화

시간 동기화 실패는 인증서/로그/오류 타임스탬프 분석을 오작동하게 만든다. timedatectl은 상태를 빠르게 확인하고, Chrony는 운영 동기화 경로를 잡는다.

핵심 개념

  • timedatectl로 시간대·NTP 활성 상태를 확인한다.
  • chronyc로 동기화 소스와 오프셋을 확인한다.
  • 방화벽에서 NTP 포트(udp/123)는 필요 시 허용되어야 한다.

확인 예시

timedatectl status
timedatectl set-timezone Asia/Seoul
timedatectl set-ntp true
chronyc sources -v
chronyc tracking

Chrony service 이름은 Rocky/RHEL 계열에서 chronyd, Debian/Ubuntu 계열에서 chrony다.

# Rocky/RHEL
systemctl status chronyd

# Debian/Ubuntu
systemctl status chrony

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

네트워크 문제는 보통 링크→주소→경로→DNS→socket→애플리케이션 순으로 좁히면 증상 후보가 안정적으로 줄어든다.

핵심 개념

  • 링크가 살아 있어도 DNS 설정 오류면 이름 해석이 멈출 수 있다.
  • 주소는 있어도 라우팅 선택이 안 맞으면 목적지로 못 가고, socket은 listening 자체가 없어도 application 레이어에서는 실패로 보인다.
  • ss는 프로세스 바인딩 상태 확인용, ip monitor는 경로/주소 변경 감시용으로 구분 사용한다.

점검 순서 예시

ip link show
ip -4 addr show
ip -4 route get 8.8.8.8
getent hosts mirror.example.com
ss -lntp
ping -c 3 api.example.internal
nc -vz 10.0.10.20 443
journalctl -u NetworkManager --since "20 min ago"

4) OpenSSH client·server

서버 프로세스가 떠 있는 것과 원하는 인증 정책으로 실제 로그인할 수 있는 것은 다르다.

핵심 개념

  • server는 sshd_config와 authorized_keys, key 정책이 핵심이다.
  • client는 host key 신뢰(~/.ssh/known_hosts)와 키 우선 인증을 기본으로 둔다.
  • PermitRootLogin, PasswordAuthentication, PubkeyAuthentication, MaxAuthTries, LoginGraceTime은 인증 정책이다.
  • ClientAliveInterval과 ClientAliveCountMax는 응답 없는 session을 정리하는 동작이지 인증 시도 제한을 대신하지 않는다.

최소 점검 항목

sshd -t
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

OpenSSH service 이름은 Rocky/RHEL 계열에서 sshd, Debian/Ubuntu 계열에서 ssh다.

# Rocky/RHEL
systemctl status sshd
journalctl -u sshd -n 80 --no-pager

# Debian/Ubuntu
systemctl status ssh
journalctl -u ssh -n 80 --no-pager

정책 예시

다음처럼 접근을 강화하기 전에는 일반 사용자 키 로그인을 별도 session에서 먼저 성공시키고 기존 복구 session을 유지한다.

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 4
LoginGraceTime 30s
ClientAliveInterval 300
ClientAliveCountMax 2

5) Packet filtering, port redirection, NAT

firewalld와 nftables는 목적과 계층이 다르다.

nftables vs firewalld (개념 구분)

  • nftables: 패킷 필터링/변환 규칙의 핵심 엔진(표, 체인, 규칙) 개념에 가깝다.
  • firewalld: nftables/iptables를 추상화해 zone·서비스·영구화 편의를 제공한다.
  • 실무/시험에서는 “동작은 영구/런타임”, “실패 로그에서 룰 경로가 어디까지 반영되었는지”를 구분해야 한다.

기본 확인/변경 흐름

ip rule
firewall-cmd --state
firewall-cmd --list-all
nft list ruleset

예시: TCP 포트 리디렉션/포트 노출

# 같은 호스트의 80/tcp를 8080/tcp로 redirection
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-forward-port=port=80:proto=tcp:toport=8080
firewall-cmd --reload
firewall-cmd --list-forward-ports
nft list ruleset

다른 호스트로 DNAT할 때는 IP forwarding, forward chain 허용, return path와 source NAT 필요 여부까지 함께 설계한다. 기존 ruleset을 저장하지 않은 채 기본 policy를 drop으로 바꾸면 SSH를 포함한 현재 연결을 끊을 수 있다.

6) 정적 라우팅(static routing)

정적 라우팅은 “목적지 기준으로 next hop를 명시”한다. 실습에서 자주 틀리는 부분은 라우트 영구화 누락이다.

핵심 개념

  • ip route add는 런타임.
  • 재부팅 유지가 필요하면 NetworkManager profile 또는 해당 배포판 영구 설정 방식으로 반영.
  • 기본 라우트는 마지막에 넣고, 특정 목적지(route) 우선순위를 먼저 점검.

예시

ip route
ip route add 172.30.40.0/24 via 192.168.122.1 dev eth0
ip route add default via 192.168.122.1 dev eth0 metric 110
ip -4 route get 172.30.40.10
ip route show table main

7) Bridge·bonding

bridge는 L2 도메인 결합, bond는 물리 링크의 논리 결합이다. 목적이 다르다.

핵심 개념

  • bridge: 여러 인터페이스를 하나의 L2 도메인으로 묶어 VM/컨테이너 브릿지 역할 수행.
  • bond: 두 개 이상 NIC를 하나로 묶어 active-backup(장애 복구) 또는 802.3ad(집선 집적) 성능을 노린다.
  • 주소는 보통 논리 인터페이스(bridge/bond)에 둔다. slave/port에 직접 주소를 다는 패턴은 의도와 다를 수 있다.

예시 구성

아래 두 블록은 서로 독립된 개념 예시다. 관리 NIC가 아닌 연결 해제 가능한 실습 NIC를 사용하고, 원격 환경에서는 먼저 콘솔 접근과 복구 절차를 확보한다.

# bridge 예시(개념)
ip link add br0 type bridge
ip link set eth2 master br0
ip addr add 192.168.20.10/24 dev br0
ip link set br0 up

# bonding 예시(개념)
ip link add bond0 type bond mode active-backup miimon 100
ip link set eth3 down
ip link set eth4 down
ip link set eth3 master bond0
ip link set eth4 master bond0
ip addr add 192.168.20.20/24 dev bond0
ip link set bond0 up

NetworkManager profile 기반 영구화 예시:

nmcli con add type bridge ifname br0 con-name br0
nmcli con add type ethernet ifname eth2 con-name br0-port1 controller br0
nmcli con modify br0 ipv4.addresses 192.168.20.10/24 ipv4.method manual
nmcli con modify br0 connection.autoconnect-ports 1

8) Reverse proxy·load balancer

Reverse proxy는 내부 서비스 접근의 단일 진입점, load balancer는 다수 업스트림의 분산 및 장애 전환이 목적이다. DNS/방화벽/포트 체인의 결합 진단이 중요하다.

nginx 예시

upstream backend_pool {
    server 192.168.56.12:8081;
    server 192.168.56.12:8082 max_fails=2 fail_timeout=10s;
}

server {
    listen 80;
    server_name app.internal;
    location / {
        proxy_pass http://backend_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

HAProxy 예시

global
  daemon
  maxconn 1024

defaults
  mode http
  timeout connect 2s
  timeout client 30s
  timeout server 30s

frontend http_in
  bind *:80
  default_backend app_pool

backend app_pool
  balance roundrobin
  option httpchk GET /health
  server app1 192.168.56.12:8081 check
  server app2 192.168.56.12:8082 check

검사 포인트

  • nginx는 nginx -t로 문법을 먼저 확인.
  • HAProxy는 haproxy -c -f /etc/haproxy/haproxy.cfg로 설정 유효성 확인.
  • 요청은 client 응답 코드와 업스트림별 접근성으로 진단한다.

참고