암호화 시대의 선택적 VPN 우회와 가시성 중심 보안 설계 fwmark 기반

fwmark + policy routing(newgate 테이블 → tun0) 방식을 “선택적 VPN 우회 + DNS 누수 방지 + 패킷/흐름(Flow) 기반 탐지·모니터링”까지 완전하게 운영 가능한 형태로 정리한 내용입니다.

목표 아키텍처 요약

우회(steering)

• 특정 트래픽(DNS, 특정 목적지/포트/프로세스 등)만 fwmark=0x1 부여
• ip rule로 fwmark=0x1 → table newgate → default dev tun0
• 나머지 트래픽은 기존 default(enp0s3) 유지

탐지·모니터링(visibility)

• (가장 권장) tun0에서 “inner packet(복호화된 실제 트래픽)”를 센서가 직접 캡처/분석
  • (보강) enp0s3에서 VPN “outer tunnel”도 관찰(가용성/장애/우회 탐지)
• 로그/메타데이터(Zeek/Suricata/eBPF/conntrack)를 중앙 분석 시스템(SIEM/NDR) 로 전송

완전성(coverage) 강화

• DNS(53/DoT/DoH) 누수 차단
• QUIC/HTTP3, SNI/JA3/JA4, TLS 가시성 한계 보완
• 우회 루프, VPN 서버로의 제어 트래픽 예외처리

선택적 VPN 우회(Policy Routing) “정석 구성”

newgate 테이블에 기본 경로를 tun0로

# newgate 테이블 이름이 등록돼 있다고 가정 (예: 100 newgate)
ip route flush table newgate
ip route add default dev tun0 table newgate

ip route ls table newgate
# 기대: default dev tun0 scope link

fwmark=0x1 트래픽을 newgate 테이블로

# 이미 있다면 생략
ip rule add pref 219 fwmark 0x1 lookup newgate

ip rule ls | grep -E 'fwmark|newgate'

포인트: fwmark 0x1 == fwmark 1 이지만, 운영은 0x 표기를 권장(비트/마스크 확장 때문)

“DNS 쿼리 등 특정 트래픽만” fwmark 찍기 (iptables / nftables)

iptables 예시 (가장 많이 씀)

(A) DNS(UDP/TCP 53)만 VPN 우회

iptables -t mangle -N VPN_MARK 2>/dev/null || true
iptables -t mangle -F VPN_MARK

# DNS 표시
iptables -t mangle -A VPN_MARK -p udp --dport 53 -j MARK --set-mark 0x1
iptables -t mangle -A VPN_MARK -p tcp --dport 53 -j MARK --set-mark 0x1

# OUTPUT에 적용(로컬 프로세스 DNS)
iptables -t mangle -A OUTPUT -j VPN_MARK

(B) “한 번 마크된 연결은 계속 마크 유지” (중요: 응답/연결 지속성)

DNS만은 짧지만, HTTP/TCP류를 확장할 때 필수입니다.

# 이미 마킹된 패킷의 connmark 복원
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

# 새로 마킹된 패킷은 connmark 저장
iptables -t mangle -A OUTPUT -m mark --mark 0x1 -j CONNMARK --save-mark

nftables 예시 (권장: 구조화/가독성/확장성 좋음)

nft add table inet mangle 2>/dev/null || true
nft 'add chain inet mangle output { type route hook output priority -150; policy accept; }' 2>/dev/null || true

# DNS만 마킹
nft add rule inet mangle output udp dport 53 meta mark set 0x1
nft add rule inet mangle output tcp dport 53 meta mark set 0x1

DNS “누수 방지”까지 완성하기 (53 + DoT + DoH + QUIC)

현업에서 “DNS만 VPN으로 보냈는데도 새는” 대표 케이스는

• 앱이 DoH(443) 를 씀
• 브라우저가 QUIC/HTTP3(UDP 443) 를 씀
• systemd-resolved/로컬 캐시가 다른 경로로 나감

