VPN과 터널링 (3) - 현대 VPN 기술 - soo:bak

작성일 :

Part 2에서 IPsec의 구조를 살펴보았습니다.

키 교환(IKE), 패킷 암호화(ESP), 보안 정책 관리(SAD/SPD)까지, IPsec은 VPN에 필요한 모든 기능을 갖추고 있습니다.

하지만 IPsec은 1990년대 후반, 본사와 지사를 연결하는 기업용 인프라를 전제로 설계되었습니다. 고정된 IP 주소, 전용 VPN 장비, 전문 네트워크 관리자가 있는 환경에서 잘 작동했습니다.

2000년대 들어 환경이 바뀌었습니다. 노트북과 스마트폰이 보편화되면서 사용자의 IP 주소는 수시로 바뀌기 시작했고, 커피숍이나 공항처럼 HTTP(80)와 HTTPS(443) 외의 포트를 차단하는 네트워크에서 VPN을 사용해야 하는 상황이 늘어났습니다.

IPsec은 이런 환경에 맞지 않았고, 다른 접근이 필요했습니다.

SSL/TLS VPN은 웹과 같은 포트(443)를 사용하여 방화벽을 우회했고, WireGuard는 코드를 4,000줄로 줄여 보안 감사가 가능한 수준의 단순함을 확보했습니다.

왜 새로운 VPN 프로토콜이 등장했는가

구체적으로 어떤 문제가 있었을까요?

설정 복잡성. IKE 버전, DH 그룹, 암호화 알고리즘, 무결성 알고리즘, 수명 등 수십 개의 파라미터를 양쪽에서 정확히 일치시켜야 합니다. 하나라도 다르면 터널이 수립되지 않습니다.

방화벽 통과 어려움. ESP(프로토콜 50), UDP 500, UDP 4500 등 일반적이지 않은 포트와 프로토콜을 사용합니다. 호텔이나 공항 Wi-Fi에서는 이 포트들이 차단되어 VPN 자체가 연결되지 않는 경우가 많습니다.

모바일 환경의 한계. SA는 특정 IP 주소 쌍에 바인딩됩니다. 스마트폰이 Wi-Fi에서 LTE로 전환하면 IP 주소가 바뀌고, SAD에서 SA를 찾을 수 없어 IKE 재협상이 필요합니다. 그 사이 연결이 끊기게 됩니다.

코드베이스 비대. Linux의 IPsec 스택(커널 XFRM + strongSwan)은 약 40만 줄에 달합니다. 코드가 많을수록 버그가 숨을 수 있는 곳도 많아지고, 공격자가 노릴 수 있는 취약점도 늘어납니다. 40만 줄을 빠짐없이 검토하는 것은 현실적으로 불가능합니다.

SSL/TLS VPN

방화벽이 IPsec을 차단할 수 있는 이유는, IPsec이 ESP라는 별도의 프로토콜을 사용하기 때문입니다. 방화벽 입장에서 ESP는 허용 목록에 없는 생소한 프로토콜입니다.

SSL/TLS VPN은 발상을 바꿉니다. VPN 트래픽을 TLS(Transport Layer Security) 안에 담아 HTTPS와 같은 포트(443)로 보냅니다. TLS는 웹 브라우저가 서버와 통신할 때 데이터를 암호화하는 프로토콜로, 주소창의 자물쇠 아이콘이 이 프로토콜이 동작하고 있다는 표시입니다.

1
2
3
4
5
6
7
8
9
10

TLS VPN 캡슐화:
┌─────────────────────────────────────────────────────────────┐
│              원본 IP 패킷 (VPN 트래픽)                       │
├─────────────────────────────────────────────────────────────┤
│                    TLS (암호화)                              │
├─────────────────────────────────────────────────────────────┤
│                    TCP (포트 443)                            │
├─────────────────────────────────────────────────────────────┤
│                       IP                                     │
└─────────────────────────────────────────────────────────────┘

방화벽이 보는 것은 바깥쪽의 TCP 포트 443뿐입니다. 포트 443을 차단하면 웹 서비스 전체가 멈추므로, 어떤 방화벽도 이 포트를 막을 수 없고 VPN 트래픽이 자연스럽게 통과합니다.

