재택근무 중 팀원이 회사 내부 API 서버에 접근해야 합니다. 포트를 외부에 열어두기엔 보안이 걱정되고, VPN을 도입하자니 IPsec과 SSL VPN 중 무엇을 선택해야 할지 모르겠습니다. 각 방식이 어떻게 동작하고 어떤 상황에 적합한지 알아야 인프라 설계에서 올바른 선택을 할 수 있습니다.

확대

VPN의 기본 원리

VPN(Virtual Private Network)은 공용 인터넷 위에 암호화된 터널을 만들어 마치 전용 회선처럼 사용하는 기술입니다. 카페 Wi-Fi에서 회사 DB에 접속한다고 생각해보세요 — 패킷이 평문으로 전송되면 네트워크 위의 누구나 내용을 볼 수 있습니다. VPN은 이 구간을 암호화해서 공용 인터넷을 통과하면서도 내부망에 직접 연결된 것처럼 동작하게 합니다.

확대

IPsec VPN

IPsec(Internet Protocol Security)은 **L3(네트워크 계층)**에서 동작하며, IP 패킷 자체를 암호화합니다.

• 동작 모드
  • Transport 모드: 페이로드만 암호화 (호스트-to-호스트)
  • Tunnel 모드: 전체 IP 패킷을 새 IP 헤더로 캡슐화 (네트워크-to-네트워크)
• 프로토콜
  • AH (Authentication Header): 무결성 인증만
  • ESP (Encapsulating Security Payload): 암호화 + 인증
• 키 교환: IKE (Internet Key Exchange) — UDP 500번 포트

IPsec의 특성을 한눈에 정리하면 언제 선택해야 하는지 판단 기준이 명확해집니다.

SSL/TLS VPN (OpenVPN)

SSL VPN은 **TLS(전송 계층 보안)**를 사용하여 암호화 터널을 구성합니다. OpenVPN은 가장 널리 사용되는 오픈소스 SSL VPN입니다.

확대

SSL VPN 특징:

IPsec vs SSL VPN 비교

.ovpn 파일을 실행하면 몇 초 뒤 Initialization Sequence Completed가 뜨고 사내망에 붙습니다. 이 짧은 사이에 클라이언트와 VPN 서버는 서로를 인증하고 → 키를 교환해 → 암호화 터널을 세우고 → 어떤 대역을 터널로 보낼지 라우팅을 잡고 → 실제 패킷을 캡슐화해 주고받습니다. 이 순서를 알면 "어디서 연결이 멈췄나"(인증? 키 교환? 라우팅?)를 단계로 좁힐 수 있고, 뒤에 나올 Zero Trust가 왜 "터널을 믿는 것" 자체를 문제 삼는지도 분명해집니다.

[클라이언트]  sudo openvpn --config client.ovpn
   │
   ① 인증          클라이언트가 인증서(또는 ID·키·MFA)로 신원 증명
   │                 서버도 자기 인증서로 신원 증명 (상호 인증)
   │
   ② 키 교환        IKE(IPsec) 또는 TLS handshake로 세션키 합의
   │                 → 개인키 없이도 도청자는 세션키를 못 계산
   │
   ③ 터널 수립      가상 인터페이스 생성 (tun0 · wg0), 이후 전 구간 암호화
   │                 → "Initialization Sequence Completed"
   │
   ④ 라우팅 설정    "어느 대역을 터널로 보낼지" 결정
   │                 OpenVPN push route · WireGuard AllowedIPs · 내부 DNS
   │
   ⑤ 캡슐화 전송    원본 패킷을 암호화해 UDP/TCP로 감싸 서버로,
   │                 서버가 복호화해 내부망에 전달 (응답은 역순)
   ▼
[회사 내부망]  사내 API · DB에 전용선처럼 접근

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 "VPN이 안 붙는다"는 이 다섯 단계 중 어디서 멈췄는지의 문제입니다 — 인증서 문제면 ①, 서버에 아예 못 닿으면 ②(포트 차단), tun0은 떴는데 큰 데이터만 끊기면 ③(MTU), IP는 되는데 특정 대역·이름만 안 되면 ④(라우팅/스플릿 터널·DNS)로 좁혀집니다. openvpn --verb 6이나 wg show의 handshake·전송 바이트가 단계별 로그 역할을 합니다. 그리고 이 다섯 단계가 모두 성공하면 전통적 VPN은 "터널 안은 신뢰" 로 내부망을 통째로 엽니다 — Zero Trust는 바로 그 지점을 문제 삼아, 터널이 섰다는 사실만으로 신뢰하지 않고 리소스에 접근할 때마다 신원·기기·정책을 다시 검증합니다(다음 개념 블록).