300x250

최소 세트: 53(UDP/TCP) + DoT(853) + QUIC(UDP 443)

# iptables 예시
iptables -t mangle -A OUTPUT -p tcp --dport 853 -j MARK --set-mark 0x1
iptables -t mangle -A OUTPUT -p udp --dport 443 -j MARK --set-mark 0x1   # QUIC/HTTP3

DoH(HTTPS 443)까지 “정교하게” 잡는 방법

DoH는 그냥 tcp/443이라 “전부 VPN 우회”하면 범위가 너무 커집니다. 현실적인 선택지는 3가지입니다.

1. 조직 표준 DNS 리졸버만 허용(권장)
   • 클라이언트는 내부 DNS(예: 10.8.0.53 같은 VPN 내부 DNS)만 사용
   • 브라우저 DoH 비활성(정책/MDM/GPO)
2. 프록시(Explicit/Transparent)로 DNS/HTTP 통제
   • Squid/mitmproxy/상용 SWG 등
3. (고급) SNI/JA4/프로세스 기반 분류로 DoH 후보만 우회
   • 완전 정확도는 어려움(암호화의 본질적 한계)

“패킷 분석 모니터링 시스템”으로 완전 탐지/모니터링 하는 방법

여기서 핵심은 어디서 캡처하느냐입니다.

가장 권장: tun0에서 분석 (inner packet 가시성)

OpenVPN/WireGuard의 tun 인터페이스에서는 암호화되기 전/후의 ‘실제 IP 패킷(Inner)’을 볼 수 있습니다.

즉, VPN으로 우회된 트래픽을 가장 깨끗하게 분석할 수 있습니다.

장점

• 목적지 IP/포트/프로토콜이 그대로 보임
• DNS 질의/응답도 직접 분석 가능
• enp0s3는 VPN 서버로 가는 암호화된 UDP만 보이므로 탐지 품질이 떨어짐 → tun0가 정답

(A) Zeek로 tun0 분석 (메타데이터 강력)

zeek -i tun0
# 생성 로그: conn.log, dns.log, http.log, ssl.log(=tls), notice.log 등

(B) Suricata로 tun0 분석 (시그니처/IDS)

suricata -i tun0 --af-packet
# alert.json / eve.json 등을 SIEM으로 전송

(C) eBPF 기반 흐름/보안 관찰(호스트 가시성)

• 프로세스/소켓/연결/바인딩 등 “호스트 레벨”은 패킷보다 더 강력합니다.
• 예: Falco, Cilium Tetragon, tracee, bpftrace 등

중앙 분석 시스템으로 “보내는” 방식 3가지

방식 1) 센서를 “해당 호스트에 직접 설치” (권장)

• tun0에서 캡처 → 로컬에서 Zeek/Suricata/eBPF 처리 → 로그만 중앙 전송
• 트래픽 미러링 대역폭 부담이 적고, 운영이 쉽습니다.

전송 예시

• Filebeat/Vector/Fluent Bit → Elastic/Splunk/Chronicle 등
• Zeek logs → Kafka → SIEM

방식 2) 패킷을 복제(mirror)해서 원격 NDR로 전송

리눅스에서 “패킷 복제”는 가능하지만, CPU/대역폭/MTU/손실 이슈가 큽니다. 필요할 때만 선택하세요.

• iptables TEE (복제)
• tc mirred (미러)
• nft dup to (복제)

예: DNS 패킷만 원격 센서(10.0.2.50)로 복제 (iptables TEE)

iptables -t mangle -A OUTPUT -p udp --dport 53 -j TEE --gateway 10.0.2.50

이건 “우회”가 아니라 복사본을 보냄입니다.

방식 3) 흐름(Flow) 기반 (NetFlow/IPFIX/sFlow)

패킷 원본 대신 “누가/언제/어디로/얼마나”를 빠르게 수집

