IPSec & xfrm

Linux xfrm/IPSec 스택을 심층 분석합니다. SPD/SAD와 selector·reqid·if_id·mark의 결합 방식, ESP/AH/IPCOMP 처리 경로, 터널/트랜스포트/BEET 모드, NAT-T와 route-based VPN, ACQUIRE/EXPIRE/NEWAE 이벤트, Crypto API 및 NIC 오프로드, strongSwan/Libreswan 운영 시 발생하는 MTU·재전송·정책 불일치 문제의 진단 포인트까지 실무 관점으로 정리합니다.

xfrm 프레임워크와 IPSec 심화

xfrm(transform)은 리눅스 커널의 IPSec 구현 프레임워크입니다. 패킷의 암호화, 인증, 압축, 캡슐화를 처리하며, SA(Security Association)와 SP(Security Policy) 데이터베이스로 관리됩니다.

xfrm 아키텍처

selector, policy, state의 결합 모델

xfrm을 가장 빠르게 이해하는 방법은 패킷의 selector가 SPD 정책을 고르고, 정책의 tmpl이 필요한 SA(xfrm_state)를 찾거나 생성하게 만든다고 보는 것입니다. 운영 중에 자주 보는 reqid, mark, if_id, output-mark는 모두 이 결합을 더 정밀하게 만드는 식별자입니다.

특히 reqid는 사람이 보기엔 사소한 숫자처럼 보이지만, IKE 데몬이 양방향 SA 쌍과 정책 템플릿을 안정적으로 묶는 데 핵심입니다. 반대로 mark, output-mark, if_id는 라우팅 도메인과 터널 인터페이스를 분리할 때 중요하며, 강한 정책 분리 없이 default route 하나로 xfrmi를 붙이면 IKE/ESP 루프를 만들기 쉽습니다.

IPSec 프로토콜 비교

터널 모드 vs 트랜스포트 모드

# 트랜스포트 모드: 호스트-to-호스트, 원본 IP 헤더 유지
# [IP Header][ESP Header][Payload (encrypted)][ESP Trailer][ESP Auth]
ip xfrm state add src 10.0.0.1 dst 10.0.0.2     proto esp spi 0x100 mode transport     enc "aes" 0x$(openssl rand -hex 16)     auth "hmac(sha256)" 0x$(openssl rand -hex 32)

# 터널 모드: 게이트웨이-to-게이트웨이, 원본 패킷 전체 캡슐화
# [New IP][ESP Header][Original IP][Payload (encrypted)][ESP Trailer][Auth]
ip xfrm state add src 203.0.113.1 dst 198.51.100.1     proto esp spi 0x200 mode tunnel     enc "aes" 0x$(openssl rand -hex 16)     auth "hmac(sha256)" 0x$(openssl rand -hex 32)

# Security Policy (어떤 트래픽에 IPSec 적용할지)
ip xfrm policy add src 192.168.1.0/24 dst 192.168.2.0/24 dir out     tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel

# 현재 SA/SP 확인
ip xfrm state list    # SA 목록 (키, SPI, 알고리즘)
ip xfrm policy list   # SP 목록 (셀렉터, 방향)
ip xfrm monitor       # 실시간 xfrm 이벤트 모니터링

BEET 모드 상세

BEET(Bound End-to-End Tunnel) 모드는 transport 모드와 tunnel 모드의 하이브리드입니다. 와이어 상에서는 터널 모드처럼 외부 IP 헤더를 추가하지만, 엔드포인트에서는 트랜스포트 모드처럼 동작하여 내부 주소와 외부 주소가 고정된 1:1 매핑을 갖습니다. HIP(Host Identity Protocol, RFC 5206)과 함께 사용되며, 일반 VPN 배포에서는 거의 사용되지 않습니다.

# BEET 모드 SA 설정 예시
# 내부 주소 10.0.0.1 ↔ 외부 주소 203.0.113.1 (1:1 매핑)
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0xBEE7 mode beet \
    sel src 10.0.0.1/32 dst 10.0.0.2/32 \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128

ip xfrm policy add src 10.0.0.1/32 dst 10.0.0.2/32 dir out \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode beet

커널 xfrm 내부 구조

/* net/xfrm/xfrm_state.c — Security Association */
struct xfrm_state {
    struct xfrm_id id;            /* (daddr, spi, proto) */
    struct xfrm_selector sel;     /* SA에 연결된 selector */
    struct xfrm_mark mark;       /* fwmark 기반 분리 */
    u32 if_id;                  /* xfrm interface 식별자 */
    struct xfrm_lifetime_cfg lft; /* soft/hard lifetime */

    struct {
        u32 reqid;             /* policy tmpl과의 결속 키 */
        u8 mode;              /* transport / tunnel / beet */
        u8 replay_window;
        xfrm_address_t saddr; /* 터널 외부 소스 주소 */
    } props;

    struct xfrm_algo_auth *aalg;  /* HMAC-SHA2 등 */
    struct xfrm_algo *ealg;       /* AES-CBC 등 */
    struct xfrm_algo *calg;       /* deflate 등 */
    struct xfrm_algo_aead *aead;  /* AES-GCM, ChaCha20-Poly1305 */
    struct xfrm_replay_state_esn *replay_esn;

    /* H/W offload state */
    struct xfrm_dev_offload xso;
};

/* net/ipv4/esp4.c — ESP 패킷 처리 */
/* esp_output(): 송신 패킷 암호화 */
/* esp_input():  수신 패킷 복호화 */

위 코드는 핵심 필드만 발췌한 축약본입니다. 실제 커널 구조체에는 lock/refcount, state cache, 보안 컨텍스트, offload 통계, garbage-collection 연결 정보까지 들어갑니다. 중요한 점은 state에도 selector, mark, if_id, reqid가 남아 있다는 것이고, 그래서 "정책만 맞고 상태는 다른 터널에 붙는" 오동작을 막을 수 있습니다.

권장 알고리즘 조합

IPSec/xfrm 주의사항

MTU / PMTUD와 단편화 상세

ESP 캡슐화는 패킷 크기를 증가시킵니다. 이 오버헤드를 고려하지 않으면 PMTUD(Path MTU Discovery) 블랙홀이 발생하여 대용량 전송이 실패하는 흔한 장애가 생깁니다. 오버헤드 크기는 알고리즘, 모드, NAT-T 여부에 따라 달라집니다.

