VPN과 터널링 (2) - IPsec의 구조 - soo:bak
작성일 :
IPsec은 어떻게 안전한 터널을 만드는가
Part 1에서 터널링의 기본 개념을 살펴보았습니다.
GRE는 단순하지만 암호화 기능이 없어 데이터가 그대로 노출됩니다.
IPsec(IP Security)은 IP 계층에서 보안을 제공하는 프레임워크로, RFC 4301~4309 등 여러 표준 문서에 정의되어 있습니다.
IPsec이 달성하고자 하는 보안 목표는 다음과 같습니다.
- 기밀성(Confidentiality): 데이터를 암호화하여 도청 방지
- 무결성(Integrity): 전송 중 데이터 변조 여부 탐지
- 인증(Authentication): 패킷 송신자의 신원 확인
- 재전송 방지(Anti-replay): 캡처된 패킷을 재사용하는 공격 차단
IPsec의 역사
1990년대 초, 인터넷이 상업적으로 확산되면서 보안 문제가 심각하게 대두되었습니다.
애초에 IP 프로토콜은 신뢰할 수 있는 연구 네트워크를 전제로 설계되었기 때문에 보안 기능이 전혀 없었습니다.
이러한 문제를 해결하기 위해 IETF는 1995년부터 IPsec 표준화 작업을 시작했습니다.
IPsec은 IPv6 사양에 필수 구성요소로 포함되었으며, IPv4 환경에서도 선택적으로 적용할 수 있습니다.
IPsec 관련 주요 RFC 문서:
- RFC 2401 (1998): 초기 IPsec 아키텍처 정의
- RFC 4301 (2005): 현재 사용되는 아키텍처로 개정
- RFC 7296 (2014): IKEv2 프로토콜 정의
IPsec의 구성 요소
IPsec은 단일 프로토콜이 아니라 여러 프로토콜과 알고리즘을 조합하여 사용하는 프레임워크입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
┌───────────────────────────────────────────────────────┐
│ IPsec 프레임워크 │
├───────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ IKE │ │ ESP │ │ AH │ │
│ │ (키 교환) │ │ (암호화+인증)│ │ (인증만) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 암호 알고리즘 │ │
│ │ AES, 3DES, SHA-256, SHA-1, DH, ECDH ... │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 데이터베이스 │ │
│ │ SAD (Security Association Database) │ │
│ │ SPD (Security Policy Database) │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────────────┘
IKE: 키 교환 프로토콜
IKE(Internet Key Exchange)는 IPsec 통신에 필요한 암호화 키를 안전하게 협상하는 프로토콜입니다.
UDP 포트 500을 사용하여 두 피어 간에 키 교환을 수행합니다.
IKEv1 vs IKEv2
IKE는 버전 1과 버전 2가 있으며, 설계 철학과 복잡도에서 큰 차이가 있습니다.
IKEv1 (RFC 2409):
- Phase 1(보안 채널 설정)과 Phase 2(실제 트래픽용 키 협상)로 나뉜 복잡한 구조
- Main Mode, Aggressive Mode, Quick Mode 등 상황별로 다른 모드 사용
- 완전한 연결 설정에 최대 9개의 메시지 교환 필요
- 다양한 옵션 조합으로 인해 상호운용성 문제가 자주 발생
IKEv2 (RFC 7296):
- 단일화된 교환 구조로 단순화
- 4개의 메시지만으로 초기 교환 완료 (IKE_SA_INIT 2개 + IKE_AUTH 2개)
- NAT 환경 자동 감지 및 NAT-T(NAT Traversal) 내장
- EAP(Extensible Authentication Protocol) 인증 지원으로 다양한 인증 방식 활용 가능
- Dead Peer Detection 내장으로 연결 상태 자동 관리
IKEv1의 복잡함과 상호운용성 문제를 해결하기 위해 IKEv2가 개발되었으며, 현재 신규 구축 시에는 IKEv2 사용이 권장됩니다.
IKEv2 초기 교환
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Initiator Responder
│ │
│ ──── IKE_SA_INIT Request ─────────► │
│ (DH 공개값, 제안 알고리즘) │
│ │
│ ◄──── IKE_SA_INIT Response ─────── │
│ (DH 공개값, 선택된 알고리즘) │
│ │
│ [이 시점에서 공유 비밀 계산] │
│ │
│ ──── IKE_AUTH Request ─────────────►│
│ (암호화됨: 신원, 인증 정보) │
│ │
│ ◄──── IKE_AUTH Response ────────── │
│ (암호화됨: 신원, 인증 정보) │
│ │
공유 비밀 계산
IKE는 네트워크 보안에서 설명한 Diffie-Hellman(DH) 알고리즘을 사용하여 공유 비밀을 생성합니다.
DH 키 교환 과정:
- 양쪽 피어가 각자 비밀 값을 생성 (a, b)
- 비밀 값에서 계산한 공개 값을 교환 (g^a, g^b)
- 상대방의 공개 값과 자신의 비밀 값으로 동일한 공유 비밀 계산 (g^ab)
- 공유 비밀에서 암호화 키, 인증 키 등 필요한 여러 키를 파생
SA: Security Association
SA(Security Association)는 두 피어 간에 합의된 보안 연결의 상태를 나타내는 개념입니다.
SA에는 다음과 같은 정보가 포함됩니다.
- 암호 알고리즘 (AES-256 등)
- 인증 알고리즘 (SHA-256 등)
- 암호화 키
- 인증 키
- 수명 (시간 또는 바이트)
- 모드 (Transport/Tunnel)
SA의 단방향 특성
SA는 단방향으로 정의됩니다.
따라서 양방향 통신을 위해서는 송신용과 수신용, 총 두 개의 SA가 필요합니다.
1
2
A ───────────────► B (SA 1: A→B 암호화)
A ◄─────────────── B (SA 2: B→A 암호화)
SPI (Security Parameter Index)
SPI는 SA를 고유하게 식별하는 32비트 값입니다.
수신자는 패킷에 포함된 SPI를 보고 어떤 SA(어떤 키와 알고리즘)를 사용하여 복호화할지 결정합니다.
1
2
3
4
5
6
7
ESP 패킷:
┌─────────┬────────────────────────────────┐
│ SPI │ 암호화된 데이터 │
│ (32비트)│ │
└─────────┴────────────────────────────────┘
수신자: SPI = 0x12345678 → SA 테이블에서 조회 → 해당 키로 복호화
SAD와 SPD
IPsec은 두 개의 핵심 데이터베이스를 사용하여 보안 정책과 연결 상태를 관리합니다.
SAD (Security Association Database)
현재 활성화된 모든 SA의 정보를 저장합니다.
1
2
3
4
5
6
7
SAD 예시:
┌───────────┬──────────────┬────────────┬─────────────┐
│ SPI │ 목적지 │ 알고리즘 │ 키 │
├───────────┼──────────────┼────────────┼─────────────┤
│0x12345678 │198.51.100.1 │AES-256-GCM │0xABCD... │
│0x87654321 │203.0.113.1 │AES-256-GCM │0x1234... │
└───────────┴──────────────┴────────────┴─────────────┘
SPD (Security Policy Database)
어떤 트래픽에 어떤 보안 처리를 적용할지 정책을 정의합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
SPD 예시:
┌───────────────────┬──────────────────┬──────────┐
│ 조건 │ 동작 │ SA │
├───────────────────┼──────────────────┼──────────┤
│10.1.0.0/16 → │ PROTECT │ SA#1 │
│10.2.0.0/16 │ (암호화 적용) │ │
├───────────────────┼──────────────────┼──────────┤
│* → *:443 │ BYPASS │ - │
│ │ (IPsec 무시) │ │
├───────────────────┼──────────────────┼──────────┤
│기타 모든 트래픽 │ DISCARD │ - │
│ │ (폐기) │ │
└───────────────────┴──────────────────┴──────────┘
ESP: 암호화와 인증
ESP(Encapsulating Security Payload)는 IPsec에서 실제 데이터 보호를 담당하는 핵심 프로토콜입니다.
IP 프로토콜 번호 50을 사용하며, 다음과 같은 보안 기능을 제공합니다.
- 데이터 암호화를 통한 기밀성 확보
- 메시지 인증 코드(MAC)를 통한 무결성 검증
- 시퀀스 번호를 통한 재전송 공격 방지
ESP 패킷 구조
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────────────────────────────────────────┐
│ ESP 헤더 (8바이트) │
├──────────────────────────────┬──────────────────────────────┤
│ SPI (32비트) │ Sequence Number (32비트) │
├──────────────────────────────┴──────────────────────────────┤
│ │
│ 암호화된 페이로드 │
│ (원본 IP 헤더 + 데이터) │
│ │
├─────────────────────────────────────────────────────────────┤
│ Padding │ Pad Length │ Next Header │
├─────────────────────────────────────────────────────────────┤
│ ICV (Integrity Check Value) │
│ (인증 태그, 예: 16바이트) │
└─────────────────────────────────────────────────────────────┘
◄─────────── 암호화 범위 ───────────►
◄──────────────────── 인증 범위 ────────────────────►
Sequence Number의 역할
32비트 시퀀스 번호는 재전송 공격(Replay Attack)을 방지하는 핵심 메커니즘입니다.
공격자가 네트워크에서 정상적인 패킷을 캡처한 뒤 나중에 다시 전송하면 어떻게 될까요?
수신자는 패킷의 시퀀스 번호를 확인하여, 이미 처리한 번호인 경우 해당 패킷을 폐기합니다.
이를 위해 Anti-replay Window 메커니즘을 사용합니다.
- 수신자는 예상되는 시퀀스 번호 범위(윈도우)를 유지
- 윈도우보다 오래된 시퀀스 번호를 가진 패킷은 즉시 폐기
- 윈도우 내에서 이미 수신한 시퀀스 번호의 패킷도 폐기
AH: 인증만
AH(Authentication Header)는 암호화 없이 무결성 검증과 송신자 인증만 제공하는 프로토콜입니다.
IP 프로토콜 번호 51을 사용합니다.
1
2
3
4
5
6
7
8
9
10
AH 헤더 구조:
┌──────────────────────────────────────────────────────────┐
│ Next Header │ Payload Len │ Reserved │
├──────────────────────────────────────────────────────────┤
│ SPI (32비트) │
├──────────────────────────────────────────────────────────┤
│ Sequence Number (32비트) │
├──────────────────────────────────────────────────────────┤
│ ICV (가변 길이) │
└──────────────────────────────────────────────────────────┘
AH가 거의 사용되지 않는 이유
현재 실무에서 AH는 거의 사용되지 않으며, 그 이유는 다음과 같습니다.
-
ESP가 인증 기능도 포함: ESP는 암호화뿐 아니라 무결성 검증과 인증도 제공하므로, AH의 기능을 완전히 대체할 수 있습니다. 따라서 별도로 AH를 사용할 필요가 없습니다.
-
NAT 환경과 호환되지 않음: AH는 IP 헤더 전체(출발지/목적지 주소 포함)를 인증 범위에 포함합니다. NAT 장비가 IP 주소를 변경하면 인증 값이 맞지 않아 패킷이 폐기됩니다. 오늘날 대부분의 네트워크가 NAT를 사용하므로 이는 치명적인 제약입니다.
-
기밀성 없이 인증만 필요한 경우가 드묾: 데이터 변조는 방지하되 내용은 평문으로 전송해도 되는 상황은 현실에서 거의 없습니다. 보안이 필요하다면 대부분 암호화도 함께 적용합니다.
이러한 이유로 현재 대부분의 IPsec 구현과 배포 환경에서는 ESP만 사용합니다.
Transport Mode vs Tunnel Mode
IPsec은 패킷을 처리하는 방식에 따라 두 가지 모드로 동작합니다.
Transport Mode
원본 IP 헤더는 그대로 유지하고, 페이로드(TCP/UDP 헤더와 데이터)만 암호화합니다.
1
2
3
4
5
6
7
8
9
10
원본:
┌────────────┬─────────────┬───────────┐
│ IP 헤더 │ TCP 헤더 │ 데이터 │
└────────────┴─────────────┴───────────┘
Transport Mode ESP:
┌────────────┬────────────┬─────────────────────┬─────┐
│ IP 헤더 │ ESP 헤더 │ TCP 헤더 + 데이터 │ ICV │
│ (원본) │ │ (암호화됨) │ │
└────────────┴────────────┴─────────────────────┴─────┘
주로 다음과 같은 상황에서 사용됩니다.
- 두 호스트 간 직접 암호화 통신
- 동일 네트워크 내에서 특정 트래픽만 암호화
- 원본 IP 주소 정보를 유지해야 하는 경우
Tunnel Mode
원본 패킷 전체(IP 헤더 포함)를 캡슐화하고, 터널 양 끝점의 IP 주소를 담은 새 IP 헤더를 추가합니다.
1
2
3
4
5
6
7
8
9
10
11
원본:
┌────────────┬─────────────┬───────────┐
│ IP 헤더 │ TCP 헤더 │ 데이터 │
│(사설 IP) │ │ │
└────────────┴─────────────┴───────────┘
Tunnel Mode ESP:
┌────────────┬────────────┬─────────────────────────────────┬─────┐
│새 IP 헤더 │ ESP 헤더 │ 원본 IP 헤더 + TCP 헤더 + 데이터 │ ICV │
│(공인 IP) │ │ (모두 암호화됨) │ │
└────────────┴────────────┴─────────────────────────────────┴─────┘
주로 다음과 같은 상황에서 사용됩니다.
- VPN 게이트웨이 간 연결 (Site-to-Site VPN)
- 원격 사용자의 사내 네트워크 접속 (Remote Access VPN)
- 원본 IP 주소를 외부에 노출하지 않아야 하는 경우
대부분의 VPN 환경에서는 Tunnel Mode를 사용합니다. 원본 패킷이 완전히 암호화되어 내부 네트워크 구조가 외부에 노출되지 않기 때문입니다.
NAT와 IPsec
IPsec은 원래 NAT 환경에서 정상적으로 동작하지 않았습니다.
문제 1: ESP에는 포트 번호가 없음
NAT(특히 NAPT/PAT)는 TCP/UDP 포트 번호로 내부 호스트를 구분합니다. 하지만 ESP는 IP 프로토콜 번호 50을 사용하는 별도의 프로토콜이며 포트 개념이 없습니다. 따라서 NAT 장비가 여러 내부 호스트의 IPsec 연결을 구분할 수 없습니다.
문제 2: 체크섬 검증 실패
TCP와 UDP의 체크섬 계산에는 IP 주소가 포함됩니다. NAT가 IP 주소를 변경하면 체크섬이 맞지 않게 되는데, ESP로 암호화된 상태에서는 NAT가 내부의 체크섬을 수정할 수 없어 패킷이 폐기됩니다.
NAT-Traversal (NAT-T)
이 문제를 해결하기 위해 NAT-T(NAT-Traversal)가 RFC 3948로 표준화되었습니다.
NAT-T의 핵심 아이디어는 ESP 패킷을 UDP로 한 번 더 캡슐화하는 것입니다.
1
2
3
4
5
ESP over UDP (NAT-T):
┌──────────────┬──────────────┬──────────────────────────────┐
│ IP 헤더 │ UDP 헤더 │ ESP 패킷 │
│ │ (포트 4500) │ │
└──────────────┴──────────────┴──────────────────────────────┘
UDP 포트 4500을 사용하면 NAT 장비가 일반적인 UDP 트래픽처럼 포트 번호로 연결을 구분할 수 있습니다.
IKEv2는 협상 과정에서 NAT 존재 여부를 자동으로 감지하고, 필요한 경우 NAT-T를 활성화합니다.
IPsec VPN 설정 예시
두 사이트 간 IPsec VPN을 설정할 때 일반적으로 지정하는 파라미터를 살펴보겠습니다.
Phase 1 (IKE SA):
- 인증 방법: PSK(Pre-Shared Key) 또는 인증서
- DH 그룹: Group 14 (2048비트 MODP)
- 암호화: AES-256
- 무결성: SHA-256
- 수명: 86400초 (24시간)
Phase 2 (IPsec SA):
- 프로토콜: ESP
- 암호화: AES-256-GCM
- PFS: DH Group 14
- 수명: 3600초 (1시간)
트래픽 선택기:
- 로컬: 10.1.0.0/16
- 원격: 10.2.0.0/16
IPsec의 장단점
장점
- 업계 표준: 모든 주요 네트워크 장비 벤더가 지원하여 이기종 환경에서도 상호운용 가능
- 강력한 보안: 오랜 기간 검증된 암호 알고리즘 사용으로 높은 신뢰성 확보
- 애플리케이션 투명성: IP 계층에서 동작하므로 상위 애플리케이션 수정 불필요
- 하드웨어 가속 지원: 전용 암호화 칩셋을 통해 높은 처리량 달성 가능
단점
- 설정 복잡성: 수많은 옵션과 파라미터로 인해 설정과 문제 해결이 어려움
- NAT 환경 제약: NAT 환경에서는 NAT-T 설정이 필수
- 방화벽 설정 필요: UDP 500, 4500 포트와 ESP(프로토콜 50)를 명시적으로 허용해야 함
- 모바일 환경 한계: 사용자 IP 주소가 변경되면 SA 재협상이 필요하여 연결이 끊김
정리: 복잡하지만 표준
IPsec은 IKE, ESP, SA, SPD, SAD 등 많은 개념을 포함하고 있어 학습 곡선이 가파릅니다.
그러나 업계 표준이라는 점에서 대체 불가능한 가치가 있습니다.
- 시스코, 주니퍼 등 모든 주요 네트워크 장비 벤더가 지원
- 기업 Site-to-Site VPN의 사실상 표준
- AWS, Azure 등 클라우드 VPN 연결의 기본 프로토콜
Part 3에서는 IPsec의 복잡함에서 벗어나 단순함을 추구하는 현대 VPN 기술들을 살펴봅니다.
관련 글