iptables

#os/linux #network/firewall #command/iptables #network/netfilter

개요

iptables는 리눅스에서 사용되는 네트워크 패킷 조작 테이블을 작성하는 명령어이다.
패킷을 필터링하고, 라우팅하고, 드랍하거나 마스크를 붙이는 등 다양한 규칙을 설정해서 넣을 수 있다.
이를 기반으로 방화벽을 구성하거나, 서비스 메시에서는 사이드카 프록시로 트래픽을 전담하는 식으로 활용한다.
특히 쿠버네티스에서는 kube-proxy가 기본적으로 이 iptables를 통해 서비스를 향하는 트래픽을 실제 파드로 전달한다.

실제 동작은 넷필터(NetFilter)라는 커널 단의 네트워크 프레임워크를 활용한다.
달리 말해, iptables가 네트워크 조작의 대명사로 활용되지만 사실 넷필터를 활용하는 다른 툴들도 있다!
iptables를 보완하고 더 효율적으로 트래픽을 처리하는 ipvs도 있고, 최근에는 nftables라는 더 효율적이고 범용적인 기능을 가진 툴이 나왔다.
그래서 iptables가 점차 사라질 것이라는 이야기가 많다.
근데 nftables도 나온지 한참 지났는데 그다지 많이 사용되지도 않고..
내 생각에는 그냥 eBPF를 활용하는 방식이 더 발전해버려서 nftables는 주류를 차지할 기회도 앞으로 없지 않을까..
다른 툴들에 대해서는 아래에서 조금 더 자세히 다루겠다.

NetFilter란

먼저 근간이 되는 넷필터에 대해서 알아보자.
넷필터는 리눅스 커널에 있는 프레임워크로[1] iptables, nftables는 사실 이걸 다루는 명령어이다.
넷필터는 커널 모듈에 콜백 함수를 넣어주는 기능을 가지고 있다.
그래서 OS에 들어온 패킷이 거쳐갈 기본 네트워크 스택에 대해 사용자가 각종 규칙과 설정을 넣을 수 있는 것이다.

netfilter에는 몇 개의 훅이 있어서, 이 훅에 대해 우리가 여러가지 규칙들을 지정하면 네트워크 패킷이 오가는 와중에 중간 중간 끼어서 각종 동작을 하게 된다.

이렇게 네트워크 스택을 도식화 했을 때 ip, tcp, arp 관련 층에서 동작하는 거라고 보면 될 것 같다.

참고로 넷필터를 전문으로 다루는 오픈소스 커뮤니티 그룹이 있다.
이 그룹에서 iptables와 nftables도 관리하고 있다.

넷필터 기능

대충 말했지만 넷필터의 기능은 간단하게 패킷 조작질로 요약할 수 있다.
조금 더 상세하게 풀어보자면..

패킷 필터링, napt(network address and port translation),패킷 로깅, 사용자공간 패킷 큐 처리 등의 일을 할 수 있다.
또 패킷 맹글링도 할 수 있는데, 이게 뭔 말인가 했더니 패킷을 갈아끼우는 행위를 말한다.
대체로 헤더를 바꿔치는 행위를 말하는 것 같다.

홈페이지에서 나오는 내용을 그대로 베끼자면,

넷필터 동작 구조

넷필터 컴포넌트는 이렇게 구성돼있다.[2]

이것들은 리눅스 커널에 위치한 넷필터 모듈로 보다시피 ip_tables, arp_tables 등으로 구성된다.
이 놈들은 각각 테이블 기반으로 이뤄져 있으며, 패킷을 전송하고 변환하는 규칙(rule)이 담긴다.
이때 규칙은 전부 넷필터가 노출하는 훅 api에 호환되도록 작성돼있다.

즉 넷필터 프레임워크라는 것은 크게는 이렇게 정리할 수 있을 것 같다.

사용자는 iptables 명령어를 이용해 어떤 규칙들을 작성한다.
이 규칙들은 테이블 형태로 관리되며 커널 단의 훅으로 주입될 수 있는 형식을 가지고 있다.
넷필터는 이 모듈들을 활용할 수 있는 훅을 만들어서 사용자에게 제공한다는 것이다.