# MTU 설정 방법들

# 1. xfrm interface MTU 직접 설정 (가장 권장)
ip link set dev xfrm0 mtu 1400

# 2. MSS clamping (TCP만, 가장 안정적인 PMTUD 우회)
iptables -t mangle -A FORWARD -o xfrm0 -p tcp \
    --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

# 3. PMTUD 동작 확인
ping -M do -s 1400 192.168.2.1  # DF bit 설정으로 단편화 금지
# "Frag needed" ICMP가 돌아와야 정상

# 4. PMTUD 블랙홀 테스트
tracepath 192.168.2.1  # PMTU 탐색 경로 표시

# 5. strongSwan에서 자동 MTU 처리
# swanctl.conf: connections.*.children.*.set_mark_out = 0x42
# → xfrm interface MTU가 자동으로 적용됨

# 6. 커널의 자동 단편화 동작
# 터널 모드에서 내부 패킷이 ESP 후 MTU를 초과하면:
# - DF=1: ICMP Frag Needed를 원본 발신자에게 전송
# - DF=0: ESP 전에 내부 패킷을 단편화한 후 각각 ESP 캡슐화
#         (비효율적: 각 fragment마다 ESP 오버헤드 추가)

IPSec 디버깅

# xfrm 통계 — 오류 원인 파악
ip -s xfrm state   # SA별 패킷/바이트 카운터
ip -s xfrm policy  # SP별 매칭 카운터
cat /proc/net/xfrm_stat
# XfrmInError: 복호화/인증 실패
# XfrmInNoStates: 매칭 SA 없음
# XfrmOutPolBlock: SP에 의해 차단
# XfrmOutBundleGenError: SA 번들 생성 실패

# 패킷 캡처 (ESP 헤더 확인)
tcpdump -i eth0 esp
tcpdump -i eth0 'ip proto 50'  # ESP
tcpdump -i eth0 'ip proto 51'  # AH

# IKE 데몬 로그 (strongSwan)
swanctl --log --level 2

xfrm_stat 카운터 완전 해설

/proc/net/xfrm_stat은 커널 xfrm 서브시스템의 MIB(Management Information Base) 카운터를 노출합니다. 이 카운터들은 IPSec 장애의 원인을 정확하게 분류하는 핵심 도구이며, 각 카운터의 의미를 혼동하면 엉뚱한 방향으로 디버깅하게 됩니다.

# xfrm_stat 전체 카운터 확인
cat /proc/net/xfrm_stat

# 특정 카운터만 모니터링 (watch로 변화 추적)
watch -d -n1 'cat /proc/net/xfrm_stat | grep -E "InNoStates|InSeqOutOfWindow|OutPolBlock"'

# Prometheus node_exporter로 수집 (textfile collector)
# /etc/node_exporter/textfile/xfrm.prom 생성 스크립트:
awk '{print "xfrm_stat_" tolower($1) " " $2}' /proc/net/xfrm_stat \
    > /etc/node_exporter/textfile/xfrm.prom

# 카운터 리셋 (네트워크 네임스페이스 재생성 외에는 불가)
# → 누적 카운터이므로 delta 방식으로 모니터링해야 함

실전 트러블슈팅 시나리오

IPSec 장애는 원인이 다양하고 증상이 모호한 경우가 많습니다. 아래는 실무에서 빈번하게 발생하는 문제와 체계적인 진단 경로를 정리한 것입니다.

# 체계적 IPSec 진단 워크플로

# Step 1: SA/SP 존재 여부 확인
ip xfrm state list   # SA가 있는가? SPI, 알고리즘, 수명 확인
ip xfrm policy list  # SP가 있는가? selector, direction, priority 확인

# Step 2: 카운터 확인 (어느 단계에서 실패하는가?)
ip -s xfrm state     # SA별 패킷/바이트 카운터
ip -s xfrm policy    # 정책 hit 카운터
cat /proc/net/xfrm_stat  # 전체 오류 카운터

# Step 3: 실시간 이벤트 관찰
ip xfrm monitor all  # ACQUIRE, EXPIRE, NEWSA 이벤트 스트림

# Step 4: 패킷 캡처 (ESP 패킷이 나가는가? 들어오는가?)
tcpdump -i eth0 -n 'esp or udp port 4500 or udp port 500' -c 20

# Step 5: IKE 데몬 로그 (협상 실패 원인)
journalctl -u strongswan --since "5 min ago" | tail -50

# Step 6: 라우팅 확인 (트래픽이 올바른 경로로 가는가?)
ip route get 192.168.2.1 mark 0x42  # xfrm mark까지 포함한 경로

# Step 7: Netfilter 간섭 확인
iptables -L -v -n | grep -E 'esp|ipsec|xfrm'
iptables -t mangle -L -v -n

ESP 패킷 형식 상세

ESP(Encapsulating Security Payload, IP 프로토콜 50)는 현대 IPSec의 핵심 프로토콜입니다. 트랜스포트 모드와 터널 모드에서 패킷 구조가 다르며, AEAD 알고리즘 사용 여부에 따라 내부 처리도 달라집니다.

/* ESP 헤더 (RFC 4303) — include/uapi/linux/ip.h */
struct ip_esp_hdr {
    __be32 spi;        /* Security Parameters Index — SA 식별 */
    __be32 seq_no;     /* 시퀀스 번호 (Anti-replay용, 단조 증가) */
    __u8   enc_data[]; /* 가변 길이: IV + 암호화된 페이로드 */
};

/* ESP Trailer (암호화 영역 끝에 위치) */
/*   [Padding (0~255 bytes)]     — 블록 정렬용 */
/*   [Pad Length (1 byte)]       — 패딩 바이트 수 */
/*   [Next Header (1 byte)]      — 원본 프로토콜 (TCP=6, UDP=17 등) */
/*   [ICV (8/12/16 bytes)]       — Integrity Check Value (MAC) */

/* ESN (Extended Sequence Number, RFC 4304) */
/* 32비트 시퀀스 번호는 10Gbps에서 ~7분 만에 소진 */
/* ESN은 64비트로 확장: 상위 32비트는 패킷에 미포함, ICV 계산에만 사용 */
struct xfrm_replay_state_esn {
    __u32 bmp_len;     /* 비트맵 길이 (워드 수) */
    __u32 oseq;        /* 송신 시퀀스 (하위 32비트) */
    __u32 seq;         /* 수신 시퀀스 (하위 32비트) */
    __u32 oseq_hi;     /* 송신 시퀀스 (상위 32비트) */
    __u32 seq_hi;      /* 수신 시퀀스 (상위 32비트) */
    __u32 replay_window; /* Anti-replay 윈도우 크기 */
    __u32 bmp[];       /* 수신 비트맵 (가변 길이) */
};

