NGFW 하드웨어 오프로드

차세대 방화벽(NGFW) 하드웨어 오프로드 아키텍처 3대 유형(CPU중심 Lookaside·SoC중심 Lookaside·Inline SmartNIC/DPU), Fast/Slow/Exception 경로, Stateful 방화벽·NAT·ACL·QoS·터널(Tunnel)·IPSec 오프로드, 상용 NGFW 비교, Linux 커널 기반 NGFW 파이프라인(Pipeline), 세션 오프로드 결정 트리 종합 가이드

단계별 학습 로드맵

선수 지식 수준 가이드

핵심 용어 정리

NGFW HW 오프로드 개요

NGFW의 정의

차세대 방화벽(Next-Generation Firewall, NGFW)은 전통적인 L3/L4 패킷 필터링 방화벽에 다음 기능을 통합한 보안 장비입니다:

• Deep Packet Inspection (DPI) — L7 애플리케이션 프로토콜 분석
• Application Identification (App-ID) — 포트 번호가 아닌 실제 애플리케이션 식별
• Intrusion Prevention System (IPS) — 시그니처 기반 공격 탐지/차단
• SSL/TLS Inspection — 암호화(Encryption)된 트래픽 복호화(Decryption) 후 검사
• Stateful Session Tracking — conntrack 기반 연결 상태 추적
• URL Filtering / Threat Intelligence — 평판 기반 차단

이러한 기능은 패킷당 처리 비용을 크게 증가시키므로, 하드웨어 오프로드를 통해 검증이 완료된 세션의 후속 패킷을 CPU를 거치지 않고 직접 전달하는 것이 성능의 핵심입니다.

NGFW 세대별 진화

5세대의 핵심 차이점은 프로그래머블 오프로드입니다. 기존 ASIC은 벤더가 설계한 고정 파이프라인만 지원했지만, SmartNIC/DPU는 TC flower, eBPF, P4 등으로 오프로드 로직을 사용자가 정의할 수 있습니다.

NGFW 배치 모델

NGFW는 네트워크 내 위치와 동작 방식에 따라 여러 배치 모델이 있으며, 각 모델에서 HW offload의 적용 범위가 달라집니다:

전통 FW vs NGFW 비교

오프로드 필요성

NGFW에서 모든 패킷을 CPU에서 처리하면 다음과 같은 병목이 발생합니다:

• DPI 처리량: Suricata/Snort 단일 코어 처리량은 약 1~5 Gbps
• CPS (Connections Per Second): conntrack NEW + DPI 첫 분류까지 코어당 수만~수십만 CPS
• 메모리 대역폭(Bandwidth): 패킷 데이터 + conntrack 테이블 + DPI 시그니처 DB 접근

100Gbps 이상 인터페이스에서 NGFW를 운영하려면, ESTABLISHED 세션의 후속 패킷을 하드웨어에서 처리하고 CPU는 NEW 세션과 예외 상황에만 집중해야 합니다.

트래픽 프로파일과 오프로드 효과

실제 네트워크 트래픽에서 세션의 특성을 분석하면 오프로드의 효과를 정량적으로 이해할 수 있습니다:

핵심 인사이트: 세션 수로는 단수명 세션이 압도적이지만, 실제 트래픽 볼륨(바이트)의 80%는 소수의 장수명 세션이 차지합니다. 이 장수명 세션을 HW offload하면 전체 CPU 부하의 대부분을 해소할 수 있습니다.

NGFW 핵심 성능 지표

NGFW 성능을 평가할 때 반드시 구분해야 하는 핵심 메트릭입니다. 벤더 데이터시트는 대부분 "방화벽 처리량"만 강조하지만, 실제 NGFW 성능은 모든 보안 기능을 활성화한 상태에서 측정해야 합니다:

오프로드 아키텍처 3대 유형

NGFW 하드웨어 오프로드는 패킷이 처리되는 주체와 경로에 따라 크게 세 가지 아키텍처로 분류됩니다. 이 분류는 앞서 소개한 Fast/Slow/Exception 3계층 경로가 어떤 하드웨어에서, 어떤 방식으로 구현되는지를 결정하는 근본적인 설계 선택입니다.

• CPU중심 룩어사이드(CPU-Centric Lookaside) — CPU가 전체 패킷 처리 파이프라인을 주도하고, 특정 기능(암호화, 패턴 매칭 등)만 외장 가속기에 위임
• SoC중심 룩어사이드(SoC-Centric Lookaside) — 전용 네트워크 프로세서(NP) 또는 ASIC이 Fast Path를 전담하고, 예외 패킷만 CPU로 전달
• 인라인(Inline) — SmartNIC/DPU가 데이터 경로 자체에서 패킷을 처리하여 호스트 CPU를 완전히 우회

세 아키텍처는 상호 배타적이 아니며, 상용 NGFW는 기능별로 이를 혼합(Hybrid)하여 사용합니다. 예를 들어 Fortinet은 세션 오프로드에 SoC중심(NP7), SSL 복호화에 SoC중심(SP5), DPI에 CPU중심(CP9+CPU)을 동시에 적용합니다. 아래에서는 각 아키텍처의 전체 패킷 처리 관점에서의 동작 원리, 장단점, 적용 사례를 상세히 살펴봅니다.

CPU중심 룩어사이드 아키텍처

CPU중심 룩어사이드(CPU-Centric Lookaside) 아키텍처에서 범용 CPU(x86, ARM 서버)가 NGFW 파이프라인의 모든 단계를 직접 실행합니다. Netfilter 훅 체인, conntrack 상태 머신, nftables 규칙 평가, DPI 엔진(Suricata/nDPI) 호출이 모두 CPU에서 수행됩니다. 특정 연산이 CPU에 과도한 부하를 주는 경우에만 해당 작업을 PCIe 버스를 통해 외장 가속기(Lookaside 엔진)에 위임하고, 결과를 돌려받습니다.

동작 원리

1. 패킷 수신: NIC이 패킷을 수신하여 DMA로 호스트 메모리에 적재 → NAPI/인터럽트로 CPU에 통보
2. 전체 파이프라인 CPU 실행: Netfilter PREROUTING → conntrack → FORWARD(nftables ACL) → NFQUEUE(DPI) → POSTROUTING(NAT) 전 과정을 CPU가 순차 처리
3. Lookaside 위임(선택적): 암호화(QAT), 정규식 매칭(HyperScan FPGA), 압축(IAA) 등 CPU 집약적 연산만 가속기에 전송 → 비동기 완료 대기
4. 오프로드 판정 후 SW Fast Path: ESTABLISHED + ACCEPT 세션은 nf_flowtable에 등록하여 이후 패킷의 Netfilter 훅 체인을 건너뜀 (여전히 CPU에서 실행, 단 경로 단축)
5. 패킷 송신: CPU가 ip_output()을 호출하여 NIC TX 큐에 패킷 전달

핵심 특성

CPU중심 Lookaside의 패킷 흐름

아래 다이어그램은 CPU중심 아키텍처에서 새 세션(Slow Path)과 확립된 세션(SW Fast Path)의 처리 흐름을 보여줍니다. Lookaside 가속기는 파이프라인의 특정 단계에서만 호출됩니다.

CPU중심 아키텍처의 성능 프로파일

CPU중심 아키텍처에서의 Crypto Offload

CPU중심 아키텍처의 가장 일반적인 Lookaside 대상은 암호화 연산입니다. SSL Inspection이 활성화된 NGFW에서 CPU의 60~80%가 TLS 핸드셰이크(RSA/ECDHE)와 레코드 암·복호화(AES-GCM)에 소비되므로, 이를 PCIe 가속기(QAT, NITROX)에 위임하면 CPU 코어를 DPI에 집중할 수 있습니다.

CPU중심 아키텍처에서 QAT 가속기를 활용한 대표적인 NGFW crypto 파이프라인은 다음과 같습니다:

/* CPU중심 Lookaside NGFW crypto 파이프라인 */

[새 TLS 세션 - Slow Path]
패킷 수신 → conntrack NEW → nftables ACL ACCEPT
  → SSL MITM Proxy (nginx/haproxy)
    → TLS ClientHello 수신
    → QAT Lookaside: RSA-2048 서명 / ECDHE P-256 키 교환
      → CPU: -EINPROGRESS → 다른 패킷 처리 → QAT IRQ → 콜백
    → TLS 핸드셰이크 완료 → 대칭키 확보
    → setsockopt(SOL_TLS) → kTLS 활성화 (NIC inline 가능)
  → NFQUEUE → Suricata DPI (평문 검사)
  → Verdict ACCEPT → flowtable 등록

[확립된 TLS 세션 - Fast Path]
패킷 수신 → NIC Inline: kTLS 복호화 (AES-GCM)
  → flowtable bypass → NAT rewrite → NIC Inline: kTLS 재암호화 → TX
  → CPU 부하: 0%

SoC중심 룩어사이드 아키텍처

SoC중심 룩어사이드(SoC-Centric Lookaside) 아키텍처에서는 전용 네트워크 프로세서(NP) 또는 ASIC이 데이터 플레인의 Fast Path를 전담합니다. NP는 패킷 파싱, 세션 테이블 룩업, NAT rewrite, ACL 매칭, QoS 스케줄링을 하드웨어 파이프라인으로 와이어 속도에 가깝게 처리합니다. CPU는 컨트롤 플레인(정책 배포, 로깅, 관리)과 예외 패킷 처리(새 세션의 DPI, ALG, 정책 미매칭 패킷)만 담당합니다.

핵심 설계 원리는 "NP가 처리할 수 있는 패킷은 CPU에 전달하지 않습니다"입니다. 새 세션의 첫 패킷만 CPU로 올라가고(Slow Path), CPU가 보안 검사를 완료하면 세션 정보를 NP의 하드웨어 세션 테이블에 프로그래밍합니다. 이후 해당 세션의 모든 패킷은 NP에서 직접 처리됩니다.

동작 원리

1. 패킷 수신: 물리 포트에서 패킷이 NP ASIC에 직접 도달 (호스트 메모리 DMA 없음)
2. NP 파이프라인 실행: 패킷 파서 → 세션 테이블 TCAM/Hash 룩업 → 매칭 시 NAT rewrite + ACL + QoS + 포워딩을 하드웨어에서 처리 → 즉시 TX
3. 세션 미스 → CPU 전달(Lookaside): 세션 테이블에 매칭되지 않는 패킷(새 세션, 예외)은 내부 버스를 통해 CPU로 전달
4. CPU에서 Slow Path 처리: conntrack NEW, nftables ACL, DPI/IPS 검사 수행
5. 세션 프로그래밍: CPU가 검사 결과(ACCEPT + 세션 정보)를 NP의 세션 테이블에 기록 → 이후 패킷은 NP에서 직접 처리

핵심 특성

SoC중심 Lookaside의 패킷 흐름

상용 NGFW의 SoC중심 구현 사례

SoC중심 아키텍처에서의 Crypto Offload

SoC중심 아키텍처에서 암호화 처리는 두 가지 경로로 나뉩니다. NP ASIC 내장 크립토 엔진이 Fast Path에서 IPSec을 인라인 처리하고, SoC 내부의 별도 크립토 코프로세서(CAAM, OCTEON CPT, SP5 등)가 SSL/TLS 복호화를 Lookaside로 처리합니다.

SoC중심 아키텍처의 핵심 장점은 NP와 크립토 엔진이 동일 SoC 다이 내에 있어 내부 버스(AXI/AMBA)로 직접 통신하는 점입니다. PCIe를 거치지 않으므로 Lookaside 지연이 1~5μs로, CPU중심 아키텍처의 QAT(10~50μs) 대비 5~10배 빠릅니다. 이에 대한 상세 분석은 SoC중심 룩어사이드(암호화) 절을 참조하세요.

인라인(Inline) 오프로드 아키텍처

인라인(Inline) 아키텍처에서는 SmartNIC/DPU가 네트워크 데이터 경로 자체에 위치하여 패킷이 호스트 CPU를 거치지 않고 NIC 하드웨어에서 직접 처리됩니다. SoC중심 아키텍처의 NP와 유사하지만, 핵심 차이점은 표준 Linux 커널 인터페이스(TC flower, eSwitch, flowtable HW offload)를 통해 오프로드 규칙을 프로그래밍하는 점입니다. 벤더 전용 API가 아닌 오픈 표준을 사용하므로 리눅스 기반 NGFW에서 가장 주목받는 아키텍처입니다.

인라인 아키텍처의 근본적인 설계 원리는 "확립된 세션의 패킷이 호스트 메모리를 전혀 건드리지 않습니다"입니다. NIC의 eSwitch FDB에 설치된 TC flower 규칙이 5-tuple + conntrack 상태로 매칭하여, NAT rewrite, 터널 encap/decap, VLAN 처리를 NIC ASIC에서 직접 수행한 뒤 대상 포트로 전달합니다.

동작 원리

1. 패킷 수신: 이더넷 프레임이 NIC의 물리 포트에 도착
2. eSwitch FDB 룩업: NIC 내장 eSwitch가 FDB 테이블에서 5-tuple + ct_state 매칭 → HW 규칙 히트(Hit) 시 즉시 처리
3. HW Fast Path 처리: NAT rewrite, TTL 감소, 터널 encap/decap, VLAN push/pop을 NIC ASIC에서 실행 → 대상 포트 TX 큐로 직접 전달 (DMA-to-DMA, CPU 인터럽트 없음)
4. FDB 미스 → 호스트 CPU: 매칭되지 않는 패킷은 일반 NIC RX 큐를 통해 호스트 CPU로 DMA 전달 → Slow Path(Netfilter + DPI) 처리
5. 오프로드 설치: CPU에서 세션이 ESTABLISHED + ACCEPT로 확인되면 nf_flowtable이 TC flower 규칙을 생성하고 ndo_setup_tc()를 통해 NIC 드라이버에 전달 → eSwitch FDB에 HW 규칙 설치

핵심 특성

인라인 오프로드의 패킷 흐름

인라인 아키텍처의 Linux 커널 연동

인라인 아키텍처의 핵심 장점은 표준 Linux 커널 API를 통한 HW 오프로드입니다. NGFW 관리자는 일반적인 nftables/TC 명령으로 정책을 설정하면, 커널이 자동으로 NIC 하드웨어에 규칙을 설치합니다.

# 1. nftables에서 flowtable HW offload 정의
nft add table inet filter
nft add flowtable inet filter ft {
    hook ingress priority 0 \;
    devices = { enp1s0f0np0, enp1s0f1np0 } \;
    flags offload \;       # ← HW offload 핵심 플래그
}

# 2. ESTABLISHED 세션을 flowtable으로 전달
nft add chain inet filter forward { type filter hook forward priority 0 \; }
nft add rule inet filter forward ct state established,related flow add @ft

# 3. 커널이 자동으로 TC flower 규칙 생성 → NIC eSwitch FDB에 설치
# 확인: HW offload 규칙 조회
tc -s filter show dev enp1s0f0np0 ingress
# filter protocol ip pref 1 flower chain 0
#   ct_state +est+trk   ← HW에서 conntrack 상태 매칭
#   action mirred (Egress Redirect to device enp1s0f1np0)
#   in_hw in_hw_count 1  ← HW offload 확인

인라인 아키텍처에서의 Crypto Offload

인라인 아키텍처에서 SmartNIC/DPU는 세션 오프로드(flowtable)뿐 아니라 암호화도 인라인으로 처리합니다. 패킷이 NIC ASIC을 통과하는 과정에서 암·복호화가 와이어 속도로 수행되므로, 호스트 메모리에 암호화된 데이터가 전혀 도달하지 않습니다.

인라인 crypto의 핵심 제약은 AES-GCM 외 알고리즘 미지원과 SA/TLS context 수 제한(NIC 메모리 의존)입니다. 이 제약을 초과하는 세션은 자동으로 SW 폴백됩니다. 상세 알고리즘 매트릭스는 아키텍처별 알고리즘 지원 매트릭스를, NIC 벤더별 지원 현황은 전용 크립토 가속기 절을 참조하세요.

3대 아키텍처 종합 비교

아래 표는 세 아키텍처를 전체 NGFW 파이프라인 관점에서 비교합니다. 암호화에 특화된 비교는 암호화 오프로드 3종 비교를 참조하세요.

아키텍처 선택 가이드

데이터 플레인 아키텍처

Fast Path (HW + SW)

Fast Path는 이미 보안 검사가 완료된 세션의 후속 패킷을 최소 비용으로 전달하는 경로입니다. 두 가지 수준이 있습니다:

HW Fast Path (eSwitch FDB)

eSwitch의 switchdev 모드에서 TC flower 규칙으로 ct_state +est +trk 매칭 후 FDB(Forwarding Database) 룰을 NIC 하드웨어에 설치합니다. 패킷이 NIC에 도착하면 CPU를 거치지 않고 직접 전달됩니다.

HW Fast Path의 동작을 단계별로 보면:

1. 패킷 도착: 이더넷 프레임이 NIC의 RX 큐에 도달
2. eSwitch FDB lookup: NIC 내장 하드웨어가 5-tuple + ct_state로 FDB 테이블을 검색
3. 매칭 시 HW 처리: NAT rewrite (IP/Port/Checksum), TTL 감소, 터널 encap/decap, VLAN push/pop
4. 직접 TX: 처리된 패킷이 대상 포트의 TX 큐로 직접 전달 (DMA to DMA, CPU interrupt 없음)

• 수행: L2/L3/L4 헤더 매칭, NAT rewrite (SNAT/DNAT), VLAN push/pop, 터널 encap/decap (VXLAN/GRE/Geneve), conntrack 상태 확인
• 미수행: DPI 재검사, TCP window 검증, 시퀀스 번호 추적, ALG 프로토콜 파싱, IP 단편화(Fragmentation) 처리
• 처리량: NIC 라인레이트 (25/50/100/200Gbps)

SW Fast Path (nf_flowtable)

nf_flowtable은 커널 소프트웨어에서 conntrack을 bypass하고 직접 L3 forwarding을 수행합니다. HW offload가 불가능한 경우(예: NIC 미지원, 복잡한 NAT, 특정 터널)의 폴백 경로입니다.

SW Fast Path는 커널의 Netfilter ingress 훅(priority -10)에서 동작하여, 일반 Netfilter 체인(PREROUTING → FORWARD → POSTROUTING)을 완전히 건너뜁니다. 이를 통해 nftables 규칙 평가, conntrack 상세 추적, NFQUEUE 전달 등의 오버헤드를 제거합니다.

• 수행: conntrack bypass, L3 forwarding, NAT rewrite, TTL 감소, 통계 카운터
• 미수행: Netfilter 훅 체인, DPI, TCP 상태 머신 상세 추적
• 처리량: 코어당 약 10~40Gbps (패킷 크기 의존)

Fast Path 전환의 커널 내부 흐름

패킷이 Fast Path로 처리되는 과정을 커널 코드 수준에서 살펴보면:

/* net/netfilter/nf_flow_table_ip.c */
/* flowtable ingress 훅에서 호출되는 핵심 함수 */
static unsigned int
nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb,
                        const struct nf_hook_state *state)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct nf_flowtable *flow_table = priv;
    struct flow_offload_tuple tuple = {};
    enum flow_offload_tuple_dir dir;
    struct flow_offload *flow;

    /* 1. skb에서 5-tuple 추출 */
    if (nf_flow_tuple_ip(skb, state->in, &tuple) < 0)
        return NF_ACCEPT;  /* 추출 실패 → Slow Path */

    /* 2. flowtable에서 lookup */
    tuplehash = flow_offload_lookup(flow_table, &tuple);
    if (!tuplehash)
        return NF_ACCEPT;  /* 미등록 플로우 → Slow Path */

    flow = container_of(tuplehash, struct flow_offload,
                        tuplehash[dir]);

    /* 3. TEARDOWN 상태면 Slow Path로 복귀 */
    if (flow_offload_stale_flow(flow))
        return NF_ACCEPT;

    /* 4. NAT rewrite 적용 */
    if (flow->flags & FLOW_OFFLOAD_SNAT)
        nf_flow_snat_ip(skb, thoff, ...);
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_ip(skb, thoff, ...);

    /* 5. TTL 감소 + routing 적용 */
    ip_decrease_ttl(iph);
    skb_dst_set_noref(skb, &rt->dst);

    /* 6. 직접 전달 (Netfilter 훅 체인 건너뜀) */
    ip_output(state->net, state->sk, skb);
    return NF_STOLEN;  /* skb 소유권 가져감 → 훅 종료 */
}

flow_offload 구조체

/* include/net/netfilter/nf_flow_table.h */
struct flow_offload_tuple {
    union {
        struct in_addr   src_v4;   /* IPv4 소스 주소 */
        struct in6_addr  src_v6;   /* IPv6 소스 주소 */
    };
    union {
        struct in_addr   dst_v4;
        struct in6_addr  dst_v6;
    };
    struct {
        __be16  src;  /* 소스 포트 */
        __be16  dst;  /* 목적지 포트 */
    } port;
    u8      l3proto;    /* AF_INET / AF_INET6 */
    u8      l4proto;    /* IPPROTO_TCP / IPPROTO_UDP */
    struct dst_entry  *dst_cache; /* 라우팅 캐시 */
    int     iifidx;     /* ingress 인터페이스 인덱스 */
    int     oifidx;     /* egress 인터페이스 인덱스 */
};

struct flow_offload {
    struct flow_offload_tuple_rhash tuplehash[2]; /* [ORIGINAL] + [REPLY] */
    struct nf_conn  *ct;         /* 대응하는 conntrack 엔트리 */
    unsigned long    flags;      /* SNAT, DNAT, TEARDOWN 등 */
    u32              timeout;    /* GC 타임아웃 (jiffies) */
};

하나의 flow_offload는 양방향 플로우를 나타냅니다. tuplehash[0]은 ORIGINAL 방향, tuplehash[1]은 REPLY 방향의 5-tuple을 저장합니다. NAT가 적용된 경우 두 방향의 IP/포트가 다릅니다.

Slow Path (전체 검사)

새로운 연결의 첫 패킷(또는 아직 DPI 분류가 완료되지 않은 초기 패킷)은 전체 보안 파이프라인을 통과합니다. Slow Path는 NGFW의 보안 정밀도를 담당하며, 여기서의 결정이 세션의 나머지 수명 동안의 처리 방식을 결정합니다.

Slow Path에서의 패킷 처리 시간은 일반적으로 100us~5ms 범위입니다. DPI 엔진의 시그니처 수, 패킷 페이로드 크기, CPU 캐시(Cache) 히트율에 따라 달라집니다.

처리 순서:

1. Ingress ACL — nftables/TC filter 기반 정적 규칙 (IP/Port/Protocol 매칭)
2. conntrack — 연결 추적 테이블에 NEW 엔트리 생성 또는 기존 상태 갱신
3. NAT — SNAT/DNAT/MASQUERADE 주소 변환(Address Translation)
4. NFQUEUE — DPI 엔진으로 패킷 전달 (NFQUEUE & DPI 엔진 통합)
5. DPI / App-ID — 프로토콜 분류, 시그니처 매칭, 애플리케이션 식별
6. IPS — 시그니처 기반 공격 탐지
7. Verdict — ACCEPT/DROP/QUEUE 최종 판정

CPS 병목: Slow Path의 처리량은 주로 초당 새 연결(CPS)으로 측정됩니다. DPI 엔진에 따라 코어당 10K~100K CPS 범위이며, 이는 NGFW의 실질적 성능 한계를 결정합니다.

Slow Path 커널 호출 체인

/* Slow Path에서 새 패킷이 거치는 커널 함수 호출 순서 */

/* 1. PREROUTING: conntrack 입구 */
nf_conntrack_in()
  → resolve_normal_ct()
    → nf_conntrack_find_get()    /* 해시 테이블에서 기존 ct 검색 */
    → init_conntrack()            /* 미발견 시 NEW ct 생성 */
      → __nf_conntrack_alloc()   /* slab에서 nf_conn 할당 */
      → nf_ct_helper_find()      /* ALG 헬퍼 자동 할당 (SIP/FTP 등) */

/* 2. FORWARD: nftables 체인 평가 */
nft_do_chain()
  → nft_lookup_eval()            /* set/map 기반 ACL 매칭 */
  → nft_ct_eval()                /* ct state 조건 평가 */
  → nft_queue_eval()             /* NFQUEUE verdict → DPI 전달 */

/* 3. NFQUEUE: 유저스페이스 DPI 전달 */
nf_queue()
  → nf_queue_entry_get_refs()    /* 참조 카운터 증가 */
  → nfnetlink_queue_enqueue()    /* netlink 소켓으로 전달 */
  /* ... Suricata/nDPI가 패킷을 분석 ... */
  → nf_reinject()                /* verdict 반환 후 재주입 */

/* 4. POSTROUTING: NAT 적용 */
nf_nat_ipv4_out()
  → nf_nat_packet()
    → nf_nat_manip_pkt()         /* SNAT/DNAT 주소 변환 */

/* 5. 전송 */
ip_output()
  → ip_finish_output()
    → neigh_output()             /* L2 헤더 추가 후 NIC TX */

CPS 병목 분석

NGFW에서 Slow Path의 CPS가 전체 성능을 제한하는 원인을 세분화하면:

DPI가 전체 Slow Path 비용의 70~90%를 차지합니다. 따라서 DPI 완료 후 세션을 즉시 Fast Path로 전환하는 것이 핵심 최적화입니다.

Exception Path

이미 오프로드된 세션이라도 다음 경우에는 Fast Path에서 CPU로 복귀합니다:

• ALG 프로토콜 — FTP DATA, SIP RTP, H.323 등 동적 포트 할당이 필요한 프로토콜 (conntrack 헬퍼 & ALG)
• IP Fragment — 단편화된 패킷은 재조립 후 검사 필요
• ICMP Error — Destination Unreachable, TTL Exceeded 등 원래 세션의 상태 갱신 필요
• 정책 변경 재분류 — 관리자가 정책을 변경하면 기존 오프로드 플로우를 삭제하고 재평가
• TCP RST/FIN — 연결 종료 → flowtable GC → HW rule 삭제
• 바이트/패킷 임계치 — 보안 정책에 따라 주기적 샘플링을 위해 복귀

Exception Path 처리의 커널 내부

Exception Path의 핵심은 flow_offload_stale_flow() 검사와 HW trap 메커니즘입니다:

/* net/netfilter/nf_flow_table_core.c */
static bool flow_offload_stale_flow(struct flow_offload *flow)
{
    /* TEARDOWN 플래그: TCP FIN/RST 수신 시 설정 */
    if (flow->flags & FLOW_OFFLOAD_TEARDOWN)
        return true;

    /* DYING 플래그: GC에 의해 만료 대기 중 */
    if (flow->flags & FLOW_OFFLOAD_DYING)
        return true;

    /* conntrack이 삭제된 경우 */
    if (!nf_ct_is_confirmed(flow->ct))
        return true;

    return false;
}

/* GC 워커: 주기적으로 만료된 플로우 정리 */
static void nf_flow_offload_gc_step(struct nf_flowtable *flow_table)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct rhashtable_iter hti;

    rhashtable_walk_enter(&flow_table->rhashtable, &hti);
    rhashtable_walk_start(&hti);

    while ((tuplehash = rhashtable_walk_next(&hti))) {
        struct flow_offload *flow = ...;
        if (nf_flow_has_expired(flow) ||
            nf_ct_is_dying(flow->ct)) {
            /* HW rule 삭제 → 카운터 동기화 → ct 삭제 */
            flow_offload_teardown(flow);
            nf_flow_offload_del(flow_table, flow);
        }
    }
}

ALG 프로토콜의 Exception 처리

FTP, SIP, H.323 등 ALG(Application Level Gateway) 프로토콜은 제어 채널에서 동적으로 데이터 채널 포트를 협상합니다. 이 과정에서 conntrack helper가 페이로드를 파싱해야 하므로 오프로드가 불가능합니다.

NIC-Level 오프로드와 NGFW 파이프라인 상호작용

NIC 하드웨어에는 RSS, GRO, TSO, checksum offload 등 다양한 NIC-Level 오프로드 기능이 내장되어 있습니다. 이 기능들은 일반 네트워크 스택에서는 성능을 극대화하지만, NGFW 파이프라인과 결합하면 세션 친화성 깨짐, DPI 시그니처 미탐지, 바이트 카운터 불일치 등의 부작용을 일으킬 수 있습니다. 이 섹션에서는 각 NIC 오프로드 기능이 NGFW 파이프라인의 어느 단계와 상호작용하는지 분석하고, 최적 설정 방법을 제시합니다.

NIC 오프로드 기능과 NGFW 파이프라인 매핑

아래 표는 주요 NIC 오프로드 기능이 NGFW 파이프라인의 어떤 단계에 영향을 미치는지 정리한 것입니다. 영향의 성격은 긍정적(+), 부정적(-), 조건부(±)로 구분합니다.

RSS/aRFS/Flow Director와 NGFW 세션 친화성

NGFW에서 세션 친화성(Session Affinity)은 동일 세션의 모든 패킷이 동일 CPU 코어에서 처리되는 것을 의미합니다. 이것이 깨지면 conntrack 엔트리의 lock contention이 증가하고, DPI 엔진이 세션 상태를 공유해야 하므로 성능이 급격히 저하됩니다.

RSS 해시와 conntrack zone 정렬

RSS는 NIC 하드웨어가 수신 패킷의 L3/L4 헤더를 해시(Hash)하여 여러 RX 큐에 분배하는 기능입니다. 문제는 RSS 해시 함수가 conntrack의 양방향 세션 매핑을 인식하지 못합니다는 점입니다.

예시: TCP 연결 (10.1.1.1:5000 → 192.168.1.1:80)

  순방향 RSS 해시: hash(10.1.1.1, 192.168.1.1, 5000, 80) = 큐 3 → CPU 3
  역방향 RSS 해시: hash(192.168.1.1, 10.1.1.1, 80, 5000) = 큐 7 → CPU 7

  결과: 동일 세션의 양방향 패킷이 서로 다른 CPU에서 처리됨
  → conntrack spinlock contention 발생
  → DPI 워커가 세션 상태를 cross-CPU로 참조해야 함

이 문제를 해결하려면 RSS 해시 키를 대칭 해시(Symmetric Hash)로 설정하여 양방향 패킷이 같은 큐로 분배되도록 해야 합니다.

# RSS 해시 키 확인
ethtool -x eth0

# 대칭(Symmetric) RSS 해시 설정 (Toeplitz 키를 대칭으로 변경)
# 드라이버에 따라 지원 여부가 다름 (mlx5, i40e 등 지원)
ethtool -X eth0 hfunc toeplitz

# RSS 해시 필드 설정: L3+L4 (src/dst IP + src/dst port)
ethtool -N eth0 rx-flow-hash tcp4 sdfn
ethtool -N eth0 rx-flow-hash udp4 sdfn

# 대칭 해시 지원 확인 (mlx5 드라이버)
ethtool --show-priv-flags eth0 | grep symmetric
# symmetric_rss가 있으면:
ethtool --set-priv-flags eth0 symmetric_rss on

aRFS: DPI 워커 CPU로 패킷 유도

aRFS(Accelerated Receive Flow Steering)는 커널이 소켓이 처리되는 CPU를 NIC에 알려주어, 해당 소켓의 패킷을 그 CPU의 RX 큐로 직접 유도하는 기능입니다. NGFW에서 NFQUEUE를 통해 DPI 엔진(Suricata, nDPI 등)이 특정 CPU에서 워커 스레드를 실행하고 있을 때, aRFS를 활용하면 해당 패킷이 DPI 워커가 실행 중인 CPU로 직접 전달됩니다.

# aRFS 활성화
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 각 RX 큐의 flow table 크기 설정
for rxq in /sys/class/net/eth0/queues/rx-*/rps_flow_cnt; do
    echo 4096 > "$rxq"
done

# ntuple 필터 활성화 (aRFS가 NIC에 룰을 설치하기 위해 필요)
ethtool -K eth0 ntuple on

# aRFS 동작 확인
cat /proc/net/softnet_stat
# 열 9: flow_limit_count, 열 10: rps_count

aRFS는 NFQUEUE 기반 DPI 파이프라인에서 특히 효과적입니다. DPI 워커가 nfq_set_queue_maxlen()으로 큐를 바인딩한 CPU와 패킷이 도착하는 CPU가 일치하면, cross-CPU IPI(Inter-Processor Interrupt) 없이 패킷이 DPI 워커로 전달됩니다.

Flow Director: Exception Path 전용 큐

Flow Director는 NIC 하드웨어가 특정 플로우 패턴(Flow Pattern)을 매칭하여 지정된 RX 큐로 스티어링(Steering)하는 기능입니다. NGFW에서는 Exception Path 트래픽(TCP RST, ICMP error, ALG 프로토콜)을 전용 큐로 분리하여 Fast Path 트래픽과의 간섭을 방지하는 데 활용합니다.

# Flow Director: TCP RST 패킷을 큐 0(Exception 전용)으로 스티어링
ethtool -N eth0 flow-type tcp4 action 0 loc 100

# ICMP error를 Exception 큐로
ethtool -N eth0 flow-type ip4 proto 1 action 0 loc 101

# FTP 제어 채널(포트 21)을 ALG 전용 큐로
ethtool -N eth0 flow-type tcp4 dst-port 21 action 1 loc 102

# SIP 시그널링(포트 5060)을 ALG 전용 큐로
ethtool -N eth0 flow-type udp4 dst-port 5060 action 1 loc 103

# 설치된 Flow Director 규칙 확인
ethtool -n eth0

GRO/GSO/LRO와 DPI 검사

패킷 병합(Coalescing) 오프로드는 인터럽트(Interrupt) 빈도를 줄이고 처리량을 높이는 데 효과적이지만, DPI 엔진의 패킷 경계 인식에 중대한 영향을 미칩니다.

GRO와 DPI 시그니처 매칭

GRO(Generic Receive Offload)는 연속된 TCP 세그먼트(Segment)를 하나의 큰 sk_buff로 병합하는 소프트웨어 오프로드입니다. GRO가 활성화되면 하나의 sk_buff에 최대 64KB의 페이로드가 담기며, 이는 DPI 엔진에 다음과 같은 영향을 줍니다:

• Suricata MPM(Multi-Pattern Matcher) — GRO 병합된 버퍼에서 시그니처 매칭 시 패턴이 두 원래 패킷의 경계에 걸쳐 있으면 정상적으로 탐지됩니다(오히려 유리). 그러나 per-packet 카운터 기반 시그니처(예: "3번째 패킷의 offset 0에서 매칭")는 오동작합니다.
• nDPI 프로토콜 탐지 — 프로토콜 핸드셰이크(Handshake)의 첫 몇 패킷을 개별적으로 분석해야 하는 경우, GRO로 병합되면 핸드셰이크 패턴 인식이 실패할 수 있습니다.
• IPS bypass 공격 — 공격자가 의도적으로 작은 세그먼트(Segment)를 전송하여 시그니처를 분산시키는 evasion 기법에 대해, GRO는 세그먼트를 재조합하므로 오히려 방어에 유리합니다.

/* net/core/dev.c - GRO 수신 경로 */
static int napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
    /* GRO 레이어가 동일 플로우의 skb를 병합 시도 */
    skb_gro_reset_offset(skb);
    /* ...
     * 병합 성공 시: skb->len이 원래 MSS의 배수로 증가
     * → NFQUEUE로 전달 시 단일 대형 skb로 전달됨
     * → DPI 엔진은 이를 단일 "논리 패킷"으로 처리
     */
    return napi_gro_complete(napi, skb);
}

LRO와 flowtable 비호환성

LRO(Large Receive Offload)는 GRO와 유사하지만 NIC 하드웨어에서 TCP 세그먼트를 병합합니다. LRO의 핵심 문제는 TCP 헤더를 재작성하는 것입니다. LRO는 병합된 슈퍼 세그먼트에 대해 새로운 시퀀스 번호와 ACK 번호를 생성하는데, 이는 다음 문제를 일으킵니다:

• nf_flowtable 시퀀스 추적 실패 — flowtable은 conntrack의 TCP 시퀀스 윈도우 추적에 의존합니다. LRO가 시퀀스 번호를 변조하면 윈도우 검증이 실패하여 세션이 오프로드에서 제외됩니다.
• conntrack TCP strict 모드 충돌 — nf_conntrack_tcp_be_liberal=0(기본값)에서 LRO의 시퀀스 변조는 INVALID 상태를 유발합니다.
• 포워딩(Forwarding) 경로 문제 — LRO는 로컬 수신(Local Receive) 전용으로 설계되었으며, 포워딩 경로에서 사용하면 원래 패킷 구조를 복원할 수 없습니다.

# flowtable 사용 시 LRO 반드시 비활성화
ethtool -K eth0 lro off

# 확인
ethtool -k eth0 | grep large-receive-offload
# large-receive-offload: off

/* net/netfilter/nf_flow_table_core.c */
static bool nf_flow_offload_check(struct nf_flowtable *flowtable,
                                   struct flow_offload *flow)
{
    /*
     * LRO가 활성화된 인터페이스에서는 TCP 시퀀스 추적이
     * 불안정하므로 flowtable 오프로드가 실패할 수 있음.
     * 커널은 dev->features에서 NETIF_F_LRO 플래그를 확인하고
     * 포워딩 경로에서 자동으로 LRO를 비활성화함.
     * (dev_disable_lro() in net/core/dev.c)
     */
    ...
}

GSO와 TC flower 액션 재분할

GSO(Generic Segmentation Offload)는 TX 경로에서 커널이 큰 세그먼트를 MSS 단위로 분할하는 소프트웨어 오프로드입니다. TC flower 액션이 적용된 후 GSO 재분할이 필요한 경우, 다음과 같은 상호작용이 발생합니다:

TX 경로에서 TC flower + GSO 상호작용:

  1. 커널이 64KB GSO 세그먼트 생성
  2. TC egress에서 flower 규칙 매칭 → NAT rewrite 액션 실행
  3. NAT rewrite 후 체크섬 무효화
  4. GSO가 MSS 단위로 분할 (예: 1460B × 44 세그먼트)
  5. 각 분할 세그먼트에 대해 체크섬 재계산 필요

  → HW TSO가 활성화되면 단계 4~5를 NIC가 처리
  → HW TSO가 비활성화되면 CPU가 44회 분할 + 체크섬 계산

eSwitch HW offload에서는 TC flower 매칭, NAT rewrite, GSO 분할이 단일 하드웨어 파이프라인으로 처리되므로 이 문제가 발생하지 않습니다. 그러나 SW 경로에서는 TC flower 액션과 GSO의 순서가 성능에 영향을 줍니다.

TSO/Checksum 오프로드와 TC flower 카운터

TX 경로의 오프로드 기능은 NGFW의 트래픽 통계와 과금(Accounting)에 직접적인 영향을 미칩니다.

TSO와 바이트 카운터 불일치

TSO(TCP Segmentation Offload)가 활성화되면 커널은 최대 64KB의 슈퍼 세그먼트를 NIC로 전달하고, NIC 하드웨어가 이를 MSS 단위로 분할합니다. 문제는 TC flower의 패킷/바이트 카운터가 분할 전의 슈퍼 세그먼트를 기준으로 계산되는 것입니다.

TSO가 TC flower 카운터에 미치는 영향:

  실제 전송: 44 × 1460B = 64,240 바이트 (44 패킷)
  TC flower 카운터: 1 패킷, 64,240 바이트

  → 패킷 카운터가 실제보다 1/44로 축소
  → PPS(Packets Per Second) 기반 QoS 정책이 부정확해짐
  → conntrack byte accounting과 TC flower 카운터가 불일치

# TC flower 규칙의 카운터 확인
tc -s filter show dev eth0 ingress

# conntrack 바이트 카운터 비교
conntrack -L -o extended | grep "10.1.1.1"

# 불일치 확인 예시:
# TC flower: packets 1523, bytes 98,234,880
# conntrack: packets 67,012, bytes 98,234,880
# → 바이트는 일치하지만 패킷 수가 44배 차이

Checksum 오프로드와 NAT 재계산

NAT 변환 후에는 IP 헤더와 TCP/UDP 체크섬을 재계산해야 합니다. 체크섬 오프로드의 SW/HW 처리 방식에 따라 NGFW 파이프라인의 동작이 달라집니다:

/* net/netfilter/nf_nat_core.c - NAT 후 체크섬 처리 */
static void nf_nat_csum_recalc(struct sk_buff *skb,
                                u8 proto, __be32 oldip, __be32 newip)
{
    /*
     * skb->ip_summed == CHECKSUM_PARTIAL이면
     * 체크섬의 pseudo-header 부분만 업데이트하고
     * 나머지는 NIC HW가 최종 계산 (TX checksum offload)
     *
     * skb->ip_summed == CHECKSUM_NONE이면
     * 전체 체크섬을 SW에서 재계산
     */
    inet_proto_csum_replace4(&tcp_hdr(skb)->check, skb,
                             oldip, newip, true);
}

conntrack의 바이트 어카운팅(Byte Accounting)과 관련하여, NAT 변환 전후의 패킷 크기가 변하지 않으므로(IP/포트 필드만 변경) 바이트 카운터에는 영향이 없습니다. 다만 NAT helper(ALG)가 페이로드를 수정하는 경우(FTP PORT 명령의 IP 주소 변경 등)에는 페이로드 크기가 변할 수 있으며, 이때 체크섬과 시퀀스 번호 조정이 모두 필요합니다.

NGFW 최적 NIC 오프로드 설정

NGFW의 동작 모드에 따라 NIC 오프로드 설정이 달라져야 합니다. 아래는 두 가지 대표적인 모드별 권장 설정입니다.

DPI 모드 vs 순수 포워딩 모드 비교

자동화 설정 스크립트

#!/bin/bash
# NGFW NIC 오프로드 최적 설정 스크립트
# 사용법: ./ngfw-nic-offload.sh <인터페이스> <dpi|forward>

IFACE="${1:?Usage: $0  }"
MODE="${2:?Usage: $0  }"

echo "=== NGFW NIC Offload 설정: ${IFACE} (${MODE} 모드) ==="

# 공통 설정 (두 모드 공유)
ethtool -K "$IFACE" lro off          # flowtable 호환을 위해 항상 OFF
ethtool -K "$IFACE" tx on            # TX checksum offload ON
ethtool -K "$IFACE" rx on            # RX checksum offload ON
ethtool -K "$IFACE" tso on           # TCP Segmentation Offload ON
ethtool -K "$IFACE" gso on           # Generic Segmentation Offload ON

# 대칭 RSS 해시 (드라이버 지원 시)
ethtool --set-priv-flags "$IFACE" symmetric_rss on 2>/dev/null \
    && echo "[OK] symmetric RSS 활성화" \
    || echo "[SKIP] symmetric RSS 미지원"

# RSS 해시 필드: L3+L4 (양방향 세션 친화성)
ethtool -N "$IFACE" rx-flow-hash tcp4 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash udp4 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash tcp6 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash udp6 sdfn 2>/dev/null

case "$MODE" in
  dpi)
    echo "--- DPI 모드 (Suricata/IPS 연동) ---"
    ethtool -K "$IFACE" gro off        # DPI 시그니처 정확도 우선
    ethtool -K "$IFACE" ntuple on      # aRFS/Flow Director 필요
    
    # aRFS 활성화
    echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
    for rxq in /sys/class/net/"$IFACE"/queues/rx-*/rps_flow_cnt; do
        echo 4096 > "$rxq"
    done
    
    # Flow Director: Exception 패킷을 큐 0으로 분리
    ethtool -N "$IFACE" flow-type tcp4 action 0 loc 100 2>/dev/null
    ethtool -N "$IFACE" flow-type ip4 proto 1 action 0 loc 101 2>/dev/null
    
    echo "[DPI] GRO=off, aRFS=on, FlowDir=on"
    ;;
  forward)
    echo "--- 순수 포워딩 모드 (ACL + NAT) ---"
    ethtool -K "$IFACE" gro on         # 처리량 최적화
    
    echo "[FORWARD] GRO=on, aRFS=off, FlowDir=off"
    ;;
  *)
    echo "ERROR: 모드는 'dpi' 또는 'forward'만 지원합니다."
    exit 1
    ;;
esac

echo "=== 최종 오프로드 상태 ==="
ethtool -k "$IFACE" | grep -E "rx-checksumming|tx-checksumming|tcp-segmentation|generic-segmentation|generic-receive|large-receive|ntuple"

세션 오프로드 생명주기

첫 패킷 처리

TCP SYN 또는 첫 UDP 패킷이 도착하면 다음 과정을 거칩니다:

1. conntrack NEW — nf_conntrack_in()에서 새 conntrack 엔트리 생성
2. 전체 Netfilter 훅 — PREROUTING → FORWARD → POSTROUTING 체인의 모든 규칙 평가
3. NFQUEUE 전달 — DPI 엔진(Suricata, nDPI 등)이 패킷을 수신하여 프로토콜 분석 시작
4. App-ID 분류 — 첫 패킷만으로 부족하면 DPI 엔진이 추가 패킷 요청 (보통 3~10패킷)
5. Verdict 반환 — DPI 엔진이 ACCEPT 또는 DROP verdict를 반환