코드에 대한 이해가 없어서 표현이 조금 애매한 것 같기도 한데, 세부적인 넷필터의 코드는 여기에서 볼 수 있다.[3]

모듈 이름이.. iptables?

모듈 이름들이 죄 tables인데, 이것들을 관리할 수 있도록 유저 공간에 제공되는 명령어 이름도 똑같이 tables이다.
그래서 iptables라고 하면 명령어 자체를 말하기도 하지만 사실 넷필터의 코어 모듈을 말하는 것이기도 하다.
그래서 넷필터랑 iptables를 따로 떼어놓고 생각하기가 어려운 지점이 있기도 하다.
아무튼 사용하는 입장에서 모듈 이름이 이렇다 정도까지 알 필요는 없고, 넷필터에는 여러 테이블이 있어 규칙을 나열하여 적용할 수 있다 정도만 알면 될 것 같다.

원래 iptables, arptables 등 tables 시리즈가 있어 각각을 관리하는 식으로 운용했다.
그러나 방식 자체도 비효율적이고 낡았다고 해서 통합 개선돼 나온 것이 nftables 모듈이며, 이를 조작하는 툴이 nftables 명령어이다.

넷필터 훅

넷필터의 동작 구조는 훨 복잡하지만, 지금부터는 iptables 설명에 초점을 맞춰 내용을 정리하겠다.
넷필터의 핵심은 결국 커널 단의 패킷 조작이 가능하도록 하는 훅을 노출하는 것이다.
이때 넷필터는 딱 5개의 훅을 노출한다.[4]
이 훅에 위 모듈 테이블에 적힌 규칙이 들어가서 트래픽이 패킷이 조작되는 것이다.

각 훅이 무엇인지 간략하게 알아볼 텐데, 그전에 먼저 OS가 받아들이는 네트워크 흐름도를 먼저 살펴보자.

이걸 처음에 빠르게 캐치 못해서 이해하는데 조금 난항이 있었다..
우리의 운영체제는 네트워크 데이터를 어떻게 주고받는가? [5]

일단 네트워크 인터페이스 카드, 혹은 장치(net_device)가 있다.
1계층에 해당하는 물리적 장치(가상 인터페이스도 있긴 한데 결국 물리적인 영역을 한 단계 추상화시켰으니 근본은 물리적 장치라 하겠다)를 말하며, 실제로 네트워크 비트를 받고 변환하는 역할을 한다.
이 장치를 통해 들어온 패킷은 두 가지 방향으로 나아갈 수 있다.

(엄밀하게는 컴퓨터에 들어오는 순간 네트워크 스택에 들어왔다고 봐야 하는 게 아닌가 싶었는데 여태 본 글들은 다 이리 표현하더라.)
라우팅 단계에서 해당 패킷이 어디로 나아갈지 결정될 것이다.

반대로 나가는 패킷 역시 두 가지 출발지를 가질 것이다!
하나는 시스템에서 나가는 패킷이 있을 것이고, 포워딩되어 그대로 나가버리는 패킷도 나가는 패킷에 해당한다.

이러한 전반적인 흐름 속에서, 넷필터는 5가지의 단계 포인트를 지정한다.
위 그림의 파란색 박스가 바로 그 포인트이다.
그리고 넷필터는 이 포인트들에 대해 조작을 가할 수 있는 훅을 노출하고 있는 것이다.

iptables 툴은 이 훅들에 원하는 규칙(rule)을 넣는 식으로 동작하게 된다는 것이다.
이제 본격적으로 iptables를 다루는 방법에 대해 알아보자.

체인

계속 말하지만, iptables는 결국 어떤 규칙들을 테이블 형태로 만드는 툴이다.
iptables에서는 이 규칙들을 체인이라는 개념으로 한 번 더 구조화시킨다.
체인은 규칙들의 집합으로, 보통 규칙의 체인(chains of rules)라고 부른다.

체인의 필요성