AH 패킷 형식과 한계

AH(Authentication Header, IP 프로토콜 51)는 패킷의 무결성과 인증을 제공하지만 암호화는 하지 않습니다. IP 헤더를 포함한 전체 패킷이 인증 범위에 포함되는 것이 ESP와의 핵심 차이점이며, 이것이 NAT 환경과 호환되지 않는 근본 원인입니다.

/* AH 헤더 (RFC 4302) — include/uapi/linux/ip_auth.h */
struct ip_auth_hdr {
    __u8   nexthdr;     /* 다음 헤더 (TCP=6, ESP=50 등) */
    __u8   hdrlen;      /* 헤더 길이 (32비트 워드 단위 - 2) */
    __be16 reserved;    /* 예약 (0) */
    __be32 spi;         /* Security Parameters Index */
    __be32 seq_no;      /* 시퀀스 번호 */
    __u8   auth_data[]; /* ICV — 가변 길이 (알고리즘에 따라) */
};

/* AH 인증 범위: IP 헤더 전체 + AH 헤더 + 페이로드 */
/* 단, 변경 가능(mutable) 필드는 0으로 치환 후 MAC 계산: */
/*   - TTL (hop마다 감소)          */
/*   - Header Checksum (TTL 변경 시 재계산) */
/*   - TOS/DSCP (라우터가 변경 가능) */
/*   - Flags (Fragment offset)     */

IPCOMP 프로토콜 상세

IPCOMP(IP Payload Compression, RFC 3173, IP 프로토콜 108)는 ESP/AH 암호화 전에 페이로드를 압축하여 대역폭을 절약하는 프로토콜입니다. 암호화된 데이터는 높은 엔트로피로 인해 압축이 불가능하므로, 반드시 IPCOMP → ESP 순서로 적용해야 합니다. 리눅스 커널에서는 SA 번들(bundle)로 IPCOMP와 ESP를 체이닝합니다.

/* IPCOMP 헤더 (RFC 3173) — include/uapi/linux/ip_comp.h */
struct ip_comp_hdr {
    __u8   nexthdr;    /* 원본 프로토콜 (TCP=6, UDP=17 등) */
    __u8   flags;      /* 예약 (0) */
    __be16 cpi;        /* Compression Parameter Index */
};

/* net/ipv4/ipcomp.c — IPCOMP 송신 처리 */
static int ipcomp_output(struct xfrm_state *x, struct sk_buff *skb)
{
    /* 1. 페이로드를 deflate로 압축 */
    /* 2. 압축 결과가 원본보다 작은지 확인 */
    if (compressed_len >= orig_len) {
        /* 압축 효과 없음 → IPCOMP 헤더 없이 원본 전달 */
        /* 수신 측은 ESP의 Next Header로 직접 판단 */
        return 0;
    }
    /* 3. IPCOMP 헤더 삽입 (nexthdr, cpi) */
    /* 4. 압축된 페이로드로 교체 → 다음 SA(ESP)에 전달 */
}

/* SA bundle에서 IPCOMP + ESP 체이닝 */
/* policy tmpl 예시:
 * tmpl[0]: proto=comp, mode=transport, reqid=1, level=use
 * tmpl[1]: proto=esp,  mode=tunnel,    reqid=1, level=required
 * → IPCOMP 적용 시도 → ESP 암호화 (필수)
 */

# IPCOMP + ESP 터널 설정 예시
# 1. IPCOMP SA (CPI 기반)
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto comp spi 0x1234 mode transport \
    comp deflate reqid 100

# 2. ESP SA (같은 reqid로 번들링)
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x5678 mode tunnel \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128 \
    reqid 100

# 3. 정책: IPCOMP(use) + ESP(required) 템플릿
ip xfrm policy add src 192.168.1.0/24 dst 192.168.2.0/24 dir out \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto comp mode transport \
         reqid 100 level use \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel \
         reqid 100 level required

IKE 프로토콜과 SA 협상

IKE(Internet Key Exchange)는 IPSec SA의 자동 협상 프로토콜입니다. 커널의 xfrm 프레임워크는 데이터 평면(패킷 암호화/복호화)만 처리하며, SA 생성/삭제/갱신의 제어 평면은 유저스페이스 IKE 데몬(strongSwan, Libreswan)이 Netlink를 통해 커널에 주입합니다.

Diffie-Hellman 그룹과 PFS: IKE_SA_INIT에서 DH 교환으로 공유 비밀 생성. PFS(Perfect Forward Secrecy)를 활성화하면 CREATE_CHILD_SA에서도 새로운 DH 교환을 수행하여, IKE SA 키가 노출되더라도 개별 CHILD SA(IPSec SA)의 트래픽 키는 보호됩니다. 주요 DH 그룹:

커널과 IKE 데몬 상호작용: IKE 데몬은 AF_NETLINK/NETLINK_XFRM 소켓을 통해 커널 xfrm 서브시스템과 통신합니다. 주요 Netlink 메시지:

/* include/uapi/linux/xfrm.h — 주요 XFRM Netlink 메시지 타입 */
/* SA (Security Association) 관리 */
XFRM_MSG_NEWSA      /* IKE → 커널: SA 생성 (키, 알고리즘, SPI, 모드) */
XFRM_MSG_DELSA      /* IKE → 커널: SA 삭제 */
XFRM_MSG_GETSA      /* IKE → 커널: SA 조회 */
XFRM_MSG_UPDSA      /* IKE → 커널: SA 갱신 (rekey) */

/* SP (Security Policy) 관리 */
XFRM_MSG_NEWPOLICY  /* IKE → 커널: 정책 생성 (셀렉터, 방향, 액션) */
XFRM_MSG_DELPOLICY  /* IKE → 커널: 정책 삭제 */