이 단계에서 오프로드는 발생하지 않습니다. 모든 검사가 완료될 때까지 Slow Path에 머뭅니다.

첫 패킷 conntrack 처리 상세

/* net/netfilter/nf_conntrack_core.c - 새 연결 생성 */
static struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
               const struct nf_conntrack_tuple *tuple,
               struct sk_buff *skb)
{
    struct nf_conn *ct;

    /* conntrack_max 초과 시 early drop (LRU) */
    if (nf_conntrack_max &&
        atomic_read(&net->ct.count) >= nf_conntrack_max) {
        if (!early_drop(net, hash))
            return ERR_PTR(-ENOMEM);  /* DROP: 테이블 가득 참 */
    }

    /* nf_conn 구조체 할당 (slab 캐시) */
    ct = __nf_conntrack_alloc(net, zone, tuple, ...);

    /* L4 프로토콜별 초기 상태 설정 */
    /* TCP: SYN_SENT, UDP: UNREPLIED */
    l4proto->new(ct, skb, dataoff);

    /* ALG helper 자동 할당 (포트 기반) */
    if (net->ct.sysctl_auto_assign_helper)
        nf_ct_helper_find(ct, tuple);

    /* unconfirmed list에 추가 (아직 해시에 삽입하지 않음) */
    /* POSTROUTING에서 confirm되면 해시 테이블에 삽입 */
    nf_ct_add_to_unconfirmed_list(ct);

    return &ct->tuplehash[IP_CT_DIR_ORIGINAL];
}

DPI 엔진의 패킷 분류 과정

NFQUEUE를 통해 유저스페이스 DPI 엔진(Suricata/nDPI)에 전달된 패킷의 분류 과정입니다:

일반적으로 3~10개 패킷이면 App-ID 분류가 완료됩니다. TLS 1.3에서 Encrypted Client Hello(ECH)가 사용되면 SNI가 암호화되어 더 많은 패킷이 필요하거나, SSL 복호화 없이는 분류가 불가능합니다.

ESTABLISHED 전환

TCP 3-way handshake가 완료되면 conntrack 상태가 ESTABLISHED로 전환됩니다. 이 시점에서 오프로드 여부를 결정합니다.

오프로드 결정 기준 4가지:

1. DPI 분류 완료 — App-ID가 결정되고 ALLOW verdict가 나왔는가?
2. ALG 프로토콜 아닌가 — FTP/SIP/H.323 등 동적 포트 할당이 필요한 프로토콜은 오프로드 불가
3. IP 단편화 아닌가 — 단편화된 패킷 스트림은 오프로드 불가
4. HW 지원 여부 — NIC/SmartNIC이 해당 플로우의 오프로드를 지원하는가? (터널 타입, NAT 유형 등)

오프로드 등록 커널 코드

nftables에서 flow add @ft가 실행되면 내부적으로 다음이 호출됩니다:

/* net/netfilter/nft_flow_offload.c */
static void nft_flow_offload_eval(const struct nft_expr *expr,
                                   struct nft_regs *regs,
                                   const struct nft_pktinfo *pkt)
{
    struct nf_conn *ct;
    enum ip_conntrack_info ctinfo;

    ct = nf_ct_get(pkt->skb, &ctinfo);

    /* 오프로드 가능 조건 확인 */
    if (nf_ct_is_dying(ct))
        goto err;
    if (nf_ct_helper(ct))        /* ALG helper 있으면 불가 */
        goto err;

    /* flow_offload 구조체 생성 */
    struct flow_offload *flow = flow_offload_alloc(ct);

    /* 라우팅 캐시 설정 */
    flow_offload_route_init(flow, &route);

    /* flowtable 해시에 등록 */
    flow_offload_add(&ft->ft, flow);

    /* HW offload 플래그가 있으면 NIC에도 등록 */
    if (ft->ft.flags & NF_FLOWTABLE_HW_OFFLOAD)
        nf_flow_offload_hw_add(net, flow, ct);
        /* → TC flower ct 규칙 → NIC eSwitch FDB 삽입 */
}

nf_flow_offload_hw_add()는 내부적으로 TC flower API를 호출하여 eSwitch에 FDB 규칙을 삽입합니다. 이 과정은 워크큐에서 비동기적으로 수행되므로, HW 규칙 설치까지 수 밀리초의 지연이 발생할 수 있습니다. 이 사이에 도착하는 패킷은 SW flowtable에서 처리됩니다.

오프로드 결정 트리

오프로드 해제

오프로드된 세션은 다음 상황에서 해제됩니다:

1. TCP FIN/RST — 연결 종료 신호가 감지되면 flowtable에서 DYING 상태로 전환
2. GC 타이머(Timer) — nf_flow_offload_gc_step()이 주기적으로 만료된 엔트리 정리
3. HW rule 삭제 — nf_flow_offload_hw_del()이 eSwitch FDB 규칙을 제거
4. conntrack 삭제 — 관련 conntrack 엔트리도 정리하여 리소스 해제

/* flowtable 오프로드 해제 흐름 */
TCP FIN/RST 수신
  → flow_offload_teardown()       /* FLOW_OFFLOAD_TEARDOWN 플래그 설정 */
    → nf_flow_offload_gc_step()   /* GC 워크큐가 DYING 플로우 정리 */
      → nf_flow_table_offload_del() /* HW rule 삭제 (TC flower del) */
        → nf_ct_delete()          /* conntrack 엔트리 삭제 */

GC 메커니즘 상세

flowtable의 Garbage Collection은 두 가지 메커니즘으로 동작합니다:

HW 카운터 동기화: HW offload된 플로우가 삭제될 때, NIC에서 처리된 패킷/바이트 카운터를 SW 카운터에 동기화합니다. 이를 통해 conntrack -L이나 nft list counter에서 정확한 통계를 확인할 수 있습니다.

/* HW 카운터 동기화 (net/netfilter/nf_flow_table_offload.c) */
static void nf_flow_offload_stats(struct flow_offload *flow,
                                    struct flow_stats *stats)
{
    struct nf_conn_acct *acct = nf_conn_acct_find(flow->ct);

    /* HW에서 읽어온 패킷/바이트 카운터를 conntrack에 반영 */
    atomic64_add(stats[0].pkts, &acct->counter[IP_CT_DIR_ORIGINAL].packets);
    atomic64_add(stats[0].bytes, &acct->counter[IP_CT_DIR_ORIGINAL].bytes);
    atomic64_add(stats[1].pkts, &acct->counter[IP_CT_DIR_REPLY].packets);
    atomic64_add(stats[1].bytes, &acct->counter[IP_CT_DIR_REPLY].bytes);

    /* 타임스탬프 갱신 → GC 타임아웃 리셋 */
    flow->timeout = nf_flowtable_time_stamp + flow_offload_get_timeout(flow);
}

Stateful 방화벽 오프로드

ACL HW 오프로드

TC flower를 사용하여 ct_state 매칭과 함께 ACL 규칙을 eSwitch에 설치할 수 있습니다. 이를 통해 conntrack 상태 기반 방화벽 규칙이 하드웨어에서 직접 평가됩니다.

# eSwitch switchdev 모드에서 TC flower ct 규칙 예시
# 1. ct zone 설정 및 conntrack 추적 시작
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# 2. ESTABLISHED+TRACKED 세션 → HW offload forward
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 \
  action mirred egress redirect dev eth1_rep0

# 3. NEW+TRACKED 세션 → CPU (Slow Path)
tc filter add dev eth0_rep0 ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass # CPU로 전달하여 전체 검사

# 4. INVALID → DROP
tc filter add dev eth0_rep0 ingress prio 4 \
  protocol ip flower \
  ct_state +trk+inv \
  action drop

conntrack HW 오프로드

NF_FLOWTABLE_HW_OFFLOAD 플래그가 활성화되면, flowtable에 등록된 플로우가 NIC 하드웨어의 conntrack 테이블에도 설치됩니다.

# flowtable HW offload 활성화
nft add flowtable inet filter ft \
  { hook ingress priority 0\; devices = { eth0, eth1 }\; \
    flags offload\; }

# forward chain에서 established 세션을 flowtable으로 등록
nft add rule inet filter forward \
  ct state established \
  flow add @ft

# 오프로드 상태 실시간 확인
conntrack -L --status OFFLOAD
# 출력 예:
# tcp  6 300 ESTABLISHED src=10.0.0.1 dst=192.168.1.1
#   sport=45678 dport=443 [OFFLOAD] mark=0 use=2

HW offload 내부 메커니즘

flowtable HW offload는 다음 과정으로 NIC에 규칙을 설치합니다:

/* HW offload 규칙 설치 흐름 */
nf_flow_offload_hw_add()
  → nf_flow_offload_tuple()
    → flow_offload_mangle()      /* NAT rewrite 액션 구성 */
    → flow_action_entry_set()    /* TC flow_action 구조체 채움 */
  → nf_flow_table_offload_add()
    → flow_block_cb()            /* NIC 드라이버 콜백 호출 */
      → mlx5e_tc_offload_fdb_rules()  /* mlx5: FDB rule 삽입 */
      → ice_tc_flower_action()         /* ice: TC flower 규칙 */

NIC 드라이버는 FLOW_BLOCK_BIND/FLOW_BLOCK_UNBIND 이벤트를 통해 flowtable과 연결됩니다. 드라이버가 지원하지 않는 플로우 타입(예: 특수 NAT, 미지원 터널)에 대해서는 -EOPNOTSUPP를 반환하고, 이 경우 SW flowtable에서만 처리됩니다.

HW conntrack의 한계:

• TCP window 검증 — HW에서는 TCP 윈도우/시퀀스 번호의 유효성을 검증하지 않습니다. 이를 악용한 공격(out-of-window injection)에 대해서는 주기적 샘플링으로 대응합니다.
• conntrack 테이블 크기 — NIC HW의 flow table 크기가 제한적 (수만~수십만 엔트리). 초과 시 SW flowtable로 폴백합니다.
• NAT 변환 복잡도 — CGNAT(Many-to-one NAT)이나 복잡한 NAT 매핑은 HW에서 지원하지 않을 수 있습니다.
• 프로토콜 제한 — TCP와 UDP만 HW offload 가능. ICMP, GRE, SCTP 등은 SW 처리
• IPv6 지원 — NIC에 따라 IPv6 CT offload 미지원 가능. 지원 여부는 ethtool -k에서 확인

conntrack HW offload 호환성 매트릭스

NAT 오프로드

SNAT/DNAT 주소 변환은 flowtable과 eSwitch 모두에서 오프로드할 수 있습니다. (NAT 아키텍처 참고)

NAT 오프로드의 커널 구현

flowtable NAT offload는 conntrack의 NAT 정보를 flow_offload 구조체에 복사하여, 이후 패킷을 conntrack 없이 직접 변환합니다:

/* net/netfilter/nf_flow_table_ip.c - NAT 오프로드 적용 */
static int nf_flow_nat_ip(const struct flow_offload *flow,
                           struct sk_buff *skb,
                           unsigned int thoff,
                           enum flow_offload_tuple_dir dir)
{
    struct iphdr *iph = ip_hdr(skb);

    /* SNAT: 소스 IP/포트 교체 */
    if (flow->flags & FLOW_OFFLOAD_SNAT) {
        /* ORIGINAL 방향: src → NAT 주소로 변경 */
        /* REPLY 방향: dst → 원래 주소로 복원 */
        nf_flow_snat_port(skb, thoff,
            flow->tuplehash[!dir].tuple.src_v4.s_addr,
            flow->tuplehash[!dir].tuple.port.src);
        /* IP 체크섬 + L4 체크섬 재계산 */
        csum_replace4(&iph->check, iph->saddr, new_addr);
    }

    /* DNAT: 목적지 IP/포트 교체 (위와 유사) */
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_port(skb, thoff, ...);

    return 0;
}

CGNAT 대규모 NAT 시나리오

통신사(ISP) 환경의 CGNAT(Carrier-Grade NAT)에서는 수만 개의 내부 IP를 소수의 공인 IP로 변환합니다. 이 경우:

• 포트 풀 관리: 각 공인 IP당 ~64K 포트를 내부 IP에 분배. 포트 소진 시 새 연결 불가
• HW NAT의 한계: 일부 NIC은 한정된 NAT 매핑 테이블만 지원 (수만 엔트리). 초과 시 SW 폴백
• Deterministic NAT: 포트 범위를 사전 할당하여 로깅 부하 감소. nft add map으로 구현 가능

# CGNAT nftables 설정 예시
table ip cgnat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;

        # 내부 대역별 공인 IP 분배 (Deterministic NAT)
        ip saddr 100.64.0.0/24 snat to 203.0.113.1:1024-32767
        ip saddr 100.64.1.0/24 snat to 203.0.113.1:32768-65535
        ip saddr 100.64.2.0/24 snat to 203.0.113.2:1024-32767

        # 폴백: 나머지 → 공인 IP 풀에서 동적 할당
        ip saddr 100.64.0.0/10 snat to 203.0.113.1-203.0.113.10
    }
}

# CGNAT 세션도 flowtable 오프로드 적용
nft add rule ip cgnat forward \
  ct state established flow add @ft

QoS/터널/IPSec 오프로드

DSCP/QoS 오프로드

TC flower로 DSCP 필드를 매칭하고 QoS 큐에 매핑하는 규칙을 eSwitch에 설치할 수 있습니다.

# DSCP EF (46) → TC 큐 0 (높은 우선순위)
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ip_tos 0xb8/0xfc \
  action skbedit priority 0

# DSCP AF11 (10) → TC 큐 2 (낮은 우선순위)
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ip_tos 0x28/0xfc \
  action skbedit priority 2

DSCP/QoS 매핑 상세

NGFW에서 QoS는 보안 정책과 연계됩니다. DPI 결과(App-ID)에 따라 DSCP 값을 재마킹하고, HW QoS 큐에 매핑하는 패턴입니다:

# NGFW에서 DPI 결과 기반 DSCP 재마킹
# nftables에서 App-ID → DSCP 매핑 (DPI 엔진이 ct mark에 App-ID 기록)
table inet qos_mark {
    map app_dscp {
        type mark : verdict
        elements = {
            0x0001 : accept,    # VoIP → DSCP EF (DPI에서 이미 마킹)
            0x0002 : accept,    # Video → DSCP AF41
            0x0003 : accept,    # Web → DSCP AF11
        }
    }

    chain forward {
        type filter hook forward priority 50; policy accept;
        # DPI 엔진이 ct mark에 기록한 App-ID → DSCP 재마킹
        ct mark 0x0001 ip dscp set ef
        ct mark 0x0002 ip dscp set af41
        ct mark 0x0003 ip dscp set af11
    }
}

# HW QoS 큐 설정 (TC MQPRIO)
tc qdisc add dev eth0 root mqprio \
  num_tc 4 map 3 3 2 2 1 1 0 0 0 0 0 0 0 0 0 0 \
  queues 1@0 1@1 2@2 4@4 hw 1

터널 오프로드

NGFW에서 터널은 두 가지 역할을 합니다: 사이트 간 VPN과 오버레이(Overlay) 네트워크. eSwitch는 다음 터널 타입의 encap/decap을 하드웨어에서 수행합니다:

• VXLAN — L2 over UDP 캡슐화(Encapsulation), 가장 널리 지원
• GRE — IP over IP 캡슐화 (GRE 프로토콜)
• Geneve — 유연한 TLV 옵션을 지원하는 현대적 터널

터널 + NGFW 오프로드 결합

터널 decap → 내부 패킷 DPI → 오프로드의 전체 흐름을 TC flower로 구성합니다:

# VXLAN 터널 디바이스 생성
ip link add vxlan0 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# eSwitch에서 VXLAN decap + conntrack + forward 규칙
# chain 0: 외부 헤더로 VXLAN 매칭 → decap
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action goto chain 1

# chain 1: decap된 내부 패킷에 conntrack 적용
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state -trk \
  action ct zone 1 pipe \
  action goto chain 2

# chain 2: EST → HW forward, NEW → CPU
tc filter add dev eth0_rep0 ingress chain 2 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 1 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 2 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass # CPU → nftables → NFQUEUE → DPI

IPSec 인라인 크립토 오프로드

IPSec & xfrm의 HW 오프로드를 NGFW 파이프라인에 통합하면, 암호화/복호화를 NIC에서 수행하고 평문 패킷만 DPI 엔진에 전달할 수 있습니다.

# IPSec crypto offload 활성화 (xfrm)
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  enc 'aes' 0x$(head -c 16 /dev/urandom | xxd -p) \
  offload dev eth0 dir out

IPSec 오프로드 모드 비교

NGFW와의 통합 포인트: IPSec 수신 시 NIC이 복호화를 수행하고, 평문(decrypted) 패킷이 커널에 전달됩니다. 이 평문 패킷에 대해 conntrack → flowtable → DPI 파이프라인이 정상 작동합니다. 송신 시에는 flowtable이 평문 패킷을 NIC에 전달하고, NIC이 ESP 캡슐화와 암호화를 인라인으로 수행합니다.

# IPSec + flowtable NGFW 조합 설정
# 1. xfrm SA에 crypto offload 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir out

ip xfrm state add src 10.0.0.2 dst 10.0.0.1 \
  proto esp spi 0x1002 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir in

# 2. xfrm 정책
ip xfrm policy add src 10.1.0.0/24 dst 10.2.0.0/24 \
  dir out tmpl src 10.0.0.1 dst 10.0.0.2 \
  proto esp reqid 1 mode tunnel

# 3. flowtable에서 decrypted 패킷 오프로드
nft add flowtable inet ngfw ft_ipsec \
  { hook ingress priority 0\; devices = { eth0 }\; flags offload\; }

nft add rule inet ngfw forward \
  ct state established \
  ipsec in reqid 1 \
  flow add @ft_ipsec accept

# 확인: IPSec HW 오프로드 상태
ip xfrm state show | grep -A1 offload
ethtool -S eth0 | grep ipsec

NGFW에서 VXLAN 오버레이 + 보안 통합

데이터센터 NGFW에서 VXLAN 오버레이 네트워크와 보안 검사를 통합하는 아키텍처입니다. eSwitch가 VXLAN 터널의 encap/decap을 하드웨어에서 수행하고, 내부 패킷에 대해 conntrack + DPI를 적용합니다.

# VXLAN + NGFW 통합 구성 (eSwitch offload)

# 1. VXLAN 터널 엔드포인트 생성
ip link add vxlan100 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# 2. nftables에서 decap된 내부 트래픽에 NGFW 정책 적용
table inet vxlan_ngfw {
    flowtable ft_vxlan {
        hook ingress priority 0
        devices = { vxlan100, eth1 }
        flags offload
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid drop

        # VXLAN 내부 트래픽: EST → offload
        iifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept

        # VXLAN 내부 트래픽: NEW → DPI
        iifname "vxlan100" ct state new \
            queue num 0-3 fanout

        # 내부 → VXLAN: EST → offload
        oifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept
    }
}

# 3. eSwitch에서 VXLAN + conntrack 통합 규칙
# 외부 헤더로 VXLAN 패킷 식별 → decap → conntrack → forward
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action ct zone 2 pipe \
  action goto chain 1

# chain 1에서 EST/NEW 분기 (위 §8 패턴과 동일)
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 2 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 1 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass

GTP-U 오프로드와 5G NGFW

5G 모바일 네트워크에서 사용자 트래픽은 GTP-U(GPRS Tunnelling Protocol User Plane)로 캡슐화되어 전송됩니다. NGFW가 5G 환경에 배치되면 GTP-U 터널 내부의 실제 사용자 트래픽을 검사해야 하며, 이때 GTP-U 디캡슐레이션(Decapsulation)과 내부 패킷 검사를 SmartNIC 하드웨어에서 오프로드하면 처리량을 극대화할 수 있습니다. 이 섹션에서는 GTP-U 프로토콜 구조, 커널 GTP 모듈, TC flower 연동, HW 오프로드 구현을 다룹니다.

GTP-U 프로토콜 구조

GTP-U(GPRS Tunnelling Protocol - User Plane)는 3GPP 표준(TS 29.281)에 정의된 터널링 프로토콜로, 모바일 네트워크에서 사용자 데이터 패킷을 캡슐화하여 네트워크 노드 간에 전달합니다. GTP-U는 UDP 포트 2152 위에서 동작하며, 핵심 식별자는 TEID(Tunnel Endpoint Identifier)입니다.

GTP-U 헤더 형식

GTP-U 캡슐화 스택

GTP-U로 캡슐화된 패킷의 전체 프로토콜 스택은 다음과 같습니다:

┌─────────────────────────────────────────────────────────────────────┐
│ Outer Ethernet │ Outer IP │ UDP(2152) │ GTP-U │ Inner IP │ Payload │
├────────────────┼──────────┼───────────┼───────┼──────────┼─────────┤
│    14 bytes    │ 20 bytes │  8 bytes  │ 8~12B │ 20 bytes │  ...    │
└────────────────┴──────────┴───────────┴───────┴──────────┴─────────┘
                                         
총 오버헤드: 14 + 20 + 8 + 8(~12) = 50~54 bytes (Inner Ethernet 없음)
1500B MTU 기준 실효 페이로드: 1446~1450 bytes

모바일 네트워크에서 NGFW 배치 위치

5G 네트워크 아키텍처(3GPP TS 23.501)에서 NGFW는 주로 N3 인터페이스(gNB ↔ UPF)와 N6 인터페이스(UPF ↔ Data Network) 두 위치에 배치됩니다.

5G 아키텍처 개요

5G 데이터 플레인 경로:

  UE ──[무선]──→ gNB ──[N3: GTP-U]──→ UPF ──[N6: IP]──→ DN (Internet)
                  │                     │
                  │   ┌──[N9: GTP-U]──┐ │
                  │   │  (UPF 간 중계)  │ │
                  │   └───────────────┘ │
                  │                     │
              ┌───┴───────────────┐   ┌─┴──────────┐
              │  NGFW 위치 A      │   │ NGFW 위치 B │
              │  (N3 인라인)       │   │ (N6 이그레스)│
              │  GTP-U 내부 검사  │   │ 일반 IP 검사 │
              └───────────────────┘   └────────────┘

N3 인라인 배치 시 트래픽 패턴

N3 인터페이스에 NGFW를 배치하면 모든 사용자 트래픽이 GTP-U로 캡슐화된 상태로 통과합니다. NGFW는 다음과 같은 처리를 수행해야 합니다:

