리눅스 네트워크 설정 실패 회고: 1년 운영 경험으로 배운 베스트 프랙티스

리눅스 서버를 1년 정도 꾸준히 운영하다 보면, 결국 한 번쯤은 리눅스 네트워크 설정 실패를 겪게 되더라고요. 저도 홈랩에서 Ubuntu Server, Rocky Linux 계열, Debian 계열을 번갈아 굴리면서 꽤 여러 번 삽질했습니다 ㅎㅎ 특히 원격으로 붙어 있는 서버에서 네트워크를 잘못 건드리면, 그 순간 SSH가 끊기고 화면 앞에서 멍해지는 경험을 하게 됩니다. 이 글은 그런 실수들을 그냥 흑역사로 남기지 않고, 리눅스 서버 운영 관점에서 무엇을 조심해야 하는지 정리한 회고입니다.

이번 글에서는 제가 실제로 자주 부딪혔던 iptables(아이피테이블즈, 리눅스 패킷 필터/방화벽) 실수, DNS(Domain Name System) 설정 꼬임, netplan(넷플랜, Ubuntu 계열 네트워크 설정 도구) 문제를 중심으로 풀어보겠습니다. 화려한 이론보다, 운영하면서 왜 망가졌는지와 어떻게 복구했는지가 더 중요하거든요.

홈랩에서 라우터, 스위치, 리눅스 서버, 관리용 노트북이 연결된 전체 네트워크 개요를 보여주는 이미지입니다.

1. 왜 리눅스 네트워크 설정 실패가 운영에서 치명적인가

서버에서 네트워크는 그냥 연결만 되면 끝나는 영역처럼 보이는데, 실제로는 아닙니다. 서비스 장애의 시작점이 되는 경우가 많습니다. CPU나 메모리는 눈에 보이게 올라가지만, 네트워크는 조용히 잘못되는 경우가 많거든요.

• SSH는 되는데 외부 패키지 저장소 접근이 안 되는 경우
• IP는 붙었는데 DNS 조회가 안 돼서 애플리케이션이 죽는 경우
• 방화벽 규칙이 꼬여서 특정 포트만 막히는 경우
• 재부팅 후 설정이 다르게 올라오는 경우

여기서 중요한 포인트! 리눅스 네트워크 설정 실패는 대부분 한 번에 크게 터지지 않습니다. 처음엔 “어? 왜 이렇게 느리지?” 정도로 시작하다가, 나중엔 서비스가 안 뜨는 식으로 번지더라고요. 저도 처음엔 이게 뭔가 싶었는데, 결국 원인은 기본값을 너무 믿었던 데 있었습니다.

2. 쉽게 말해 보는 핵심 개념: IP, Gateway, DNS, Firewall

복잡해 보여도 네트워크는 몇 가지만 분리해서 보면 정리가 됩니다. 쉽게 말해, 서버가 네트워크에서 길을 찾고, 이름을 해석하고, 누굴 통과시킬지 결정하는 과정입니다.

운영 입장에서 보면 순서도 중요합니다. 보통은 링크(Link, 물리/가상 NIC 상태)가 살아 있는지 확인하고, 그다음 IP, 라우팅, DNS, 방화벽 순으로 봐야 합니다. 근데 저도 예전에는 바로 iptables부터 의심했었거든요. 실제로는 게이트웨이 한 줄이 빠진 경우가 더 많았습니다.

3. 1년 운영하면서 가장 많이 했던 리눅스 네트워크 설정 실패 세 가지

3-1. iptables 실수: 기본 정책부터 DROP으로 바꿨다가 SSH 차단

iptables 실수는 진짜 한 번은 꼭 겪습니다. 저도 “보안을 좀 더 깔끔하게 하자”는 생각으로 INPUT 기본 정책을 DROP으로 바꿨다가, SSH 허용 규칙 적용 순서를 잘못 넣어서 바로 접속이 끊긴 적이 있습니다. 콘솔이 붙어 있어서 망정이지, 원격 장비였으면 더 골치 아팠을 겁니다.

3-2. DNS 설정 꼬임: ping은 되는데 apt와 curl이 실패

이건 초보 때보다 오히려 익숙해진 뒤에 더 자주 터지더라고요. IP 통신은 되는데 저장소 접근이 안 되면 대개 DNS 설정 문제였습니다. 특히 systemd-resolved를 쓰는 환경에서 /etc/resolv.conf를 직접 고쳐 버리면, 재부팅이나 네트워크 재시작 때 다시 꼬이는 경우가 있었습니다.

3-3. netplan 문제: YAML 들여쓰기 하나로 네트워크가 안 올라옴