/* 커널 → IKE 이벤트 (비동기 알림) */
XFRM_MSG_ACQUIRE    /* 커널 → IKE: 매칭 SA 없음, 새 SA 생성 요청 */
XFRM_MSG_EXPIRE     /* 커널 → IKE: SA 수명 만료 (soft/hard) */
XFRM_MSG_MIGRATE    /* MOBIKE: SA를 새 주소로 마이그레이션 */
XFRM_MSG_MAPPING    /* NAT-T: NAT 매핑 변경 알림 */

/* 워크플로 예시:
 * 1. 패킷 도착 → xfrm_policy 매칭 → 해당 SA 없음
 * 2. 커널이 XFRM_MSG_ACQUIRE 전송 → IKE 데몬 수신
 * 3. IKE 데몬이 피어와 IKEv2 교환 수행
 * 4. IKE 데몬이 XFRM_MSG_NEWSA + XFRM_MSG_NEWPOLICY로 SA/SP 커널에 주입
 * 5. 대기 중이던 패킷 처리 재개
 */

SA 수명주기와 커널 이벤트

실제 운영에서는 "패킷이 왜 지금은 통과하고 1시간 뒤에는 안 통과하는가"가 중요합니다. 그 답은 대부분 SA 수명주기와 Netlink 이벤트에 있습니다. 커널은 패킷을 보다가 SA가 필요하면 ACQUIRE를 올리고, 수명이 다가오면 EXPIRE를 올리며, HA 동기화가 필요한 환경에서는 replay/lifetime 값을 NEWAE로 흘려보냅니다.

IPSec 고가용성 (HA) 상세

IPSec VPN 게이트웨이의 고가용성은 SA 상태 동기화가 핵심입니다. active 장비가 장애 시 standby가 동일한 SA(키, 시퀀스 번호, replay 윈도우)를 가지고 있어야 기존 터널이 재협상 없이 유지됩니다. 리눅스 커널의 NEWAE(Anti-replay Event) 메커니즘과 IKE 데몬의 HA 플러그인이 이를 지원합니다.

# HA 관련 sysctl 파라미터
# NEWAE 이벤트 발생 조건 (replay 시퀀스 임계값)
sysctl -w net.core.xfrm_aevent_rseqth=2    # 2패킷마다 이벤트
# NEWAE 이벤트 발생 조건 (시간 임계값)
sysctl -w net.core.xfrm_aevent_etime=1000  # 1초(1000ms)마다 이벤트

# NEWAE 이벤트 모니터링
ip xfrm monitor aevent  # anti-replay 이벤트만 관측

# SA 상태를 standby에 주입 (UPDSA)
# 실제로는 IKE 데몬의 HA 플러그인이 자동 처리
# strongSwan: ha 플러그인 (charon.plugins.ha)
# 설정 예:
# charon.plugins.ha.local = 10.0.0.1
# charon.plugins.ha.remote = 10.0.0.2
# charon.plugins.ha.segment_count = 2
# charon.plugins.ha.fifo_interface = yes

# Keepalived + IPSec HA 연동
# VRRP로 VIP failover → notify_master 스크립트에서 SA 활성화

xfrm과 네트워크 스택 통합

IPSec/xfrm 프레임워크는 Linux 네트워크 스택에 깊숙이 통합되어 있습니다. 다음 다이어그램은 전체 네트워크 플로우에서 xfrm이 어떻게 위치하고, Netfilter 훅 및 라우팅과 어떻게 상호작용하는지 보여줍니다.

IPSec과 GRO/GSO 통합

고성능 IPSec에서는 NIC의 GRO(Generic Receive Offload)와 GSO(Generic Segmentation Offload)가 ESP 처리와 어떻게 상호작용하는지가 중요합니다. 커널 4.18+에서는 ESP 전용 GRO/GSO 경로가 도입되어 대형 패킷을 세그먼트 단위로 분할하지 않고 한 번에 암복호화할 수 있습니다.

# ESP GRO/GSO 활성화 확인
ethtool -k eth0 | grep -i esp
# tx-esp-segmentation: on   → ESP GSO 활성
# rx-gro-hw: on             → HW GRO 활성
# esp-hw-offload: on        → ESP 오프로드 활성

# GSO 최대 크기 확인/조정
ip -d link show eth0 | grep gso_max
# gso_max_size 65536  gso_max_segs 65535

# ESP GRO 통계 확인
ethtool -S eth0 | grep -i esp
# rx_esp_input_pkts, tx_esp_output_pkts 등 (드라이버 의존)

# SW GRO/GSO만으로도 성능 향상 가능 (HW 지원 불필요)
ethtool -K eth0 gro on gso on tso on

xfrm 패킷 처리 경로 상세

xfrm의 패킷 처리는 Netfilter 훅과 밀접하게 통합되어 있습니다. 송신 경로에서는 라우팅 후 xfrm 정책 검색을 수행하고, 수신 경로에서는 ESP 복호화 후 정책 검증을 거칩니다.

/* net/xfrm/xfrm_output.c — 송신 경로 핵심 */
static int xfrm_output_one(struct sk_buff *skb, int err)
{
    struct xfrm_state *x = skb_dst(skb)->xfrm;
    /* 1. 시퀀스 번호 할당 (ESN 지원) */
    err = x->outer_mode.output(x, skb);    /* 터널: 외부 IP 헤더 추가 */
    err = x->type->output(x, skb);         /* ESP: esp_output() 호출 */
    /* 2. skb→dst를 외부 라우팅 엔트리로 교체 */
    /* 3. 중첩 SA가 있으면 다음 xfrm_state에 대해 반복 (bundle) */
}

/* net/ipv4/esp4.c — ESP 암호화 처리 */
static int esp_output(struct xfrm_state *x, struct sk_buff *skb)
{
    struct crypto_aead *aead = x->data;
    /* 1. ESP 헤더 (SPI + Seq#) 삽입 */
    /* 2. IV 생성 (AEAD: salt + seq_no) */
    /* 3. 패딩 추가 (블록 크기 정렬) */
    /* 4. aead_request 생성 → crypto_aead_encrypt() */
    /*    → 비동기 완료: esp_output_done() 콜백 */
    /* 5. ICV 첨부 */
}

/* net/xfrm/xfrm_input.c — 수신 경로 핵심 */
int xfrm_input(struct sk_buff *skb, int nexthdr,
              __be32 spi, int encap_type)
{
    /* 1. (daddr, spi, proto)로 SAD 해시 테이블 검색 */
    x = xfrm_state_lookup(net, &daddr, spi, nexthdr, family);
    /* 2. anti-replay 검사 */
    xfrm_replay_check(x, skb, seq);
    /* 3. ESP 복호화: x→type→input() → esp_input() */
    /* 4. anti-replay 윈도우 업데이트 */
    xfrm_replay_advance(x, seq);
    /* 5. 정책 검증: 복호화된 패킷이 SP와 일치하는지 확인 */
    /*    (수신 정책 없으면 드롭 — XfrmInNoPols) */
}