• GTP-U 디캡슐레이션 — 외부 Ethernet/IP/UDP/GTP-U 헤더를 제거하여 내부(Inner) IP 패킷을 추출합니다.
• TEID 기반 세션 매핑 — TEID를 사용자(가입자) 세션에 매핑합니다. 단일 UPF에 10만~100만 개의 동시 TEID가 존재할 수 있습니다.
• Inner 패킷 검사 — 추출된 내부 IP 패킷에 대해 ACL, conntrack, DPI, IPS를 수행합니다.
• GTP-U 재캡슐레이션 — 검사 완료 후 원래의 GTP-U 헤더를 재부착하여 전달합니다.

N6 이그레스 배치 시 장단점

N6 인터페이스에서는 UPF가 이미 GTP-U 디캡슐레이션을 완료했으므로, NGFW는 일반 IP 패킷을 처리합니다. 이 경우 GTP-U 처리 오버헤드가 없어 기존 NGFW 파이프라인을 그대로 사용할 수 있지만, TEID 기반 가입자 식별이 불가능하다는 단점이 있습니다. 가입자별 정책(Per-Subscriber Policy)을 적용하려면 UPF가 내부 IP에 DSCP 마킹이나 VLAN 태그로 가입자 정보를 전달해야 합니다.

커널 GTP 모듈과 TC flower 연동

Linux 커널은 gtp.ko 모듈을 통해 GTP-U 터널 인터페이스를 제공합니다. 이 모듈은 커널 4.7부터 포함되어 있으며, Open5GS, free5GC 등 오픈소스 5G 코어에서 UPF 구현에 사용됩니다.

gtp.ko 모듈 아키텍처

# GTP 커널 모듈 로드
modprobe gtp

# GTP 터널 인터페이스 생성 (libgtpnl 사용)
# gtp-link 명령은 genl(generic netlink) 기반
ip link add gtp0 type gtp role sgsn hashsize 131072

# 또는 gtp_newlink netlink API로 직접 생성
# (Open5GS UPF가 내부적으로 사용하는 방식)

# GTP 인터페이스 상태 확인
ip link show gtp0
ip addr add 10.45.0.1/16 dev gtp0
ip link set gtp0 up

# GTP 터널 세션(PDP context) 추가
# TEID 0x12345678, peer 192.168.1.100 (gNB IP)
gtp-tunnel add gtp0 v1 12345678 192.168.1.100 10.45.0.2

/* drivers/net/gtp.c - GTP-U 수신 처리 */
static int gtp1u_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
{
    struct gtphdr *gtp1;
    struct pdp_ctx *pctx;

    /* GTP-U 헤더 파싱 */
    gtp1 = (struct gtphdr *)(skb->data + sizeof(struct udphdr));
    
    if ((gtp1->flags >> 5) != GTP_V1)
        return 1;  /* not GTPv1 */
    
    if (gtp1->type != GTP_TPDU)
        return 1;  /* not T-PDU (user data) */

    /* TEID로 PDP context (세션) 조회 */
    pctx = gtp1_pdp_find(gtp, ntohl(gtp1->tid));
    if (!pctx)
        return -1;  /* unknown TEID */

    /* outer 헤더 제거, inner IP 패킷 노출 */
    skb_pull(skb, hdrlen);
    
    /* inner 패킷을 GTP 인터페이스(gtp0)로 수신 처리 */
    skb->dev = gtp->dev;
    netif_rx(skb);
    return 0;
}

TC flower로 GTP-U 매칭

커널 5.7부터 TC flower는 enc_key_id 필드로 GTP-U의 TEID를 매칭할 수 있습니다. 이를 통해 특정 TEID(가입자 세션)에 대한 정책을 TC flower 규칙으로 설정할 수 있습니다.

# TC flower로 GTP-U TEID 매칭
# enc_key_id = TEID (tunnel key)

# 1. GTP-U 터널의 특정 TEID에 대한 트래픽 미러링
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_key_id 0x12345678 \
    enc_dst_port 2152 \
    action mirred egress mirror dev mon0

# 2. 특정 TEID의 inner IP 기반 ACL
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_key_id 0x12345678 \
    enc_dst_port 2152 \
    enc_src_ip 192.168.1.100 \
    ip_proto tcp \
    dst_port 443 \
    action pass

# 3. tunnel_key 액션으로 GTP-U decap
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    action tunnel_key unset \
    action mirred egress redirect dev gtp_decap0

# 4. 결합: GTP decap + conntrack + NAT
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    enc_key_id 0x12345678 \
    action tunnel_key unset \
    action ct zone 100 \
    action ct commit zone 100 nat src addr 203.0.113.1 \
    action mirred egress redirect dev eth1

GTP-U HW 오프로드 구현

NVIDIA ConnectX-7(BlueField-3)은 GTP-U 하드웨어 디캡슐레이션을 지원하는 대표적인 SmartNIC입니다. GTP-U decap을 TC flower와 결합하면 디캡슐레이션, conntrack, NAT, ACL을 단일 HW 파이프라인에서 처리할 수 있습니다.

NVIDIA ConnectX-7 GTP-U 오프로드

# ConnectX-7 eSwitch 모드 설정
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# GTP-U decap offload 활성화
# representor 인터페이스에서 GTP-U 터널 매칭

# 1단계: GTP-U decap + inner 패킷 추출
tc filter add dev eth0_rep ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    enc_key_id 0x12345678 \
    action tunnel_key unset pipe \
    action goto chain 1

# 2단계: chain 1에서 inner 패킷에 대해 conntrack
tc filter add dev eth0_rep ingress chain 1 protocol ip \
    flower \
    ct_state -trk \
    action ct zone 100 pipe \
    action goto chain 2

# 3단계: chain 2에서 ESTABLISHED 세션 offload
tc filter add dev eth0_rep ingress chain 2 protocol ip \
    flower \
    ct_state +trk+est \
    action ct commit zone 100 nat pipe \
    action tunnel_key set \
    id 0x87654321 \
    dst_ip 10.100.1.1 \
    dst_port 2152 \
    action mirred egress redirect dev eth1_rep

# NEW 세션은 SW로 (Slow Path)
tc filter add dev eth0_rep ingress chain 2 protocol ip \
    flower \
    ct_state +trk+new \
    action trap

위 규칙이 eSwitch FDB에 설치되면, 확립된 GTP-U 세션의 패킷은 다음 HW 파이프라인을 거칩니다:

ConnectX-7 HW 파이프라인 (GTP-U offload):

  NIC RX → TEID 매칭 → GTP-U decap → inner IP 추출
  → CT lookup (zone 100) → EST 매칭 → NAT rewrite
  → GTP-U encap (new TEID) → TX → Wire

  전체 과정이 NIC 하드웨어에서 완료 (CPU 개입 없음)
  지연(Latency): ~5μs (SW 경로 대비 1/100)

Stateful GTP 검사 파이프라인

완전한 5G NGFW HW 오프로드 파이프라인은 다음 요소를 결합합니다:

5G NGFW 오프로드 성능 특성

5G NGFW 오프로드의 성능은 가입자 세션 밀도, GTP-U 오버헤드, 오프로드 비율에 따라 크게 달라집니다.

가입자 세션 밀도

5G UPF의 가입자 세션 규모는 다음과 같습니다:

GTP-U 오버헤드 분석

SW 전용 vs HW 오프로드 성능 비교

오프로드 효과 분석

HW 오프로드의 효과는 트래픽 프로파일(Profile)에 따라 달라집니다:

처리량 모델 (100Gbps 환경):

  총 트래픽: 100 Gbps
  
  시나리오 1: 오프로드 비율 0% (SW 전용)
    CPU 필요: 100Gbps ÷ 10Gbps/코어 = 10코어 (GTP decap + CT + NAT)
    DPI 추가 시: 100Gbps ÷ 3Gbps/코어 = 33코어
    → 총 33+ CPU 코어 필요 (불가능에 가까움)

  시나리오 2: 오프로드 비율 80%
    HW 처리: 80 Gbps (CPU 부하 없음)
    SW 처리: 20 Gbps → 20 ÷ 10 = 2코어 (EST)
    DPI (새 세션만): ~5 Gbps → 5 ÷ 3 = 2코어
    → 총 4 CPU 코어로 100Gbps 처리 가능

  시나리오 3: 오프로드 비율 90%
    HW 처리: 90 Gbps
    SW 처리: 10 Gbps → 1코어 (EST) + 1코어 (DPI)
    → 총 2 CPU 코어로 100Gbps 처리 가능

암/복호화 트래픽 HW 오프로드

Regex/DPI 하드웨어 가속 엔진

NGFW의 핵심 기능인 심층 패킷 검사(DPI, Deep Packet Inspection)는 네트워크 트래픽의 페이로드(Payload)를 정규식(Regular Expression) 패턴으로 분석하여 악성 코드, 침입 시도, 애플리케이션 프로토콜을 식별합니다. 이 과정은 CPU 집약적이며, 10Gbps 이상의 환경에서 소프트웨어만으로는 라인 레이트 처리가 불가능합니다. 이 절에서는 정규식 매칭의 비용 구조와 하드웨어 가속 엔진 3종(NVIDIA RXP, Marvell REE, Intel Hyperscan+QAT)의 아키텍처 및 통합 방법을 다룹니다.

NGFW에서 정규식 매칭의 비용

IDS/IPS 엔진(Suricata, Snort)의 CPU 프로파일링(Profiling) 데이터를 보면, 멀티 패턴 매칭(Multi-Pattern Matching, MPM)이 전체 CPU 사이클의 40~60%를 소비합니다. 이는 수천 개의 시그니처(Signature)를 동시에 매칭해야 하기 때문입니다.

다음 명령으로 Suricata 프로세스의 CPU 프로파일을 수집할 수 있습니다.

# perf를 이용한 Suricata CPU 프로파일링 (30초 샘플링)
sudo perf record -g -p $(pidof suricata) -- sleep 30
sudo perf report --sort=dso,symbol --stdio | head -60

# 특정 함수별 CPU 비중 확인
sudo perf report --stdio --sort=symbol | grep -E "(SCACSearch|MpmSearch|DetectMatch)"

# bpftrace로 MPM 함수 레이턴시 분포 확인
sudo bpftrace -e '
uprobe:/usr/bin/suricata:SCACSearch {
    @start[tid] = nsecs;
}
uretprobe:/usr/bin/suricata:SCACSearch /@start[tid]/ {
    @latency_ns = hist(nsecs - @start[tid]);
    delete(@start[tid]);
}
interval:s:10 { exit(); }
'

# flamegraph 생성 (CPU 핫스팟 시각화)
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > suricata-flame.svg

10Gbps 이상 환경에서 하드웨어 가속이 중요한 이유를 정리하면 다음과 같습니다.

• 결정론적 레이턴시: DFA 기반 하드웨어 엔진은 O(n) 처리 시간을 보장하므로, NFA 폴백으로 인한 지연 스파이크(Latency Spike)가 발생하지 않습니다.
• CPU 오프로드: 정규식 매칭을 전용 하드웨어에 위임하면 CPU 코어를 세션 관리, 정책 판단, 로깅 등 다른 작업에 할당할 수 있습니다.
• 확장성: 트래픽 증가 시 CPU 코어를 추가하는 것보다 하드웨어 엔진의 병렬 처리 유닛을 활용하는 것이 전력 효율과 비용 면에서 유리합니다.
• 일관된 처리량: 소프트웨어 MPM은 패턴 집합 크기에 따라 성능이 변동하지만, 하드웨어 엔진은 수만 개 패턴에서도 안정적인 처리량을 유지합니다.

NVIDIA BlueField-3 RXP 엔진

NVIDIA BlueField-3 DPU에 내장된 RXP(RegEx Processing Unit)는 하드웨어 DFA 기반 정규식 가속 엔진입니다. 최대 400Gbps의 정규식 매칭 처리량을 제공하며, DOCA(Data Center Infrastructure on a Chip Architecture) SDK를 통해 프로그래밍합니다.

RXP 엔진의 워크플로는 다음과 같습니다.

1. 규칙 컴파일: rxpc 컴파일러가 PCRE 형식의 정규식 패턴 파일(.rules)을 RXP 하드웨어가 이해하는 바이너리 규칙 파일(.rxp)로 변환합니다.
2. 엔진 초기화: DOCA RegEx 컨텍스트를 생성하고, 컴파일된 규칙을 RXP 엔진에 로드합니다.
3. 배치 제출: 검사할 패킷 버퍼들을 배치(Batch)로 묶어 RXP 엔진에 비동기 제출합니다.
4. 결과 수집: 폴링(Polling) 또는 이벤트 기반으로 매칭 결과를 수집하고, 매칭된 규칙 ID와 오프셋 정보를 확인합니다.

# rxpc를 이용한 규칙 컴파일
# 입력: PCRE 패턴 파일, 출력: RXP 바이너리 규칙
rxpc -f suricata_patterns.rules -o compiled_rules.rxp \
     --max-rules 10000 \
     --optimize-level 3

# 컴파일 결과 통계 확인
rxpc -f suricata_patterns.rules --stats-only
# 출력 예: Total rules: 8432, DFA states: 124567, Memory: 48MB

다음은 DOCA RegEx API를 사용한 정규식 하드웨어 가속 코드 예제입니다.

#include <doca_regex.h>
#include <doca_buf.h>
#include <doca_ctx.h>
#include <doca_dev.h>
#include <doca_error.h>
#include <doca_log.h>

DOCA_LOG_REGISTER(REGEX_DPI);

#define MAX_BATCH_SIZE  256
#define MAX_MATCHES     16

struct regex_dpi_ctx {
    struct doca_dev       *dev;
    struct doca_regex     *regex;
    struct doca_ctx       *ctx;
    struct doca_pe        *pe;       /* Progress engine */
    struct doca_buf_arr   *buf_arr;
    struct doca_mmap      *mmap;
    uint32_t               total_matches;
    uint32_t               total_scanned;
};

/* 매칭 완료 콜백 — 비동기 결과 처리 */
static void regex_task_completion_cb(struct doca_regex_task_search *task,
                                     union doca_data task_user_data,
                                     union doca_data ctx_user_data)
{
    struct regex_dpi_ctx *dpi = (struct regex_dpi_ctx *)ctx_user_data.ptr;
    struct doca_regex_search_result *result;
    uint32_t num_matches = 0;
    doca_error_t err;

    err = doca_regex_task_search_get_result(task, &result);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_WARN("regex result retrieval failed: %s",
                      doca_error_get_descr(err));
        goto cleanup;
    }

    num_matches = doca_regex_search_result_get_num_matches(result);
    if (num_matches > 0) {
        dpi->total_matches += num_matches;

        /* 매칭된 각 규칙 ID와 오프셋 순회 */
        for (uint32_t i = 0; i < num_matches && i < MAX_MATCHES; i++) {
            struct doca_regex_match *match;
            doca_regex_search_result_get_match(result, i, &match);

            uint32_t rule_id = doca_regex_match_get_rule_id(match);
            uint32_t offset  = doca_regex_match_get_offset(match);
            uint32_t length  = doca_regex_match_get_length(match);

            DOCA_LOG_DBG("Match: rule=%u offset=%u len=%u",
                         rule_id, offset, length);
        }
    }
    dpi->total_scanned++;

cleanup:
    doca_task_free(doca_regex_task_search_as_task(task));
}

/* RXP 엔진 초기화: 디바이스 탐색, 규칙 로드, 컨텍스트 생성 */
static doca_error_t init_regex_engine(struct regex_dpi_ctx *dpi,
                                      const char *rules_path)
{
    doca_error_t err;

    /* BlueField DPU의 RegEx 디바이스 열기 */
    err = doca_dev_open_by_capability(DOCA_DEV_CAP_REGEX, &dpi->dev);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_ERR("RegEx device not found: %s",
                     doca_error_get_descr(err));
        return err;
    }

    /* DOCA RegEx 인스턴스 생성 */
    err = doca_regex_create(dpi->dev, &dpi->regex);
    if (err != DOCA_SUCCESS)
        return err;

    /* 컴파일된 규칙 파일 로드 */
    err = doca_regex_set_hardware_compiled_rules(dpi->regex, rules_path);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_ERR("Failed to load rules from %s", rules_path);
        return err;
    }

    /* Progress Engine 생성 (비동기 태스크 관리) */
    err = doca_pe_create(&dpi->pe);
    if (err != DOCA_SUCCESS)
        return err;

    /* 컨텍스트 연결 및 시작 */
    dpi->ctx = doca_regex_as_ctx(dpi->regex);
    err = doca_pe_connect_ctx(dpi->pe, dpi->ctx);
    if (err != DOCA_SUCCESS)
        return err;

    /* 완료 콜백 설정 */
    union doca_data user_data = { .ptr = dpi };
    err = doca_regex_task_search_set_conf(
              dpi->regex,
              regex_task_completion_cb,  /* 성공 콜백 */
              regex_task_completion_cb,  /* 에러 콜백 */
              MAX_BATCH_SIZE);
    if (err != DOCA_SUCCESS)
        return err;

    err = doca_ctx_set_user_data(dpi->ctx, user_data);
    if (err != DOCA_SUCCESS)
        return err;

    return doca_ctx_start(dpi->ctx);
}

/* 패킷 버퍼 배치를 RXP 엔진에 제출 */
static doca_error_t submit_packet_batch(struct regex_dpi_ctx *dpi,
                                        void **pkt_bufs,
                                        uint32_t *pkt_lens,
                                        int count)
{
    doca_error_t err;

    for (int i = 0; i < count; i++) {
        struct doca_regex_task_search *task;
        struct doca_buf *buf;

        /* 패킷 데이터를 DOCA 버퍼에 매핑 */
        err = doca_buf_arr_get_buf(dpi->buf_arr, i, &buf);
        if (err != DOCA_SUCCESS)
            continue;

        doca_buf_set_data(buf, pkt_bufs[i], pkt_lens[i]);

        /* 검색 태스크 생성 및 제출 */
        union doca_data task_data = { .u64 = i };
        err = doca_regex_task_search_alloc_init(
                  dpi->regex, buf, task_data, &task);
        if (err != DOCA_SUCCESS)
            continue;

        err = doca_task_submit(
                  doca_regex_task_search_as_task(task));
        if (err != DOCA_SUCCESS) {
            doca_task_free(doca_regex_task_search_as_task(task));
            continue;
        }
    }

    /* Progress Engine 폴링 — 완료된 태스크의 콜백 호출 */
    while (dpi->total_scanned < (uint32_t)count) {
        (void)doca_pe_progress(dpi->pe);
    }

    return DOCA_SUCCESS;
}

Marvell REE (RegEx Engine)

Marvell OCTEON CN10K SoC에 내장된 REE(RegEx Engine)는 하드웨어 DFA/NFA 하이브리드 정규식 코프로세서(Coprocessor)입니다. DPDK의 rte_regexdev API를 통해 접근하며, 이벤트 기반 비동기 처리 모델을 지원합니다.

DPDK rte_regexdev API의 핵심 구성 요소는 다음과 같습니다.

• rte_regexdev_configure(): REE 디바이스를 초기화하고 큐 수, 규칙 DB 크기 등을 설정합니다.
• rte_regexdev_rule_db_update(): 컴파일된 규칙을 하드웨어에 로드합니다.
• rte_regexdev_enqueue_burst(): 검사 대상 버퍼를 배치로 제출합니다.
• rte_regexdev_dequeue_burst(): 완료된 매칭 결과를 배치로 수집합니다.
• eventdev 연동: rte_event_regex_adapter를 통해 이벤트 기반 비동기 파이프라인에 통합합니다.

#include <rte_regexdev.h>
#include <rte_mbuf.h>
#include <rte_log.h>

#define REGEX_DEV_ID    0
#define REGEX_QP_ID     0
#define BATCH_SIZE      64
#define MAX_MATCHES     8

/* REE 디바이스 초기화 및 규칙 로드 */
static int init_ree_device(const char *rules_file)
{
    struct rte_regexdev_config cfg = {
        .nb_queue_pairs   = 4,
        .nb_max_matches   = MAX_MATCHES,
        .nb_rules         = 10000,
        .rule_db_len      = 0,      /* 자동 감지 */
        .dev_cfg_flags    = 0,
    };
    struct rte_regexdev_info dev_info;
    int ret;

    /* 디바이스 정보 조회 */
    ret = rte_regexdev_info_get(REGEX_DEV_ID, &dev_info);
    if (ret < 0) {
        RTE_LOG(ERR, USER1, "REE device info failed: %d\n", ret);
        return ret;
    }
    RTE_LOG(INFO, USER1, "REE device: %s, max_rules=%u\n",
            dev_info.driver_name, dev_info.max_rules);

    /* 디바이스 설정 */
    ret = rte_regexdev_configure(REGEX_DEV_ID, &cfg);
    if (ret < 0)
        return ret;

    /* 규칙 DB 업데이트 — 컴파일된 바이너리 규칙 로드 */
    struct rte_regexdev_rule *rules;
    uint32_t nb_rules;

    /* 규칙 파일 파싱 (실제 구현에서는 파일 I/O) */
    ret = load_compiled_rules(rules_file, &rules, &nb_rules);
    if (ret < 0)
        return ret;

    ret = rte_regexdev_rule_db_update(REGEX_DEV_ID,
                                       rules, nb_rules);
    if (ret < 0)
        return ret;

    ret = rte_regexdev_rule_db_compile_activate(REGEX_DEV_ID);
    if (ret < 0)
        return ret;

    /* 큐 페어 설정 */
    struct rte_regexdev_qp_conf qp_conf = {
        .nb_desc = 1024,
        .qp_conf_flags = RTE_REGEX_QUEUE_PAIR_CFG_OOS_F,
    };
    ret = rte_regexdev_queue_pair_setup(REGEX_DEV_ID,
                                         REGEX_QP_ID, &qp_conf);
    if (ret < 0)
        return ret;

    return rte_regexdev_start(REGEX_DEV_ID);
}