왜 체인이라는 개념이 필요한가?
이건 규칙이 테이블 형태로 설정된다는 것에 그 이유가 있다.
패킷이 들어오면 규칙 테이블에 의해 순차적으로 검사와 조작을 받게 된다.
말 그대로 테이블이에 순서는 엄격하게 지켜진다.

그런데 이런 상황을 생각해보자.
간략하게 a로 들어온 패킷을 b라는 곳으로 보내는 규칙을 쓰고 싶다고 해보겠다.

그냥 예시로 아무렇게나 쓴 규칙이니 예시로만 참고하자.
체인이란 개념이 없으면 모든 트래픽은 이 규칙들을 순차적으로 적용 받는다.
그럼 a로 들어오지 않은 패킷은 자신과 관련도 없는 규칙을 4번이나 검사받아야 한다!

여기에 체인 개념을 도입하면 이런 식으로 수정할 수 있다.

이제 a로 들어오지 않은 패킷은 하나의 규칙만 검사를 받으면 맘 편히 드랍될 수 있게 된다!
a로 들어온 패킷은 zz 체인의 규칙들의 검사를 받게 될 것이다.

이렇게 체인이란 것은 각종 규칙들을 그룹화시키는 역할을 한다.
그리고 규칙들은 이 체인을 대상으로 삼음으로서 트래픽에 적용될 규칙들을 분기시켜서 다양한 로직을 구성할 수 있게 된다.
이는 세밀한 네트워크 규칙을 구성할 수 있게 돕는 한편 패킷이 불필요한 규칙의 적용을 받지 않게 함으로서 처리 효율을 증가시킨다.

내장 체인

위 예시에서 내가 마음대로 zz라는 체인을 만들었듯이 체인은 사용자가 다양하게 구성할 수 있다.
여기에서 체인의 진입점이 어떻게 되는가에 대한 의문이 생겼다면 체인을 제대로 이해한 것이다.
기본적으로 패킷은 어떤 규칙의 적용을 받는가?
iptables에는 사전 정의된(pre-defined), 내장된(built-in) 5개의 체인을 가지고 있다.


이름만 봐도 알겠지만, 이 체인들은 각각 넷필터의 훅과 1:1 매핑된다.[6]
이제 넷필터의 개념과 더불어서 각 체인이 언제 발동되는지 명확하게 알 수 있다.
일단 전체 순서나 발동 시기는 이렇게 보면 이해가 편할 듯 싶다.

zz 체인 예시의 규칙들을 INPUT 체인에 넣어놨다면, NF_IP_LOCAL_IN 훅을 발동시키는 패킷에 대해 해당 규칙들이 적용될 것이다.
체인은 규칙이 적용되는 시기를 정한다.
달리 말하자면 관리자가 패킷 전달이 되는 과정에서 어디에다 규칙을 박을지를 정할 때 원하는 위치의 체인을 쓰면 된다는 것이다.
가령 일단 패킷이 들어온 순간 어떤 규칙을 발동하고 싶다? 그럼 PREROUTING 체인을 활용해야 할 것이다.

테이블

이 개념을 이해하는데 가장 오래 걸렸던 것 같은데, iptables에서는 테이블이란 개념으로 체인들을 다시 한 번 그룹화시킨다...
개념만 보면 어렵진 않은 게, 여러 규칙과 체인을 작성하는데 있어서 사용 목적에 맞게 사용하라고 iptables에서 제공하는 그룹이라고 보면 된다.

예를 들어 방화벽처럼 패킷을 드랍시키는 동작을 하는 규칙은 filter라는 테이블에 넣고, 패킷의 출처 주소를 조작하는 규칙은 nat 테이블에 넣는 식이다.
다양한 체인들을 작성하는데 있어서 이들을 목적에 맞게 더 구조화시키라고 제공해주는 단위가 테이블인 것이다.
정의로 보자면 테이블은 체인들을 가지고 있는 집합체이다.
iptables에서는 기본 5개의 테이블을 제공하는데, 커스텀이 가능한 체인과 다르게 이건 완전히 못박아버렸다.
그래서 관리자는 본인이 만드려는 규칙의 용도를 생각하고 각 테이블에 넣는 방식으로 설정하면 된다.