/* xfrm_state 해시 테이블 검색 — O(1) 평균 */
/* 키: (daddr, spi, proto) → 해시 버킷 → 체인 순회 */
/* 대규모 SA 환경에서도 검색 성능 보장 */

xfrm_policy 내부 구조

/* include/net/xfrm.h — Security Policy 핵심 구조체 */
struct xfrm_policy {
    struct hlist_node bydst;       /* dst 주소별 해시 체인 */
    struct hlist_node byidx;       /* 인덱스별 해시 체인 */

    struct xfrm_selector selector;  /* 트래픽 셀렉터 (아래 상세) */
    struct xfrm_lifetime_cfg lft;   /* 수명: 바이트/패킷/시간 */
    struct xfrm_lifetime_cur curlft; /* 현재 사용량 카운터 */

    u8 type;           /* XFRM_POLICY_TYPE_MAIN / SUB */
    u8 action;         /* XFRM_POLICY_ALLOW / BLOCK */
    u8 flags;          /* XFRM_POLICY_LOCALOK, ICMP 등 */
    u8 xfrm_nr;        /* tmpl 배열 크기 (최대 6) */
    u16 family;        /* AF_INET / AF_INET6 */
    u32 priority;      /* 정책 우선순위 (낮을수록 높음) */
    u32 if_id;         /* xfrm interface ID (4.19+) */

    struct xfrm_tmpl xfrm_vec[XFRM_MAX_DEPTH]; /* SA 템플릿 */
    /* tmpl: 요구하는 SA의 속성 (proto, mode, reqid, level) */
};

/* 트래픽 셀렉터 — 어떤 패킷에 정책을 적용할지 결정 */
struct xfrm_selector {
    xfrm_address_t daddr;    /* 목적지 주소 */
    xfrm_address_t saddr;    /* 소스 주소 */
    __be16 dport;             /* 목적지 포트 */
    __be16 dport_mask;        /* 포트 마스크 (0xFFFF = exact) */
    __be16 sport;             /* 소스 포트 */
    __be16 sport_mask;
    __u16 family;             /* AF_INET / AF_INET6 */
    __u8 prefixlen_d;         /* 목적지 서브넷 길이 */
    __u8 prefixlen_s;         /* 소스 서브넷 길이 */
    __u8 proto;               /* 프로토콜 (6=TCP, 17=UDP, 0=all) */
    int ifindex;              /* 인터페이스 바인딩 */
    __kernel_uid32_t user;   /* UID 기반 정책 (Android) */
};

SPD 검색 알고리즘: 정책 검색은 3개의 방향(in/out/fwd)별로 독립된 해시 테이블에서 수행됩니다. 패킷의 (src, dst, proto, sport, dport)를 셀렉터와 매칭하며, 여러 정책이 매칭되면 priority가 가장 낮은(= 우선순위 높은) 정책이 선택됩니다.

/* net/xfrm/xfrm_policy.c — SPD 검색 핵심 */
static struct xfrm_policy *
xfrm_policy_lookup_bytype(struct net *net, u8 type,
    const struct flowi *fl, u16 family, u8 dir)
{
    /* 1. (dst_addr, family) 기반 해시 버킷 선택 */
    /* 2. 버킷 내 정책 순회 → 셀렉터 매칭 검사 */
    /*    xfrm_selector_match(sel, fl, family) */
    /* 3. 매칭된 정책 중 priority 최소값 반환 */
    /* 4. action == BLOCK이면 패킷 드롭 (XfrmOutPolBlock) */
    /* 5. action == ALLOW이면 tmpl 배열로 SA 검색 */
}

/* 정책 방향 (dir) */
XFRM_POLICY_IN   0  /* 수신: 복호화 후 정책 검증 */
XFRM_POLICY_OUT  1  /* 송신: 패킷 나가기 전 정책 검색 */
XFRM_POLICY_FWD  2  /* 포워딩: 라우터 역할 시 터널 간 전달 */

PF_KEY vs NETLINK_XFRM API

커널 xfrm 서브시스템과 유저스페이스 IKE 데몬 간 통신에는 두 가지 API가 있습니다. PF_KEY(RFC 2367)는 BSD 유래의 레거시 인터페이스이고, NETLINK_XFRM은 리눅스 전용의 현대 인터페이스입니다. 현재 모든 주요 IKE 데몬은 NETLINK_XFRM을 기본으로 사용합니다.

/* NETLINK_XFRM 주요 메시지 속성 (NLA — Netlink Attribute) */
/* include/uapi/linux/xfrm.h */

/* SA 생성 시 포함되는 주요 속성 */
XFRMA_ALG_AEAD         /* AEAD 알고리즘 (AES-GCM) */
XFRMA_ALG_AUTH_TRUNC   /* 인증 알고리즘 + truncation 길이 */
XFRMA_ALG_CRYPT        /* 암호화 알고리즘 */
XFRMA_ENCAP            /* NAT-T 캡슐화 정보 */
XFRMA_REPLAY_ESN_VAL   /* ESN 상태/윈도우 */
XFRMA_OFFLOAD_DEV      /* H/W offload 대상 디바이스 */
XFRMA_IF_ID            /* xfrm interface 식별자 */
XFRMA_SET_MARK         /* SA에 적용할 fwmark */
XFRMA_SET_MARK_MASK    /* fwmark 마스크 */
XFRMA_SA_PCPU          /* per-CPU SA 분산 (6.7+) */

/* PF_KEY → NETLINK_XFRM 매핑 예시 */
/*   SADB_ADD       → XFRM_MSG_NEWSA     */
/*   SADB_DELETE     → XFRM_MSG_DELSA     */
/*   SADB_ACQUIRE    → XFRM_MSG_ACQUIRE   */
/*   SADB_X_SPDADD   → XFRM_MSG_NEWPOLICY */
/*   SADB_EXPIRE     → XFRM_MSG_EXPIRE    */

NAT Traversal (NAT-T) 상세