/* 패킷 배치를 REE 엔진에 제출하고 결과 수집 */
static int process_packet_batch(struct rte_mbuf **pkts,
                                uint16_t nb_pkts,
                                uint32_t *match_flags)
{
    struct rte_regex_ops *ops[BATCH_SIZE];
    struct rte_regex_ops *results[BATCH_SIZE];
    uint16_t enqueued, dequeued;
    int i;

    /* 검색 오퍼레이션 생성 */
    for (i = 0; i < nb_pkts && i < BATCH_SIZE; i++) {
        ops[i] = rte_malloc(NULL, sizeof(struct rte_regex_ops), 0);
        if (!ops[i])
            return -ENOMEM;

        ops[i]->mbuf     = pkts[i];
        ops[i]->group_id0 = 0;      /* 규칙 그룹 ID */
        ops[i]->user_id   = i;      /* 패킷 식별자 */
        ops[i]->req_flags = 0;
    }

    /* 배치 제출 (enqueue) */
    enqueued = rte_regexdev_enqueue_burst(REGEX_DEV_ID,
                                           REGEX_QP_ID,
                                           ops, nb_pkts);

    /* 결과 수집 (dequeue) — 폴링 루프 */
    dequeued = 0;
    while (dequeued < enqueued) {
        uint16_t n = rte_regexdev_dequeue_burst(
                         REGEX_DEV_ID, REGEX_QP_ID,
                         results + dequeued,
                         enqueued - dequeued);
        dequeued += n;
    }

    /* 매칭 결과 처리 */
    for (i = 0; i < dequeued; i++) {
        uint16_t nb_matches = results[i]->nb_matches;
        uint32_t pkt_idx    = results[i]->user_id;

        if (nb_matches > 0) {
            match_flags[pkt_idx] = 1;

            for (uint16_t m = 0; m < nb_matches; m++) {
                struct rte_regexdev_match *match;
                match = &results[i]->matches[m];
                RTE_LOG(DEBUG, USER1,
                        "pkt[%u] match: rule=%u off=%u len=%u\n",
                        pkt_idx, match->rule_id,
                        match->start_offset, match->len);
            }
        } else {
            match_flags[pkt_idx] = 0;
        }
        rte_free(results[i]);
    }

    return dequeued;
}

Hyperscan + Intel QAT 가속

Hyperscan은 Intel이 개발한 고성능 정규식 매칭 라이브러리로, SIMD(SSE4.2/AVX2/AVX-512) 명령어를 활용한 멀티 패턴 매칭을 제공합니다. 전용 하드웨어가 아닌 CPU 기반이지만, 하드웨어 수준에 근접하는 성능을 달성합니다. Intel QAT(QuickAssist Technology)와 조합하면 암호 해제 + 정규식 매칭 파이프라인을 구성할 수 있습니다.

Hyperscan의 핵심 장점은 다음과 같습니다.

• 멀티 패턴 동시 매칭: 수만 개 패턴을 단일 패스(Single Pass)로 매칭합니다.
• SIMD 최적화: AVX-512 기반 DFA 시뮬레이션으로 코어당 수 Gbps 처리를 달성합니다.
• Chimera 모드: Hyperscan + PCRE 폴백을 결합하여 호환성과 성능을 모두 확보합니다.
• 사전 컴파일: 패턴 DB를 바이트코드로 사전 컴파일하여 런타임 오버헤드를 제거합니다.

Suricata에서 Hyperscan MPM을 활성화하는 설정 예제입니다.

# /etc/suricata/suricata.yaml — Hyperscan MPM 설정

# Multi-Pattern Matching 엔진 선택
mpm-algo: hs  # 'ac' (Aho-Corasick) 대신 'hs' (Hyperscan)

# 패턴 매칭 상세 설정
detect:
  profile: high       # high = 더 많은 메모리, 더 빠른 매칭
  sgh-mpm-context: full  # 시그니처 그룹별 독립 MPM 컨텍스트
  inspection-recursion-limit: 3000

# Hyperscan 관련 상세 설정
# Suricata 빌드 시 --enable-hyperscan 필요
# 의존성: libhs-dev (Intel Hyperscan 라이브러리)

# Intel QAT 암호 해제 가속 (AF_ALG 또는 OpenSSL QAT engine)
# TLS 복호화 → Hyperscan 매칭 파이프라인
app-layer:
  protocols:
    tls:
      enabled: yes
      detection-ports:
        dp: 443
      # QAT 가속 OpenSSL 엔진 사용 시 별도 설정 필요

# Suricata 빌드 시 Hyperscan 활성화
./configure --enable-hyperscan \
            --with-libhs-includes=/usr/include/hs \
            --with-libhs-libraries=/usr/lib/x86_64-linux-gnu

# Hyperscan 성능 벤치마크
# hsbench: Hyperscan 공식 벤치마크 도구
hsbench -e /path/to/patterns.db \
        -c /path/to/corpus/ \
        -T 8            # 8 스레드

# Intel QAT 디바이스 확인
lspci | grep "QuickAssist"
# 출력 예: 0000:6b:00.0 Co-processor: Intel Corporation
#          C62x Chipset QuickAssist Technology

# QAT 상태 확인
adf_ctl status
# 출력 예: qat_dev0 - type: c6xx, state: up

# QAT OpenSSL 엔진 설정 확인
openssl engine -t qatengine
# 출력 예: (qatengine) Reference implementation of QAT engine
#          [ available ]

Regex HW와 NGFW 파이프라인 통합 패턴

정규식 하드웨어 가속 엔진을 NGFW 파이프라인에 효율적으로 통합하려면 2단계 필터링 모델을 사용합니다. 모든 패킷을 하드웨어 정규식 엔진에 보내는 것은 비효율적이므로, 저비용 사전 필터(Pre-filter)로 후보를 먼저 선별하고, 후보 패킷만 정밀 매칭 엔진에 전달합니다.

이 2단계 모델의 핵심은 1단계에서 대부분의 정상 트래픽을 빠르게 통과시키고(95~99%), 의심 트래픽(1~5%)만 2단계 하드웨어 엔진으로 전달하는 것입니다.

• 블룸 필터 사전 필터: 시그니처에서 추출한 고정 문자열(Literal)로 블룸 필터를 구성합니다. 블룸 필터에 히트되지 않으면 해당 패킷은 어떤 시그니처와도 매칭되지 않으므로 즉시 통과(PASS)합니다.
• 위양성 처리: 블룸 필터는 위양성(False Positive)이 존재하므로, 1단계를 통과한 패킷이 2단계에서 실제로 매칭되지 않을 수 있습니다. 이는 정상적인 동작이며, 블룸 필터 크기와 해시 함수 수를 조정하여 위양성 비율을 0.1~1% 수준으로 관리합니다.
• XDP/TC 기반 인라인 통합: 1단계 사전 필터를 XDP 또는 TC BPF 프로그램에 구현하면, 커널 네트워크 스택에 진입하기 전에 필터링할 수 있습니다.
• NFQUEUE 기반 통합: Netfilter의 NFQUEUE를 통해 패킷을 사용자 공간으로 전달하고, regex HW 엔진으로 검사한 후 NF_ACCEPT 또는 NF_DROP 판정을 반환합니다.

위 다이어그램은 2단계 DPI 파이프라인의 전체 흐름을 보여줍니다. 1단계 사전 필터에서 95~99%의 정상 트래픽을 즉시 통과시키고, 나머지 1~5%의 의심 트래픽만 2단계 Regex HW 엔진으로 전달합니다. 2단계에서도 위양성 패킷은 PASS로 처리되며, 실제 시그니처 매칭이 확인된 패킷만 DROP/LOG/ALERT 정책을 적용합니다.

상용 NGFW HW 아키텍처

커널 NGFW 빌딩 블록

Linux 커널에서 NGFW를 구축할 때 사용하는 주요 서브시스템과 NGFW 기능 간의 매핑입니다. 각 서브시스템은 독립적으로 발전해 왔지만, NGFW에서는 이들을 하나의 통합 파이프라인으로 결합해야 합니다. 이 절에서는 각 서브시스템의 역할과 연동 포인트를 정리합니다.

HW 오프로드 인터페이스 전체 지도

Linux에서 "HW 오프로드 인터페이스"는 하나의 API가 아닙니다. 사용자 공간에서 보이는 명령은 ethtool, tc, nft, ip xfrm, ip macsec, ip link xdpoffload, devlink처럼 제각각이지만, 커널 내부에서는 결국 feature bit 토글, 객체 생성/삭제, 드라이버 콜백, 펌웨어/ASIC 프로그래밍으로 수렴합니다. NGFW 관점에서는 다음 표를 하나의 지도처럼 기억하는 것이 가장 중요합니다.

사용자 공간 UAPI 계열 전수 분류

NGFW에서 "커널이 제공하는 HW offload 인터페이스"를 빠짐없이 이해하려면, 먼저 사용자 공간에서 보이는 인터페이스를 능력 협상, 데이터 경로 프로그래밍, 프로토콜 상태 오프로드, 예외/관측 네 계열로 나눠 보는 것이 좋습니다. 이름은 제각각이지만, 실제로는 모두 netlink, socket option, feature bit, 드라이버 콜백으로 수렴합니다.

패킷 경로별 부착 지점 지도

각 인터페이스는 패킷의 서로 다른 시점에 개입합니다. 이 위치를 잘못 이해하면 "XDP에서 이미 드롭된 패킷이 왜 NFQUEUE로 안 오느냐", "TLS offload를 켰는데 왜 TC 카운터와 상관이 없느냐" 같은 혼란이 생깁니다. 다음 그림은 NGFW에서 실제로 중요한 부착 지점을 시간 순서대로 보여 줍니다.

flow_rule와 flow_action 공통 계약

TC, nf_flowtable, 일부 switchdev 오브젝트가 결국 드라이버에게 전달될 때는 각자 별개의 형식으로 가지 않습니다. 커널은 대체로 flow dissector가 만든 match key와 flow_action 배열로 정규화합니다. 즉, 사용자 공간에서 tc filter ... flower action ct nat mirred라고 쓰든, nftables에서 flowtable offload를 요청하든, 드라이버 입장에서는 "어떤 field를 비교하고 어떤 action을 어떤 순서로 실행할지"라는 동일한 문제로 환원됩니다.

/* HW offload 요청이 드라이버로 내려가기 전 정규화되는 공통 형태(개념도) */
struct flow_cls_offload {
    enum flow_cls_command command;
    unsigned long cookie;
    u32 chain_index;
    u32 prio;
    struct flow_rule *rule;
    struct netlink_ext_ack *extack;
};

struct flow_rule {
    struct flow_match_basic      basic;
    struct flow_match_control    control;
    struct flow_match_meta       meta;
    struct flow_match_ipv4_addrs ipv4;
    struct flow_match_ports      ports;
    struct flow_match_vlan       vlan;
    struct flow_match_enc_keyid  enc_keyid;
    struct flow_action           action;
};

struct flow_action_entry {
    enum flow_action_id id;
    union {
        struct net_device *dev;      /* REDIRECT, MIRRED */
        u32 chain_index;            /* GOTO */
        u32 mark;                   /* CT metadata */
    };
};

리소스, extack, 폴백 계약

규칙이 HW에 "들어가지 않는" 대부분의 이유는 기능 미지원보다 자원 고갈과 조합 제한입니다. 커널은 이 문제를 netlink_ext_ack, devlink resource, devlink trap, 드라이버 통계로 노출합니다. 즉, offload 인터페이스는 규칙을 설치하는 기능만이 아니라, 실패 이유를 구조화해 되돌려 주는 오류 계약까지 포함합니다.

# 리소스와 실패 이유를 한 번에 확인하는 기본 점검 순서
ethtool -k eth0 | grep -E 'hw-tc-offload|tls-hw|esp-hw-offload'
devlink dev eswitch show pci/0000:03:00.0
devlink resource show pci/0000:03:00.0
tc -s filter show dev eth0 ingress
devlink -s trap show pci/0000:03:00.0
ethtool -S eth0 | grep -E 'offload|flow|ct_|tls|macsec'

예외 경로와 제로카피 연동 인터페이스

NGFW는 모든 트래픽을 HW만으로 처리하지 않습니다. DPI, 포렌식, 이상 행위 탐지, 사용자 공간 보안 엔진 연동을 위해 예외 경로가 반드시 필요합니다. 중요한 점은 이 예외 경로도 커널이 제공하는 별도의 인터페이스 집합으로 정의돼 있는 점입니다.

UAPI에서 ASIC까지 내려가는 제어 스택

모든 오프로드는 결국 같은 4단계를 거칩니다. 1) 사용자 공간 UAPI가 요청을 만들고, 2) 커널 서브시스템이 이를 일반화된 오브젝트로 정리한 뒤, 3) 드라이버 계약으로 변환하고, 4) NIC 펌웨어/ASIC 테이블에 실제 엔트리를 설치합니다. NGFW를 운영할 때 장애 지점을 찾으려면 이 4단계를 역순으로 확인해야 합니다.

ethtool과 netdev feature 계약

ethtool -K는 단순한 토글처럼 보이지만 실제로는 드라이버가 선언한 hw_features, 커널이 허용한 feature 조합, 개별 skb가 충족한 제약이 동시에 맞아야 비로소 HW 경로에 들어갑니다. 따라서 NGFW 장비에서 feature bit를 켜는 일은 "속도를 높이는 옵션"이 아니라 드라이버와 데이터 경로의 계약을 활성화하는 행위입니다.

/* feature 토글이 실제 HW 계약으로 번역되는 방식 */
static netdev_features_t ngfw_fix_features(struct net_device *dev,
                                              netdev_features_t features)
{
    /* SG가 없으면 대형 세그먼트와 TLS TX offload를 함께 쓸 수 없습니다. */
    if (!(features & NETIF_F_SG))
        features &= ~(NETIF_F_GSO_MASK | NETIF_F_HW_TLS_TX);

    /* HW checksum이 없으면 ESP offload도 사실상 성립하기 어렵습니다. */
    if (!(features & NETIF_F_HW_CSUM))
        features &= ~NETIF_F_HW_ESP;

    return features;
}

static int ngfw_set_features(struct net_device *dev,
                                    netdev_features_t features)
{
    if (features & NETIF_F_HW_TC)
        program_acl_parser(dev);
    if (features & NETIF_F_HW_TLS_TX)
        program_tls_tx_context(dev);
    if (features & NETIF_F_HW_ESP)
        enable_ipsec_context(dev);
    return 0;
}

# NGFW 장비에서 feature 계약 확인
ethtool -k eth0 | grep -E 'hw-tc-offload|tls-hw|esp-hw-offload|checksum'

# HW TC / TLS / ESP 지원을 켜기
ethtool -K eth0 hw-tc-offload on
ethtool -K eth0 tls-hw-tx-offload on tls-hw-rx-offload on
ethtool -K eth0 tx-checksum-ip-generic on

# per-skb 제약 때문에 실제 offload가 빠졌는지 확인
ip -details link show dev eth0
ethtool -S eth0

TC, switchdev, representor, devlink 계약

NGFW의 HW fast path는 보통 TC flower, nf_flowtable, switchdev, representor, devlink가 묶여 동작합니다. 즉, 매칭 규칙은 TC가 만들고, 세션/브리지 객체는 switchdev가 동기화하며, 포트 토폴로지와 trap/health 관리는 devlink가 담당합니다. 어느 하나라도 빠지면 "규칙은 들어갔는데 실제 와이어에서 안 돈다"는 현상이 생깁니다.

# 1. eSwitch를 switchdev 모드로 전환
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 2. representor와 포트 토폴로지 확인
devlink port show pci/0000:03:00.0
ip -details link show | grep -E 'repr|phys_port'

# 3. TC flower + conntrack offload 규칙 설치
tc filter add dev eth0 ingress protocol ip flower \
    ct_state +trk+est ip_proto tcp dst_port 443 \
    skip_sw action mirred egress redirect dev eth1

# 4. 오프로드 결과와 예외 패킷 확인
tc -s filter show dev eth0 ingress
bridge fdb show dev eth0
devlink trap show pci/0000:03:00.0
devlink health show pci/0000:03:00.0

IPsec, kTLS, MACsec 오프로드 계약

암호화 offload는 "암호화 장치 하나"로 통합돼 있지 않습니다. Linux는 프로토콜별로 별도의 계약을 둡니다. IPsec은 xfrmdev_ops, kTLS는 tlsdev_ops, MACsec은 macsec_ops를 사용합니다. 따라서 상용 NGFW처럼 SSL inspection ASIC 하나로 모든 암호화 경로를 덮는 구조가 아니라, 프로토콜마다 다른 offload 계약을 조합하는 방식입니다.

/* IPsec / TLS / MACsec은 서로 다른 드라이버 계약을 사용합니다. */
struct xfrmdev_ops {
    int  (*xdo_dev_state_add)(struct net_device *dev,
                              struct xfrm_state *x,
                              struct netlink_ext_ack *extack);
    bool (*xdo_dev_offload_ok)(struct sk_buff *skb,
                               struct xfrm_state *x);
    int  (*xdo_dev_policy_add)(struct xfrm_policy *p,
                               struct netlink_ext_ack *extack);
};

struct tlsdev_ops {
    int (*tls_dev_add)(struct net_device *netdev, struct sock *sk,
                       enum tls_offload_ctx_dir direction,
                       struct tls_crypto_info *crypto_info,
                       u32 start_offload_tcp_sn);
    void (*tls_dev_del)(struct net_device *netdev,
                        struct tls_context *ctx,
                        enum tls_offload_ctx_dir direction);
    int (*tls_dev_resync)(struct net_device *netdev,
                          struct sock *sk, u32 seq,
                          u8 *rcd_sn, enum tls_offload_ctx_dir direction);
};

struct macsec_ops {
    int (*mdo_add_secy)(struct macsec_context *ctx);
    int (*mdo_add_txsa)(struct macsec_context *ctx);
    int (*mdo_add_rxsc)(struct macsec_context *ctx);
    int (*mdo_add_rxsa)(struct macsec_context *ctx);
};

# IPsec offload
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x1000 mode transport \
    aead 'rfc4106(gcm(aes))' 0x00112233445566778899aabbccddeeff00112233 128 \
    offload dev eth0 dir out

# kTLS offload
ethtool -K eth0 tls-hw-tx-offload on tls-hw-rx-offload on
cat /proc/net/tls_stat

# MACsec offload
ip link add link eth0 macsec0 type macsec port 1 encrypt on
ip macsec offload macsec0 mac

# 실제 feature 노출 확인
ethtool -k eth0 | grep -E 'esp-hw-offload|tls-hw'

예외 경로, 통계, 폴백 인터페이스

오프로드 운영에서 중요한 것은 "켜졌는지"보다 "왜 빠졌는지"입니다. HW 용량 초과, 지원하지 않는 match field, MTU 제약, TLS resync 실패, XFRM 정책 불일치 같은 이유로 언제든 SW 경로로 되돌아갈 수 있습니다. 아래 인터페이스는 그 순간을 잡아내는 데 사용합니다.

드라이버 오프로드 계약 (ndo_setup_tc)

NIC 드라이버가 TC flower offload를 지원하기 위해 구현해야 하는 인터페이스입니다. NGFW 파이프라인의 HW offload는 이 계약에 의존합니다. (Network Device 드라이버 참고)

/* include/linux/netdevice.h */
struct net_device_ops {
    /* TC flower offload 진입점 */
    int (*ndo_setup_tc)(struct net_device *dev,
                        enum tc_setup_type type,
                        void *type_data);
};

/* 드라이버가 처리해야 하는 TC 타입 */
enum tc_setup_type {
    TC_SETUP_QDISC_MQPRIO,   /* MQPRIO QoS 큐 설정 */
    TC_SETUP_CLSFLOWER,       /* TC flower 분류기 규칙 */
    TC_SETUP_FT,              /* flowtable offload */
    TC_SETUP_BLOCK,           /* 블록 바인딩 (CT offload) */
};

/* CLSFLOWER 콜백에서 처리하는 명령 */
enum tc_fl_command {
    TC_CLSFLOWER_REPLACE,    /* 규칙 추가/교체 */
    TC_CLSFLOWER_DESTROY,    /* 규칙 삭제 */
    TC_CLSFLOWER_STATS,      /* HW 카운터 읽기 */
};

nf_flowtable 내부 구조

/* include/net/netfilter/nf_flow_table.h */
struct nf_flowtable {
    struct list_head   list;        /* flowtable 전역 리스트 */
    struct rhashtable  rhashtable;  /* 5-tuple 해시 테이블 */
    int                priority;    /* Netfilter 훅 우선순위 */
    unsigned int       flags;       /* NF_FLOWTABLE_HW_OFFLOAD 등 */
    struct nf_flowtable_type *type;
    struct delayed_work gc_work;    /* GC 워크큐 */
    struct flow_block  flow_block;  /* HW offload 블록 */
    struct mutex       flow_block_lock;
    possible_net_t     net;
};

/* rhashtable 파라미터: 자동 크기 조절 */
static const struct rhashtable_params nf_flow_offload_rhash_params = {
    .head_offset     = offsetof(struct flow_offload_tuple_rhash, node),
    .key_offset      = offsetof(struct flow_offload_tuple_rhash, tuple),
    .key_len         = sizeof(struct flow_offload_tuple),
    .automatic_shrinking = true,  /* 엔트리 감소 시 자동 축소 */
};

flowtable은 rhashtable(Resizable Hash Table)을 사용합니다. 엔트리 수에 따라 버킷이 자동으로 확장/축소되며, RCU 기반 읽기로 lock-free lookup을 보장합니다. 이는 NGFW에서 높은 CPS 환경에서도 Fast Path lookup의 일관된 성능을 유지하는 핵심입니다.

핵심 커널 API 흐름

/* NGFW 파이프라인의 커널 API 호출 흐름 (개념도) */

/* 1. 패킷 수신 → Netfilter PREROUTING 훅 */
nf_hook(NFPROTO_IPV4, NF_INET_PRE_ROUTING, skb);

/* 2. conntrack: 세션 추적 */
struct nf_conn *ct = nf_ct_get(skb, &ctinfo);
if (ctinfo == IP_CT_NEW) {
    /* 새 세션 → Slow Path: 전체 규칙 평가 */
    nft_do_chain(chain, skb);  /* nftables 규칙 평가 */
    nf_queue(skb, queue_num);  /* NFQUEUE → DPI 엔진 */
}

/* 3. flowtable: ESTABLISHED 세션 Fast Path */
if (ctinfo == IP_CT_ESTABLISHED) {
    struct flow_offload *flow = flow_offload_lookup(ft, skb);
    if (flow) {
        /* Fast Path: conntrack bypass → 직접 전달 */
        nf_flow_offload_ip_hook(skb);  /* NAT rewrite + forward */
        return NF_STOLEN;  /* Netfilter 훅 체인 종료 */
    }
}

/* 4. HW offload 등록 */
flow_offload_add(ft, flow);
if (ft->flags & NF_FLOWTABLE_HW_OFFLOAD)
    nf_flow_offload_hw_add(net, flow, ct);  /* eSwitch FDB rule 설치 */

NFQUEUE 연동 API

DPI 엔진이 NFQUEUE에서 패킷을 수신하고 verdict를 반환하는 과정의 유저스페이스 API입니다:

/* libnetfilter_queue를 사용한 DPI 엔진 기본 구조 */
#include <libnetfilter_queue/libnetfilter_queue.h>

static int nfq_callback(struct nfq_q_handle *qh,
                        struct nfgenmsg *nfmsg,
                        struct nfq_data *nfa,
                        void *data)
{
    struct nfqnl_msg_packet_hdr *ph;
    unsigned char *payload;
    int payload_len;
    uint32_t id;

    ph = nfq_get_msg_packet_hdr(nfa);
    id = ntohl(ph->packet_id);
    payload_len = nfq_get_payload(nfa, &payload);

    /* DPI 분석 수행 */
    int verdict = analyze_packet(payload, payload_len);

    /* verdict 반환: NF_ACCEPT 또는 NF_DROP */
    if (verdict == DPI_ALLOW)
        return nfq_set_verdict(qh, id, NF_ACCEPT, 0, NULL);
    else
        return nfq_set_verdict(qh, id, NF_DROP, 0, NULL);
}

/* 메인 루프: NFQUEUE 수신 + DPI 콜백 */
int main(void)
{
    struct nfq_handle *h = nfq_open();
    struct nfq_q_handle *qh = nfq_create_queue(h, 0,
                                                 &nfq_callback, NULL);

    /* 배치 verdict 활성화 (성능 향상) */
    nfq_set_queue_flags(qh, NFQA_CFG_F_GSO, NFQA_CFG_F_GSO);

    /* 소켓에서 패킷 수신 루프 */
    int fd = nfq_fd(h);
    char buf[65536];
    int rv;
    while ((rv = recv(fd, buf, sizeof(buf), 0)) > 0)
        nfq_handle_packet(h, buf, rv);

    return 0;
}

오프로드 구현 패턴

Suricata NFQUEUE 통합 설정

Suricata를 NGFW의 DPI/IPS 엔진으로 사용할 때의 최적화된 설정입니다:

# /etc/suricata/suricata.yaml (NGFW 최적화)

# NFQUEUE 모드 설정
nfq:
  mode: repeat          # verdict 후 재주입 (NFQUEUE → nftables 계속)
  repeat-mark: 1        # 재주입된 패킷 마킹 (중복 큐잉 방지)
  repeat-mask: 1
  bypass: yes           # Suricata 과부하 시 패킷 bypass (가용성 우선)
  fail-open: yes        # Suricata 장애 시 패킷 통과 (HA 환경)
  batchcount: 20        # 배치 verdict (성능 향상)

# 멀티 스레드 설정 (CPU 코어 4~16개 환경)
threading:
  set-cpu-affinity: yes
  cpu-affinity:
    - management-cpu-set:
        cpu: [ 0 ]
    - receive-cpu-set:
        cpu: [ 1, 2, 3, 4 ]    # NFQUEUE 수신 스레드
    - worker-cpu-set:
        cpu: [ 5, 6, 7, 8, 9, 10, 11, 12 ]  # 분석 워커

# App-Layer 프로토콜 분석 (NGFW App-ID)
app-layer:
  protocols:
    tls:
      enabled: yes
      detection-ports:
        dp: 443, 8443
      ja3-fingerprints: yes   # JA3/JA3S 핑거프린트 (TLS 분류)
    http:
      enabled: yes
      server-body-limit: 1mb  # DLP를 위한 바디 검사 한계
    dns:
      enabled: yes
    smb:
      enabled: yes
    ssh:
      enabled: yes
      hassh: yes              # HASSH 핑거프린트

# 플로우 타임아웃 (flowtable과 동기화)
flow-timeouts:
  default:
    new: 30
    established: 300          # nf_flowtable_tcp_timeout과 일치
    closed: 10
    bypassed: 300             # bypass된 세션 (오프로드됨)
  tcp:
    new: 60
    established: 600
    closed: 60

# bypass 설정 (오프로드 연동)
stream:
  bypass: yes                 # 분류 완료 후 스트림 바이패스
  max-sessions: 1000000       # 최대 동시 세션

nftables NGFW 설정

완전한 nftables 규칙셋으로 NGFW 데이터 플레인을 구성하는 예시입니다. flowtable으로 ESTABLISHED 세션을 오프로드하고, NEW 세션은 NFQUEUE로 DPI 검사를 수행합니다.

#!/usr/sbin/nft -f
# NGFW nftables 규칙셋 (flowtable + NFQUEUE DPI)

table inet ngfw {
    # flowtable 정의 (HW offload 활성화)
    flowtable ft {
        hook ingress priority 0
        devices = { eth0, eth1 }
        flags offload  # NF_FLOWTABLE_HW_OFFLOAD
    }

    # forward chain: NGFW 핵심 파이프라인
    chain forward {
        type filter hook forward priority 0; policy drop;

        # 1. INVALID 패킷 즉시 DROP
        ct state invalid drop

        # 2. ESTABLISHED/RELATED → flowtable offload
        ct state established,related flow add @ft accept

        # 3. NEW 세션 → 기본 ACL 통과 후 NFQUEUE로 DPI
        ct state new ip protocol tcp \
            tcp dport { 80, 443, 8080, 8443 } \
            queue num 0-3 fanout  # 4개 DPI 워커로 분산

        ct state new ip protocol udp \
            udp dport { 53, 443 } \
            queue num 0-3 fanout

        # 4. 허용된 ICMP
        ct state new icmp type { echo-request, echo-reply } accept

        # 5. 나머지 NEW → DROP (기본 정책)
    }

    # input chain: 관리 인터페이스 보호
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iifname "lo" accept
        tcp dport 22 accept  # SSH 관리
    }
}

TC flower ACL 오프로드

eSwitch switchdev 모드에서 TC flower를 사용하여 ACL 규칙을 하드웨어에 직접 설치합니다. 이 방식은 nftables의 SW 경로와 병행하여, NEW 패킷은 CPU(nftables → NFQUEUE → DPI)에서 처리하고 ESTABLISHED 패킷은 eSwitch HW에서 직접 전달합니다.

# 1. eSwitch switchdev 모드 전환
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# 2. VF representor에서 hw-tc-offload 활성화
ethtool -K eth0_rep0 hw-tc-offload on

# 3. conntrack zone 설정 + 추적 시작
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# 4. EST+TRK → NAT + forward (HW offload)
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 nat \
  action mirred egress redirect dev eth1_rep0

# 5. NEW+TRK → pass to CPU (Slow Path)
tc filter add dev eth0_rep0 ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass

# 6. 특정 IP 대역 차단 (HW에서 DROP)
tc filter add dev eth0_rep0 ingress prio 0 \
  protocol ip flower \
  src_ip 192.168.100.0/24 \
  action drop

DPI 오프로드 바이패스 패턴

DPI 엔진이 세션을 분류하면 이후 패킷은 NFQUEUE를 bypass해야 합니다. eBPF map을 활용한 캐시 패턴입니다:

eBPF DPI 결과 캐시 (완전한 구현)

/* dpi_cache.bpf.c — eBPF DPI 결과 캐시 프로그램 */
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/udp.h>

/* 5-tuple 플로우 키 */
struct flow_key {
    __be32 src_ip;
    __be32 dst_ip;
    __be16 src_port;
    __be16 dst_port;
    __u8   protocol;
    __u8   pad[3];
};

/* DPI 결과 값 */
struct dpi_result {
    __u32 verdict;      /* 0=ACCEPT, 1=DROP, 2=CONTINUE */
    __u32 app_id;       /* 애플리케이션 ID (DPI 엔진이 설정) */
    __u64 timestamp;    /* 마지막 갱신 (nsec) */
    __u64 bytes;        /* 바이트 카운터 (샘플링용) */
};

/* LRU 해시 맵: 자동으로 가장 오래된 엔트리 퇴출 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 500000);
    __type(key, struct flow_key);
    __type(value, struct dpi_result);
} dpi_cache SEC(".maps");

/* 통계 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 4);
    __type(key, __u32);
    __type(value, __u64);
} stats SEC(".maps");
/* stats[0]=cache_hit, stats[1]=cache_miss,
   stats[2]=bypass_accept, stats[3]=bypass_drop */

static __always_inline int
extract_flow_key(struct __sk_buff *skb, struct flow_key *key)
{
    void *data = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;
    struct iphdr *iph = data + sizeof(struct ethhdr);

    if ((void *)(iph + 1) > data_end)
        return -1;

    key->src_ip = iph->saddr;
    key->dst_ip = iph->daddr;
    key->protocol = iph->protocol;

    if (iph->protocol == IPPROTO_TCP) {
        struct tcphdr *tcph = (void *)iph + (iph->ihl * 4);
        if ((void *)(tcph + 1) > data_end) return -1;
        key->src_port = tcph->source;
        key->dst_port = tcph->dest;
    } else if (iph->protocol == IPPROTO_UDP) {
        struct udphdr *udph = (void *)iph + (iph->ihl * 4);
        if ((void *)(udph + 1) > data_end) return -1;
        key->src_port = udph->source;
        key->dst_port = udph->dest;
    }
    return 0;
}

SEC("netfilter")
int dpi_bypass(struct bpf_nf_ctx *ctx)
{
    struct flow_key key = {};
    __u32 idx;
    __u64 *counter;

    if (extract_flow_key(ctx->skb, &key) < 0)
        return NF_ACCEPT;

    struct dpi_result *result = bpf_map_lookup_elem(&dpi_cache, &key);
    if (result) {
        /* 캐시 히트 */
        idx = 0; counter = bpf_map_lookup_elem(&stats, &idx);
        if (counter) (*counter)++;

        /* 바이트 카운터 갱신 (샘플링 판단용) */
        __sync_fetch_and_add(&result->bytes, ctx->skb->len);

        /* 10MB 초과 시 캐시 무효화 → 재검사 */
        if (result->bytes > 10485760) {
            bpf_map_delete_elem(&dpi_cache, &key);
            return NF_ACCEPT;  /* NFQUEUE로 전달 */
        }

        if (result->verdict == 0) {
            idx = 2; counter = bpf_map_lookup_elem(&stats, &idx);
            if (counter) (*counter)++;
            return NF_ACCEPT;   /* DPI ALLOW → bypass */
        } else if (result->verdict == 1) {
            idx = 3; counter = bpf_map_lookup_elem(&stats, &idx);
            if (counter) (*counter)++;
            return NF_DROP;     /* DPI DROP → 즉시 차단 */
        }
    }
    /* 캐시 미스 → NFQUEUE로 전달 (DPI 검사) */
    idx = 1; counter = bpf_map_lookup_elem(&stats, &idx);
    if (counter) (*counter)++;
    return NF_ACCEPT;
}

char _license[] SEC("license") = "GPL";

DPI 엔진에서 eBPF 맵 업데이트

Suricata의 output 플러그인에서 verdict를 eBPF 맵에 기록합니다:

/* Suricata output 플러그인 (유저스페이스): verdict를 eBPF 맵에 기록 */
#include <bpf/libbpf.h>
#include <bpf/bpf.h>

int map_fd;  /* bpf_obj_get()으로 pinned map 열기 */

void update_dpi_cache(struct Packet *p, int verdict)
{
    struct flow_key key = {
        .src_ip   = p->src.addr_data32[0],
        .dst_ip   = p->dst.addr_data32[0],
        .src_port = p->sp,
        .dst_port = p->dp,
        .protocol = p->proto,
    };
    struct dpi_result result = {
        .verdict   = (verdict == VERDICT_PASS) ? 0 : 1,
        .app_id    = p->flow->alproto,
        .timestamp = get_timestamp_ns(),
        .bytes     = 0,
    };

    bpf_map_update_elem(map_fd, &key, &result, BPF_ANY);

    /* 역방향 플로우도 등록 (양방향 캐시) */
    struct flow_key rev_key = {
        .src_ip = key.dst_ip, .dst_ip = key.src_ip,
        .src_port = key.dst_port, .dst_port = key.src_port,
        .protocol = key.protocol,
    };
    bpf_map_update_elem(map_fd, &rev_key, &result, BPF_ANY);
}

# eBPF 프로그램 로드 및 nftables 연동
# 1. 컴파일
clang -O2 -target bpf -c dpi_cache.bpf.c -o dpi_cache.bpf.o

# 2. 로드 및 맵 핀닝
bpftool prog load dpi_cache.bpf.o /sys/fs/bpf/dpi_bypass \
  type netfilter

# 3. nftables에서 eBPF 프로그램 연결
# (nftables 커널 5.18+에서 BPF verdict 지원)
nft add rule inet ngfw forward \
  ct state new \
  meta mark != 0xff \
  queue num 0-3 fanout  # BPF 캐시 미스만 NFQUEUE로 전달

# 4. 캐시 통계 확인
bpftool map dump pinned /sys/fs/bpf/dpi_bypass/stats
# key: 0  value (per-cpu): [12345, 12340, ...]  ← cache_hit
# key: 1  value (per-cpu): [567, 570, ...]      ← cache_miss

NGFW 시스템 서비스 구성

Linux NGFW를 프로덕션에 배포하기 위한 systemd 서비스 구성입니다:

# /etc/systemd/system/ngfw-nftables.service
[Unit]
Description=NGFW nftables Rules
Before=suricata.service
After=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/nftables-ngfw.conf
ExecReload=/usr/sbin/nft -f /etc/nftables-ngfw.conf
ExecStop=/usr/sbin/nft flush ruleset

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/ngfw-eswitch.service
[Unit]
Description=NGFW eSwitch TC flower Rules
After=ngfw-nftables.service
Requires=ngfw-nftables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=/usr/bin/devlink dev eswitch set pci/0000:03:00.0 mode switchdev
ExecStartPre=/usr/bin/sleep 2
ExecStartPre=/usr/sbin/ethtool -K eth0_rep0 hw-tc-offload on
ExecStart=/usr/local/bin/ngfw-tc-rules.sh
ExecStop=/usr/sbin/tc filter del dev eth0_rep0 ingress

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/ngfw-tuning.service
[Unit]
Description=NGFW Kernel Tuning
Before=ngfw-nftables.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '\
  sysctl -w net.netfilter.nf_conntrack_max=2000000; \
  sysctl -w net.netfilter.nf_conntrack_buckets=500000; \
  sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300; \
  sysctl -w net.netfilter.nf_flowtable_tcp_timeout=300; \
  sysctl -w net.core.optmem_max=81920; \
  sysctl -w net.core.netdev_budget=600; \
  sysctl -w net.core.netdev_max_backlog=10000; \
  sysctl -w net.ipv4.ip_forward=1; \
  ethtool -C eth0 rx-usecs 50 rx-frames 64 adaptive-rx on; \
  ethtool -G eth0 rx 4096 tx 4096; \
  /usr/local/bin/set_irq_affinity.sh 0-3 eth0 \
'

[Install]
WantedBy=multi-user.target

# 서비스 활성화 및 시작 순서
systemctl enable ngfw-tuning ngfw-nftables ngfw-eswitch
systemctl enable suricata conntrackd

# 시작 순서: tuning → nftables → eswitch → suricata → conntrackd
systemctl start ngfw-tuning
systemctl start ngfw-nftables
systemctl start ngfw-eswitch
systemctl start suricata
systemctl start conntrackd

# 상태 확인
systemctl status ngfw-nftables ngfw-eswitch suricata conntrackd

멀티 테이블 파이프라인

TC chain을 사용하여 다단계 매칭 파이프라인을 구성합니다:

# chain 0: conntrack 추적 및 분기
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower ct_state -trk \
  action ct zone 1 pipe \
  action goto chain 1

# chain 1: 상태 기반 분기
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state +trk+est \
  action goto chain 2  # ESTABLISHED → Fast Path chain

tc filter add dev eth0_rep0 ingress chain 1 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass  # NEW → CPU (Slow Path)

# chain 2: Fast Path (NAT + forward)
tc filter add dev eth0_rep0 ingress chain 2 prio 1 \
  protocol ip flower \
  action ct zone 1 nat \
  action mirred egress redirect dev eth1_rep0

XDP DDoS Pre-filter 패턴

NGFW의 가장 앞단에서 XDP를 사용하여 DDoS/스캔 트래픽을 CPU 부하 없이 처리합니다. 이 패턴은 conntrack 테이블 포화를 방지하는 핵심 방어선입니다.

/* xdp_ddos_filter.c — NGFW XDP DDoS Pre-filter */
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>

/* 차단 IP 세트 (관리 도구에서 동적 업데이트) */
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
    __uint(max_entries, 100000);
    __uint(map_flags, BPF_F_NO_PREALLOC);
    __type(key, struct lpm_key);
    __type(value, __u32);
} blocklist SEC(".maps");

/* SYN flood 속도 제한 (per-source IP) */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, __be32);      /* source IP */
    __type(value, __u64);     /* timestamp + count */
} syn_rate SEC(".maps");

SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end) return XDP_DROP;
    if (eth->h_proto != __constant_htons(ETH_P_IP)) return XDP_PASS;

    struct iphdr *iph = (void *)(eth + 1);
    if ((void *)(iph + 1) > data_end) return XDP_DROP;

    /* 1. IP 차단 리스트 확인 (LPM Trie: CIDR 매칭) */
    struct lpm_key key = { .prefixlen = 32, .addr = iph->saddr };
    if (bpf_map_lookup_elem(&blocklist, &key))
        return XDP_DROP;  /* 차단 IP → 즉시 DROP (최소 지연) */

    /* 2. SYN flood 감지 (TCP SYN 패킷만) */
    if (iph->protocol == IPPROTO_TCP) {
        struct tcphdr *tcph = (void *)iph + (iph->ihl * 4);
        if ((void *)(tcph + 1) > data_end) return XDP_DROP;

        if (tcph->syn && !tcph->ack) {
            /* SYN 속도 제한: 소스 IP당 초당 100 SYN */
            __u64 *rate = bpf_map_lookup_elem(&syn_rate, &iph->saddr);
            __u64 now = bpf_ktime_get_ns();
            if (rate) {
                __u64 last = *rate & 0xFFFFFFFF00000000ULL;
                __u32 count = *rate & 0xFFFFFFFF;
                if (now - last < 1000000000ULL) { /* 1초 이내 */
                    if (count > 100)
                        return XDP_DROP; /* 속도 초과 → DROP */
                    *rate = last | (count + 1);
                } else {
                    *rate = (now & 0xFFFFFFFF00000000ULL) | 1;
                }
            } else {
                __u64 val = (now & 0xFFFFFFFF00000000ULL) | 1;
                bpf_map_update_elem(&syn_rate, &iph->saddr, &val, BPF_ANY);
            }
        }
    }

    return XDP_PASS;  /* 정상 → 커널 네트워크 스택으로 전달 */
}

char _license[] SEC("license") = "GPL";

# XDP DDoS 필터 운영 명령
# 프로그램 로드
ip link set dev eth0 xdp obj xdp_ddos_filter.o sec xdp

# IP 차단 리스트 관리 (bpftool)
bpftool map update pinned /sys/fs/bpf/xdp_ddos/blocklist \
  key hex 20 00 00 00 c0 a8 64 00 \
  value hex 01 00 00 00  # 192.168.100.0/32 차단

# SYN flood 상위 공격자 확인
bpftool map dump pinned /sys/fs/bpf/xdp_ddos/syn_rate | \
  sort -t: -k2 -rn | head -20

# XDP 통계 확인
ip -s link show dev eth0 | grep -A5 xdp

conntrackd HA (세션 동기화)

Active-Standby NGFW 클러스터에서 failover 시 기존 세션을 유지하려면 conntrack 테이블을 실시간 동기화해야 합니다:

# /etc/conntrackd/conntrackd.conf (NGFW HA)
Sync {
    Mode FTFW {          # Fault Tolerant (ack 기반 신뢰성)
        DisableExternalCache Off
        CommitTimeout 1800
        PurgeTimeout 5
    }

    # 동기화 프로토콜
    Multicast {
        IPv4_address 225.0.0.50
        Group 3780
        IPv4_interface 192.168.100.1  # HA 전용 인터페이스
        Interface eth2
        SndSocketBuffer 1249280
        RcvSocketBuffer 1249280
        Checksum on
    }
}

General {
    Nice -20                  # 높은 우선순위
    HashSize 32768
    HashLimit 131072          # 최대 동기화 엔트리

    # 동기화 대상 필터 (flowtable 오프로드 세션 포함)
    Filter From Kernelspace {
        Protocol Accept {
            TCP
            UDP
        }
        Address Ignore {
            IPv4_address 127.0.0.1   # 로컬 제외
            IPv4_address 224.0.0.0/4 # 멀티캐스트 제외
        }
    }
}

# HA failover 스크립트 (Keepalived notify 스크립트)
#!/bin/bash
# /usr/local/bin/ngfw-failover.sh

case "$1" in
  "MASTER")
    # Active 전환: flowtable HW offload 재등록
    conntrackd -c           # 외부 캐시 → 커널 동기화
    conntrackd -k           # 커널 conntrack 동기화 요청

    # eSwitch FDB 규칙 재설치 (기존 EST 세션)
    nft flush flowtable inet ngfw ft
    nft add flowtable inet ngfw ft \
      { hook ingress priority 0\; devices = { eth0, eth1 }\; flags offload\; }

    # 기존 conntrack의 EST 세션을 flowtable에 재등록
    # (자동으로 다음 패킷이 도착하면 flow add @ft에 의해 등록됨)
    ;;
  "BACKUP")
    # Standby 전환: HW offload 정리
    conntrackd -f           # 외부 캐시 플러시
    nft flush flowtable inet ngfw ft
    ;;
esac

XDP HW 오프로드와 라인레이트 DDoS 방어

XDP(eXpress Data Path)는 리눅스 커널의 네트워크 스택 최하단에서 BPF 프로그램을 실행하여 패킷을 초기 단계에 처리하는 프레임워크입니다. 특히 HW 오프로드 모드에서는 BPF 프로그램이 NIC의 ASIC/FPGA에서 직접 실행되어, CPU를 전혀 사용하지 않고 라인 레이트(Line Rate)로 패킷을 필터링합니다. 이 절에서는 XDP의 3가지 동작 모드, HW 오프로드의 제약사항, 라인레이트 DDoS 필터 구현, 그리고 XDP offload + TC flower + flowtable 3계층 방어 아키텍처를 다룹니다.

XDP 오프로드 모드 비교

XDP는 BPF 프로그램이 실행되는 위치에 따라 세 가지 모드로 동작합니다. 각 모드는 성능, 호환성, 기능 제약 사이의 트레이드오프(Trade-off)가 다릅니다.

XDP 프로그램의 모드별 로딩 방법은 다음과 같습니다.

