인터넷 프로토콜 보안

인증 헤더(AH)는 IPsec 프로토콜 스위트의 핵심 구성 요소 중 하나로, 데이터 무결성과 데이터 인증 서비스를 제공하지만 기밀성은 보장하지 않는다. 즉, AH는 패킷이 전송 중에 변조되지 않았음을 보장하고 패킷의 발신자를 확인하는 역할을 한다. 이를 통해 재전송 공격과 같은 위협을 방지할 수 있다.

AH는 IP 프로토콜 번호 51로 식별되며, 원본 IP 패킷에 특별한 헤더를 삽입하는 방식으로 동작한다. 이 헤더에는 시퀀스 번호 필드와 무결성 검사 값(ICV)이 포함된다. ICV는 메시지 인증 코드(MAC)를 생성하는 키 해시 메시지 인증 코드(HMAC) 알고리즘을 사용하여 계산된다. 일반적으로 SHA-1 또는 MD5 해시 함수가 사용되지만, 더 강력한 알고리즘으로 대체될 수 있다[1]. AH는 IP 헤더의 일부 필드(전송 중에 변경될 수 있는 TTL이나 체크섬 같은 필드는 제외)와 페이로드 전체에 대해 ICV를 계산한다.

AH의 주요 제한 사항은 네트워크 주소 변환(NAT) 환경과의 호환성 문제이다. NAT 장비는 패킷의 IP 주소와 포트를 변환하는데, 이는 AH가 보호하는 IP 헤더 필드를 변경하게 되어 ICV 검증이 실패하게 만든다. 또한 AH는 데이터 암호화를 수행하지 않기 때문에, 내용을 숨기려면 반드시 암호화 페이로드(ESP)와 함께 사용해야 한다. 이러한 이유로 현대의 많은 IPsec VPN 구현에서는 ESP를 우선적으로 사용하며, AH는 ESP와 결합하거나 특정 무결성만 요구하는 환경에서 제한적으로 활용된다.

암호화 페이로드(Encapsulating Security Payload, ESP)는 IPsec의 핵심 프로토콜 중 하나로, 기밀성, 데이터 무결성, 데이터 출처 인증, 그리고 재전송 공격 방지 서비스를 제공합니다. 인증 헤더(AH)가 무결성과 인증만을 담당하는 반면, ESP는 패킷 페이로드의 실제 데이터를 암호화하여 기밀성을 보장하는 것이 가장 큰 차이점입니다.

ESP는 패킷의 구조를 변경하여 동작합니다. ESP 헤더와 ESP 트레일러 사이에 원본 IP 패킷의 페이로드 데이터(전송 모드에서는 상위 계층 프로토콜 데이터, 터널 모드에서는 전체 원본 IP 패킷)를 캡슐화하고 암호화합니다. 일반적인 ESP 패킷의 구조는 다음과 같은 순서로 구성됩니다[2].

ESP는 두 가지 형태로 동작할 수 있습니다. 첫째, 암호화만을 사용하는 모드입니다. 둘째, 암호화와 인증을 모두 사용하는 모드(일반적으로 권장됨)입니다. 인증을 활성화하면 ESP 인증 데이터 필드가 추가되어, 암호화된 데이터와 ESP 헤더의 무결성과 인증을 보장합니다. 이를 통해 데이터가 변조되지 않았음을 확인하고 송신자를 검증할 수 있습니다. ESP는 전송 모드와 터널 모드 모두에서 사용되며, 선택된 모드에 따라 어떤 부분이 암호화되고 보호되는지가 결정됩니다.

보안 연관(Security Association, SA)은 IPsec 통신을 위해 필요한 보안 매개변수들의 집합을 정의하는 일방향 논리적 연결입니다. 양방향 통신을 위해서는 일반적으로 두 개의 SA(송신용과 수신용 각각)가 필요합니다. SA는 보안 매개변수 색인(SPI), 목적지 IP 주소, 사용할 보안 프로토콜(AH 또는 ESP)의 조합으로 고유하게 식별됩니다. 각 SA는 협상된 암호화 알고리즘, 인증 알고리즘, 암호화 키, 키 수명 등의 정보를 포함합니다.