ESP는 IP 프로토콜 번호 50을 사용하므로, 포트 번호가 없어 일반 NAT가 처리할 수 없습니다. NAT-T(NAT Traversal, RFC 3948)는 ESP 패킷을 UDP 4500 포트로 캡슐화하여 NAT 장비를 통과할 수 있게 합니다.

UDP 4500 위에서는 세 가지가 공존합니다. IKE는 UDP 헤더 뒤에 4바이트 Non-ESP Marker(0x00000000)를 두고, NAT keepalive는 1바이트 0xFF만 보내며, UDP-encapsulated ESP는 곧바로 ESP Header의 0이 아닌 SPI가 시작됩니다.

/* NAT-T 감지: IKEv2 NAT_DETECTION_*_IP payload */
/* IKE_SA_INIT 교환에서 양쪽이 NAT 감지 해시 전송:
 *   HASH = SHA-1(SPIi | SPIr | IP | port)
 * 수신 측에서 자신의 IP/port로 재계산한 해시와 비교
 * → 불일치하면 경로 상에 NAT 존재 → NAT-T 활성화
 */

/* 커널 NAT-T 처리: net/ipv4/esp4.c + net/ipv4/udp.c */
/* 수신: UDP 4500 소켓에 ESP-in-UDP 핸들러 등록 */
static int esp4_rcv_cb(struct sk_buff *skb)
{
    /* 1. UDP 헤더 제거 */
    /* 2. SPI로 xfrm_state 검색 */
    /* 3. encap_type = UDP_ENCAP_ESPINUDP 설정 */
    /* 4. esp_input()으로 복호화 진행 */
}

/* 송신: xfrm_state에 encap 정보가 있으면 UDP 래핑 */
struct xfrm_encap_tmpl {
    __u16 encap_type;   /* UDP_ENCAP_ESPINUDP (2) */
    __be16 encap_sport; /* 로컬 UDP 포트 (4500) */
    __be16 encap_dport; /* 원격 UDP 포트 (4500) */
    xfrm_address_t encap_oa; /* 원본 주소 (NAT 이전) */
};

xfrm interface vs VTI

리눅스에서 route-based VPN을 구현하는 두 가지 방법이 있습니다: 레거시 VTI(Virtual Tunnel Interface)와 커널 4.19에서 도입된 xfrm interface입니다. xfrm interface는 VTI의 한계를 해결하고 현대 VPN 아키텍처에 필수적인 기능을 제공합니다.

# xfrm interface 생성 및 설정
# 1. xfrm interface 생성 (if_id=42로 SA와 바인딩)
ip link add xfrm0 type xfrm dev eth0 if_id 42
ip addr add 10.10.0.1/30 dev xfrm0
ip link set xfrm0 up

# 2. SA에 if_id 지정
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x1000 mode tunnel if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128

# 3. 정책에 if_id 지정
ip xfrm policy add dir out if_id 42 \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel

# 4. 라우팅: xfrm interface를 통해 터널 트래픽 라우팅
ip route add 192.168.2.0/24 dev xfrm0

# 멀티 터널 시나리오 (서로 다른 피어에 대해 별도 xfrm interface)
ip link add xfrm1 type xfrm dev eth0 if_id 43
ip link add xfrm2 type xfrm dev eth0 if_id 44
# → BGP/OSPF 동적 라우팅을 각 xfrm interface에서 실행 가능

# 네임스페이스 격리 (멀티 테넌트)
ip netns add tenant1
ip link set xfrm0 netns tenant1
ip netns exec tenant1 ip addr add 10.10.0.1/30 dev xfrm0
ip netns exec tenant1 ip link set xfrm0 up
# → tenant1 네임스페이스 내에서만 IPSec 터널 접근 가능

xfrm 네임스페이스와 네트워크 격리

리눅스 네트워크 네임스페이스(netns)는 xfrm SPD/SAD를 완전히 격리합니다. 각 네임스페이스는 독립된 정책/상태 테이블, 통계 카운터, sysctl 파라미터를 가지며, xfrm interface는 네임스페이스 간 이동이 가능하여 멀티 테넌트 VPN 아키텍처를 구현할 수 있습니다.

# 멀티 테넌트 VPN 네임스페이스 설정 예시

# 1. 테넌트 네임스페이스 생성
ip netns add tenant-a
ip netns add tenant-b

# 2. xfrm interface 생성 (호스트 netns)
ip link add xfrm-a type xfrm dev eth0 if_id 100
ip link add xfrm-b type xfrm dev eth0 if_id 200

# 3. xfrm interface를 테넌트 netns로 이동
ip link set xfrm-a netns tenant-a
ip link set xfrm-b netns tenant-b

# 4. 테넌트별 주소/라우팅 설정
ip netns exec tenant-a bash -c '
    ip addr add 10.10.1.1/30 dev xfrm-a
    ip link set xfrm-a up
    ip route add 192.168.100.0/24 dev xfrm-a
'
ip netns exec tenant-b bash -c '
    ip addr add 10.10.2.1/30 dev xfrm-b
    ip link set xfrm-b up
    ip route add 192.168.200.0/24 dev xfrm-b
'

# 5. SA/SP는 호스트 netns에서 설치 (if_id로 바인딩)
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x100 mode tunnel if_id 100 \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128

ip xfrm policy add dir out if_id 100 \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode tunnel

# 6. 네임스페이스 간 xfrm 이벤트 모니터링
ip xfrm monitor all-nsid  # 모든 netns의 xfrm 이벤트 통합 관측

# 7. 테넌트별 xfrm 통계 확인
ip netns exec tenant-a cat /proc/net/xfrm_stat

Anti-replay 메커니즘

Anti-replay는 공격자가 캡처한 ESP 패킷을 재전송하는 것을 방지합니다. 수신 측은 슬라이딩 윈도우 비트맵을 유지하여 이미 처리한 시퀀스 번호의 패킷을 거부합니다.

/* net/xfrm/xfrm_replay.c — anti-replay 검사 (ESN 모드) */
static int xfrm_replay_check_esn(struct xfrm_state *x,
    struct sk_buff *skb, __be32 net_seq)
{
    u32 seq = ntohl(net_seq);
    struct xfrm_replay_state_esn *replay_esn = x->replay_esn;
    u32 wsize = replay_esn->replay_window;
    u32 top = replay_esn->seq;         /* 최신 수신 시퀀스 */
    u32 bottom = top - wsize + 1;     /* 윈도우 왼쪽 경계 */