# Generic 모드 — 모든 NIC에서 동작 (테스트 용도)
ip link set dev eth0 xdpgeneric obj xdp_filter.o sec xdp

# Native 모드 — 드라이버 레벨 (고성능, 대부분의 최신 NIC)
ip link set dev eth0 xdp obj xdp_filter.o sec xdp

# HW Offload 모드 — NIC ASIC에서 직접 실행 (라인 레이트)
ip link set dev eth0 xdpoffload obj xdp_filter.o sec xdp

# 현재 XDP 프로그램 확인
ip link show dev eth0
# 출력 예: ... xdpoffload prog/id 42 tag abc123...

# XDP 프로그램 제거
ip link set dev eth0 xdpoffload off

# 커널에서 XDP HW offload 지원 여부 확인
ethtool -i eth0 | grep driver
# Netronome: nfp
# NVIDIA:    mlx5_core
bpftool feature probe dev eth0 | grep xdp

XDP HW 오프로드 제약사항과 지원 NIC

XDP HW 오프로드는 BPF 프로그램을 NIC 내부의 프로세서(마이크로엔진, FPGA 등)에서 실행하므로, CPU 기반 실행과는 다른 엄격한 제약이 있습니다.

HW 오프로드 모드에서의 주요 제약사항은 다음과 같습니다.

• 루프(Loop) 금지: BPF 검증기(Verifier)의 bounded loop도 HW에서는 지원되지 않습니다. 모든 반복 작업은 언롤링(Unrolling)해야 합니다.
• 꼬리 호출(Tail Call) 미지원: bpf_tail_call()은 HW 오프로드에서 사용할 수 없습니다.
• 헬퍼 함수 제한: bpf_map_lookup_elem(), bpf_map_update_elem() 등 기본 맵 연산만 지원되며, bpf_ktime_get_ns(), bpf_trace_printk() 등 커널 의존 헬퍼는 사용할 수 없습니다.
• 맵 타입 제한: BPF_MAP_TYPE_HASH, BPF_MAP_TYPE_ARRAY, BPF_MAP_TYPE_LPM_TRIE 정도만 지원됩니다.
• 명령어 수 제한: NIC의 마이크로엔진 메모리 크기에 따라 BPF 명령어 수가 제한됩니다. Netronome NFP는 4,000개 이상을 지원하지만, 복잡한 프로그램은 최적화가 필요합니다.
• 패킷 수정 제한: 일부 NIC에서는 XDP_TX(수정 후 재전송)가 HW 오프로드에서 동작하지 않습니다.

라인레이트 DDoS 필터 구현

HW 오프로드 가능한 XDP 프로그램으로 라인 레이트 DDoS 방어 필터를 구현합니다. 핵심 전략은 세 가지입니다: (1) LPM Trie 기반 IP 블랙리스트, (2) SYN 검증, (3) 소스별 패킷 레이트 제한입니다.

/* xdp_ddos_filter.c — HW offload 가능 DDoS 필터 */
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>

/* LPM Trie 키: prefix + IPv4 주소 */
struct lpm_key {
    __u32 prefixlen;
    __u32 addr;
};

/* 소스 IP별 카운터 */
struct rate_info {
    __u64 packets;
    __u64 bytes;
    __u64 last_reset;   /* HW 모드에서는 userspace에서 리셋 */
};

/* IP 블랙리스트 — LPM Trie (CIDR 매칭) */
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
    __uint(max_entries, 100000);
    __type(key, struct lpm_key);
    __type(value, __u64);       /* drop counter */
    __uint(map_flags, BPF_F_NO_PREALLOC);
} ip_blocklist SEC(".maps");

/* 소스 IP별 레이트 카운터 */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1000000);
    __type(key, __u32);          /* src IP */
    __type(value, struct rate_info);
} rate_counters SEC(".maps");

/* 글로벌 설정 (userspace에서 업데이트) */
struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 4);
    __type(key, __u32);
    __type(value, __u64);
} config SEC(".maps");

/* 설정 인덱스 */
#define CFG_RATE_LIMIT_PPS   0   /* 소스당 최대 pps */
#define CFG_RATE_LIMIT_BPS   1   /* 소스당 최대 bps */
#define CFG_SYN_VALIDATE     2   /* SYN 검증 활성화 여부 */
#define CFG_DROP_COUNTER     3   /* 전체 드롭 카운터 */

static __always_inline __u64 get_config(__u32 idx)
{
    __u32 key = idx;
    __u64 *val = bpf_map_lookup_elem(&config, &key);
    return val ? *val : 0;
}