SA의 수립, 유지, 삭제를 관리하는 핵심 프로토콜이 인터넷 키 교환(Internet Key Exchange, IKE)입니다. IKE는 통신 당사자 간에 인증을 수행하고, 안전한 채널을 설정하여 IPsec SA에 사용될 암호화 키와 보안 매개변수를 협상하는 역할을 담당합니다. IKE는 두 단계로 진행됩니다. 1단계에서는 통신 당사자 간의 상호 인증과 보안 채널(ISAKMP SA)을 수립합니다. 2단계에서는 이 보안 채널을 통해 실제 데이터를 보호하는 데 사용될 IPsec SA를 협상합니다.

IKE의 주요 버전에는 IKEv1과 IKEv2가 있습니다. IKEv2는 IKEv1의 복잡성과 메시지 교환 수를 줄여 효율성과 안정성을 개선한 버전으로, 현재 널리 사용됩니다[3]. IKE 프로토콜은 디피-헬만 키 교환(Diffie-Hellman Key Exchange)을 기반으로 하여 사전에 공유된 비밀 키 없이도 안전하게 세션 키를 생성할 수 있도록 합니다.

전송 모드는 IPsec이 IP 패킷의 페이로드(데이터 부분)만을 보호하는 동작 방식이다. 이 모드에서는 원본 IP 헤더가 그대로 유지되며, 인증 헤더(AH)나 암호화 페이로드(ESP) 헤더가 IP 헤더와 상위 계층 프로토콜(예: TCP, UDP) 데이터 사이에 삽입된다. 결과적으로 생성된 패킷은 새로운 IP 헤더로 캡슐화되지 않기 때문에, 최종 목적지 IP 주소가 변경되지 않는다.

이 모드는 주로 종단 간(end-to-end) 통신 보호에 사용된다. 예를 들어, 한 호스트에서 다른 호스트로의 직접적인 보안 통신이 필요할 때 적합하다. 전송 모드를 사용하면 중간 라우터나 게이트웨이는 패킷의 IP 헤더를 확인하여 라우팅할 수 있지만, 페이로드 내용은 보호받는다. 이는 인터넷 프로토콜 스위트의 상위 계층 프로토콜에 대한 보안 서비스를 제공하는 데 초점을 맞춘다.

전송 모드에서 AH와 ESP의 적용 범위는 다음과 같이 차이가 있다.

전송 모드는 터널 모드에 비해 오버헤드가 적다는 장점이 있다. 새로운 IP 헤더를 추가하지 않기 때문에 패킷 크기가 상대적으로 작아지며, 이는 네트워크 성능에 유리하게 작용할 수 있다. 그러나 원본 IP 헤더가 노출되기 때문에, 트래픽 분석에 취약할 수 있으며, 네트워크 주소 변환(NAT) 환경과의 호환성 문제가 발생할 수 있다는 한계도 존재한다.

터널 모드는 IPsec이 전체 원본 IP 패킷을 암호화하고 인증하여 새로운 IP 헤더로 감싸는 동작 방식이다. 이 모드는 주로 네트워크 장비 간의 통신을 보호하거나 가상 사설망을 구축할 때 사용된다. 터널 모드에서는 원본 패킷의 출발지와 목적지 IP 주소가 내부에 숨겨지고, 외부에는 보안 게이트웨이(예: 라우터, 방화벽, 전용 VPN 장비)의 IP 주소가 새 헤더로 표시된다.

터널 모드의 주요 적용 사례는 사이트 간 VPN 구축이다. 예를 들어, 본사와 지사 네트워크를 연결할 때, 양쪽의 IPsec 게이트웨이가 중간 공용 네트워크를 통해 터널을 형성한다. 지사 사용자의 패킷이 본사 서버로 전송될 때, 지사 게이트웨이는 패킷 전체를 암호화 페이로드로 처리하여 캡슐화하고, 본사 게이트웨이 주소를 목적지로 하는 새 IP 헤더를 추가한다. 본사 게이트웨이는 패킷을 수신하여 복호화 및 인증한 후, 원본 패킷을 내부 네트워크로 전달한다.

이 모드의 구조적 특징은 다음과 같다.

터널 모드는 종단 시스템(호스트)이 IPsec을 지원하지 않아도 네트워크 간 통신을 보호할 수 있게 하는 장점이 있다. 또한 내부 네트워크의 실제 주소 체계를 외부에 노출시키지 않아 추가적인 네트워크 주소 변환 효과와 프라이버시 보호를 제공한다. 그러나 전송 모드에 비해 패킷 크기가 증가하여 오버헤드가 더 크고, 주로 게이트웨이 간 구성에 사용된다는 차별점이 있다.