    /* Case 1: 윈도우 오른쪽 밖 → 새 패킷, 수락 */
    if (likely(seq > top))
        return 0;

    /* Case 2: 윈도우 왼쪽 밖 → 너무 오래된 패킷, 드롭 */
    if (seq < bottom)
        return -EINVAL;  /* XfrmInSeqOutOfWindow */

    /* Case 3: 윈도우 내 → 비트맵 검사 */
    u32 diff = top - seq;
    u32 pos = diff / 32;
    u32 bit = 1 << (diff % 32);
    if (replay_esn->bmp[pos] & bit)
        return -EINVAL;  /* XfrmInStateReplay — 중복 패킷 */

    return 0;  /* 윈도우 내 미수신 패킷, 수락 */
}

/* 윈도우 업데이트: 패킷 수락 후 비트맵 갱신 */
static void xfrm_replay_advance_esn(struct xfrm_state *x, __be32 net_seq)
{
    /* seq > top이면 윈도우 오른쪽으로 슬라이드 */
    /* 이동 과정에서 벗어난 비트들은 0으로 클리어 */
    /* 새 seq 위치의 비트를 1로 설정 */
}

RFC 4301은 서로 다른 QoS/재정렬 특성을 가진 트래픽을 같은 selector 하나로 몰아넣지 말라고 봅니다. 대역폭이 높고 RSS/ECMP 재정렬이 심한 환경이라면 윈도우만 키우는 것보다, 트래픽 클래스를 SA 단위로 나누는 쪽이 더 안정적일 수 있습니다.

IPSec 하드웨어 오프로드

소프트웨어 ESP 처리는 CPU 집약적이어서 10Gbps 이상 환경에서 병목이 됩니다. 리눅스 커널의 공식 XFRM device API는 두 가지 오프로드만 정의합니다: crypto offload와 packet offload입니다. 업계에서 말하는 "inline crypto", "full offload", "DPU offload"는 대개 이 둘, 특히 packet offload의 구현 형태를 가리키는 벤더 용어입니다.

/* include/net/xfrm.h — H/W 오프로드 구조체 */
struct xfrm_dev_offload {
    struct net_device *dev;     /* 오프로드 대상 NIC */
    struct net_device *real_dev; /* bond/vlan 하위 실제 디바이스 */
    unsigned long offload_handle; /* 드라이버 전용 핸들 */
    u8 dir : 2;               /* XFRM_DEV_OFFLOAD_IN / OUT */
    u8 type : 2;              /* CRYPTO / PACKET */
    u8 flags : 2;             /* XFRM_DEV_OFFLOAD_FLAG_ACE 등 */
};

/* NIC 드라이버가 구현하는 xdo_dev_* 콜백 */
struct xfrmdev_ops {
    int (*xdo_dev_state_add)(struct net_device *dev,
                             struct xfrm_state *x,
                             struct netlink_ext_ack *extack);
    void (*xdo_dev_state_delete)(struct net_device *dev,
                                        struct xfrm_state *x);
    void (*xdo_dev_state_free)(struct net_device *dev,
                                      struct xfrm_state *x);
    bool (*xdo_dev_offload_ok)(struct sk_buff *skb,
                              struct xfrm_state *x);
    /* packet offload는 정책 콜백도 필요 */
    int (*xdo_dev_policy_add)(struct xfrm_policy *p,
                              struct netlink_ext_ack *extack);
};

# Inline crypto offload 설정 (NVIDIA ConnectX-6 Dx 예시)
# 1. crypto offload: 암복호화만 HW
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x1000 mode tunnel \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128 \
    offload dev eth0 dir out

# 2. packet offload: state + policy를 HW와 동기화
ip xfrm state add src 203.0.113.1 dst 198.51.100.1 \
    proto esp spi 0x2000 mode transport \
    aead 'rfc4106(gcm(aes))' 0x$(openssl rand -hex 20) 128 \
    sel src 203.0.113.1/32 dst 198.51.100.1/32 proto tcp dport 443 \
    offload packet dev eth0 dir out

ip xfrm policy add src 203.0.113.1/32 dst 198.51.100.1/32 proto tcp dport 443 \
    dir out offload packet dev eth0 \
    tmpl src 203.0.113.1 dst 198.51.100.1 proto esp mode transport

# 3. 오프로드 상태 확인
ip xfrm state list
ip xfrm policy list
# → "offload packet dev eth0" 또는 "offload dev eth0" 표시

# Intel QAT crypto offload (AEAD)
# QAT 드라이버 로드 → openssl engine → strongSwan에서 QAT 플러그인 사용
modprobe qat_4xxx                    # Intel 4세대 QAT 디바이스
# strongSwan: charon.plugins.openssl.engine_id = qatengine

# 오프로드 실패 시 자동 소프트웨어 폴백
# ethtool -k eth0 | grep esp
# esp-hw-offload: on → 하드웨어 오프로드 활성화됨

strongSwan/Libreswan 실전 설정

IKE 데몬은 커널 xfrm과 협력하여 SA의 자동 생성/갱신/삭제를 처리합니다. 현대 리눅스 환경에서는 strongSwan(swanctl)과 Libreswan(ipsec.conf)이 주로 사용됩니다.

# /etc/swanctl/swanctl.conf — strongSwan site-to-site 설정
connections {
    site-to-site {
        version = 2                    # IKEv2 전용
        local_addrs = 203.0.113.1
        remote_addrs = 198.51.100.1

        local {
            auth = pubkey                # X.509 인증서 인증
            certs = server.pem
            id = vpn.example.com
        }
        remote {
            auth = pubkey
            id = vpn.peer.com
        }

        proposals = aes256gcm128-x25519-sha256  # IKE SA 암호 스위트
        dpd_delay = 30s                 # DPD 간격

        children {
            lan-to-lan {
                local_ts = 192.168.1.0/24   # 로컬 트래픽 셀렉터
                remote_ts = 192.168.2.0/24  # 원격 트래픽 셀렉터
                esp_proposals = aes256gcm128-x25519  # CHILD SA 암호 스위트
                rekey_time = 3600s          # 1시간마다 rekey
                replay_window = 2048       # Anti-replay 윈도우
                start_action = start        # 부팅 시 자동 연결
                dpd_action = restart        # DPD 실패 시 재연결
                # hw_offload = packet      # inline crypto 오프로드 (지원 NIC)
            }
        }
    }
}