다만 완벽하지는 않습니다. DPI(Deep Packet Inspection)를 사용하는 방화벽은 포트 번호가 아니라 트래픽 패턴을 분석하므로, 같은 443 포트를 쓰더라도 일반 HTTPS와 VPN 트래픽의 패턴 차이를 탐지하여 차단할 수 있습니다.

OpenVPN

SSL/TLS VPN이 방화벽 우회라는 문제를 해결했다면, 이를 실제로 구현한 소프트웨어는 무엇일까요?

OpenVPN은 2001년에 시작된 오픈소스 프로젝트입니다. TLS를 VPN에 처음 적용했으며, 현재까지 가장 널리 사용되는 TLS 기반 VPN입니다.

OpenVPN의 구조

OpenVPN은 두 가지 채널을 분리합니다.

  • 제어 채널: TLS로 보호되며, 인증과 키 교환을 담당
  • 데이터 채널: 제어 채널에서 협상된 키로 암호화하여 실제 VPN 트래픽을 전송
1
2
3
4
5
6
7
8
9
10
11

제어 채널:                        데이터 채널:
┌─────────────────────┐          ┌─────────────────────┐
│    키 교환 / 인증    │          │    원본 IP 패킷     │
├─────────────────────┤          ├─────────────────────┤
│        TLS          │          │     자체 암호화      │
├─────────────────────┤          ├─────────────────────┤
│  TCP 또는 UDP       │          │  TCP 또는 UDP       │
│  (기본: UDP 1194)   │          │  (기본: UDP 1194)   │
├─────────────────────┤          ├─────────────────────┤
│         IP          │          │         IP          │
└─────────────────────┘          └─────────────────────┘

OpenVPN의 특징

오픈소스로 누구나 소스 코드를 검토할 수 있고, Windows, macOS, Linux, iOS, Android 등 주요 플랫폼을 지원합니다.

전송 프로토콜로 TCP와 UDP를 모두 지원합니다. 기본은 UDP를 사용하지만, 방화벽이 엄격한 환경에서는 TCP 443 포트로 전환하여 HTTPS 트래픽처럼 통과할 수 있습니다. 인증 방식도 인증서, 비밀번호, 2단계 인증 등을 지원합니다.

다만 성능에는 한계가 있습니다. Part 1에서 설명한 것처럼, IPsec과 WireGuard는 커널에서 패킷을 바로 처리합니다. OpenVPN은 사용자 공간에서 동작하므로, 패킷이 커널에서 프로세스로, 다시 커널로 전달되어야 합니다. 이 컨텍스트 스위칭이 처리량을 낮춥니다.

설정도 복잡합니다. 수백 개의 옵션이 존재하여 최적의 구성을 찾기까지 시행착오가 필요할 수 있습니다.

TCP 모드를 사용하면 TCP-over-TCP 문제도 발생합니다.

TCP-over-TCP 문제

OpenVPN을 TCP 모드로 사용하면, 애플리케이션의 TCP 위에 OpenVPN의 TCP가 겹칩니다.

1
2
3
4
5
6
7
8
9
10
11

┌──────────────────────────┐
│    애플리케이션 데이터     │
├──────────────────────────┤
│        TCP (내부)         │ ← 애플리케이션
├──────────────────────────┤
│     OpenVPN 암호화        │
├──────────────────────────┤
│        TCP (외부)         │ ← OpenVPN
├──────────────────────────┤
│           IP              │
└──────────────────────────┘

Part 1에서 설명한 TCP Meltdown이 발생하는 구조입니다. 패킷 손실이 생기면 내부와 외부 TCP가 모두 재전송을 시도하고, 혼잡 제어가 서로 간섭하여 지연이 급격히 증가합니다.

방화벽 우회가 필요한 환경이 아니라면 UDP 모드를 권장합니다.

WireGuard

IPsec은 설정이 복잡하고, OpenVPN은 사용자 공간에서 동작하여 성능이 제한됩니다.

WireGuard는 이 두 문제를 동시에 해결하기 위해 설계된 VPN 프로토콜입니다. 보안 연구자 Jason Donenfeld가 만들었으며, 2020년 Linux 커널 5.6에 정식 포함되었습니다.

설계 철학: 단순함

다른 VPN과 코드 크기를 비교하면:

  • OpenVPN: 약 100,000줄
  • IPsec (strongSwan): 약 400,000줄
  • WireGuard: 약 4,000줄

코드가 적으면 보안 검토도 수월해집니다.