netplan 문제는 문법 자체는 단순한데, YAML이 공백에 민감해서 생각보다 자주 발목을 잡습니다. 제가 직접 해보니, 설정을 급하게 바꾸다가 NIC 이름을 잘못 쓰거나 들여쓰기를 틀리면 부팅 후 네트워크가 예상과 다르게 올라오더라고요. 특히 ens18과 eth0를 혼동하는 케이스가 많았습니다.

4. 실전 구현: 안전하게 네트워크 설정 바꾸는 절차

여기서는 제가 지금도 지키는 최소한의 변경 절차를 정리해보겠습니다. 핵심은 한 번에 바꾸지 않고, 검증 가능한 작은 단위로 진행하는 겁니다.

1. 현재 상태를 백업합니다.
2. 활성 NIC 이름과 라우팅 테이블을 확인합니다.
3. IP, Gateway, DNS를 한 번에 다 바꾸지 말고 순서대로 적용합니다.
4. 원격 작업이면 세션을 하나 더 열어 둡니다.
5. 방화벽은 허용 규칙을 먼저 넣고 기본 정책을 나중에 바꿉니다.
6. 적용 후 즉시 ping, ss, resolvectl, journalctl로 검증합니다.

ip -brief address
ip route
resolvectl status
ss -tulpen
sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak
sudo iptables-save > ~/iptables-backup.rules

이 정도만 해도 복구 속도가 확실히 빨라집니다. 저는 예전엔 백업 없이 바로 수정했었는데, 그게 제일 큰 실수였습니다.

4-1. netplan 예시

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 192.168.0.50/24
      routes:
        - to: default
          via: 192.168.0.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

적용 전에 꼭 문법을 다시 보셔야 합니다. 원격 서버라면 특히 더요.

sudo netplan generate
sudo netplan try

netplan try는 정말 유용합니다. 잘못 적용하면 자동으로 이전 상태로 되돌릴 수 있어서, 저처럼 리눅스 네트워크 설정 실패를 많이 겪은 사람에게는 안전벨트 같은 기능이거든요.

netplan YAML 파일과 터미널에서 ip, route, resolvectl로 확인하는 과정을 함께 보여주는 이미지입니다.

4-2. iptables 적용 예시

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

여기서 순서가 중요합니다. 허용 규칙을 먼저 넣고 마지막에 정책을 조정해야 합니다. 저는 예전에 이 순서를 반대로 했다가 SSH가 끊겼습니다. iptables 실수의 전형적인 사례죠. “드디어 됐다!” 싶어서 정책부터 바꾸면, 바로 사고 납니다.

4-3. DNS 점검 예시

ping -c 2 8.8.8.8
getent hosts example.com
resolvectl query example.com
cat /etc/resolv.conf

IP로는 통신되는데 도메인만 안 되면 DNS 설정을 보시면 됩니다. 반대로 DNS 설정이 정상인데도 외부가 안 되면 라우팅이나 방화벽 쪽일 가능성이 높습니다.

5. ⚠️ 실제 리눅스 네트워크 설정 실패 사례와 복구 과정

이 섹션은 좀 더 현실적인 회고입니다. 보기엔 사소한데, 운영에선 꽤 아픈 문제들이었습니다.

5-1. 게이트웨이 누락으로 내부망만 되고 외부망은 불가

서버 간 통신은 되는데 패키지 업데이트가 안 됐습니다. 처음엔 DNS 문제인 줄 알았는데, 실제로 써보니까 기본 게이트웨이(default gateway)가 빠져 있더라고요. 내부망은 같은 서브넷이라 통신되지만, 외부로 나갈 출구가 없으니 당연히 실패한 겁니다.

• ip route에 default 경로가 있는지 확인
• 게이트웨이 IP가 실제 라우터 주소와 일치하는지 확인
• 정적 라우트가 있으면 우선순위도 함께 점검

5-2. NIC 이름 오인으로 netplan 적용 실패

가상화 환경을 옮기고 나서 기존 설정을 그대로 썼는데 NIC 이름이 달랐습니다. 예전엔 eth0였는데 새 환경에서는 ens18로 올라왔거든요. 문법은 맞는데 적용이 안 되니 한참 헤맸습니다. 이것도 리눅스 네트워크 설정 실패의 전형적인 경우죠.

• ip -brief link로 실제 인터페이스 이름 확인
• 클라우드 이미지나 VM 템플릿 복제 시 이름이 바뀔 수 있음
• 문법보다 장치 식별이 먼저라는 점을 기억

5-3. 방화벽 저장 누락으로 재부팅 후 규칙 유실

이것도 흔합니다. 세션 중에는 잘 되는데 재부팅하면 다시 열려 있거나 다시 막혀 있죠. 이유는 간단합니다. 런타임 규칙과 영구 저장 규칙을 분리해서 이해하지 않았기 때문입니다. 배포판마다 iptables-persistent나 별도 서비스 관리 방식이 다를 수 있으니, 현재 서버가 어떤 방식으로 규칙을 유지하는지 먼저 확인하셔야 합니다.