IKE는 IPsec 통신을 위해 필요한 암호화 키를 안전하게 생성하고 교환하는 프로토콜이다. 이 프로토콜은 통신 당사자들이 사전에 공유 비밀 키를 갖고 있지 않더라도, 공개 네트워크를 통해 안전하게 보안 연관을 설정할 수 있게 해준다. IKE는 디피-헬만 키 교환과 같은 방법을 사용하여 양측이 공유할 대칭 키를 협상하며, 이 과정에서 상대방의 신원을 인증한다. IKE의 주요 목적은 IPsec 보안 연관을 위한 매개변수, 즉 사용할 암호화 알고리즘, 인증 알고리즘, 그리고 세션 키를 합의하고 관리하는 것이다.

IKE 프로토콜은 두 단계(Phase)로 구성된 협상 과정을 거친다. 1단계에서는 통신 당사자 간에 안전한 인증된 채널(IKE SA)을 수립한다. 이 채널은 그 후의 협상을 보호하는 데 사용된다. 2단계에서는 앞서 수립된 보안 채널을 통해 실제 IPsec 통신에 사용될 매개변수(IPsec SA)를 협상한다. 이 두 단계 구조는 여러 개의 IPsec SA를 설정해야 할 때 효율적이다. 1단계 채널을 한 번 설정하면, 그 안에서 여러 번의 2단계 협상을 빠르게 수행할 수 있기 때문이다.

IKE의 주요 버전에는 IKEv1과 IKEv2가 있다. IKEv1은 복잡하고 메시지 교환 방식이 여러 가지여서 구현과 문제 해결이 어려운 점이 있었다. 이를 개선한 IKEv2는 프로토콜을 단순화하고, 메시지 교환 횟수를 줄여 연결 설정 속도를 높였으며, NAT 트래버설과 MOBIKE(Mobile IKE) 같은 현대적인 요구사항을 더 잘 지원한다. 결과적으로 IKEv2는 현재 더 널리 권장되고 채택되는 표준이다.

IPsec 통신을 시작하기 전에, 통신 당사자들은 어떤 트래픽을 보호할지, 어떻게 보호할지에 대한 규칙을 정해야 한다. 이 규칙을 정의하고 설정하는 과정이 보안 정책과 협상이다.

보안 정책은 보안 정책 데이터베이스(SPD)에 저장된다. SPD는 모든 입출력 IP 패킷을 처리할 때 참조되는 규칙 집합이다. 각 정책 엔트리는 선택자(Selector)와 동작(Action)으로 구성된다. 선택자는 패킷을 식별하는 기준(예: 출발지/목적지 IP 주소, 프로토콜, 포트 번호)이며, 동작은 해당 패킷에 대해 취할 조치를 정의한다. 주요 동작에는 BYPASS(보호 없이 통과), DISCARD(폐기), PROTECT(IPsec 적용)가 있다. PROTECT 동작이 지정되면, 해당 트래픽에 적용할 구체적인 보안 매개변수(예: 사용할 암호화 알고리즘, 인증 알고리즘)를 찾기 위해 보안 연관(SA)을 참조한다.

이러한 보안 매개변수는 인터넷 키 교환(IKE) 프로토콜을 통해 협상되어 보안 연관 데이터베이스(SAD)에 저장된다. IKE 협상은 두 단계로 이루어진다. 1단계에서는 통신 당사자 간의 상호 인증과 안전한 채널(ISAKMP SA)을 수립한다. 2단계에서는 이 안전한 채널을 통해 실제 데이터를 보호하는 데 사용할 구체적인 매개변수(IPsec SA)를 협상한다. 협상 내용은 다음과 같은 요소를 포함한다.

협상이 성공적으로 완료되면 생성된 SA의 매개변수(SPI, 목적지 주소, 보안 프로토콜)와 선택자 정보는 SPD 엔트리와 연결된다. 이후 외부로 나가는 패킷은 SPD를 검사하여 PROTECT 동작이면 연결된 SA를 찾아 캡슐화하고, 들어오는 패킷은 헤더의 SPI 값을 통해 SAD에서 해당 SA를 찾아 역캡슐화 및 검증을 수행한다. 이 전체 과정을 통해 응용 프로그램의 변경 없이도 네트워크 계층에서 일관된 보안 서비스를 제공할 수 있다.