SEC("xdp")
int xdp_ddos_filter(struct xdp_md *ctx)
{
    void *data     = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    /* 이더넷 헤더 파싱 */
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;

    /* IPv4만 처리 */
    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;

    __u32 src_ip = ip->saddr;

    /* === 1단계: LPM Trie IP 블랙리스트 === */
    struct lpm_key lpm = {
        .prefixlen = 32,
        .addr      = src_ip,
    };
    __u64 *blocked = bpf_map_lookup_elem(&ip_blocklist, &lpm);
    if (blocked) {
        __sync_fetch_and_add(blocked, 1);
        return XDP_DROP;
    }

    /* === 2단계: 소스별 레이트 제한 === */
    __u64 max_pps = get_config(CFG_RATE_LIMIT_PPS);
    if (max_pps > 0) {
        struct rate_info *info;
        info = bpf_map_lookup_elem(&rate_counters, &src_ip);
        if (info) {
            __u64 cur = __sync_fetch_and_add(&info->packets, 1);
            __sync_fetch_and_add(&info->bytes,
                                  data_end - data);
            if (cur > max_pps)
                return XDP_DROP;
        } else {
            struct rate_info new_info = {
                .packets    = 1,
                .bytes      = data_end - data,
                .last_reset = 0,
            };
            bpf_map_update_elem(&rate_counters, &src_ip,
                                &new_info, BPF_NOEXIST);
        }
    }

    /* === 3단계: TCP SYN 검증 === */
    if (ip->protocol == IPPROTO_TCP) {
        struct tcphdr *tcp = (void *)ip + (ip->ihl * 4);
        if ((void *)(tcp + 1) > data_end)
            return XDP_DROP;

        __u64 syn_check = get_config(CFG_SYN_VALIDATE);
        if (syn_check && tcp->syn && !tcp->ack) {
            /*
             * SYN 패킷 레이트 제한:
             * HW 모드에서는 SYN cookie 계산이 불가능하므로,
             * 단순 레이트 기반 SYN flood 완화를 적용합니다.
             * 소스 IP당 SYN 레이트가 임계치 초과 시 DROP.
             */
            struct rate_info *info;
            info = bpf_map_lookup_elem(&rate_counters, &src_ip);
            if (info && info->packets > (max_pps / 10))
                return XDP_DROP;
        }
    }

    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

# BPF 프로그램 컴파일 (HW offload 호환)
clang -O2 -g -target bpf \
      -D__TARGET_ARCH_x86 \
      -c xdp_ddos_filter.c \
      -o xdp_ddos_filter.o

# HW offload 모드로 로드 (Netronome Agilio CX 예시)
ip link set dev eth0 xdpoffload obj xdp_ddos_filter.o sec xdp

# 로드 확인
bpftool prog show dev eth0
# 출력 예:
# 42: xdp  tag abc123def456  dev eth0  offloaded
#     loaded_at 2026-03-26T10:00:00+0900  uid 0
#     xlated 384B  jited 0B  memlock 4096B
#     map_ids 10,11,12

# IP 블랙리스트에 CIDR 추가 (userspace에서 맵 업데이트)
bpftool map update id 10 \
    key hex 20 00 00 00 c0 a8 01 00 \
    value hex 00 00 00 00 00 00 00 00
# → 192.168.1.0/32 차단

# 대역 차단 (/24)
bpftool map update id 10 \
    key hex 18 00 00 00 0a 00 01 00 \
    value hex 00 00 00 00 00 00 00 00
# → 10.0.1.0/24 차단

# 레이트 제한 설정 (소스당 10000 pps)
bpftool map update id 12 \
    key hex 00 00 00 00 \
    value hex 10 27 00 00 00 00 00 00

# SYN 검증 활성화
bpftool map update id 12 \
    key hex 02 00 00 00 \
    value hex 01 00 00 00 00 00 00 00

# 레이트 카운터 주기적 리셋 (cron 또는 userspace 데몬)
# HW 모드에서는 bpf_ktime_get_ns()를 사용할 수 없으므로
# userspace에서 주기적으로 카운터를 리셋해야 합니다
while true; do
    bpftool map dump id 11 | \
        awk '/key:/{k=$2} /packets:/{if($2>0) print k}' | \
        while read key; do
            bpftool map delete id 11 key hex $key
        done
    sleep 1
done

# 드롭 통계 확인
bpftool map dump id 10   # IP별 드롭 카운터
bpftool map dump id 12   # 글로벌 설정 및 통계

XDP offload + TC flower + flowtable 3계층 아키텍처

NGFW에서 최적의 DDoS 방어와 세션 오프로드를 달성하려면, XDP HW offload, TC flower eSwitch, nf_flowtable 세 가지 메커니즘을 계층적으로 조합해야 합니다. 각 계층은 서로 다른 유형의 트래픽을 담당하며, 상위 계층이 처리하지 못한 패킷만 하위 계층으로 전달됩니다.

3계층 아키텍처의 패킷 처리 흐름은 다음과 같습니다.

1. Layer 1 — XDP HW Offload (라인 레이트 필터): NIC가 패킷을 수신하면, ASIC에 로드된 XDP BPF 프로그램이 먼저 실행됩니다. IP 블랙리스트 매칭(LPM_TRIE)과 소스별 레이트 제한을 수행하여, DDoS 공격 트래픽을 CPU에 도달하기 전에 차단합니다. 이 단계에서 볼류메트릭 공격의 대부분(90%+)이 제거됩니다.
2. Layer 2 — TC flower eSwitch (세션 레벨 오프로드): XDP를 통과한 패킷은 eSwitch FDB(Forwarding Database)의 TC flower 규칙을 확인합니다. flowtable에 의해 설치된 HW 오프로드 규칙이 매칭되면, NIC 내부에서 NAT 변환과 MAC/VLAN 재작성을 수행하여 즉시 포워딩합니다.
3. Layer 3 — nf_flowtable (SW 고속 경로): HW 오프로드가 불가능한 세션(예: GRE 터널, 소프트웨어 브릿지)이지만 conntrack ESTABLISHED 상태인 경우, 커널의 flowtable 소프트웨어 경로에서 Netfilter 훅을 우회하여 고속 포워딩합니다.
4. Slow Path — 전체 검사: 위 세 계층 어디에도 해당하지 않는 패킷(새 세션, 미분류 트래픽)은 전체 Netfilter 훅 체인, conntrack, NFQUEUE DPI/IPS 검사를 거칩니다.

# === 3계층 구성 예시 ===

# --- Layer 1: XDP HW Offload (DDoS 사전 필터) ---
ip link set dev eth0 xdpoffload obj xdp_ddos_filter.o sec xdp

# --- Layer 2: TC flower + CT offload (세션 레벨) ---
# eSwitch 모드 활성화
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# CT offload 지원 TC flower 규칙 (nftables flowtable이 자동 생성)
# 수동 예시: 특정 서브넷 간 트래픽 HW 오프로드
tc filter add dev eth0 ingress protocol ip \
    flower ct_state +trk+est \
    ip_proto tcp \
    action ct zone 1 pipe \
    action mirred egress redirect dev eth1

# --- Layer 3: nf_flowtable (SW 고속 경로) ---
nft add table inet filter
nft add flowtable inet filter ft \
    '{ hook ingress priority 0; devices = { eth0, eth1 }; flags offload; }'
nft add chain inet filter forward \
    '{ type filter hook forward priority 0; }'
nft add rule inet filter forward \
    ct state established,related flow add @ft accept
nft add rule inet filter forward \
    ct state new accept

# flowtable offload 상태 확인
nft list flowtable inet filter ft
conntrack -L | grep OFFLOAD
# HW 오프로드 규칙 확인
tc filter show dev eth0 ingress | grep -A5 "ct_state"

위 다이어그램은 3계층 방어 아키텍처의 패킷 흐름을 보여줍니다. 패킷이 수신되면 Layer 1(XDP HW Offload)에서 볼류메트릭 DDoS를 라인 레이트로 차단하고, 통과한 패킷은 Layer 2(TC flower eSwitch)에서 확립된 세션을 하드웨어 포워딩하며, HW 오프로드가 불가능한 세션은 Layer 3(nf_flowtable)에서 소프트웨어 고속 경로로 처리합니다. 어느 계층에도 해당하지 않는 새 세션만 Slow Path의 전체 DPI/IPS 검사를 거칩니다. Slow Path에서 ESTABLISHED로 전환된 세션은 flowtable을 통해 Layer 2로 승격(오프로드)됩니다.

보안 vs 오프로드 트레이드오프

트레이드오프 모델

NGFW에서 가장 중요한 설계 결정은 어느 수준의 보안 검사를 활성화하고, 어느 지점에서 오프로드할 것인가입니다. 이 결정이 전체 시스템의 처리량을 결정합니다.

보안 기능을 추가할수록 오프로드 가능한 트래픽 비율이 줄어듭니다. 대략적인 모델:

• L4 ACL만 — 오프로드 비율 ~95%. 거의 모든 ESTABLISHED 세션이 Fast Path
• +IPS — 오프로드 비율 ~80%. 첫 패킷 IPS 검사 후 ALLOW된 세션만 오프로드
• +SSL Inspection — 오프로드 비율 ~40%. SSL 복호화가 필요한 세션은 CPU에서 처리
• +Full DPI + 주기적 재검사 — 오프로드 비율 ~20%. 지속적 모니터링이 필요한 세션

오프로드 비율 측정

# conntrack 전체 세션 수
conntrack -C

# flowtable 오프로드된 세션 수
conntrack -L -p tcp --state ESTABLISHED | wc -l

# flowtable 통계 (nftables)
nft list flowtable inet ngfw ft

# ethtool HW offload 카운터
ethtool -S eth0 | grep offload

# 오프로드 비율 계산
# ratio = (flowtable_sessions / total_established) * 100

위협 회피 대응

공격자가 오프로드 메커니즘을 악용하여 검사를 회피할 수 있는 시나리오와 대응:

주기적 샘플링 구현

오프로드된 세션에 대한 주기적 재검사(sampling)는 위협 회피를 방지하는 핵심 메커니즘입니다:

# nftables에서 바이트 기반 샘플링 구현
table inet ngfw_sampling {
    chain forward {
        type filter hook forward priority -50; policy accept;

        # 오프로드된 세션의 패킷이 N번째마다 CPU로 복귀
        # (flowtable timeout이 만료되면 자동으로 이 체인을 거침)

        # 10MB 이상 전송된 세션 → DPI 재검사
        ct state established \
            ct bytes gt 10485760 \
            ct mark != 0xfe \
            queue num 4 bypass  # 재검사용 별도 큐

        # 1시간 이상 지속된 세션 → 재분류
        ct state established \
            ct original packets gt 100000 \
            ct mark != 0xfe \
            queue num 4 bypass

        # 재검사 완료 마킹 (중복 방지)
        ct state established ct mark 0xfe accept
    }
}

정책 설계 가이드

Zone-based 오프로드 정책 매트릭스

네트워크 Zone 간 트래픽 특성에 따라 오프로드 수준을 차별화합니다:

nftables Zone 구현 예시

# Zone-based NGFW nftables 설정
table inet ngfw_zones {
    # Zone별 flowtable (오프로드 수준 차별화)
    flowtable ft_trust {
        hook ingress priority 0
        devices = { eth0 }    # 내부 네트워크
        flags offload          # HW offload 활성화
    }

    flowtable ft_untrust {
        hook ingress priority 0
        devices = { eth1 }    # 인터넷 연결
        # flags offload 미설정 → SW offload만
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid drop

        # Trust → Trust: 즉시 HW offload (DPI 건너뜀)
        iifname "eth0" oifname "eth0" \
            ct state established,related \
            flow add @ft_trust accept

        # Trust → Untrust: DPI 검사 후 SW offload
        iifname "eth0" oifname "eth1" \
            ct state established,related \
            flow add @ft_untrust accept

        # Untrust → DMZ: 반드시 DPI 검사
        iifname "eth1" oifname "eth2" \
            ct state new \
            queue num 0-3 fanout

        # Untrust → DMZ: DPI 완료 후에만 offload
        iifname "eth1" oifname "eth2" \
            ct state established ct mark 0xff \
            flow add @ft_untrust accept
    }
}

오프로드 비율 정량 모델

NGFW의 전체 처리량은 Fast Path와 Slow Path의 가중 합으로 모델링됩니다:

이 모델에서 Slow Path 처리량(DPI 성능)보다 오프로드 비율을 높이는 것이 전체 성능에 훨씬 큰 영향을 미칩니다. 오프로드 비율 1% 향상은 Slow Path 성능 20% 향상과 동등한 효과를 가집니다.

보안 수준별 성능 영향 시뮬레이션

• 오프로드 우선 정책: 내부 트래픽, 신뢰된 애플리케이션은 빠른 오프로드
• 보안 우선 정책: 인터넷 트래픽, 알 수 없는 프로토콜은 DPI 유지
• 하이브리드 접근: 세션 시작 시 DPI 검사 → 분류 완료 후 오프로드 → 주기적 샘플링

성능 튜닝과 벤치마크

RFC 9411 메트릭

NGFW 성능 측정에 사용되는 주요 메트릭 (RFC 9411 — Benchmarking Methodology for Network Security Device Performance):

• CPS (Connections Per Second) — 초당 새 TCP/UDP 연결 수립 수. Slow Path 성능의 핵심 지표
• CC (Concurrent Connections) — 동시 유지 가능한 세션 수. conntrack 테이블 + flowtable 크기
• Throughput — 총 데이터 처리량 (bps). Fast Path + Slow Path 합산
• Latency — 패킷 지연. Fast Path <10us, Slow Path >100us (DPI 포함)
• Offload Ratio — Fast Path로 처리되는 트래픽 비율

IRQ Affinity / NUMA 최적화

NGFW에서 CPU 코어 할당은 성능에 결정적입니다. NIC IRQ, Netfilter, DPI 엔진을 올바른 NUMA 노드와 코어에 배치해야 합니다:

# NUMA 토폴로지 확인
lscpu | grep -E "NUMA|Socket|Core"
# NUMA node0 CPU(s): 0-7    (NIC PCI 슬롯과 같은 노드)
# NUMA node1 CPU(s): 8-15

# NIC의 NUMA 노드 확인
cat /sys/class/net/eth0/device/numa_node
# 0  ← NIC이 NUMA 노드 0에 연결

# IRQ Affinity: NIC IRQ를 같은 NUMA 노드 코어에 바인딩
# eth0의 IRQ 번호 확인
grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':'
# IRQ 42, 43, 44, 45 (4개 큐)

# 각 IRQ를 NUMA node0 코어에 1:1 바인딩
echo 1 > /proc/irq/42/smp_affinity   # CPU 0
echo 2 > /proc/irq/43/smp_affinity   # CPU 1
echo 4 > /proc/irq/44/smp_affinity   # CPU 2
echo 8 > /proc/irq/45/smp_affinity   # CPU 3

# 또는: mlx5/ice 드라이버의 set_irq_affinity 스크립트
/usr/sbin/set_irq_affinity_cpulist.sh 0-3 eth0

NGFW 코어 배치 가이드

CPS/처리량/지연 최적화

# ===== 1. conntrack 최적화 =====
sysctl -w net.netfilter.nf_conntrack_max=2000000
sysctl -w net.netfilter.nf_conntrack_buckets=500000
# 해시 충돌 최소화: buckets ≥ max/4

# conntrack 타임아웃 단축 (빠른 리소스 회수)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=30

# ===== 2. flowtable 최적화 =====
sysctl -w net.netfilter.nf_flowtable_tcp_timeout=300
sysctl -w net.netfilter.nf_flowtable_udp_timeout=30

# ===== 3. NFQUEUE 최적화 =====
sysctl -w net.core.optmem_max=81920
# NFQUEUE 소켓 버퍼 증가 → 버스트 트래픽 대응
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# ===== 4. NIC RSS/ethtool 최적화 =====
# RSS 큐를 IRQ affinity 코어 수에 맞춤
ethtool -L eth0 combined 4

# Interrupt Coalescing (배치 처리로 IRQ 빈도 감소)
ethtool -C eth0 rx-usecs 50 rx-frames 64 \
  tx-usecs 50 tx-frames 64 adaptive-rx on

# Ring Buffer 크기 증가 (버스트 흡수)
ethtool -G eth0 rx 4096 tx 4096

# HW offload 기능 활성화
ethtool -K eth0 hw-tc-offload on
ethtool -K eth0 ntuple on

# ===== 5. XDP DDoS pre-filter =====
ip link set dev eth0 xdp obj xdp_ddos_filter.o sec xdp

# ===== 6. eSwitch 최적화 =====
devlink dev eswitch set pci/0000:03:00.0 mode switchdev
devlink dev eswitch set pci/0000:03:00.0 inline-mode transport

# ===== 7. 커널 파라미터 =====
sysctl -w net.core.netdev_budget=600
sysctl -w net.core.netdev_max_backlog=10000
sysctl -w net.ipv4.ip_forward=1

# NAPI busy_poll (지연 최소화)
sysctl -w net.core.busy_read=50
sysctl -w net.core.busy_poll=50

ethtool Interrupt Coalescing 상세

NGFW에서 Interrupt Coalescing은 처리량과 지연 사이의 균형을 결정합니다:

벤치마크 방법론 (RFC 9411)

NGFW 성능을 올바르게 측정하기 위한 RFC 9411 기반 방법론입니다:

# TRex를 사용한 NGFW 벤치마크 예시

# 1. CPS 측정 (TCP SYN flood → 세션 수립률 측정)
./t-rex-64 -f cap2/http_simple.yaml \
  --duration 60 --multiplier 100000 \
  --latency 1000

# 2. 처리량 측정 (기존 세션에 대량 트래픽)
./t-rex-64 -f cap2/imix_64_594_1518.yaml \
  --duration 120 --multiplier 1 \
  --astf  # Application-layer TRex

# 3. 결과에서 Fast Path / Slow Path 분리 확인
# TRex 실행 중 DUT에서:
conntrack -C                          # 전체 세션 수
conntrack -L --status OFFLOAD | wc -l # 오프로드 세션
ethtool -S eth0 | grep tx_packets_phy # HW 처리 패킷

패킷 크기별 성능 특성

NGFW 성능은 패킷 크기에 크게 의존합니다. 작은 패킷은 PPS(초당 패킷)에 의해, 큰 패킷은 BPS(초당 비트)에 의해 제한됩니다:

IMIX(Internet Mix)는 실제 인터넷 트래픽을 모사한 혼합 패킷 크기 분포입니다 (7:4:1 비율로 64B:594B:1518B). NGFW 벤치마크에서는 IMIX 또는 HTTP 애플리케이션 트래픽을 사용하는 것이 실제 환경에 가장 가깝습니다.

성능 최적화 체크리스트

진단과 모니터링

모니터링 아키텍처

NGFW의 각 구성 요소에서 메트릭을 수집하여 중앙 모니터링 시스템으로 전달하는 아키텍처입니다:

핵심 알림 규칙

flowtable 진단

# flowtable 오프로드 상태 확인
nft list flowtable inet ngfw ft

# conntrack 테이블에서 offloaded 세션 확인
conntrack -L --status OFFLOAD

# conntrack 이벤트 실시간 모니터
conntrack -E -e NEW,DESTROY

# TC flower 오프로드 규칙 통계
tc -s filter show dev eth0_rep0 ingress

# eSwitch FDB 규칙 확인
tc -s filter show dev eth0_rep0 ingress chain 0

# ethtool 오프로드 카운터
ethtool -S eth0 | grep -E '(offload|flower|ct)'

# devlink 트랩 (오프로드 실패 원인)
devlink trap show pci/0000:03:00.0

bpftrace / perf 진단

# flowtable offload 이벤트 추적
bpftrace -e 'kprobe:nf_flow_offload_add { printf("flow offload add: %s\n", comm); }'

# conntrack NEW 이벤트 빈도 측정 (CPS 추정)
bpftrace -e 'kprobe:__nf_conntrack_alloc { @cps = count(); }
             interval:s:1 { printf("CPS: %d\n", @cps); clear(@cps); }'

# NFQUEUE 지연 측정
perf probe -a 'nf_queue_entry_get_refs'
perf stat -e probe:nf_queue_entry_get_refs -a sleep 10

# Netfilter 훅 처리 시간 분포
bpftrace -e 'kprobe:nf_hook_slow { @start[tid] = nsecs; }
             kretprobe:nf_hook_slow /@start[tid]/ {
               @latency_us = hist((nsecs - @start[tid]) / 1000);
               delete(@start[tid]);
             }'

Prometheus 메트릭 수집

NGFW의 성능을 지속적으로 모니터링하기 위한 주요 메트릭과 수집 방법입니다:

#!/bin/bash
# /usr/local/bin/ngfw-metrics.sh
# node_exporter textfile collector용 메트릭 생성

METRICS_DIR="/var/lib/node_exporter/textfile_collector"

{
  # conntrack 메트릭
  ct_count=$(conntrack -C 2>/dev/null || echo 0)
  ct_max=$(sysctl -n net.netfilter.nf_conntrack_max)
  echo "ngfw_conntrack_entries $ct_count"
  echo "ngfw_conntrack_max $ct_max"
  echo "ngfw_conntrack_utilization $(echo "scale=4; $ct_count/$ct_max" | bc)"

  # flowtable 오프로드 세션 수
  offloaded=$(conntrack -L --status OFFLOAD 2>/dev/null | wc -l)
  echo "ngfw_flowtable_offloaded_sessions $offloaded"

  # 오프로드 비율
  established=$(conntrack -L -p tcp --state ESTABLISHED 2>/dev/null | wc -l)
  if [ "$established" -gt 0 ]; then
    ratio=$(echo "scale=4; $offloaded/$established" | bc)
    echo "ngfw_offload_ratio $ratio"
  fi

  # NIC HW offload 카운터 (mlx5)
  for stat in tx_packets_phy rx_packets_phy \
              rx_vport_rdma_unicast_packets \
              tx_vport_rdma_unicast_packets; do
    val=$(ethtool -S eth0 2>/dev/null | grep "$stat" | awk '{print $2}')
    [ -n "$val" ] && echo "ngfw_nic_${stat} $val"
  done

  # TC flower 규칙 수
  tc_rules=$(tc -s filter show dev eth0_rep0 ingress 2>/dev/null | grep -c "filter")
  echo "ngfw_tc_flower_rules $tc_rules"

  # NFQUEUE 드롭 (과부하 지표)
  nfq_drops=$(cat /proc/net/netfilter/nfnetlink_queue 2>/dev/null | \
    awk '{sum+=$5} END {print sum+0}')
  echo "ngfw_nfqueue_drops $nfq_drops"

} > "$METRICS_DIR/ngfw.prom.$$"
mv "$METRICS_DIR/ngfw.prom.$$" "$METRICS_DIR/ngfw.prom"

실시간 성능 대시보드 스크립트

#!/bin/bash
# /usr/local/bin/ngfw-dashboard.sh — 실시간 NGFW 상태
watch -n 1 '
echo "===== NGFW Status ====="
echo ""
echo "--- Conntrack ---"
printf "  Entries:    %s / %s\n" $(conntrack -C) $(sysctl -n net.netfilter.nf_conntrack_max)
printf "  Offloaded:  %s\n" $(conntrack -L --status OFFLOAD 2>/dev/null | wc -l)
echo ""
echo "--- Flowtable ---"
nft list flowtable inet ngfw ft 2>/dev/null | tail -5
echo ""
echo "--- TC flower (HW rules) ---"
tc -s filter show dev eth0_rep0 ingress 2>/dev/null | \
  grep -E "(filter|action|Sent)" | head -20
echo ""
echo "--- NIC Offload Stats ---"
ethtool -S eth0 2>/dev/null | grep -E "(offload|flower|ct)" | head -10
echo ""
echo "--- NFQUEUE ---"
cat /proc/net/netfilter/nfnetlink_queue 2>/dev/null
'

트러블슈팅 체크리스트

자주 발생하는 문제와 해결

디버깅용 커널 트레이싱

# flowtable 이벤트 전체 추적 (디버깅 시에만 사용)
# 주의: 프로덕션에서는 성능 영향 있음

# 1. ftrace로 flowtable 함수 추적
echo 'nf_flow_offload*' > /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/current_tracer
echo 1 > /sys/kernel/debug/tracing/tracing_on
cat /sys/kernel/debug/tracing/trace_pipe | head -100
echo 0 > /sys/kernel/debug/tracing/tracing_on

# 2. perf로 Netfilter 훅 프로파일링
perf top -g -e cycles:k --filter='nf_*'

# 3. bpftrace: flowtable HW offload 성공/실패 추적
bpftrace -e '
kprobe:nf_flow_offload_hw_add {
    printf("HW add: ct=%p\n", arg2);
}
kretprobe:nf_flow_offload_hw_add /retval != 0/ {
    printf("HW add FAILED: err=%d\n", retval);
}
kprobe:nf_flow_offload_hw_del {
    printf("HW del: flow=%p\n", arg1);
}'

# 4. conntrack 이벤트와 flowtable 이벤트 상관관계 추적
bpftrace -e '
kprobe:nf_conntrack_in {
    @ct_in = count();
}
kprobe:nf_flow_offload_ip_hook {
    @flow_hit = count();
}
interval:s:5 {
    printf("conntrack_in: %d, flow_hit: %d, ratio: ",
           @ct_in, @flow_hit);
    printf("%d%%\n",
           @flow_hit * 100 / (@ct_in + @flow_hit + 1));
    clear(@ct_in); clear(@flow_hit);
}'

커널 설정

커널 버전 요구사항

NGFW HW offload의 각 기능에 필요한 최소 커널 버전입니다:

필수 CONFIG_* 옵션

# Netfilter / conntrack
CONFIG_NF_CONNTRACK=y
CONFIG_NF_TABLES=y
CONFIG_NF_TABLES_INET=y
CONFIG_NFT_FLOW_OFFLOAD=y        # flowtable offload 지원
CONFIG_NF_FLOW_TABLE=y            # nf_flowtable 코어
CONFIG_NF_FLOW_TABLE_INET=y
CONFIG_NETFILTER_NETLINK_QUEUE=y  # NFQUEUE

# HW offload (eSwitch/TC)
CONFIG_NET_SWITCHDEV=y            # switchdev 프레임워크
CONFIG_NET_CLS_FLOWER=y           # TC flower classifier
CONFIG_NET_ACT_CT=y               # TC conntrack action
CONFIG_NET_ACT_MIRRED=y           # TC mirred (redirect)
CONFIG_NET_ACT_PEDIT=y            # TC packet edit
CONFIG_NET_ACT_TUNNEL_KEY=y       # TC tunnel encap/decap

# NIC 드라이버 (예: NVIDIA ConnectX)
CONFIG_MLX5_CORE=y
CONFIG_MLX5_ESWITCH=y
CONFIG_MLX5_TC_CT=y               # mlx5 CT offload

# XDP
CONFIG_XDP_SOCKETS=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_JIT=y

# IPSec HW offload
CONFIG_XFRM=y
CONFIG_XFRM_OFFLOAD=y
CONFIG_INET_ESP_OFFLOAD=y

# conntrack 헬퍼 (ALG 프로토콜)
CONFIG_NF_CONNTRACK_FTP=m       # FTP ALG
CONFIG_NF_CONNTRACK_SIP=m       # SIP ALG
CONFIG_NF_CONNTRACK_H323=m      # H.323 ALG
CONFIG_NF_CONNTRACK_TFTP=m      # TFTP ALG
CONFIG_NF_CONNTRACK_PPTP=m      # PPTP ALG
CONFIG_NF_CT_NETLINK=y          # conntrackd 통신

# NAT 관련
CONFIG_NF_NAT=y
CONFIG_NF_NAT_MASQUERADE=y
CONFIG_NFT_NAT=y
CONFIG_NFT_MASQ=y

# NFQUEUE 관련
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NFT_QUEUE=y              # nft queue 표현식

# Intel E810 드라이버 (대안 NIC)
CONFIG_ICE=y
CONFIG_ICE_SWITCHDEV=y          # ice eSwitch 지원

# QoS 관련
CONFIG_NET_SCH_HTB=y            # HTB qdisc
CONFIG_NET_SCH_FQ_CODEL=y       # fq_codel (AQM)
CONFIG_NET_SCH_MQPRIO=y         # HW QoS 큐 매핑
CONFIG_NET_SCH_INGRESS=y        # TC ingress qdisc

모듈 로딩 순서와 검증

NGFW 관련 커널 모듈(Kernel Module)은 의존성 순서대로 로드해야 합니다. 다음은 systemd 서비스 이전에 실행할 모듈 로딩 스크립트입니다:

#!/bin/bash
# /usr/local/sbin/ngfw-modules-load.sh
# NGFW 커널 모듈 로딩 (의존성 순서)

set -e

# 1단계: 기본 Netfilter 프레임워크
modprobe nf_conntrack
modprobe nf_tables
modprobe nft_chain_nat
modprobe nft_ct              # nft ct 표현식

# 2단계: flowtable 오프로드
modprobe nf_flow_table
modprobe nf_flow_table_inet
modprobe nft_flow_offload    # nft flow offload 표현식

# 3단계: NFQUEUE (DPI 엔진 연동)
modprobe nfnetlink_queue
modprobe nft_queue           # nft queue 표현식

# 4단계: TC offload 프레임워크
modprobe act_ct              # TC conntrack action
modprobe act_mirred          # TC redirect action
modprobe act_pedit           # TC packet edit
modprobe cls_flower          # TC flower classifier

# 5단계: conntrack 헬퍼 (필요한 ALG만 선택 로드)
# modprobe nf_conntrack_ftp
# modprobe nf_conntrack_sip

# 6단계: IPSec offload (필요시)
# modprobe esp4_offload
# modprobe esp6_offload

echo "NGFW modules loaded successfully"

모듈 로딩 후 다음 명령으로 검증합니다:

# 모듈 로딩 확인
lsmod | grep -E "nf_flow|nft_flow|nf_conntrack|cls_flower|act_ct"

# 기대 출력 예시:
# nft_flow_offload     20480  1
# nf_flow_table_inet   16384  1 nft_flow_offload
# nf_flow_table        36864  1 nf_flow_table_inet
# nf_conntrack        172032  5 nf_flow_table,nft_ct,...
# cls_flower           40960  0
# act_ct               20480  0

# dmesg에서 초기화 로그 확인
dmesg | grep -iE "flow.table|conntrack|switchdev"

# NIC eSwitch 상태 확인
devlink dev eswitch show pci/0000:03:00.0 2>/dev/null || echo "eSwitch not available"

# NIC hw-tc-offload 기능 확인
ethtool -k eth0 | grep hw-tc-offload

커널 부트 파라미터

# /etc/default/grub의 GRUB_CMDLINE_LINUX에 추가
# NGFW 최적화 커널 부트 파라미터

# IOMMU (SmartNIC SR-IOV/eSwitch 필수)
intel_iommu=on iommu=pt

# CPU 격리: 데이터 플레인 코어를 커널 스케줄러에서 분리
isolcpus=4-11                  # Suricata 전용 코어 격리
nohz_full=4-11                 # 격리 코어의 타이머 틱 제거
rcu_nocbs=4-11                 # RCU 콜백을 다른 코어에서 실행

# Hugepages (VPP/DPDK 사용 시)
default_hugepagesz=1G hugepagesz=1G hugepages=4

# NIC MMIO 매핑 최적화
pci=assign-busses              # PCI 버스 재할당

# 네트워크 스택 최적화
net.ifnames=0                  # 예측 가능한 인터페이스 이름 비활성화 (선택)

sysctl 튜닝 파라미터

운영 가이드

NGFW 초기 배포 절차

Linux 기반 NGFW를 처음부터 배포하는 단계별 가이드입니다:

일상 운영 명령 요약

# ===== 상태 확인 =====
# 전체 NGFW 상태 요약
echo "=== conntrack ===" && conntrack -C && \
echo "=== offloaded ===" && conntrack -L --status OFFLOAD 2>/dev/null | wc -l && \
echo "=== nft flowtable ===" && nft list flowtable inet ngfw ft 2>/dev/null && \
echo "=== suricata ===" && systemctl is-active suricata

# ===== 긴급 대응 =====
# DDoS 감지 시 XDP 긴급 필터 적용
ip link set dev eth0 xdp obj /usr/local/lib/xdp/emergency_block.o sec xdp

# conntrack 테이블 긴급 정리 (가득 참 상황)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=60
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=5
conntrack -F  # 전체 플러시 (주의: 모든 세션 끊김)

# 특정 IP 긴급 차단
nft add element inet ngfw blocklist { 203.0.113.50 }

# ===== 정책 변경 =====
# 규칙 변경 시 기존 오프로드 세션 재평가
nft flush flowtable inet ngfw ft  # flowtable 초기화
# 이후 패킷이 도착하면 자동으로 새 규칙에 따라 재등록

# nftables 규칙 리로드 (서비스 무중단)
systemctl reload ngfw-nftables

# ===== 유지보수 =====
# Suricata 시그니처 업데이트
suricata-update
systemctl reload suricata

# NIC 펌웨어 업데이트 (다운타임 필요)
mlxfwmanager --online-activate

장애 복구 시나리오

업그레이드/롤백(Rollback) 절차

NGFW 커널이나 NIC 펌웨어 업그레이드 시 무중단 또는 최소 중단을 위한 절차입니다:

# ===== 안전한 커널 업그레이드 절차 (HA 구성) =====

# 1단계: Standby 노드에서 먼저 업그레이드
conntrackd -n  # Standby 역할 확인

# 2단계: 새 커널 설치
dnf install kernel-6.6.x  # 또는 dpkg -i linux-image-6.6.x

# 3단계: Standby 재부팅 (Active가 트래픽 처리 중)
reboot

# 4단계: 재부팅 후 검증
uname -r                    # 새 커널 버전 확인
lsmod | grep nf_flow_table  # 모듈 로딩 확인
conntrackd -s               # HA 동기화 상태 확인
suricatasc -c uptime        # Suricata 정상 기동 확인

# 5단계: Failover → 이 노드를 Active로 승격
conntrackd -c commit        # 캐시된 세션 커밋
conntrackd -k               # Active 역할 요청

# 6단계: 구 Active 노드도 동일 절차로 업그레이드

로그 관리와 감사

NGFW는 보안 장비이므로 로그 관리가 법적 요구사항일 수 있습니다. 주요 로그 소스와 관리 방안입니다:

# /etc/rsyslog.d/ngfw.conf — NGFW 로그 분리 저장
# nftables LOG 타겟 로그
:msg, contains, "NGFW_" /var/log/ngfw/firewall.log
& stop

# conntrackd 로그
:programname, isequal, "conntrackd" /var/log/ngfw/conntrackd.log
& stop

# logrotate 설정
# /etc/logrotate.d/ngfw
# /var/log/ngfw/*.log {
#     daily
#     rotate 90
#     compress
#     delaycompress
#     missingok
#     notifempty
#     sharedscripts
#     postrotate
#         systemctl reload rsyslog
#     endscript
# }

용량 계획

NGFW 장비의 리소스 소요를 사전에 계획하기 위한 가이드입니다:

QUIC/TLS 1.3과 NGFW 오프로드

멀티 테넌트 NGFW 아키텍처

Hairpin/Loopback 오프로드와 East-West 트래픽 보안

eBPF 기반 차세대 NGFW

P4 프로그래머블 파이프라인 NGFW 오프로드

흔한 실수와 안티패턴

NGFW 오프로드를 구현할 때 자주 발생하는 실수와 안티패턴 10가지를 정리합니다. 각 실수에 대한 증상, 원인, 올바른 해결 방법을 포함합니다.

실수 1: flowtable에 flags offload 누락

# ❌ 잘못된 설정: flags offload 누락
nft add flowtable inet filter ft \
  { hook ingress priority 0; devices = { eth0, eth1 }; }
# → SW fast path만 동작, HW offload 없음

# ✅ 올바른 설정
nft add flowtable inet filter ft \
  { hook ingress priority 0; devices = { eth0, eth1 }; \
    flags offload; }

# 검증: HW offload 확인
conntrack -L --status OFFLOAD 2>/dev/null | wc -l
# 0이면 HW offload 동작하지 않음

# NIC 지원 여부 확인
ethtool -k eth0 | grep hw-tc-offload
# hw-tc-offload: on → HW offload 가능

실수 2: nf_conntrack_max 부족

# 현재 conntrack 사용량 확인
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# ❌ 기본값(65536)은 NGFW에 부족
# 증상: dmesg에 "nf_conntrack: table full, dropping packet" 출력
dmesg | grep "table full"

# ✅ 예상 동시 세션의 1.5배로 설정
# 예: 동시 세션 200K 예상 → 300K으로 설정
sysctl -w net.netfilter.nf_conntrack_max=300000

# 해시 테이블 크기도 함께 조정 (max / 4 권장)
# 부팅 시 모듈 파라미터로 설정 (런타임 변경 불가)
echo "options nf_conntrack hashsize=75000" > \
  /etc/modprobe.d/nf_conntrack.conf

# 메모리 계산: 300K × ~320 bytes = ~96 MB
# 영구 설정
echo "net.netfilter.nf_conntrack_max = 300000" >> /etc/sysctl.d/99-ngfw.conf

실수 3: NFQUEUE fail-open 미설정

# ❌ 잘못된 설정: bypass 없음
# Suricata가 죽으면 모든 트래픽이 DROP됨
nft add rule inet filter forward \
  ct state new queue num 0

# ✅ 올바른 설정: bypass 옵션으로 fail-open
nft add rule inet filter forward \
  ct state new queue num 0-3 fanout,bypass

# fanout: 여러 NFQUEUE에 분산 (Suricata 멀티스레드)
# bypass: NFQUEUE가 비어있으면 자동으로 ACCEPT

# 검증: Suricata 프로세스 상태 확인
ss -nlp | grep suricata
# Suricata가 NFQUEUE를 바인딩하고 있는지 확인

# Suricata 설정 (suricata.yaml)
# nfqueue:
#   mode: accept   ← fail-open (NFQUEUE 바인딩 해제 시 accept)
#   fail-open: yes

실수 4: flowtable timeout > conntrack timeout

# ❌ 위험: conntrack timeout이 먼저 만료되면
# conntrack 엔트리 삭제 → flowtable 엔트리 고아화
# → HW에 유령 규칙 잔존 → 보안 위험

# conntrack timeout 확인
sysctl net.netfilter.nf_conntrack_tcp_timeout_established
# 기본: 432000 (5일)

# ✅ flowtable timeout은 conntrack timeout보다 짧게
# flowtable 기본 timeout: 30초 (자동 갱신)
# 문제가 되는 경우: conntrack timeout을 짧게 줄인 경우
# 예: UDP conntrack timeout을 30초로 줄이면
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60
# flowtable aging은 이보다 짧은 주기로 동작해야 함

# HW flow 엔트리 상태 확인 (mlx5)
tc -s filter show dev eth0 ingress
# → 각 규칙의 packets/bytes 카운터 확인
# 카운터가 오래 정지된 규칙 = 유령 플로우 의심

실수 5: ALG 프로토콜 무조건 오프로드

# ❌ 잘못된 설정: 모든 EST 세션을 무조건 오프로드
nft add rule inet filter forward \
  ct state established flow add @ft

# ✅ 올바른 설정: ALG helper가 있는 세션은 제외
nft add rule inet filter forward \
  ct state established \
  ct helper "" \
  flow add @ft

# ct helper ""는 helper가 없는 세션만 매칭
# FTP, SIP, H.323 등 ALG 세션은 항상 Slow Path 유지

# 현재 ALG helper가 할당된 세션 확인
conntrack -L | grep helper
# 예: tcp  6 300 ESTABLISHED ... helper=ftp

실수 6: eSwitch switchdev 전환 시 VF 미재설정

# ❌ 잘못된 순서: VF가 바인딩된 상태에서 switchdev 전환
# 결과: 전환 실패 또는 VF가 legacy 모드에 잔류

# ✅ 올바른 순서
# 1. VF unbind (모든 VF)
for vf in /sys/bus/pci/devices/0000:04:00.0/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/unbind 2>/dev/null
done

# 2. switchdev 모드 전환
devlink dev eswitch set pci/0000:04:00.0 mode switchdev

# 3. VF rebind
for vf in /sys/bus/pci/devices/0000:04:00.0/virtfn*; do
    pci_addr=$(basename $(readlink $vf))
    echo $pci_addr > /sys/bus/pci/drivers/mlx5_core/bind 2>/dev/null
done

# 4. 검증
devlink dev eswitch show pci/0000:04:00.0
# mode switchdev inline-mode transport encap-mode basic

# VF representor 확인
ip link show | grep "enp4s0f0v"