6. 네트워크 베스트 프랙티스: 제가 지금은 이렇게 운영합니다

네트워크 베스트 프랙티스는 거창한 게 아닙니다. 사고를 줄이는 습관에 가깝습니다. 1년 동안 리눅스 서버를 굴려보니 아래 원칙이 가장 효과가 좋았습니다.

• 변경 전 현재 상태를 텍스트로 저장해 둡니다.
• 운영 서버는 콘솔 접근 수단을 반드시 확보합니다.
• DNS와 라우팅을 분리해서 테스트합니다.
• 보안 강화를 할 때는 서비스 영향도를 먼저 봅니다.
• 재부팅 후에도 유지되는지 꼭 확인합니다.

혹시 이런 경험 있으신가요? 설정은 맞는 것 같은데, 재부팅 한 번 하고 나면 갑자기 안 되는 상황이요. 그런 경우는 대부분 “현재 세션에만 반영된 상태”와 “영구 설정 파일”이 다를 때가 많습니다. 저도 처음엔 헷갈렸는데, 이 구분만 해도 리눅스 네트워크 설정 실패 문제 절반은 줄어듭니다.

SSH 허용 규칙을 먼저 넣고 기본 정책을 나중에 적용하는 안전한 iptables 흐름을 설명하는 이미지입니다.

7. 검증 방법: 적용 후 무엇을 확인해야 하나

설정이 들어갔다고 끝이 아닙니다. 검증이 빠지면 다음 장애 때 원인을 다시 처음부터 찾게 됩니다.

1. 링크 상태: 인터페이스가 UP인지 확인합니다.
2. 주소 확인: IP와 서브넷이 의도대로 붙었는지 봅니다.
3. 라우팅 확인: default route가 맞는지 확인합니다.
4. 이름 해석: DNS 질의가 정상인지 테스트합니다.
5. 포트 확인: 서비스가 실제로 바인딩됐는지 확인합니다.
6. 외부 접속: 다른 장비에서 실제 접속 테스트를 합니다.

ip -brief address
ip route
getent hosts github.com
ss -tulpen
journalctl -u systemd-networkd --since "10 minutes ago"

저는 여기에 하나를 더 합니다. 바로 “재부팅 검증”입니다. 지금 당장 되느냐보다, 다음 부팅에서도 그대로 올라오느냐가 운영에서는 더 중요하거든요.

IP, 라우팅, DNS, 포트 상태를 체크리스트 형태로 확인하는 검증 결과 이미지를 넣는 자리입니다.

8. 자주 묻는 질문과 정리

Q1. ping이 되면 네트워크는 정상 아닌가요?

꼭 그렇지는 않습니다. ICMP는 되는데 TCP 포트가 막혀 있을 수 있고, IP는 되는데 DNS 설정이 안 될 수도 있습니다. 그래서 계층별로 봐야 합니다.

Q2. netplan만 쓰면 리눅스 네트워크 설정 문제가 다 해결되나요?

아닙니다. netplan은 선언형 설정 도구일 뿐이고, 실제 렌더러가 networkd인지 NetworkManager인지도 봐야 합니다. 도구를 맹신하면 오히려 원인 파악이 늦어집니다.

Q3. iptables와 nftables 중 무엇을 써야 하나요?

배포판과 운영 환경에 따라 다릅니다. 중요한 건 이름보다도 현재 시스템이 어떤 프레임워크를 실제로 쓰는지 확인하는 겁니다. 혼용된 상태에서 규칙을 만지는 게 더 위험하더라고요.

리눅스 네트워크 설정 실패를 줄이는 가장 좋은 방법은 천재적인 설정이 아니라, 평범한 검증 습관입니다. 저도 1년 동안 서버를 굴리면서 별별 문제를 다 겪었는데, 결국 살아남는 방법은 백업, 단계별 적용, 즉시 검증이었습니다. 다음 글에서는 방화벽 정책을 서비스별로 나누는 방법이나, 홈랩 기준 VLAN 분리 전략도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 확인 습관과 함께 보시면 더 도움이 되실 겁니다.

리눅스 서버 운영에서 네트워크 베스트 프랙티스를 한눈에 정리한 요약 인포그래픽 이미지입니다.

정리하자면 이렇습니다.

• 리눅스 네트워크 설정 실패는 대부분 기본 개념보다 적용 순서와 검증 부족에서 시작됩니다.
• iptables 실수는 규칙 순서와 영구 저장 여부를 먼저 확인하셔야 합니다.
• DNS 설정은 resolver 구조를 이해하고 나서 건드려야 덜 꼬입니다.
• netplan 문제는 YAML 문법과 NIC 이름 확인이 핵심입니다.
• 네트워크 베스트 프랙티스는 결국 안전한 변경 절차를 습관으로 만드는 일입니다.