유의해야 할 테이블의 특징은,

테이블 종류

그럼 각 테이블이 어떤 역할을 하는지 구체적으로 보자.

filter table

패킷 필터링을 하는, 패킷이 원하는 요청대로 가도될지 말지를 결정하는 테이블.
그냥 흔히 이야기하는 방화벽 관련 규칙이라 하면 이 테이블을 사용하는 것이다.

nat table

이름 그대로 nat 규칙을 구현하는 테이블.
네트워크 스택에 패킷이 들어오면, 패킷의 소스나 목적지 주소를 바꾼다.
이를 통해 패킷, 트래픽이 라우팅되는 경로에 영향을 준다.
대체로 직접적 접근이 안되는 트래픽을 라우팅할 때 사용한다.

mangle table

패킷 헤더를 조작할 때 사용하는 테이블.
예를 들면 패킷의 ttl 값을 싹 바꿔서, 패킷이 더 오래 네트워크를 타고 다니게 할 수도 있다.
다른 네트워크 툴이나 테이블의 조작을 위해, 내부적인 커널 마크를 남기는 일도 할 수 있다고 한다.

주의

이 부분은 소켓에 대한 이해를 필요로 한다.

주의할 점으로, 여기에서 말하는 패킷 조작은 실제 패킷을 조작하는 게 아니다.
커널에 들어온 패킷은 하나의 구조체로 타입으로 추상화되는데, 이때 IP 패킷 구조체의 헤더 정보를 조작한다는 것이다.
이것이 중요한 이유는 패킷을 조작한다고 해도 해당 내용은 한 노드 내에서만 인식될 수 있기 때문이다.

raw table

굉장히 제한적인 목적을 가지고 있는 테이블.
연결 추적(connection tracking)을 거부하기 위해 패킷에 마킹하는 매커니즘을 제공하기 위해 존재한다.

연결 추적?

넷필터에는 conntrack, 즉 연결을 추적하는 기능이 있다.
L7의 HTTP 요청은 사실 저수준 계층에서 보면 여러 개의 패킷으로 쪼개져 있다.
이때 분절되어 날아오는 여러 패킷을 파편이 아닌, 세션이나 지속적인 연결로 인식하게 돕는 것이 바로 컨트랙이다.
(tcp 단위로 컨트랙하는 게 기본)
참고로 이 기능은 네트워크 인터페이스에 접촉한 시점에 거의 즉시 추적이 시작된다고 한다.
패킷이 이전 패킷과의 관계에 따라 평가될 수 있도록 한다는 점에서 iptables는 stateful하다고 흔히 이야기한다.

security table

SELinux의 보안 컨텍스트 마킹을 매기기 위해 존재한다.
그래서 SELinux나 관련 툴들이 패킷을 다룰 때 도움을 준다고 한다.
커넥션 별, 패킷 별 적용할 수 있다.
사용해본 적도 없고 여기에 규칙 쓰인 걸 본 적이 없어서 잘 모르겠다.

테이블과 체인의 관계

테이블은 우선순위가 있다고 했다.
그리고 체인들도, 네트워크 흐름따라 당연히 먼저 적용되는 놈들이 있다.

그래서 이게 순서를 나타내는 표이다.
위쪽부터 아래로 테이블이 적용되고, 왼쪽부터 오른쪽으로 체인이 발동된다.

몇 가지 추가사항

여기에서 nat는 두 개로 나뉘었는데, snat와 dnat를 나눴다.
라우팅 결정이 내려지고, 연결 트래킹이 일어나는 시점에 행으로 기입됐다.

이걸 토대로 예시를 들어보겠다.
혼자 웹서버를 띄우고 localhost에 curl 요청을 날린다고 쳐보겠다.
그럼 여기에서 두 가지 네트워크 흐름이 생성된다.

이렇게 이해를 하면 된다.
다시 말해 이 표를 볼 때는 열 순서대로, 그리고 그 내부에서는 행 순서대로 보면 된다는 것이다.
(아니 이렇게 보니까, 조금 더 개발자적으로 보려면 행렬을 뒤집는 게 나았겠다.)

