한 장으로 비교: AH와 ESP, 전송모드와 터널모드
| 구분 | AH (RFC 4302) | ESP (RFC 4303) |
|---|---|---|
| 무결성·출처 인증 | 제공 | 제공 |
| 암호화(기밀성) | 제공하지 않음 | 제공(선택 사항, 암호화를 쓰지 않는 NULL 설정도 가능) |
| 재전송 방지 | 제공(수신 측이 SA별로 켬) | 제공 |
| 바깥 IP 헤더 보호 | 바뀌지 않는 필드는 검사 범위에 포함 | 포함하지 않음(ESP 헤더부터 보호) |
| 구현 의무(RFC 4301) | MAY(지원해도 됨) | MUST(반드시 지원) |
| 구분 | 전송모드 | 터널모드 |
|---|---|---|
| 보호 대상 | 상위 계층 프로토콜(데이터 부분) | 원본 IP 패킷 전체(내부 헤더 포함) |
| IP 헤더 | 원본 헤더를 그대로 사용 | 게이트웨이 주소를 가진 새 바깥 헤더가 추가됨 |
| 주로 쓰는 곳 | 호스트와 호스트 사이의 종단 간 보호 | 보안 게이트웨이를 낀 사이트 투 사이트·원격 접속 VPN |
RFC 4301은 AH와 ESP 모두 두 모드를 지원한다고 규정합니다. 즉 "ESP는 터널모드 전용" 같은 연결은 성립하지 않고, 보호 방식과 사용 모드는 서로 독립된 선택입니다.
연결이 만들어지는 순서: IKE 훑어보기
RFC 7296에 따르면 IKE는 먼저 IKE_SA_INIT에서 암호 알고리즘을 협상하고 난수(nonce)와 디피-헬만 값을 교환합니다. 이어지는 IKE_AUTH에서 서로의 신원을 확인하고 첫 번째 Child SA, 즉 실제 ESP 또는 AH 통신용 보안 연결을 만듭니다. 이후 키를 바꾸거나 연결을 추가할 때는 CREATE_CHILD_SA를 쓰고, 상대가 살아 있는지는 내용이 없는 INFORMATIONAL 메시지로 확인하는 경우가 흔합니다. 통신은 보통 UDP 500번 포트로 시작하며, NAT가 있으면 UDP 4500번 포트로 옮겨 가 NAT 통과를 지원합니다.
실제 사례와 가상 점검 시나리오
사례 1. 1024비트 디피-헬만 그룹 연구(2015)
2015년 ACM CCS 학회에서 아드리안, 그린, 핼더먼, 하이닝어 등 연구진이 발표한 논문 「Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice」(Best Paper 수상)는 서로 다른 서버들이 같은 소수를 디피-헬만에 재사용하는 현실을 짚었습니다. 연구진의 웹 페이지는 IPv4 주소 공간을 조사한 결과, 가장 흔한 1024비트 그룹이 깨진다면 IKEv1을 쓰는 IPsec VPN 서버의 약 66%가 영향을 받을 수 있다고 정리합니다. 또한 공개된 유출 문서에 나온 국가 기관의 VPN 공격이 이런 해독이 가능했다는 가정과 일치한다고 서술합니다. 이는 추정이며 실제 공격이 확인되었다는 뜻은 아닙니다. 여기서 배울 점은 IPsec 자체의 구조적 결함이 아니라 협상에 쓰이는 키 교환 설정(그룹 크기, 재사용)이 전체 보안을 좌우한다는 것입니다. 운영자는 장비가 허용하는 DH 그룹과 IKE 버전을 점검해야 합니다.
가상 예시. 지사와 본사를 잇는 터널모드 (실제 사건이 아님)
가상의 지사 PC(내부 주소 10.1.0.5)가 본사 서버(10.2.0.9)로 보내는 패킷이 있다고 해 봅시다. 지사 게이트웨이(공인 주소 198.51.100.1)는 이 패킷 전체를 ESP로 감싸고, 바깥에 본사 게이트웨이(203.0.113.1)를 목적지로 하는 새 IP 헤더를 붙여 인터넷에 내보냅니다. 중간 경로에서는 두 게이트웨이 주소만 보이고 10.x 내부 주소와 내용은 보이지 않습니다. 반대로 같은 두 PC가 게이트웨이 없이 직접 전송모드로 통신하면 두 PC의 실제 주소가 그대로 노출됩니다. 위 주소는 설명용 예시 값입니다.
직접 점검해 볼 체크리스트
- 양쪽 장비가 IKEv2를 쓰는지, 오래된 IKEv1 설정이 남아 있지 않은지 확인합니다.
- NAT 뒤에서 연결이 안 된다면 방화벽이 UDP 500·4500번을 허용하는지 먼저 봅니다.
- ESP를 쓰면서 암호화가 꺼진(NULL) 설정이 아닌지 확인합니다.
- 양쪽의 보호 대상 주소 범위(내부 대역)가 서로 일치하는지 대조합니다. 한쪽만 다르면 터널은 올라와도 통신이 되지 않는 경우가 흔합니다.
흔한 오해와 정정
- 오해: IPsec을 쓰면 무조건 암호화된다. 실제: AH는 암호화를 하지 않고, ESP도 암호화를 끄는 설정이 규격상 가능합니다(RFC 4303).
- 오해: 터널모드는 ESP에서만 쓴다. 실제: RFC 4301은 AH와 ESP가 모두 전송·터널 두 모드를 지원한다고 합니다.
- 오해: IPsec을 쓰면 내가 누구인지 완전히 숨겨진다. 실제: 터널모드에서도 바깥 헤더의 게이트웨이 주소와 통신 시점·양은 보입니다. ESP는 제한적인 트래픽 흐름 기밀성만 제공합니다.
한계와 더 알아볼 점
IPsec은 기기 사이의 구간을 보호할 뿐, 단말이 악성코드에 감염되었거나 계정이 탈취된 경우까지 막아 주지는 않습니다. 설정 항목이 많아 장비 제조사 사이의 상호 운용 문제가 생기기 쉽고, NAT와 방화벽을 지날 때 추가 조치(NAT-T)가 필요합니다. 어떤 VPN 프로토콜이 더 낫다는 단정은 용도와 환경에 따라 달라지므로 아래 비교 가이드를 함께 보시기 바랍니다.
자주 묻는 질문
AH는 요즘도 쓰이나요?
RFC 4301은 구현이 ESP를 반드시 지원하되 AH는 선택으로 둡니다. 암호화가 없어 도청을 막지 못하고, 실무에서는 ESP가 주로 쓰입니다. AH는 개념을 설명하거나 특수한 요구가 있을 때 언급되는 경우가 많습니다.
IPsec과 SSL/TLS VPN은 뭐가 다른가요?
IPsec은 IP 계층에서 동작해 모든 트래픽을 통째로 보호하는 반면, SSL/TLS 기반 VPN은 더 상위 계층에서 동작해 브라우저만으로 접속하거나 특정 애플리케이션 트래픽만 선택적으로 보호하기가 더 쉽습니다. 기업들은 필요에 따라 두 방식을 함께 쓰기도 합니다.
SA(보안 연결)가 정확히 무엇인가요?
RFC 4301은 SA를 해당 트래픽에 보안 서비스를 제공하는 단방향 "연결"로 정의합니다. 단방향이므로 양방향 통신에는 보통 방향별로 SA가 하나씩 필요하고, 어떤 알고리즘과 키를 쓸지가 SA마다 정해집니다.
IKEv1과 IKEv2 중 무엇을 써야 하나요?
RFC 7296은 IKEv2를 인터넷 표준으로 올리고 이전 문서(RFC 5996, 그보다 앞선 RFC 4306)를 대체합니다. 장비가 지원한다면 IKEv2를 쓰는 것이 일반적인 방향이지만, 실제 선택은 장비 지원 범위와 조직의 보안 정책에 따라 정하세요.
IPsec 터널이 올라왔는데 통신이 안 되는 이유는 뭔가요?
IKE 단계는 성공해도 양쪽이 보호 대상으로 합의한 주소 범위가 다르거나, 경로·방화벽 규칙이 빠져 있으면 통신이 되지 않습니다. 이런 경우가 흔하니 설정 대조를 먼저 해 보세요.