# Road Warrior (모바일 클라이언트) 설정
connections {
    roadwarrior {
        version = 2
        local_addrs = %any              # 서버: 모든 주소에서 수신
        pools = pool-ipv4               # 클라이언트에게 IP 할당

        local {
            auth = pubkey
            certs = server.pem
        }
        remote {
            auth = eap-mschapv2         # EAP 인증 (사용자/비밀번호)
            eap_id = %any
        }

        children {
            rw-child {
                local_ts = 0.0.0.0/0    # 모든 트래픽 터널링
            }
        }
    }
}

pools {
    pool-ipv4 {
        addrs = 10.10.0.0/24
        dns = 8.8.8.8, 8.8.4.4
    }
}

IPSec 성능 튜닝

IPSec 성능은 암호 알고리즘, CPU 아키텍처, 패킷 크기, NIC 설정에 크게 의존합니다. 고성능 환경에서는 체계적인 벤치마크와 프로파일링이 필수적입니다.

# CPU affinity와 RPS/RFS 최적화
# ESP 처리를 특정 CPU에 고정하여 캐시 효율 극대화

# 1. NIC 인터럽트를 특정 CPU에 바인딩
# (CPU 0~3: 일반 트래픽, CPU 4~7: ESP 처리)
for i in /proc/irq/*/smp_affinity_list; do
    irq=$(echo $i | grep -oP '/proc/irq/\K[0-9]+')
    cat /proc/irq/$irq/actions | grep -q eth0 && echo "4-7" > $i
done

# 2. RPS (Receive Packet Steering) — 소프트웨어 수신 분산
echo f0 > /sys/class/net/eth0/queues/rx-0/rps_cpus   # CPU 4-7
echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt

# 3. xfrm 관련 sysctl 파라미터
sysctl -w net.core.xfrm_larval_drop=1    # SA 미완성 시 패킷 즉시 드롭 (대기 안 함)
sysctl -w net.core.xfrm_acq_expires=30   # ACQUIRE 타임아웃 (초)
sysctl -w net.core.xfrm_aevent_rseqth=2  # replay 이벤트 시퀀스 임계값
sysctl -w net.ipv4.xfrm4_gc_thresh=32768 # xfrm dst 가비지 컬렉션 임계값

# perf 프로파일링 — ESP 처리 핫스팟 식별
perf top -C 4-7 -g                        # ESP 처리 CPU에서 실시간 프로파일
perf record -C 4-7 -g -- sleep 10        # 10초 샘플링
perf report --sort=dso,sym                # 심볼별 CPU 사용량
# 주요 핫스팟: gcm_hash_crypt_*, aesni_ctr_enc, esp_output/input

# 암호 알고리즘 벤치마크 (커널 crypto API 테스트)
modprobe tcrypt sec=1 mode=211           # AES-GCM 벤치마크
dmesg | tail -50                          # 결과 확인

IPSec과 QoS / DSCP 처리

터널 모드에서는 원본 IP 헤더가 ESP 안으로 들어가므로, 외부 IP 헤더의 TOS/DSCP 필드를 어떻게 설정할지가 QoS 정책에 직접 영향을 줍니다. 리눅스 xfrm은 세 가지 모드를 지원합니다.

# DSCP 복사 확인 — 터널 모드 송신 패킷 캡처
tcpdump -i eth0 -v esp | grep -i tos
# TOS 0xb8 (DSCP EF) → 내부 DSCP가 외부에 복사됨

# 외부 DSCP를 고정값으로 변경 (트래픽 분석 방지)
iptables -t mangle -A POSTROUTING -o eth0 -p esp \
    -j DSCP --set-dscp 0

# ECN 전파 확인
sysctl net.ipv4.tunnel4.ecn    # 1이면 ECN 전파 활성

# tc로 ESP 트래픽 QoS 클래스 지정
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:10 htb rate 500mbit
tc filter add dev eth0 parent 1: protocol ip u32 \
    match ip protocol 50 0xff flowid 1:10  # ESP=proto 50

커널 빌드 옵션 (CONFIG_XFRM)

IPSec/xfrm 기능은 커널 빌드 시 여러 CONFIG 옵션으로 제어됩니다. 모듈로 빌드하면 필요할 때만 로드할 수 있지만, 고성능 환경에서는 built-in이 유리합니다.

# 현재 커널의 xfrm 관련 설정 확인
zgrep CONFIG_XFRM /proc/config.gz 2>/dev/null || \
    grep CONFIG_XFRM /boot/config-$(uname -r)

# 로드된 xfrm 모듈 확인
lsmod | grep -E 'xfrm|esp[46]|ah[46]|ipcomp|af_key'

# ESP 모듈 수동 로드
modprobe esp4
modprobe esp6

# Crypto 알고리즘 가용성 확인
cat /proc/crypto | grep -A4 'gcm(aes)'
# driver: generic vs aesni → 하드웨어 가속 여부 확인

주요 1차 자료

• RFC 4301 — SPD/SAD, selector, BYPASS/DISCARD/PROTECT 기본 의미
• RFC 4303 — ESP packet format, transport/tunnel mode, ICV 범위
• RFC 3948 — UDP encapsulation of ESP, NAT keepalive, UDP 4500
• RFC 4106 — AES-GCM-ESP의 IV/ICV 길이와 KEYMAT
• RFC 7296 — IKEv2, IKE_SA_INIT/IKE_AUTH/CREATE_CHILD_SA, NAT detection
• RFC 8221 — ESP/AH 알고리즘 요구사항 최신 정리
• Linux kernel xfrm_device.rst — 공식 offload API와 callback 설명
• Linux kernel xfrm_proc.rst — /proc/net/xfrm_stat 카운터 의미
• Linux kernel xfrm_sync.rst — NEWAE, replay/lifetime 동기화, HA 관점
• strongSwan Route-based VPN — xfrmi, if_id, install_routes_xfrmi, routing loop 회피
• Linux kernel ipsec.rst — IPComp corner case와 level use 관련 메모

관련 문서

• WireGuard — 현대적인 VPN 프로토콜
• 네트워크 보안 — Flooding 방어, Netlink, Unix Domain Socket
• Linux Crypto Framework (Crypto API) — 암호화 알고리즘 프레임워크
• Netfilter — 패킷 필터링 및 NAT