참고로 연결을 추적되고 있다면, 첫 패킷의 결과가 정해지면 다른 패킷들은 추가적인 평가 없이 바로 바로 적용된다.

규칙

그래서 체인을 구성한다는 그 규칙들은 어떻게 생긴 놈들인가?
룰은 구체적으로 조건과, 실행으로 이뤄진다.
어떤 ip에서 왔다면(조건), 그 패킷을 버려라!(실행)
당연한 말이다..ㅋㅋ
근데 iptables는 이걸 또 뭔가 참 안 와닿는 표현으로 표현한다.

매칭

이게 조건에 해당하는 표현이다.
규칙은 어떤 패킷을 대상으로 하는지 기준이 필요하다.
프로토콜 타입, 아니면 목적지나 소스 주소나 포트, 헤더 등.. 매칭 조건은 정말 유연하고 확장 가능하다.
어떻게 잘 설정할지는.. 사용자 마음! 이러니 안 어려울 수가 있나

타겟

기준에 맞는 대상이 나왔다면 어떤 동작을 할지도 정해야 한다.
크게는 두 가지 동작이 있다.

근데 솔직히 이렇게만 개념을 이해하면 오히려 iptables를 사용하는데 더 헷갈리기만 한다.
한 테이블 내에서 적용할 수 있는 동작이 뭐가 있는지도 알 필요가 있다.
다음이 기본으로 제공되는 동작 타겟의 예시로, 적용할 수 있는 체인, 테이블에 제한이 있다는 것에 유의하자.

근데 왜 동작(action)이라 부르지 않고 타겟이라 부르는가?
위에서 체인 개념을 볼 때 커스텀 체인을 만들어서 해당 체인으로 패킷을 넘길 수 있다(점핑이라고 표현한다)고 했다.
규칙에는 조건에 매칭되는 패킷에 대해 타겟으로 체인을 지정할 수도 있다.
어떤 동작들에 대한 설정만이 아니라 어떤 체인으로 가야할지 대상을 정하기 때문에 Target이라고 부르는 것이다.

정리

|1000
이게 지금까지 말한 과정을 조금 더 자세하게 도식화한 그림이다.
처음에는 이게 뭔 소리인가 싶었는데, 조금 더 이해를 하고 보니 잘 보이는 것 같다.

이건 LoxiLB에 나온 iptables의 흐름 사진이다.
kube-proxy에서 어떻게 iptables 룰을 설정하고, 트래픽이 흐르는지에 대한 내용인데, 직관적이라 가져와봤다.

다른 툴

관련 문서

이름 noteType created
iptables knowledge 2024-12-30
kube-proxy knowledge 2025-02-12
2주차 - 네트워크 project 2025-02-25
8W - 가상머신 통합하기 published 2025-06-01
8W - 엔보이와 iptables 뜯어먹기 published 2025-06-01
9W - 앰비언트 모드 구조, 원리 published 2025-06-07
9W - 앰비언트 헬름 설치, 각종 리소스 실습 published 2025-06-07
E-iptables와 nftables의 차이 topic/explain 2024-12-30
E-이스티오의 데이터 플레인 트래픽 세팅 원리 topic/explain 2025-05-27
E-이스티오 DNS 프록시 동작 topic/explain 2025-06-01
E-이스티오 가상머신 통합 topic/explain 2025-06-01
E-앰비언트 ztunnel 트래픽 경로 분석 topic/explain 2025-06-07

참고

  1. https://www.netfilter.org/ ↩︎

  2. https://en.wikipedia.org/wiki/Netfilter ↩︎

  3. https://pr0gr4m.github.io/linux/kernel/netfilter/ 이 블로그 대박이다.. ↩︎

  4. https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture ↩︎

  5. https://thermalcircle.de/doku.php?id=blog:linux:nftables_packet_flow_netfilter_hooks_detail ↩︎

  6. https://hayz.tistory.com/entry/번역-Iptables-및-Netfilter-구조에-대한-심층분석 ↩︎