VPN으로 내부망에 접속한 직원 계정이 탈취되었습니다. 공격자는 내부망에 진입한 순간 모든 서버에 자유롭게 접근할 수 있었습니다. 내부는 믿는다는 "경계 기반 보안"의 전제가 무너진 것입니다. Zero Trust는 이 전제를 버리고 내부에서도 매번 인증/인가를 요구하는 방식으로, 클라우드 환경에서 점점 표준이 되어가고 있습니다.

확대

전통적인 경계 기반 보안의 한계

확대

문제점:

• 한 번 내부 진입에 성공하면 자유롭게 이동 가능 (Lateral Movement)
• 내부자 위협에 취약 (직원, 계약업체)
• 클라우드/SaaS 환경에서 "내부"의 경계가 모호

Zero Trust 핵심 원칙

"Never Trust, Always Verify" — 절대 신뢰하지 않고, 항상 검증

모든 접속 요청은 정책 엔진을 거쳐 허용/거부가 결정됩니다(위 그림 오른쪽). 정책 엔진은 사용자 신원(MFA), 디바이스 상태(보안 패치·백신), 접속 위치(지리적 이상 탐지), 요청 행위(정상 패턴 여부), 최소 권한(필요한 리소스만)을 매번 검증합니다.

Zero Trust의 5가지 원칙

1. 최소 권한 원칙: 필요한 최소한의 접근 권한만 부여
2. 마이크로 세그멘테이션: 내부 네트워크도 세밀하게 분리
3. 다중 인증(MFA): 비밀번호 + 추가 인증 수단 필수
4. 지속적 검증: 세션 중에도 지속적으로 신뢰 검증
5. 암호화: 내부 트래픽도 암호화 (TLS)

NAC (Network Access Control)

NAC는 Zero Trust의 구현 요소 중 하나로, 네트워크에 접속하려는 디바이스를 검증합니다.

확대

VPN 트러블은 대개 '터널이 서느냐(L3)'에 집중하지만, 터널이 정상인데도 이름 해석(DNS) 이 엉키면 내부 서비스에 도메인으로는 못 붙습니다. IP로는 되는데 도메인으로는 안 되는 순간, 문제는 라우팅이 아니라 DNS 경로입니다.

• 터널이 서는 것과 DNS가 터널로 가는 것은 별개입니다: VPN이 연결되면 서버가 내부 DNS 서버와 검색 도메인을 push하지만, 클라이언트가 이를 실제로 적용하는지는 OS·리졸버(systemd-resolved, resolvconf, macOS 등)에 달렸습니다. 적용이 안 되면 클라이언트는 여전히 카페·공용 DNS로 질의해 내부 호스트명을 못 풉니다. 그래서 ping 10.0.0.10(IP)은 되는데 ping intranet.company.com(이름)은 실패합니다.
• split-horizon DNS: 같은 도메인이 외부에선 공인 IP, 내부에선 사설 IP로 응답하도록 갈라진 경우가 많습니다. VPN을 타야 내부 DNS가 사설 IP를 주는데, 질의가 공용 DNS로 새면 공인 IP가 돌아와 내부 방화벽에서 막히거나 엉뚱한 곳으로 갑니다.
• DNS 캐시가 전환을 늦춥니다: VPN 연결 전에 그 도메인을 조회해 공인 IP를 캐시했다면, 연결 후에도 TTL이 살아 있는 동안 캐시된 공인 IP로 붙습니다. '방금 VPN 켰는데 왜 아직 안 되지'의 흔한 원인 — 리졸버·브라우저 캐시가 옛 답을 쥐고 있는 것입니다.
• DNS 누수(leak)는 반대 문제: split tunnel에서 DNS 질의만 공용 리졸버로 새면, 내부 조회가 실패할 뿐 아니라 '어떤 내부 도메인을 찾는지'가 외부에 노출되는 보안·프라이버시 문제가 됩니다. Zero Trust 관점에선 이름 해석 경로도 통제 대상입니다.