Noise Protocol Framework

TLS나 IKE는 버전, 모드, 암호 알고리즘을 협상하는 과정에서 복잡해지고, 구현 오류가 발생하기 쉽습니다. WireGuard는 이 협상 자체를 없애는 Noise Protocol Framework를 사용합니다.

고정된 암호 조합. IKE나 TLS는 “AES-128로 할까, AES-256으로 할까, 키 교환은 어떤 방식으로 할까”를 협상합니다. 옵션이 많을수록 잘못된 조합을 선택할 가능성도 커집니다. WireGuard는 협상 없이 미리 정해진 조합만 사용합니다.

단순한 핸드셰이크. IKEv2는 먼저 알고리즘을 협상하고(1왕복), 그 다음 신원을 인증합니다(1왕복). 협상이 끝나야 인증을 암호화할 수 있으므로, 4개 메시지(2-RTT)가 필요합니다. WireGuard는 알고리즘이 고정되어 있고, 상대방의 공개키를 설정 시 미리 교환해 두므로 협상과 인증을 한 번에 처리합니다. 2개 메시지, 1-RTT로 충분합니다.

형식적 검증 가능. 복잡한 프로토콜은 테스트로 취약점을 찾습니다. 모든 경우를 테스트할 수는 없으므로, 수년 후에 새로운 취약점이 발견되기도 합니다. 단순한 프로토콜은 다릅니다. “제3자가 키를 알아낼 수 없다”는 것을 수학적으로 증명할 수 있습니다. WireGuard의 핸드셰이크는 이런 증명이 완료되었습니다.

앞서 말한 “고정된 암호 조합”은 다음 알고리즘으로 구성됩니다.

  • Curve25519: 키 교환. Part 2의 Diffie-Hellman과 같은 역할이지만, 타원곡선을 사용하여 2048비트 대신 256비트 키로 동등한 보안 강도를 제공합니다.
  • ChaCha20-Poly1305: 암호화와 무결성 검증. Part 2에서 ESP는 암호화 키와 인증 키를 따로 사용했지만, 이 방식은 하나의 키로 둘을 동시에 처리합니다. 하드웨어 가속 없이도 빠르므로 모바일 기기에서도 성능이 좋습니다.
  • BLAKE2s: 해시. SHA-256보다 빠르면서 동등한 보안 강도를 제공합니다.


알고리즘이 고정되어 있으므로 사용자가 약한 알고리즘을 실수로 선택할 가능성이 없습니다.

대신 특정 알고리즘에 취약점이 발견되면, 그 알고리즘만 교체할 수 없고 프로토콜 버전 자체를 업그레이드해야 합니다.

WireGuard 핸드셰이크

1
2
3
4
5
6
7
8
9
10

개시자                                 응답자
    │                                      │
    │ ─── Handshake Initiation ─────────► │
    │     (임시 공개키 + 암호화된 신원)     │
    │                                      │
    │ ◄─── Handshake Response ──────────  │
    │     (임시 공개키 + 확인)              │
    │                                      │
    │ ◄────── 데이터 전송 ──────────►     │
    │                                      │

개시자는 응답자의 공개키를 이미 알고 있으므로, 첫 메시지부터 자신의 신원을 암호화하여 보낼 수 있습니다. 응답자가 확인을 보내면 바로 데이터 전송이 시작됩니다.


Cryptokey Routing

IPsec에서는 “누구와 연결할 것인가”와 “어떤 트래픽을 터널로 보낼 것인가”를 따로 설정해야 합니다.

예를 들어 지사와 VPN을 연결하려면:

  1. 인증 설정: “지사 서버의 인증서를 신뢰한다”
  2. 트래픽 정책: “10.200.200.0/24 대역을 터널로 보낸다”

두 설정이 맞지 않으면 터널은 수립되었는데 트래픽이 흐르지 않는 문제가 발생합니다.

WireGuard는 Cryptokey Routing으로 이 두 설정을 하나로 통합합니다.

1
2
3

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb60Y7YAf21J7YQMlYhM2IPVY=
AllowedIPs = 10.200.200.2/32, 192.168.0.0/24

PublicKey가 “누구인지”를, AllowedIPs가 “어떤 트래픽을 허용할지”를 결정합니다. 하나의 설정 블록에서 둘이 함께 정의되므로 불일치가 발생할 수 없습니다.

