IPsec 전송 모드 특징과 터널 모드 차이점 및 용도 완벽 정리
IPsec을 한 문장으로 잡고 가면요
IPsec은 “IP 패킷 단위”로 암호화/인증을 걸어서, 앱이 뭘 쓰든(웹이든 메신저든) 네트워크 계층에서 통째로 보호해주는 방식이거든요. 그리고 이 IPsec이 일을 하는 자세가 딱 두 가지인데, 그게 전송(Transport) 모드와 터널(Tunnel) 모드예요. 자료에 따르면 전송 모드는 IP 헤더를 빼고 페이로드(실제 데이터) 위주로 보호하고, 터널 모드는 IP 패킷 전체를 보호하면서 새 IP 헤더를 하나 더 씌우는 구조입니다(https://liveyourit.tistory.com/4).
제가 2021년에 싱가포르 리전에 있는 AWS VPC랑 한국 본사 방화벽 사이 사이트-투-사이트 IPsec을 붙이면서 MTU를 1500 그대로 믿었다가, 실제로는 캡슐화 오버헤드 때문에 일부 트래픽만 조용히 깨지는 걸 잡느라 반나절을 태운 적이 있거든요.
전송 모드(Transport): “편지 봉투는 그대로, 내용물만 잠금”
전송 모드는 비유로 치면 “기존 봉투(원래 IP 헤더)는 그대로 두고, 편지지(데이터)만 봉인”하는 느낌이에요. 겉봉투 주소는 보여야 라우터들이 길 안내를 하니까요. 그래서 원래 IP 헤더는 그대로 남고, 그 안쪽의 상위계층 데이터(TCP/UDP와 애플리케이션 데이터)가 주로 보호 대상이 됩니다.
실무에서 이 개념이 중요한 이유는 “어디까지가 보호되고 어디까지가 밖에 보이냐”가 ACL/방화벽 정책, 트러블슈팅, 그리고 MTU 같은 운영 이슈까지 한 번에 엮여서 사고(?)를 내기 쉽기 때문이거든요.
어디에 잘 쓰이냐면요: 호스트-호스트
전송 모드는 “통신 당사자 둘 다 엔드 호스트”인 상황에 잘 맞아요. ktword 자료에서도 수송(전송) 모드는 IP 헤더를 제외한 데이터 부분을 보호해서 호스트 간 통신에 적합하다고 정리하거든요(http://www.ktword.co.kr/test/view/view.php?no=6185).
즉, PC ↔ 서버처럼 양쪽이 직접 IPsec을 처리할 수 있으면 전송 모드가 깔끔합니다.
장점/특징
오버헤드가 상대적으로 적은 편: 새 IP 헤더로 한 겹 더 싸지 않으니 패킷이 덜 “뚱뚱”해지기 쉬워요.
정책을 세밀하게 주기 좋음: 전송 모드는 외부 IP 헤더 기준으로 정책을 적용하고, 포트/헤더를 더 세분화해 정책을 설정할 수 있다고 Oracle 문서가 설명합니다(https://docs.oracle.com/cd/E38901_01/html/E38894/ipsec-ov-13.html).
말하자면 “이 서버의 443만 보호” 같은 식으로요(환경/구현에 따라 가능 범위는 달라질 수 있어요).
단점/제약
“게이트웨이가 대신 처리”하는 구조에는 한계가 있어요. 엔드 호스트가 직접 IPsec을 해야 자연스러운 모드니까요.
터널 모드(Tunnel): “봉투째로 다른 택배 상자에 넣기”
터널 모드는 한마디로 “원래 IP 패킷(원래 IP 헤더 포함)을 통째로 캡슐화”하고, 바깥에 새 IP 헤더를 하나 더 붙여서 보내는 방식이에요. 그러니까 택배로 치면 “원래 상자(내부 IP 패킷)를 새 상자(외부 IP 헤더)로 한 번 더 포장”하는 거죠. liveyourit 자료에서도 터널 모드는 IP 패킷 전체를 보호하며 새로운 IP 헤더를 추가한다고 설명합니다(https://liveyourit.tistory.com/4).
어디에 잘 쓰이냐면요: 게이트웨이-게이트웨이(사이트 투 사이트)
터널 모드는 VPN 장비(라우터/방화벽)가 “뒤에 있는 여러 호스트를 대표해서” 보안 처리를 해줘야 할 때 정석으로 많이 씁니다. ktword 자료에서도 터널 모드는 주로 라우터 간 VPN 구현에 사용된다고 정리해요(http://www.ktword.co.kr/test/view/view.php?no=6185).
레딧의 네트워킹 토론에서도 “한쪽 또는 양쪽이 게이트웨이로서 다른 호스트를 대신해 보안 서비스를 수행한다면 터널 모드를 써야 한다”는 요지가 반복되고요(https://www.reddit.com/r/networking/comments/4o6ugy/ipsec_tunnel_mode_vs_transport_mode/).
참고로 IETF에서 발행하는 IPsec 관련 RFC들(예: ESP를 다루는 RFC 4303, 아키텍처를 정리한 RFC 4301)도 전송/터널 모드를 전제로 동작을 정의해두고 있어서, 벤더마다 표현이 달라도 큰 줄기는 여기서 크게 벗어나기 어렵습니다.
장점/특징
내부 주소/구조를 감추기 쉬움: 내부 IP 패킷이 통째로 암호화/보호되면, 밖에서 보기엔 “게이트웨이↔게이트웨이” 트래픽처럼 보이기 좋거든요.
“사설망끼리 연결” 같은 VPN 시나리오에 잘 맞음: 내부망을 통째로 이어 붙이는 느낌을 만들기 쉬워요.
단점/주의점
오버헤드와 부담이 늘 수 있음: 패킷에 새 IP 헤더가 붙고 캡슐화가 들어가니 처리량/MTU(한 번에 실을 수 있는 크기) 이슈가 생길 수 있어요. ktword 자료에서도 터널 모드는 보안성이 높지만 시스템 과부하가 발생할 수 있다고 언급합니다(http://www.ktword.co.kr/test/view/view.php?no=6185).
이건 “무조건 느리다”가 아니라, 장비 성능/회선/암호화 설정에 따라 체감이 달라질 수 있어요.
“그래서 뭐가 다르냐”를 딱 4줄로 정리하면요
보호 범위: 전송은 “IP 헤더 제외”, 터널은 “IP 패킷 전체 + 새 IP 헤더”
누가 처리하나: 전송은 “호스트가 직접”, 터널은 “게이트웨이가 대표로”가 자연스러움
용도: 전송은 호스트-호스트, 터널은 사이트-투-사이트 VPN에 찰떡
부담: 전송이 상대적으로 가볍고, 터널은 캡슐화로 오버헤드가 늘 수 있음
흔한 오해 3개만 콕 집으면요
1) “터널 모드가 무조건 더 안전하죠?”
터널 모드는 “더 많이 감싼다”는 의미에서 보안적으로 유리한 면이 있지만, 안전은 모드만으로 결정되지 않아요. 어떤 트래픽을 어떤 정책으로 보호하는지, 키 교환(IKE)과 알고리즘, 장비 설정이 같이 맞물립니다. Oracle 문서에서도 전송/터널은 정책 적용 기준이 달라진다고 설명하거든요(https://docs.oracle.com/cd/E38901_01/html/E38894/ipsec-ov-13.html). 즉 “보안 목표가 뭐냐”에 따라 선택이 달라져요.
2) “전송 모드는 VPN이 아닌가요?”
VPN을 “터널링”으로만 생각하면 헷갈리는데요, IPsec 자체가 네트워크 계층에서 패킷을 보호하는 기술이라 전송 모드도 보안 통신을 만들 수 있어요. 다만 “사설망 대 사설망을 통째로 잇는” 우리가 흔히 떠올리는 VPN 그림은 터널 모드가 더 자주 등장할 뿐이죠.
3) “동적 라우팅은 터널 모드로만 해야죠?”
꼭 그렇진 않아요. IETF RFC 3884에서는 기존 IPsec 터널 모드가 가상 네트워크 내 라우팅/포워딩과 충돌할 수 있는 점을 언급하면서, IPIP 캡슐화와 IPsec 전송 모드를 결합해 동적 라우팅을 지원하는 방법(IIPtran)을 소개합니다(https://www.ietf.org/rfc/rfc3884.txt).
현장에서는 설계 목표(라우팅/운영 편의/상호운용성)에 따라 선택지가 갈릴 수 있다는 포인트만 기억해두시면 됩니다.
마무리: 선택 기준은 “누가 IPsec을 처리하냐”부터예요
다만, 이 글에서 말한 “전송=호스트-호스트, 터널=게이트웨이-게이트웨이”는 제일 흔한 그림을 기준으로 한 거라서, 클라우드/컨테이너/SD-WAN처럼 구성요소가 섞인 환경에서는 예외 케이스가 충분히 나올 수 있어요.
전송 모드와 터널 모드를 고를 때 제일 쉬운 출발점은 이거예요.
엔드 호스트끼리 직접 잠그고 풀 수 있다 → 전송 모드가 자연스럽고 가볍습니다.
방화벽/라우터가 뒤의 여러 기기를 대표해서 VPN을 세워야 한다 → 터널 모드가 정석에 가깝습니다.
결국 “봉투를 그대로 둘 거냐(전송)”, “봉투째로 새 상자에 넣을 거냐(터널)” 차이인데요. 내 환경에서 누가 암호화를 담당하고, 어떤 범위를 숨기거나 보호해야 하는지부터 잡으면 선택이 훨씬 쉬워지실 거예요.