기밀성은 인터넷 프로토콜 보안이 제공하는 핵심 보안 서비스 중 하나로, 전송 중인 데이터의 내용이 권한 없는 제3자에게 노출되는 것을 방지하는 것을 목표로 한다. 이는 암호화 페이로드 프로토콜을 통해 구현된다. ESP는 대칭키 암호 알고리즘을 사용하여 IP 패킷의 페이로드(전송 모드) 또는 전체 원본 패킷(터널 모드)을 암호화하여, 도청자가 패킷의 실제 데이터 내용을 알 수 없도록 만든다.

사용되는 암호화 알고리즘은 보안 연관 협상 과정에서 결정된다. 일반적으로 AES와 같은 강력한 현대 암호화 알고리즘이 널리 사용되며, 3DES와 같은 구형 알고리즘도 지원된다. 암호화의 강도는 선택된 알고리즘과 키 길이에 직접적으로 의존한다. 기밀성 서비스는 인증 헤더 단독으로는 제공할 수 없으며, 반드시 ESP를 사용해야 한다.

기밀성은 민감한 정보를 포함하는 통신, 예를 들어 가상 사설망을 통한 원격 접속이나 기업 지점 간 통신에서 필수적이다. 이를 통해 네트워크 계층에서 종단 간 또는 게이트웨이 대 게이트웨이 수준의 비공개 통신 채널을 확보할 수 있다. 다만, 암호화 및 복호화 과정은 패킷 처리에 추가적인 계산 부하를 일으켜 지연 시간 증가나 처리량 감소와 같은 성능 오버헤드를 초래할 수 있다.

무결성은 전송 중인 데이터가 변조되거나 손상되지 않았음을 보장하는 서비스이다. IPsec은 인증 헤더나 암호화 페이로드 프로토콜을 통해 해시 함수를 사용한 메시지 인증 코드를 생성하여 이를 제공한다. 수신 측은 동일한 알고리즘과 키로 MAC을 재계산하고 비교함으로써 패킷의 무결성을 검증한다. 이를 통해 악의적인 중간자 공격자가 데이터를 변조하는 것을 탐지할 수 있다.

인증은 통신 상대방의 신원을 확인하는 서비스로, 데이터 무결성과 밀접하게 연관되어 있다. IPsec은 두 가지 수준의 인증을 제공한다. 첫째는 데이터 인증으로, 위에서 설명한 무결성 검증 과정 자체가 특정 송신자로부터 데이터가 왔음을 간접적으로 증명한다. 둘째는 피어 인증으로, 인터넷 키 교환 프로토콜 단계에서 사전에 공유된 비밀키, 디지털 인증서, 또는 공개키 암호 방식을 사용하여 통신을 시작하기 전에 상대방의 신원을 확인한다.

아래 표는 IPsec에서 무결성과 인증을 제공하는 주요 프로토콜별 특징을 요약한 것이다.

이러한 무결성 및 인증 서비스는 재전송 공격을 방지하는 메커니즘과 결합되어 작동한다. 각 패킷에는 순차 번호가 포함되어 수신 측은 이미 수신한 번호의 패킷을 차단함으로써 공격자가 합법적인 패킷을 가로채 나중에 재전송하는 것을 막는다.

재전송 공격 방지는 IPsec이 제공하는 핵심 보안 서비스 중 하나로, 공격자가 합법적으로 획득한 패킷을 나중에 다시 전송하여 시스템을 혼란시키거나 불법적인 접근을 얻는 것을 차단하는 기능이다. 이 서비스는 주로 암호화 페이로드 프로토콜을 통해 구현되며, 인증 헤더와 함께 사용될 수도 있다.

재전송 공격 방지 메커니즘은 시퀀스 번호 필드를 활용한다. 각 보안 연관이 설정될 때 송신 측의 시퀀스 번호 카운터는 0으로 초기화된다. 이후 이 SA를 통해 보호되는 모든 패킷에는 순차적으로 증가하는 고유한 시퀀스 번호가 포함된다. 수신 측은 이미 수신된 시퀀스 번호 범위를 기록해 두고, 새로 도착한 패킷의 번호가 이 범위 내에 있거나 너무 큰 차이를 보이면 해당 패킷을 재전송 공격으로 간주하고 폐기한다.

