iptables vs nftables – 리눅스 방화벽 세대 교체 정리

조회수: 0

리눅스 방화벽, 왜 세대 교체가 필요했나

리눅스 방화벽은 오래전부터 Netfilter 프레임워크와 함께 iptables를 표준처럼 사용해 왔다. iptables는 강력하지만, 규칙이 많아질수록 관리가 복잡해지고, IPv4/IPv6, ARP, 브리지 등 각각 다른 명령어(iptables, ip6tables, arptables, ebtables)를 써야 하는 구조 때문에 유지보수가 부담스러웠다.(위키백과)

대규모 트래픽을 처리하는 환경이나, 여러 서버의 방화벽 정책을 통합 관리해야 하는 상황이 늘어나면서 “더 단순한 문법, 통합된 규칙 집합, 높은 성능”에 대한 요구가 생겼고, 그 답으로 등장한 것이 nftables다. nftables는 Linux 커널 3.13부터 공식 포함된 새로운 패킷 필터링 서브시스템으로, iptables의 후속 기술로 설계되었다.(위키백과)

결국 지금 리눅스 방화벽 환경은 “iptables를 유지할 것인가, nftables로 넘어갈 것인가”라는 세대 교체 구도 속에 놓여 있다.

iptables 개요: 오래된 표준 방화벽

iptables는 리눅스 커널의 Netfilter 모듈에 필터 규칙을 설정하는 유틸리티다. 패킷 처리 규칙을 여러 개의 테이블(table)과 체인(chain)으로 나누어 관리한다. 대표적인 테이블로는 filter, nat, mangle, raw, security 등이 있다.(위키백과)

iptables의 특징을 정리하면 다음과 같다.

  • 프로토콜별 명령 분리: IPv4는 iptables, IPv6는 ip6tables, ARP는 arptables, 브리지는 ebtables처럼 명령이 나뉜다.
  • 선형(rule-by-rule) 처리: 하나의 체인에 많은 규칙이 쌓이면, 패킷은 위에서부터 순차적으로 규칙을 평가하므로 규칙 수가 많아질수록 성능에 영향을 줄 수 있다.(DEV Community)
  • 스크립트 기반 관리: 대부분의 운영 환경에서 여러 iptables 명령을 하나의 스크립트로 관리하는 패턴이 일반적이다.

소규모 서버나 단순한 정책에는 여전히 충분하고, 많은 운영 문서와 예제가 iptables 기준으로 적혀 있기 때문에 학습 자료도 풍부하다.

nftables 개요: iptables 후속 기술

nftables는 Netfilter 프로젝트가 iptables의 한계를 해결하기 위해 만든 새로운 방화벽 기술이다. 커널 내부의 nf_tables API와 이를 제어하는 사용자 공간 유틸리티 nft로 구성된다.(위키백과)

주요 특징은 다음과 같다.

  • 통합 프레임워크: iptables, ip6tables, arptables, ebtables에서 하던 일을 하나의 nftables로 통합 관리할 수 있다.(위키백과)
  • 단일 규칙 집합(single ruleset): 다양한 프로토콜과 테이블을 하나의 일관된 규칙 집합으로 다룰 수 있어 중복이 줄고 구조를 더 명확하게 표현할 수 있다.(Zenarmor)
  • 성능 개선: 맵(map), 세트(set)와 같은 고급 자료구조를 통해 많은 규칙을 효율적으로 처리하고, 대규모 트래픽 환경에서 CPU 사용량을 줄이도록 설계되어 있다.(DEV Community)
  • 확장성과 유지보수성: 새로운 프로토콜이나 기능을 추가하기 쉽도록 커널과 유저 공간 레이어가 설계되어 있다.(위키백과)

최신 배포판에서는 nftables를 기본 방화벽 솔루션으로 채택하거나, 최소한 권장 옵션으로 안내하는 경우가 많다.(Red Hat Docs)

구조와 개념 비교: 테이블·체인·규칙

둘 다 Netfilter 기반이라는 공통점이 있지만, 구조와 표현 방식에는 차이가 있다.

iptables의 구조