AllowedIPs는 수신과 송신 양쪽에서 동작합니다.

  • 수신: 이 피어에서 온 패킷의 출발지가 범위 안에 있어야 허용
  • 송신: 목적지가 범위 안에 있으면 이 피어로 전송

WireGuard의 특징

장점.

앞서 살펴본 것처럼 OpenVPN은 패킷이 커널과 사용자 공간을 오갈 때마다 데이터 복사와 컨텍스트 스위칭이 발생합니다. WireGuard는 커널 안에서 바로 처리하므로 이 오버헤드가 없고, 처리량이 OpenVPN 대비 3~4배에 달합니다.

IPsec은 IP 주소로 연결을 식별합니다. Wi-Fi에서 LTE로 전환하면 IP 주소가 바뀌므로, IPsec 입장에서는 새로운 연결이 됩니다. IKE가 처음부터 키 교환을 다시 수행해야 하고, 그 동안 VPN이 끊깁니다.

WireGuard는 공개키로 피어를 식별합니다. 새 IP에서 정상적으로 암호화된 패킷이 도착하면, 해당 공개키의 접속 주소만 갱신합니다. 암호화 세션은 그대로 유지되므로 Wi-Fi에서 LTE로 전환해도 VPN이 끊기지 않습니다.

OpenVPN이 수백 개의 설정 옵션을 제공하는 것과 달리, WireGuard는 앞서 본 것처럼 수십 줄이면 충분합니다.


단점.

IPsec(1995년~)이나 OpenVPN(2001년~)에 비해 역사가 짧아, 대규모 기업 환경에서의 운영 사례가 아직 많지 않습니다.

앞서 살펴본 것처럼 알고리즘이 고정되어 있어, 미국 정부의 FIPS 140처럼 AES 사용을 의무화하는 규제 환경에서는 사용할 수 없습니다.

UDP만 지원하므로, TCP 443만 허용하는 네트워크에서는 방화벽을 통과할 수 없습니다.

피어에게 IP를 자동으로 할당하는 기능이 없어, 규모가 커지면 수동 관리나 별도 도구가 필요합니다.

프로토콜 비교

앞에서 살펴본 세 프로토콜의 특성을 비교합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

┌───────────────┬─────────────┬──────────────┬─────────────┐
│    항목       │    IPsec    │   OpenVPN    │  WireGuard  │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 동작 위치     │    커널     │  사용자 공간  │    커널     │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 암호화        │  협상 가능   │   TLS 기반   │  고정 조합  │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 전송 프로토콜 │  ESP / UDP  │  TCP / UDP   │   UDP만     │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 코드 규모     │ ~400,000줄  │ ~100,000줄   │  ~4,000줄   │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 성능          │    높음     │     중간     │  매우 높음   │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 방화벽 우회   │   어려움    │     쉬움     │   제한적    │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 모바일 로밍   │   제한적    │    제한적    │    우수     │
├───────────────┼─────────────┼──────────────┼─────────────┤
│ 표준화        │ IETF 표준   │  사실상 표준  │  커널 내장  │
└───────────────┴─────────────┴──────────────┴─────────────┘


사용 사례별 선택

기업 Site-to-Site VPN. IPsec은 IETF 표준이며, 시스코와 주니퍼 등 주요 장비 벤더가 지원하여 이기종 환경에서도 호환됩니다.

개인 또는 소규모 VPN. WireGuard는 설정이 단순하고 성능이 높아 유지보수 부담이 적습니다.

방화벽 우회가 필요한 환경. OpenVPN의 TCP 443 모드는 일반 HTTPS 트래픽과 구분이 어려워 차단을 피할 수 있습니다.

모바일 환경. WireGuard는 공개키로 피어를 식별하므로, IP 주소가 바뀌어도 연결이 유지됩니다.

Split Tunneling

프로토콜을 선택한 다음에는 또 하나의 결정이 필요합니다. 모든 트래픽을 VPN으로 보낼 것인가, 일부만 보낼 것인가?

Split Tunneling은 목적지에 따라 일부 트래픽만 VPN을 통과시키는 기법입니다.

Full Tunnel

Full Tunnel 모드에서는 사용자의 모든 인터넷 트래픽이 VPN을 통과합니다.

1
2

사용자 ──► VPN ──► 인터넷
          (모든 트래픽)