이 메커니즘의 효과적인 운영을 위해 수신 측은 '슬라이딩 윈도우' 방식을 사용한다. 일반적으로 32 또는 64 패킷 너비의 윈도우를 유지하며, 윈도우의 왼쪽 경계는 성공적으로 검증된 가장 높은 시퀀스 번호를 나타낸다. 윈도우 내에 있는 낮은 번호의 패킷은 중복 수신으로 거부되고, 윈도우 오른쪽 너머의 너무 높은 번호는 순서가 잘못된 것으로 간주되어 처리되지 않을 수 있다[6]. 이 방식은 패킷의 순서 재배열이나 일부 손실이 발생하는 일반적인 네트워크 환경에서도 정상적인 통신을 허용하면서 재전송 공격을 효과적으로 차단한다.

호스트 기반 구현은 IPsec이 통신의 종단점이 되는 개별 호스트 시스템 자체에 직접 구현되는 방식을 가리킨다. 이 방식에서는 운영 체제의 네트워크 스택에 IPsec 기능이 통합되거나, 호스트에 설치된 특수 소프트웨어를 통해 보안 서비스가 제공된다. 각 호스트는 자신이 송수신하는 IP 패킷에 대해 개별적으로 암호화와 인증을 처리하며, 중간 네트워크 장비의 지원 없이 종단 간(end-to-end) 보안을 실현한다.

이 구현 방식의 주요 특징은 다음과 같다.

호스트 기반 구현은 네트워크의 중간 구간이 아닌, 최종 통신 당사자 사이에서 직접 보안을 보장해야 할 때 유용하다. 예를 들어, 금융 거래 서버와 데이터베이스 서버 간의 통신, 또는 기업 내부의 중요한 워크스테이션 간의 직접적인 데이터 교환을 보호하는 데 적합하다. 이 방식은 게이트웨이 기반 구현에 비해 네트워크 토폴로지 변경이 필요 없지만, 보호가 필요한 모든 호스트에 IPsec을 개별적으로 구성하고 관리해야 하는 부담이 따른다.

게이트웨이/라우터 기반 구현은 네트워크의 경계에 위치한 라우터나 전용 보안 게이트웨이 장비에서 IPsec을 실행하는 방식이다. 이 방식은 주로 사무실이나 지사와 같은 전체 네트워크 구간을 보호하거나, 원격 사용자가 내부 네트워크에 안전하게 접속하는 가상 사설망(VPN)을 구축할 때 사용된다. 개별 호스트가 아닌 네트워크 장비에서 보안 처리를 담당하므로, 내부 네트워크에 있는 일반 호스트들은 추가적인 설정이나 소프트웨어 설치 없이도 보호된 통신을 이용할 수 있다는 장점이 있다.

이 구현 방식에서는 터널 모드가 주로 활용된다. 예를 들어, 본사와 지사의 게이트웨이 사이에 IPsec 터널을 설정하면, 두 지점 내부 네트워크(예: 10.1.1.0/24와 10.2.2.0/24) 간에 오가는 모든 트래픽이 암호화되고 인증되어 공용 인터넷을 통해 전송된다. 내부 호스트들은 마치 동일한 사설 네트워크에 연결된 것처럼 통신할 수 있다. 배포 시나리오는 다음과 같이 구분할 수 있다.

이 방식의 주요 관리적 이점은 중앙 집중식 보안 정책 적용이 가능하다는 점이다. 네트워크 관리자는 경계 게이트웨이에서 모든 들어오고 나가는 트래픽에 대한 보안 정책(SP)을 정의하고, 필요한 암호화 및 인증 알고리즘을 강제할 수 있다. 또한, 네트워크 계층에서 동작하기 때문에 상위 계층의 애플리케이션을 변경할 필요가 없다. 그러나 게이트웨이 장비의 성능이 전체 처리량의 병목 지점이 될 수 있으며, 특히 대량의 동시 터널을 처리할 때는 하드웨어 가속 기능이 필수적이다.

IPsec은 가상 사설망 구축을 위한 핵심 프로토콜 중 하나로 널리 사용된다. IPsec VPN은 공중망인 인터넷을 통해 마치 전용 회선을 사용하는 것처럼 안전한 통신 경로를 생성한다. 이를 통해 지리적으로 분산된 사무실 네트워크를 연결하거나, 원격 사용자가 내부 네트워크 자원에 안전하게 접근할 수 있게 한다. 구축 방식은 주로 터널 모드를 사용하며, 게이트웨이나 라우터에 IPsec을 구현하는 것이 일반적이다.