iptables에서는 여러 테이블(filter, nat, mangle 등) 아래에 INPUT, OUTPUT, FORWARD 같은 체인이 있고, 각 체인에 규칙을 나열하는 방식이다. 규칙마다 개별 명령으로 추가/삭제하는 형태라, 규칙이 많아지면 전체 규칙 상태를 파악하기가 점점 어려워진다.(위키백과)

예를 들어 SSH 허용 규칙은 다음처럼 작성한다.

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

규칙이 100개, 200개 늘어나는 환경에서는 “이 규칙이 어느 서비스용이었는지”, “어떤 순서로 평가되는지”를 추적하는 것이 점점 부담이 된다.

nftables의 구조

nftables도 테이블과 체인 개념을 사용하지만, 규칙을 하나의 구성 파일로 선언형에 가깝게 정의하는 방식이 일반적이다. 예를 들어 다음과 같이 ssh 체인을 따로 나누어 표현할 수 있다.

table inet filter {
  chain input {
    type filter hook input priority 0;

    tcp dport 22 accept
  }
}

하나의 ruleset 안에서 IPv4/IPv6, 여러 체인을 일관된 문법으로 관리할 수 있고, 세트(set)를 활용해 여러 포트나 IP를 묶어서 표현할 수도 있다.

set ssh_hosts {
  type ipv4_addr
  elements = { 192.168.0.10, 192.168.0.11 }
}

tcp dport 22 ip saddr @ssh_hosts accept

이런 표현 방식은 규칙 수가 많을수록 장점이 커진다.

성능과 확장성 비교

성능 측면에서 가장 큰 차이는 “규칙 처리 방식”과 “데이터 구조”다.

  • iptables: 체인에 쌓인 규칙을 위에서부터 순차적으로 평가하는 선형 구조다. 규칙이 많아질수록 패킷 처리에 필요한 연산 수도 늘어난다.(DEV Community)
  • nftables: 세트·맵 등을 활용해 특정 포트, IP 목록, 서비스 그룹 등을 한 번에 매칭할 수 있도록 설계되어 있고, 내부 구현도 규칙 중복을 줄이고 효율적으로 평가하도록 만들어졌다.(DEV Community)

대부분의 소규모 서버에서는 체감 차이가 크지 않을 수 있지만, 수백·수천 개의 규칙을 가진 대규모 환경이나 고트래픽 서버에서는 nftables가 CPU 사용량과 규칙 평가 시간을 줄이는 데 유리하다는 평가가 많다.(TuxCare)

확장성 관점에서도, 새 프로토콜 지원이나 복잡한 정책(예: 여러 포트 범위, 접속 국가별 차단, 다단계 정책)을 구현할 때 nftables 문법이 더 유연하고 간결하다.

운영 편의성과 관리 방식 비교

운영·관리 관점에서 iptables vs nftables를 비교하면 다음 포인트가 중요하다.

문법과 가독성

  • iptables: 규칙마다 긴 명령을 기억해야 하고, 여러 파일에 나뉜 스크립트를 붙여 쓰는 경우가 많다.
  • nftables: 한 파일에 전체 ruleset을 선언형으로 정리할 수 있어, “이 정책이 무엇을 의미하는지”를 한눈에 파악하기 쉽다.

백업과 형상 관리

nftables는 전체 규칙을 하나의 설정 파일로 관리하기 좋기 때문에, Git 같은 형상 관리 도구에 올려 diff를 보면서 변경 이력을 추적하기에 적합하다. iptables도 스크립트로 관리하면 비슷한 패턴을 만들 수 있지만, IPv4/IPv6가 분리되고 테이블별로 파일이 나뉘면 구조가 쉽게 분산된다.

학습 곡선

기존 iptables에 익숙한 운영자에게 nftables 문법은 처음엔 낯설 수 있다. 대신 테이블·체인·규칙이라는 기본 개념은 그대로이기 때문에, 구조를 이해하고 나면 오히려 nftables 쪽이 규칙을 “읽고 이해하기” 편하다는 의견도 많다.(Medium)

iptables에서 nftables로 이전 전략