모든 트래픽이 암호화되므로 보안 범위가 넓고, 라우팅 정책도 단순합니다.

하지만 유튜브 스트리밍이나 OS 업데이트까지 VPN을 경유하면, VPN 서버가 보호할 필요 없는 트래픽까지 암호화하고 중계해야 합니다. 직접 연결보다 경로도 길어지므로 지연이 커집니다.

CDN(Content Delivery Network)은 사용자 가까이에 콘텐츠를 배치하는 기술입니다. 서울에서 유튜브에 접속하면 서울 근처 서버에서 영상을 전달합니다. 하지만 VPN을 경유하면 요청이 VPN 서버 위치에서 출발하므로, 가까운 CDN 서버를 활용하지 못합니다.

Split Tunnel

Split Tunnel 모드에서는 지정된 대역으로 향하는 트래픽만 VPN을 통과하고, 나머지는 직접 연결합니다.

1
2
3

사용자 ──► VPN ──► 회사 내부 (10.0.0.0/8)
      │
      └──────────► 인터넷 (직접)

VPN 서버 부하가 줄어들고, 일반 웹 서핑이나 스트리밍 지연도 낮아집니다.

하지만 VPN 밖의 트래픽은 암호화되지 않습니다. 공용 Wi-Fi에서 Split Tunnel을 사용하면, VPN을 경유하지 않는 트래픽은 같은 네트워크의 공격자에게 노출될 수 있습니다.

정책 설계도 복잡해집니다. 어떤 대역을 VPN으로 보낼지 정의해야 하는데, 클라우드 서비스의 IP 대역은 수시로 변경됩니다. 규칙이 누락되면 보호해야 할 트래픽이 VPN 밖으로 빠져나갑니다.

역 Split Tunnel

Split Tunnel과 반대 방향입니다. 모든 트래픽을 VPN으로 보내되, 지정한 서비스만 VPN을 우회합니다.

1
2
3

사용자 ──► VPN ──► 인터넷 (대부분의 트래픽)
      │
      └──────────► Zoom, Teams (직접)

화상 회의처럼 지연에 민감한 서비스만 직접 연결하여 품질을 확보하고, 나머지 트래픽은 VPN으로 보호합니다.

다만 우회 대상의 트래픽은 VPN 보호 밖에 놓이므로, 예외 목록을 최소한으로 유지해야 합니다.

VPN과 Zero Trust

지금까지 VPN의 암호화와 터널링을 살펴봤습니다. 하지만 터널을 암호화하는 것과, 터널 안에서 누가 무엇에 접근하는지는 별개의 문제입니다.

전통적 경계 보안

전통적으로 VPN은 경계 보안(Perimeter Security) 모델과 함께 사용되었습니다. VPN이 암호화된 터널을 제공하고, 경계 보안이 접근을 제어하는 구조입니다. 핵심 가정은 “내부는 안전하고, 외부는 위험하다”입니다.

1
2
3
4
5
6
7
8
9
10

┌──────────────────────────────────────┐
│           신뢰된 내부 네트워크        │
│                                      │
│     서버      데이터베이스    사용자  │
│                                      │
└───────────────────┬──────────────────┘
                    │ 방화벽/VPN
                    │
        ────────────┴────────────────
               신뢰되지 않은 외부

VPN에 연결하면 내부 네트워크의 일원이 됩니다. 인증은 연결 시점에 한 번뿐이고, 이후에는 내부 리소스에 제한 없이 접근할 수 있습니다.

경계 보안의 한계

하지만 이 모델은 현대 환경에서 한계를 드러냈습니다.

대형 보안 사고는 외부 침입보다 내부에서 시작되는 경우가 많았습니다. 2013년 에드워드 스노든 사건은 정당한 접근 권한을 가진 내부자가 그 권한을 남용한 사례입니다. 2020년 SolarWinds 해킹은 공급망을 통해 내부에 침투한 공격자가 네트워크 안에서 다른 시스템으로 확산하며 피해를 키운 사례입니다.

경계 보안은 내부자의 권한 남용도, 내부 침투 후 확산도 막지 못했습니다.


내부 위협. 경계 보안은 경계를 넘는 시점만 감시합니다. 악성코드에 감염된 노트북이 VPN으로 연결되면, 경계 안에서 다른 시스템을 공격해도 탐지하지 못합니다.