IPsec VPN의 일반적인 구축 시나리오는 크게 두 가지로 나뉜다.

구축 과정에서는 먼저 IKE 프로토콜을 통해 양측 간에 보안 연관을 협상하고 암호화 키를 교환한다. 이후 실제 데이터 트래픽은 ESP를 통해 기밀성과 무결성을 보장받으며 터널을 통해 전송된다. 이때, 터널 모드는 원본 IP 패킷 전체를 캡슐화하여 새 IP 헤더로 감싸기 때문에, 내부 네트워크 주소가 공중망에 노출되지 않는다.

이러한 IPsec VPN은 방화벽과 연동되어 배포되거나, 전용 VPN 어플라이언스 또는 소프트웨어 형태로 제공된다. 표준화된 프로토콜 덕분에 서로 다른 벤더의 장비 간 상호 운용성이 보장되는 경우가 많지만, 정책 설정과 NAT 통과 문제 등 구성의 복잡성은 여전히 관리상의 과제로 남아있다.

IPsec은 네트워크 계층에서 동작하여 상위 계층의 응용 프로그램이나 사용자에게 투명하게 보안 서비스를 제공한다. 이는 응용 프로그램을 수정할 필요 없이 패킷 수준에서 기밀성, 무결성, 인증을 보장함을 의미한다. 이러한 투명성은 광범위한 네트워크 트래픽을 쉽게 보호할 수 있게 하며, VPN 구축에 매우 적합한 특성이 된다.

IPsec은 IETF에 의해 표준화된 개방형 프로토콜 스위트이다. 이는 다양한 벤더의 장비와 소프트웨어 간의 상호 운용성을 보장한다. 표준화 덕분에 IPsec은 라우터, 방화벽, 운영 체제, 전용 VPN 장비 등 다양한 플랫폼에 광범위하게 구현되고 채택되었다. 이는 네트워크 보안 솔루션 선택에 있어서 벤더 종속성을 줄여준다.

IPsec은 단일 기술이 아닌 여러 프로토콜의 조합으로, 포괄적이고 강력한 보안 서비스를 제공한다. 암호화 페이로드를 통한 기밀성, 인증 헤더와 ESP를 통한 데이터 무결성 및 인증, 그리고 시퀀스 번호를 활용한 재전송 공격 방지 기능을 통합한다. 또한, IKE 프로토콜을 통해 안전한 키 관리와 보안 연관 협상을 수행하여 보안 채널을 동적으로 설정한다.

IPsec은 강력한 보안 서비스를 제공하지만, 몇 가지 실질적인 한계와 도전 과제를 안고 있다. 가장 두드러진 문제는 성능 오버헤드이다. 패킷에 대한 암호화와 인증 연산은 추가적인 CPU 자원을 소모하며, 특히 소프트웨어 방식으로 구현될 때 처리 지연을 유발한다. 대칭키 암호화나 해시 함수 계산 자체는 빠르지만, 이러한 작업이 네트워크 경로상의 모든 패킷에 적용되면 전체적인 처리량 감소와 지연 시간 증가로 이어진다. 이는 고대역폭 링크나 실시간 애플리케이션에서 더욱 두드러진다.

구성의 복잡성은 또 다른 주요 장벽이다. IPsec을 성공적으로 배포하려면 보안 연관, 암호화 알고리즘, 인증 방법 등 다양한 매개변수를 양단에서 일치시켜야 한다. IKE 협상 과정은 유연성을 제공하지만, 방화벽 규칙, 라우팅 정책, 호스트 설정 등과의 정확한 조정이 필요하여 관리 부담을 가중시킨다. 특히 대규모 또는 이기종 환경에서는 정책 설정 오류로 인한 연결 실패가 빈번히 발생할 수 있다.

NAT 환경에서의 동작 문제는 역사적으로 IPsec의 취약점으로 지적되어 왔다. 인증 헤더는 패킷 무결성을 보호하기 위해 IP 헤더의 주소 필드를 포함하여 인증 값을 계산한다. NAT 장비가 IP 주소를 변조하면 이 인증 값이 무효화되어 통신이 실패한다. 암호화 페이로드는 UDP 캡슐화 등의 방법으로 이 문제를 일부 우회할 수 있지만, 이는 표준화된 해결책이 아니며 추가적인 구성 복잡성을 초래한다. 이러한 한계들은 IPsec이 이론적으로 완벽한 보안을 제공하더라도, 실제 네트워크 환경에서의 적용에는 신중한 설계와 절충이 필요함을 보여준다.

