iptables Connection Tracking 테이블 구조와 튜닝 포인트

리눅스에서 iptables 기반 방화벽과 NAT 기능의 핵심은 Connection Tracking(conntrack)이다.
conntrack은 단순히 패킷을 필터링하는 수준을 넘어, 연결의 상태를 기억하고 흐름을 추적함으로써 stateful 방화벽과 NAT를 가능하게 한다.
하지만 트래픽이 증가하면 conntrack 테이블은 쉽게 병목 지점이 될 수 있으며, 적절한 튜닝 없이는 성능 저하나 패킷 드롭이 발생한다.
이 글에서는 iptables Connection Tracking 테이블의 구조와 동작 방식, 그리고 실무에서 중요한 튜닝 포인트를 기술적으로 분석한다.

1. Connection Tracking(conntrack)의 역할

Connection Tracking은 커널이 네트워크 연결의 상태를 추적하는 메커니즘이다.
iptables에서 -m state 또는 -m conntrack 매치를 사용할 수 있는 이유도 이 기능 덕분이다.

conntrack이 수행하는 핵심 역할은 다음과 같다.

TCP/UDP/ICMP 세션 상태 추적
NEW, ESTABLISHED, RELATED 상태 판별
NAT(SNAT/DNAT) 매핑 유지
비정상 패킷 탐지 및 차단

즉, conntrack은 네트워크 흐름의 메모리 역할을 하며, 방화벽과 NAT의 기반이 된다.

2. Connection Tracking 테이블의 기본 구조

conntrack 테이블은 커널 내부의 해시 테이블 구조로 관리된다.
각 엔트리는 하나의 네트워크 흐름(flow)을 나타낸다.

엔트리에 포함되는 주요 정보

원본/응답 방향 IP 주소
원본/응답 방향 포트
프로토콜(TCP, UDP, ICMP 등)
연결 상태(NEW, ESTABLISHED 등)
타임아웃 정보
NAT 변환 정보(있는 경우)

TCP의 경우 양방향 패킷 흐름을 하나의 엔트리로 관리하며, UDP처럼 연결 개념이 약한 프로토콜도 논리적 세션으로 추적한다.

3. conntrack 테이블 용량과 한계

conntrack 테이블은 유한한 크기를 가진다.
기본 최대 엔트리 수는 시스템 메모리에 따라 자동 계산되지만, 고트래픽 환경에서는 부족한 경우가 많다.

4. 프로토콜별 conntrack 동작 특성

TCP

3-way handshake 기반 상태 추적
FIN/RST 이후 타임아웃까지 엔트리 유지
상태 관리가 정교하지만 엔트리 유지 시간이 길 수 있음

UDP

연결 개념이 없으므로 단순 타임아웃 기반
짧은 타임아웃이 중요
DNS, 스트리밍 트래픽에서 엔트리 급증 가능

ICMP

요청/응답 쌍 기반
비교적 짧은 수명

UDP 기반 서비스가 많을수록 conntrack 테이블이 빠르게 소모되는 경향이 있다.

5. 핵심 튜닝 포인트 1: 테이블 크기 조정

가장 기본적인 튜닝은 최대 엔트리 수 조정이다.

트래픽 규모 대비 충분한 nf_conntrack_max 설정
메모리 사용량 고려 필수
대략적인 계산: 엔트리 하나당 수백 바이트 메모리 사용

일반적인 서버에서는 기본값보다 2~4배 이상 늘리는 경우가 많다.
단, 무작정 크게 설정하면 메모리 압박이 발생할 수 있다.

6. 핵심 튜닝 포인트 2: 타임아웃 최적화

conntrack 성능 튜닝의 핵심은 불필요한 엔트리를 빨리 제거하는 것이다.

중요 타임아웃 항목

TCP ESTABLISHED timeout
TCP FIN_WAIT timeout
UDP timeout
UDP stream timeout

특히 UDP timeout을 줄이면 다음 효과가 있다.

단기 트래픽 엔트리 빠른 회수
DNS, 미디어 트래픽 환경에서 효과적

타임아웃은 워크로드 특성에 맞게 조정해야 하며, 너무 짧게 설정하면 정상 트래픽이 끊길 수 있다.

7. 핵심 튜닝 포인트 3: conntrack 사용 최소화

모든 패킷이 반드시 conntrack을 거칠 필요는 없다.

conntrack을 우회하면 좋은 경우

로컬 서비스 간 트래픽
단순 포워딩 트래픽
상태 추적이 필요 없는 패킷

이를 위해 다음 전략이 사용된다.

-j NOTRACK 또는 raw 테이블 활용
특정 인터페이스/포트에 대해 conntrack 비활성화

이 방식은 conntrack 부하를 크게 줄일 수 있지만, NAT나 stateful 필터링과는 함께 사용할 수 없다는 점을 고려해야 한다.

8. 핵심 튜닝 포인트 4: NAT 환경에서의 고려 사항

NAT를 사용하는 경우 conntrack 의존도는 더욱 커진다.

주의할 점

모든 NAT 연결은 conntrack 엔트리 필수
대규모 SNAT 환경에서 테이블 급증
Keepalive 트래픽으로 엔트리 장시간 유지

NAT 서버에서는

더 큰 테이블
더 짧은 타임아웃
적극적인 모니터링
이 함께 필요하다.

9. 모니터링과 장애 징후 파악

conntrack 문제는 사전에 감지하는 것이 중요하다.

확인해야 할 지표

nf_conntrack_count / nf_conntrack_max 비율
table full 로그 발생 여부
연결 생성 실패 증가
트래픽 대비 비정상적인 latency 증가

실무에서는 이 비율이 70~80%를 넘기기 전에 대응하는 것이 안정적이다.

10. 정리 및 결론

iptables Connection Tracking은 리눅스 네트워크 스택의 핵심이지만,
트래픽이 많아질수록 가장 먼저 병목이 되는 요소이기도 하다.

핵심 요약

conntrack은 stateful 방화벽과 NAT의 기반
테이블 크기와 타임아웃이 성능의 핵심
UDP·NAT 환경에서 특히 주의 필요
불필요한 트래픽은 conntrack 우회 고려
모니터링 없이는 안정적인 운영 불가능

conntrack 튜닝은 단순한 설정 변경이 아니라
트래픽 특성과 서비스 구조를 이해한 뒤 적용해야 하는 네트워크 최적화 작업이다.
올바른 튜닝을 통해 방화벽 성능과 네트워크 안정성을 동시에 확보할 수 있다.