이미 iptables를 사용 중인 환경에서 nftables로 넘어가려면, 한번에 전체를 바꾸기보다 단계적으로 이전하는 전략이 안전하다. 대표적인 단계는 다음과 같이 잡을 수 있다.

  1. 현행 규칙 인벤토리 작성
    • iptables-save 명령으로 현재 규칙을 모두 덤프한다.
    • 어떤 서비스가 어떤 포트/체인에 의존하는지 정리한다.
  2. nftables 기본 구조 설계
    • inet 테이블 하나로 IPv4/IPv6를 통합할지, 테이블을 역할별로 나눌지 구조를 정한다.(기피말고깊이)
    • input, output, forward 체인의 정책(default policy)을 어떻게 둘지 결정한다.
  3. 핵심 규칙부터 변환
    • SSH, HTTP/HTTPS, 데이터베이스 등 핵심 서비스 규칙을 nftables 문법으로 먼저 옮긴다.
    • 테스트 서버나 비중이 낮은 서버에서 먼저 적용해 본다.
  4. 점진적 치환
    • iptables와 nftables를 동시에 쓰는 혼합 상태를 최소화하되, 완전히 교체하기 전까지는 롤백 계획을 항상 준비한다.
    • 문제 없이 동작이 확인되면 iptables 기반 스크립트와 서비스를 순차적으로 제거한다.

Red Hat 등 일부 배포판은 iptables 명령을 내부적으로 nf_tables 백엔드에 매핑해 주는 호환 계층을 제공하기도 하므로, 이 점을 활용하면 완전한 마이그레이션 전에 혼합 운영을 할 수 있다.(Red Hat Docs)

간단한 마이그레이션 예제

예를 들어, 다음과 같은 iptables 규칙이 있다고 가정해 보자.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -j DROP

이를 nftables로 옮기면 다음과 같이 표현할 수 있다.

table inet filter {
  chain input {
    type filter hook input priority 0;

    ct state established,related accept

    tcp dport { 22, 80 } accept

    drop
  }
}

포트 22, 80을 세트로 묶어 한 줄로 표현할 수 있고, 체인 전체 흐름을 위에서 아래로 읽으면서 “연결 상태 허용 → SSH/HTTP 허용 → 나머지 드롭”이라는 정책을 직관적으로 이해할 수 있다.

이런 식의 변환을 반복하다 보면, 자연스럽게 규칙 중복을 줄이고 구조를 단순화하게 된다.

언제 여전히 iptables를 써도 되는가

모든 환경에서 무조건 nftables로 갈아탈 필요는 없다. 다음과 같은 경우라면 iptables를 당장 버리지 않아도 된다.

  • 규칙 수가 매우 적고, 단순한 개인 서버나 테스트 서버
  • 기존 자동화 스크립트, 관리 도구가 iptables에 강하게 묶여 있는 환경
  • 방화벽 정책이 자주 변하지 않고, 유지 관리 부담이 크지 않은 경우

다만, 새로운 프로젝트나 장기적으로 운영할 신규 인프라라면 처음부터 nftables를 기준으로 설계하는 편이 앞으로의 유지보수와 확장성 측면에서 유리하다.(TuxCare)

정리: 지금 선택해야 할 방화벽은?

iptables vs nftables를 한 줄로 정리하면 다음과 비슷하다.

  • iptables: 오랫동안 검증된 레거시 표준, 작은 환경에서는 여전히 충분히 쓸 만하다.
  • nftables: iptables의 후속 세대, 통합된 구조와 성능, 유지보수성을 고려하면 앞으로의 리눅스 방화벽 기본 선택지에 가깝다.(위키백과)

이미 iptables에 익숙한 환경이라도, 새로 서버를 구축하거나 방화벽 정책을 크게 손볼 계획이 있다면 nftables 기반 설계를 진지하게 검토할 시점이다. 점진적인 마이그레이션 전략을 잘 세워 두면, 중간에 큰 장애 없이 리눅스 방화벽의 세대 교체를 비교적 부드럽게 진행할 수 있다.

정보 추천글 더보기