• 대규모 환경에 매우 유리
• 단, 페이로드 탐지는 제한

“완전 탐지”를 위해 반드시 알아야 하는 현실 제약 & 보완책

암호화 트래픽(TLS/QUIC)의 한계

• HTTPS는 페이로드가 안 보입니다.
• 그래서 탐지는 메타데이터 + 행위 기반이 중요합니다.

보완 포인트

• Zeek의 TLS 메타(서버 IP/포트, SNI, 인증서, JA3/JA4 계열 지문)
• DNS 로그(도메인 ↔ 접속 IP 상관분석)
• eBPF로 “어떤 프로세스가 어떤 연결을 만들었는지” 연결

QUIC(UDP 443) 대응

• QUIC은 일부 가시성이 더 떨어집니다.
• 정책적으로
  • QUIC 차단 후 TCP/443로 폴백 유도(조직 정책)
  • 또는 QUIC도 VPN 우회/센서 튜닝

운영 안정성(루프/장애/예외처리) 체크리스트

VPN 서버로 가는 트래픽은 절대 tun0로 보내면 안 됨

OpenVPN 서버 경로가 잘못 마킹되면 터널 자체가 깨집니다.

대응(iptables 예외)

iptables -t mangle -A OUTPUT -d $VPN_SERVER_IP -j RETURN
# (그 다음에 MARK 룰이 오도록 체인 순서 관리)

tun0 다운 시 fail-safe

• “VPN으로 보내야 하는 트래픽”이 평문으로 새면 안 된다면
  • newgate 테이블에 blackhole을 두거나
  • iptables로 해당 트래픽을 DROP

예

ip route replace blackhole default table newgate

rp_filter(역경로 필터) 이슈

정책 라우팅 쓰면 rp_filter가 충돌할 수 있습니다. (비대칭 경로)

sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.default.rp_filter=0

운영 정책에 따라 “loose(2)”를 쓰는 경우도 많습니다.

“실전 예시 시나리오” 2가지

시나리오 A) DNS(53/853) + QUIC(UDP443)만 VPN 우회 + tun0에서 탐지

1. newgate → tun0 기본경로
2. 53/853/udp443만 mark 0x1
3. Zeek/Suricata를 tun0에서 구동
4. 로그를 SIEM으로 전송
5. VPN 서버 IP 예외 처리 + fail-safe

효과

• DNS/브라우저 우회류가 VPN 정책 밖으로 새기 어려움
• tun0에서 분석하므로 탐지 품질 좋음

시나리오 B) “특정 프로세스(예: curl, apt, backup-agent)만” VPN 우회

• iptables -m owner --uid-owner 같은 방식으로 프로세스 기반 마킹
• 백업/점검 트래픽만 VPN으로 보내고 싶은 경우에 많이 씁니다.

예

iptables -t mangle -A OUTPUT -m owner --uid-owner backup -j MARK --set-mark 0x1
iptables -t mangle -A OUTPUT -m mark --mark 0x1 -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

환경에 맞춘 완성형 레시피

“완성형(영구 적용 + 예외처리 + 탐지 파이프라인)”으로 구체화하려면 아래 4개만 알면 됩니다.

• VPN 종류: OpenVPN인가요 WireGuard인가요? (tun0 이름상 OpenVPN 가능성 높음)
• DNS는 어디로 보내고 싶으신가요? (VPN 내부 DNS IP/리졸버 존재 여부)
• 중앙 분석 시스템: Zeek/Suricata/Elastic/Chronicle/Splunk 중 무엇을 쓰시나요?
• “특정 트래픽”의 정의
  • DNS만?
  • 특정 도메인/목적지?
  • 특정 프로세스/컨테이너?
  • 특정 포트/대역?

 

위 정보 없이도 큰 틀은 위와 같고, 실제 명령 세트는 이 4개에 따라 가장 깔끔한 정답이 달라집니다.