과도한 접근 권한. 경계 보안은 “안과 밖”만 구분합니다. 안에 들어온 사용자의 접근 범위를 세분화하지 않으므로, 재무팀 직원이 개발 서버에, 인턴이 경영 데이터베이스에 접근할 수 있습니다.

경계의 모호화. 경계 보안은 “회사 네트워크”라는 물리적 경계를 전제합니다. 하지만 회사 데이터가 AWS에 있고 직원이 카페에서 일한다면, 경계를 어디에 그어야 하는지 불분명합니다.

VPN의 암호화된 터널 자체는 문제가 아닙니다. 문제는 터널을 통과하면 네트워크 전체에 접근할 수 있는 모델입니다.

Zero Trust 모델

Zero Trust 모델은 “내부는 안전하다”는 가정 자체를 버립니다.

“절대 신뢰하지 말고, 항상 검증하라(Never Trust, Always Verify).”

1

사용자 ──[신원/장치 검증]──► 정책엔진 ──[권한 확인]──► 리소스

항상 검증. 네트워크 위치와 관계없이 모든 접근 요청을 검증합니다.

최소 권한. 작업에 필요한 최소한의 권한만 부여합니다. 재무팀은 재무 시스템에만, 개발팀은 개발 서버에만 접근할 수 있습니다.

마이크로 세분화. 네트워크를 작은 단위로 분리합니다. 하나의 시스템이 침해되어도 다른 시스템으로 확산되지 않도록 격리합니다.

침해 가정. 이미 침해되었다고 가정하고 설계합니다. 목표는 침입을 막는 것이 아니라, 피해를 제한하는 것입니다.

구글이 2014년에 공개한 BeyondCorp이 대표적인 구현 사례입니다. 구글은 2009년 해커가 내부 네트워크에 침투한 사건을 계기로 경계 보안 모델 자체를 폐기하기로 결정했습니다.

BeyondCorp에서 직원은 VPN으로 사내 네트워크에 접속하는 대신, 인증 프록시를 통해 개별 애플리케이션에 접근합니다. 프록시가 신원과 장치 상태를 확인한 후 접근을 허용합니다.

이는 자체 인프라를 갖춘 구글이기에 가능한 접근이며, 대부분의 조직은 기존 VPN 위에 Zero Trust 원칙을 적용합니다.

VPN의 역할 변화

VPN의 터널링 기술은 사라지지 않습니다. 달라지는 것은 터널을 통과한 뒤의 접근 범위입니다.

ZTNA(Zero Trust Network Access)가 이 변화를 구현합니다. 사용자는 암호화된 터널을 통해 접속하지만, 접근할 수 있는 대상은 특정 애플리케이션으로 제한됩니다. Zscaler Private Access나 Cloudflare Access 같은 서비스가 대표적입니다.

VPN이 제공하는 암호화된 터널 위에, 누가 무엇에 접근할 수 있는지를 제어하는 레이어가 추가된 것입니다.

마무리: 단순함이 보안이다

  • IPsec: 벤더 호환성이 높고 보안이 검증되었지만, 설정이 복잡하고 모바일 환경에서 제약이 있습니다.
  • SSL/TLS VPN(OpenVPN): 방화벽 우회가 쉽지만, 사용자 공간에서 동작하여 성능 오버헤드가 있습니다.
  • WireGuard: 4,000줄의 코드, 고정된 암호 조합, 1-RTT 핸드셰이크로 단순함과 성능을 확보했습니다.
  • Split Tunneling: 트래픽을 선별적으로 VPN을 통과시켜 보안과 성능 사이의 균형을 잡습니다.
  • Zero Trust와 ZTNA: VPN의 암호화된 터널 위에 접근 제어 레이어를 추가하는 방향으로 변화하고 있습니다.


세 흐름이 같은 방향을 가리킵니다. 코드는 40만 줄에서 4,000줄로, 터널은 전체 트래픽에서 필요한 트래픽만으로, 접근 범위는 네트워크 전체에서 개별 애플리케이션으로 좁아졌습니다.

단순할수록 검증할 수 있고, 검증할 수 있을수록 안전합니다. 단순하고 검증 가능한 VPN은 그 위에 인증과 접근 제어를 쌓아올리는 기반입니다.


관련 글

시리즈

Tags: OpenVPN, SSL VPN, VPN, WireGuard, Zero Trust, 네트워크

Categories: ,

관련 문제