IPsec과 SSL/TLS는 모두 네트워크 통신 보안을 제공하는 프로토콜 스위트이지만, 작동 계층, 주요 사용 사례 및 구현 방식에서 뚜렷한 차이를 보인다.

가장 근본적인 차이는 작동하는 OSI 모델 계층에 있다. IPsec은 네트워크 계층(3계층)에서 동작하여 IP 패킷 자체를 보호한다. 이는 상위 계층의 애플리케이션(예: 웹 브라우저, 이메일 클라이언트)이 변경될 필요 없이 운영 체제나 네트워크 장비 수준에서 투명하게 보안 서비스를 제공할 수 있음을 의미한다. 반면, SSL/TLS는 전송 계층(4계층) 위, 즉 애플리케이션 계층과 전송 계층 사이에서 동작한다. 이는 주로 특정 애플리케이션(예: HTTPS, FTPS)의 통신을 보호하는 데 사용되며, 애플리케이션 자체가 SSL/TLS 라이브러리를 활용하여 보안 연결을 수립해야 한다.

이러한 계층적 차이는 주요 사용 사례와 배포 모델로 이어진다. IPsec은 두 네트워크 사이에 안전한 터널을 구축하는 사이트 간 VPN이나 원격 사용자가 회사 네트워크에 안전하게 접속하는 원격 액세스 VPN에 널리 사용된다. 모든 IP 트래픽을 캡슐화하여 보호할 수 있기 때문이다. SSL/TLS는 전통적으로 웹 트래픽(HTTPS) 보호에 특화되어 있었지만, SSL VPN 기술의 발전으로 특정 애플리케이션 서비스(예: 웹 메일, 파일 공유)에 대한 원격 접근을 제공하는 데 더 많이 활용된다. 구성 측면에서 IPsec은 종종 클라이언트 측에 전용 소프트웨어 설치를 필요로 하는 반면, SSL VPN은 표준 웹 브라우저를 클라이언트로 사용할 수 있어 배포가 상대적으로 간편하다.

다음 표는 두 기술의 주요 차이점을 요약한다.

요약하면, IPsec은 네트워크 수준에서 모든 트래픽을 보호하는 포괄적인 터널을 제공하는 반면, SSL/TLS는 애플리케이션 수준에서 보다 세분화된 접근 제어와 함께 특정 서비스의 보안을 담당한다. 현대 네트워크 환경에서는 조직의 요구사항에 따라 두 기술을 상호 보완적으로 사용하는 경우가 많다.

IPsec은 가상 사설망 구축을 위한 표준 프로토콜 중 하나로, OpenVPN이나 WireGuard와 같은 다른 VPN 프로토콜과는 설계 철학과 구현 방식에서 차이를 보인다. OpenVPN은 주로 사용자 공간에서 동작하는 애플리케이션 계층 VPN 솔루션으로, 전송 계층 보안 프로토콜을 기반으로 한다. 이는 높은 유연성과 다양한 플랫폼 호환성을 제공하지만, 커널 수준에서 동작하는 IPsec에 비해 성능 오버헤드가 클 수 있다. 반면, WireGuard는 IPsec과 마찬가지로 커널 공간에서 동작하는 현대적인 VPN 프로토콜로, 코드베이스가 훨씬 간결하고 구성이 단순하다는 특징이 있다.

다음 표는 IPsec과 다른 주요 VPN 프로토콜의 특징을 비교한 것이다.

IPsec은 장기간 검증된 강력한 보안과 네트워크 계층에서의 투명한 보호를 제공하여 기업 환경에서 널리 사용된다. 그러나 WireGuard는 설정의 단순성과 뛰어난 성능으로 인해 빠르게 채택되고 있으며, 특히 클라우드와 컨테이너 환경에서 인기를 얻고 있다. OpenVPN은 방화벽 친화적인 TCP 포트(예: 443)를 사용할 수 있어 제한적인 네트워크 환경에서 유리한 경우가 많다. 결국, 프로토콜 선택은 보안 요구사항, 네트워크 토폴로지, 관리 편의성, 그리고 성능 목표에 따라 달라진다.