iptables에서 nftables로 — 리눅스 방화벽 마이그레이션 실전 가이드

Debian 10, RHEL 8/9, Ubuntu 20.04 이후 주요 배포판은 기본 방화벽 백엔드로 nftables를 채택했습니다. iptables 명령은 여전히 동작하지만, 내부적으로 iptables-nft라는 호환 레이어를 거쳐 nftables 규칙으로 변환되는 구조입니다. 즉 대부분의 서버가 이미 사실상 nftables 위에서 돌아가고 있고, 남은 것은 규칙을 nftables 문법으로 직접 관리하느냐의 문제입니다.

왜 옮기나 — iptables의 구조적 한계

iptables 방식:
  규칙 A → 순차 매칭 → 규칙 B → 순차 매칭 → 규칙 C → ...
  IP 1000개를 차단하려면 규칙 1000줄, 패킷마다 최악의 경우 1000번 비교

nftables 방식:
  set/map 자료구조 → 해시 기반 O(1) 조회
  IP 1000개를 하나의 set에 넣고 단일 규칙으로 매칭

iptables는 규칙을 위에서 아래로 순차 매칭하는 선형 구조입니다. 규칙이 많아질수록(특히 대량 IP 차단 리스트) 성능이 선형으로 나빠집니다. nftables는 커널 수준의 set·map 자료구조를 지원해 대량 매칭을 해시 조회 수준으로 처리합니다. IP 블랙리스트가 수천 개 단위로 커지는 서버(스팸 차단, DDoS 방어 룰)에서 체감 차이가 명확합니다.

문법 면에서도 nftables는 IPv4·IPv6를 하나의 규칙셋으로 통합 관리(inet family)할 수 있어, iptables/ip6tables를 따로 관리하던 이중 작업이 사라집니다.

문법 비교

# iptables: SSH 허용
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# nftables: SSH 허용
nft add rule inet filter input tcp dport 22 accept

# iptables: 여러 IP 차단 (규칙 여러 줄)
iptables -A INPUT -s 1.2.3.4 -j DROP
iptables -A INPUT -s 5.6.7.8 -j DROP

# nftables: set 하나로 통합
nft add set inet filter blacklist { type ipv4_addr\; }
nft add element inet filter blacklist { 1.2.3.4, 5.6.7.8 }
nft add rule inet filter input ip saddr @blacklist drop

set을 쓰면 IP를 추가·삭제할 때 규칙 전체를 재작성할 필요 없이 set 원소만 갱신하면 됩니다. fail2ban·CrowdSec 같은 자동 차단 도구와 연동할 때도 훨씬 가볍게 동작합니다.

마이그레이션 절차

1) 현재 규칙 백업

iptables-save > /root/iptables-backup-$(date +%F).rules
ip6tables-save > /root/ip6tables-backup-$(date +%F).rules

2) iptables-translate로 1차 변환

iptables-translate는 기존 iptables 명령을 nftables 문법으로 자동 변환해 줍니다. 완벽하지 않으니 검토가 필요하지만 초안으로는 충분합니다.

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# 출력: nft add rule ip filter INPUT tcp dport 22 counter accept

규칙 전체를 옮기려면 iptables-restore-translate를 사용합니다.

iptables-save > current.rules
iptables-restore-translate -f current.rules > nftables-migrated.nft

3) 변환 결과 검토·정리

자동 변환된 결과는 규칙마다 개별 체인으로 나열되기 쉬워, 반복되는 패턴(대량 IP 차단 등)은 수동으로 set으로 묶어 정리하는 것이 좋습니다.

4) 테스트 환경에서 먼저 적용

nft -f nftables-migrated.nft
nft list ruleset   # 실제 로드된 규칙 확인

5) 원자적 교체와 롤백 대비

nftables는 규칙셋을 원자적으로(all-or-nothing) 교체할 수 있습니다. 다만 SSH로 원격 작업 중이라면 자기 자신을 잠그는 실수를 막기 위해 아래처럼 타이머를 걸어두는 방법을 권장합니다.

# 5분 뒤 자동으로 이전 규칙 복구 (안전장치)
(sleep 300 && iptables-restore < /root/iptables-backup-*.rules) &
JOB=$!
nft -f nftables-migrated.nft
# 문제 없으면 안전장치 취소
kill $JOB

흔한 함정

1) 기본 정책(default policy) 누락

iptables의 체인 기본 정책(-P INPUT DROP 등)은 자동 변환에서 빠지기 쉽습니다. nft list ruleset으로 최종 정책을 반드시 눈으로 확인하세요.

2) 상태 추적(conntrack) 규칙 확인

ESTABLISHED,RELATED 허용 규칙이 빠지면 응답 패킷이 막혀 기존 연결까지 끊깁니다.

nft add rule inet filter input ct state established,related accept

3) NAT 테이블 이관 누락

iptables -t nat로 관리하던 포트포워딩·마스커레이딩 규칙은 nftables에서 별도 nat 테이블/체인으로 옮겨야 합니다. 변환 스크립트가 이 부분을 빠뜨리는 경우가 있으니 별도 확인이 필요합니다.

4) Docker·libvirt와의 충돌

Docker·libvirt 등은 여전히 iptables(iptables-nft 호환 레이어)를 통해 자체 체인을 관리합니다. nftables로 완전히 이관하면서 이 도구들의 자동 규칙과 충돌하지 않는지 확인이 필요합니다. 확신이 없다면 애플리케이션이 관리하는 체인은 건드리지 않고, 사용자 정의 체인만 nftables로 옮기는 절충안도 있습니다.

검증 체크리스트

nft list ruleset으로 최종 규칙 육안 확인
기본 정책(DROP/ACCEPT)이 의도대로 설정됐는지 확인
ct state established,related accept 규칙 존재 확인
외부에서 SSH·서비스 포트 접근 테스트(별도 세션 유지한 채로)
재부팅 후에도 규칙이 유지되는지 확인(nftables.service 활성화 여부)
Docker·libvirt 등 자동 규칙과 충돌 없는지 확인

마무리

iptables에서 nftables로의 전환은 “당장 바꿔야 하는 긴급한 일”은 아니지만, 대량 IP 차단이 필요한 환경(봇 차단, DDoS 대응 룰)에서는 성능·관리 편의 양쪽에서 이득이 명확합니다. 백업 → 자동 변환 → 수동 검토 → 안전장치를 건 테스트 적용 순서를 지키면 위험 없이 옮길 수 있습니다.

TCP-80.NET 전용서버는 커널·방화벽을 포함해 서버를 완전히 통제할 수 있는 환경을 제공합니다. 네트워크 레이어 공격 방어는 기본 DDoS 보안이 함께 처리하고, 애플리케이션 레이어 침입 방어가 필요하면 해킹 보안 서비스를 함께 검토해 보세요.