VPN 변경 계기

개발망에 vpn을 사용하고 있긴 한데, 보안이 약한 레거시 프로토콜을 사용하고 있었다. PPTP와 L2TP이다.

PPTP는 사실상 프로토콜 자체가 뚫렸다고 보는 수준이다. MS-CHAPv2 인증은 오프라인 공격으로 빠르게 크랙 가능하고, 사용하는 RC4/MPPE 등도 현대 기준 취약하다.

L2TP는 암호화를 제공하지 않는 터널링 프로토콜이라, 단독으로는 트래픽이 평문이다. 따라서 “VPN”이라고 부르긴 해도 보안은 거의 없는 수준이라 반드시 IPsec과 같이(L2TP/IPsec) 써야 의미가 있다. 개발망에서는 L2TP를 2차 인증 수단을 함께 사용하고 있었다.

개발망은 격리 되어있기도 하고, 애초에 위의 프로토콜을 이미 계속 사용하고 있었어서 관성처럼 사용하고 있었다. 원래는 PPTP
프로토콜만 사용하고 있었고, LT2P를 사용하기 시작한 것도 내가 적용하고 나서 사용하기 시작하게 했다.

기존 vpn 프로토콜들은 보안 문제도 있었고 외부에서 개발을 하게 될 때 불편한 점들이 있었다. 라우터에서 해당 프로토콜들은 헤어핀 처리를 안 해줘서 기존 소스대로 개발을 할 수가 없었다. (필요한 소스들이 모두 공인ip 주소로 되어있음) 그래서 외부 개발 시에는
vpn + vpn 용 properties를 따로 만들어서 개발할 수 있도록 했다.

팀원들 사이에서 개발 이외의 작업들을 외부에서 진행하기를 원하는 수요들이 있었다. 팀뷰어나 애니데스트를 사용하고자 했었는데, 지원을 해주지 않아서 사용하기 어려운 상황이었다. 업무망에서 개발망에 붙을 수는 있어서 업무망과 개발망 사이에 터널을 만들어서 외부 - 개발망 - 업무망 접속 테스트를 진행했고, 결과적으로 원격 업무를 수행할 수 있었다.

문제는 보안인데, 터널을 뚫어놓았을 때 개발망이 뚫리면 업무망에 위험해지는 것이 문제라 생각됐다. 개발망은 방화벽 처리가 잘 되어있었지만, vpn은 다른 문제였다. 기존 프로토콜들은 보안상 좋지 않아서 모두 vpn 서버 자체를 종료하고 wireguard로 대체했다. wireguard는 보안도 최상위고 속도도 빠르고 헤어핀도 잘 작동돼서 최적의 vpn이었다.. 또한 vpn 서버 자체가 있는지 외부에서 알 수 없기 때문에 보안상 이점도 더 크다.

단점은 프로그램을 설치해야 된다는 것인데, 현재 구조에서 wireguard 사용 시 이점이 훨씬 많다고 판단되어 이정도는 불편한 것도
아니라 생각됐다. 운영체제에 구애 받지 않아서 오히려 편하다고 생각됐다.

VPN 종류와 특성

VPN의 목표

VPN(Virtual Private Network)의 목표는 크게 네 가지다.

1. 기밀성 (Confidentiality) – 중간에서 패킷을 훔쳐봐도 내용을 알아볼 수 없도록 암호화

2. 무결성 (Integrity) – 누가 패킷을 중간에서 바꾸지 않았다는 보장 (HMAC, MAC, AEAD 등)

3. 인증 (Authentication) – 패킷을 보낸 쪽이 진짜 의도한 상대인지 확인 (키, 인증서, 계정 등)

4. 재전송/재생 공격 방지 (Anti-replay) – 옛날 패킷을 다시 보내서 시스템을 속이지 못하게 시퀀스 번호, nonce 등으로 방지

VPN터널

원래 네트워크 패킷을 다른 패킷 안에 통째로 캡슐화(encapsulation) 해서, 마치 두 지점이 같은 사설망에 있는 것처럼 보이게 만드는 동작

VPN의 종류

1. IPsec

1-1. 개념 & 역사

• IPsec(Internet Protocol Security): IP 레벨(L3)에서 동작하는 보안 프로토콜 스위트.

• 원래 IPv6의 필수 보안 기능으로 설계되었고, 현재는 IPv4/IPv6 둘 다에서 사용.

• 1990년대 초·중반 미국 NRL, SDNS 프로젝트 등에서 나온 L3 암호화 아이디어가 기반이고, 1995년 1세대 RFC(1825~1829), 1998년 2세대(RFC 2401), 2005년 3세대(RFC 4301, 4303, IKEv2)로 표준이 정리됨.

핵심 포인트:

IPsec은 하나의 프로토콜이 아니라, 아래 것들을 묶은 보안 프레임워크야.

• AH (Authentication Header) – 인증/무결성/anti-replay 제공 (요즘은 거의 안 씀)

• ESP (Encapsulating Security Payload) – 암호화 + 인증/무결성/anti-replay 제공 (실전은 거의 ESP 위주)

• IKE/IKEv2 (Internet Key Exchange) – 키 교환 및 Security Association(SA) 협상

1-2. 동작 구조 (보안 원리 + 터널링 과정)

(1) SA(Security Association)와 정책

• 양 끝단은 “어떤 트래픽을 IPsec으로 보호할지”를 보안 정책( SPD )으로 정의.

• 실제로 암호화/인증에 사용하는 알고리즘, 키, 수명 등은 SA(Security Association)에 저장.

• SA는 “단방향”이라 송신/수신 방향 각각 별도의 SA를 가짐.

(2) IKE 핸드셰이크

IKEv2 기준:

1. INIT 교환

   • 양 끝단이 서로 지원하는 암호 알고리즘, DH 그룹 등을 주고받고, Diffie-Hellman으로 공유 비밀키를 만든다.

2. AUTH 교환

   • 이 공유 비밀 기반으로 서로를 인증 (PSK, X.509 인증서, EAP 등).

   • 이때 IPsec SA(ESP용)를 생성하고, 사용될 세션 키, SPI 등을 확정.

3. 이후 필요할 때 재키 교환(rekey)로 Perfect Forward Secrecy 유지.

(3) ESP 캡슐화 구조

ESP는 IP 패킷에 다음을 붙여서 송신.

• ESP Header (SPI, Sequence Number)

• 암호화된 Payload (원래의 IP 페이로드 또는 전체 IP 패킷)

• ESP Auth (무결성 체크값, AEAD 사용 시는 암호화에 포함)

전송 모드 vs 터널 모드

• 전송 모드(transport mode):

  • 원래 IP 헤더는 그대로 두고, TCP/UDP 페이로드만 ESP로 감싼다.

• 터널 모드(tunnel mode):

  • 원래 IP 패킷 전체를 ESP로 감싸고 새 IP 헤더를 하나 더 씌운다.

  • VPN 게이트웨이(라우터)끼리 사이트-투-사이트 VPN할 때 대표적으로 사용.

보안 원리 정리

• 기밀성: AES-GCM, ChaCha20-Poly1305 같은 대칭키 암호로 제공.

• 무결성/인증: HMAC-SHA, AEAD(GCM, ChaCha20-Poly1305) 등으로 제공.

• anti-replay: ESP Sequence Number + 윈도우 기반 재전송 방지.

• PFS: IKE에서 매 세션마다 새 Diffie-Hellman 키 협상.

1-3. 보안 정도 & 특징

• 현대 설정(AES-GCM/ChaCha20, IKEv2, 큰 DH/ECDH 그룹, 짧은 SA 수명)에서는 아주 강력한 보안 제공.

• 단점은

  • 프로토콜이 복잡하고

  • 설정이 어려워서

  • “잘못 설정된 IPsec”이 실제 보안 사고의 원인이 되기도 한다는 점.

2. GRE (Generic Routing Encapsulation)

2-1. 개념 & 역사

• GRE: “아무 네트워크 프로토콜이나, 다른 프로토콜 안에 싸서 보내기 위한 일반적인 캡슐화 프로토콜” (RFC 2784)

• 2000년 RFC 2784로 표준화.

• IP 안에 다시 IP, 또는 IP 안에 다른 L3 프로토콜(IPX, MPLS 등)을 넣는 식으로 L3 over L3 터널을 만드는 데 쓰임.

2-2. 동작 원리 & 터널링

• 양 끝단에 GRE 터널 인터페이스를 만들고, 그 인터페이스를 통해 들어오는 패킷을 GRE 헤더 + 바깥쪽 IP 헤더를 붙여서 반대편으로 전송.

• 반대편은 GRE 헤더와 바깥 IP 헤더를 벗기고, 원래 패킷을 내부 라우팅에 넘김.

중요: GRE는 ‘캡슐화’만 해준다.

• 암호화 X

• 인증 X

• 무결성 X

그래서 실전에서는 “GRE + IPsec” 조합이 자주 나온다고 함.

• GRE로 라우팅/멀티캐스트/동적 라우팅 프로토콜들을 하나의 터널 위에 싣고 그 GRE 패킷 전체를 IPsec ESP로 암호화해서 보안 확보.

2-3. 보안 정도

• GRE 자체만 보면 보안은 0 (그냥 터널링).

• 반드시 IPsec 같은 암호화/인증 프로토콜과 같이 써야 한다고 보면 됨.

3. L2TP (Layer 2 Tunneling Protocol)

3-1. 개념 & 역사

• L2TP는 PPP, L2F, PPTP 계열의 터널링 기술을 통합/개선한 “2계층 터널링 프로토콜”.

• RFC 2661 (1999)에 표준화.

• 목적:

  • PPP 세션을 IP망 위로 터널링해서, ISP/기업망에서 “가상 다이얼업(VPDN)” 같은 걸 구현.

3-2. 동작 원리 & 구조

• 용어:

  • LAC (L2TP Access Concentrator) – 사용자의 접속을 받아서 터널 쪽으로 보내는 쪽

  • LNS (L2TP Network Server) – 터널의 반대편, 실제 PPP 세션을 종단하는 쪽

• L2TP는 UDP 위에서 동작하고,

  • Control 메시지 (터널/세션 설정, 유지, 종료)

  • Data 메시지 (PPP 프레임 실어 나름)

    로 나뉨.

• 실제 사용자 인증/주소 할당 등은 터널 안의 PPP 프로토콜이 담당 (PAP/CHAP, RADIUS 연동 등).

중요: L2TP 자체는 암호화를 제공하지 않는다.

• L2TP는 “PPP 프레임들을 잘 터널링하는 역할”만 하고,

• 기밀성/무결성/인증은 외부 암호 프로토콜, 보통 IPsec에 맡김.

3-3. L2TP/IPsec (실전에서 쓰는 조합)

IPsec + L2TP 조합의 일반 흐름

1. IPsec SA 협상 (IKE) – UDP 500 (그리고 NAT-T 시 4500)

2. ESP(transport mode)로 양 끝 사이에 보안 채널 수립 (IPsec만으로는 아직 L2 터널은 아님)

3. 그 채널 안에서 L2TP 터널 설정 – L2TP는 UDP 1701 사용하지만, 실제 패킷은 ESP로 감싸져 있어 중간 라우터는 1701을 볼 수 없음.

4. 이후 PPP 세션이 L2TP 터널 안을 흐르고, 이 전체가 IPsec로 암호화되어 전송.

3-4. 보안 정도

• L2TP 단독 → 암호화 X, 보안 거의 없음.

• L2TP/IPsec → 보안은 사실상 IPsec 수준 (강력).

4. PPTP (Point-to-Point Tunneling Protocol)

4-1. 개념 & 역사

• 1990년대 중반, 마이크로소프트가 중심이 되어 만든 초기 Windows VPN 프로토콜.

• PPP 프레임을 GRE + TCP 제어 채널로 터널링.

• Windows 95/NT 시절에 “클릭 두 번으로 VPN”을 만들 수 있게 해줬던 바로 그 프로토콜.

4-2. 동작 원리

• 제어 채널: TCP 1723

• 데이터 채널: GRE 캡슐화로 PPP 프레임 전송.

• 암호화: PPP 위에서 MPPE(Microsoft Point-to-Point Encryption) 사용.

• 인증: 대부분 MS-CHAPv1/v2 사용.

4-3. 보안 문제

핵심 부분...

• MS-CHAPv2는 디자인 상 심각한 취약점이 있어서, 1회의 캡처로 오프라인 브루트포스 공격이 가능하고, 사실상 하나의 56bit DES 키를 크랙하는 것과 비슷한 수준으로 공격 가능하다고 평가됨.

• 실제로 2012년 MS Security Advisory 2743314에서도 PPTP + MS-CHAPv2 조합을 사용하는 VPN이 취약하다고 경고했고, 다른 프로토콜로의 전환을 권고함.

4-4. 보안 정도

• 오늘날 보안 커뮤니티의 컨센서스:

  • “PPTP는 사실상 깨졌다”에 가깝고,

  • 새로운 시스템을 설계할 때 절대 쓰지 말라는 수준.

• 단지 “속도만 빠르고 설정이 쉬웠던 옛날 유물” 정도로 볼 수 있다고 한다.

5. OpenVPN

5-1. 개념 & 역사

• 2001년부터 개발된 오픈소스 VPN 데몬.

• IPsec처럼 L3에 깊이 박힌 게 아니라, 유저 공간에서 동작하는 TLS 기반 VPN.

• 설계 철학:

  • SSL/TLS(OpenSSL)를 최대한 활용해서

  • 방화벽, NAT, 프록시 환경에서도 잘 동작하는 유연한 터널 제공.

5-2. 구조 & 동작 원리

OpenVPN은 크게 제어 채널(TLS)과 데이터 채널(대칭키)로 나뉜다.

1. TLS 핸드셰이크 (제어 채널)

   • 클라이언트와 서버가 TLS로 서로 인증(서버 인증서, 클라 인증서 또는 계정+TLS 등)

   • 이때 세션 키, HMAC 키 등 데이터 채널에 쓸 각종 키를 교환.

   • 선택적으로 tls-auth, tls-crypt로 추가 HMAC/암호화 레이어를 더해 DoS/포트스캔 방어.

2. 데이터 채널

   • 실제 데이터는 AES-256-GCM 같은 강력한 대칭키 암호 + HMAC 또는 AEAD 로 보호.

   • UDP 또는 TCP 위에서 동작 (보통 성능 때문에 UDP 선호).

3. 터널 인터페이스

   • OS에 TUN/TAP 가상 인터페이스를 만들어서 그 인터페이스로 들어오는 IP(또는 이더넷) 프레임을 OpenVPN이 캡슐화해서 보내고, 반대편에서 복원.

5-3. 보안 원리

• 기밀성: TLS + 대칭키 암호 (AES, ChaCha20)

• 무결성/인증: TLS MAC/AEAD + 자체 HMAC(tls-auth/tls-crypt)

• 서버/클라이언트 인증: X.509 인증서 기반 구조, 또는 계정 + TLS 조합.

5-4. 보안 정도

• 현대 설정 (TLS 1.2/1.3, AES-GCM, 충분히 긴 키, 인증서 기반)에서는 매우 높은 보안성.

• 장점:

  • 오픈소스·광범위한 코드 검증

  • 방화벽 통과 능력 (TCP/UDP 포트 자유 선택)

• 단점:

  • WireGuard에 비해 코드베이스가 크고 구조가 복잡해서

  • 설정 실수 가능성이 좀 더 있고, CPU 부담/성능도 비교적 덜 효율적.

6. WireGuard

6-1. 개념 & 역사

• 2018년경부터 본격적으로 알려진 신세대 VPN 프로토콜.

• Linux 커널에 직접 통합될 정도로 설계가 깔끔하고, Windows/macOS/모바일 포팅도 활발.

• 목표:

  “더 빠르고, 더 단순하고, 더 안전한 OpenVPN/IPsec 대체제”

6-2. 암호 설계(보안 원리)

WireGuard의 특징은 “암호 알고리즘 선택을 고민할 필요가 없게 만들어버린 것”에 가깝다.

• 키 교환: Curve25519(ECDH)

• 암호화: ChaCha20-Poly1305(AEAD)

• 해시: BLAKE2s

• 키 도출: HKDF

• 프로토콜: Noise IK 기반 핸드셰이크

중요한 포인트:

• 선택지를 늘리는 대신, 검증된 최신 알고리즘 몇 개만 고정해서

  • 설정 오·남용을 막고

  • 코드도 작고 검증 가능하게 만들었다는 점.

코드라인도 약 4천 줄 정도라서, 이론상 숙련된 개발자 한 명이 전체를 리뷰할 수도 있는 수준.

6-3. 동작 원리 & 터널링

1. 각 노드는 “고정 공개키/비밀키 쌍”을 가진다.

2. 상대 노드의 공개키를 알고 있어야 연결이 가능 (일종의 “정적 피어 리스트”).

3. 처음 데이터 패킷을 보내려 할 때, Noise 핸드셰이크를 수행해

   • 에페메럴 키 교환 (Curve25519)

   • 세션 키 도출 (HKDF)

   • Perfect Forward Secrecy 보장.

4. 이후에는 UDP 패킷 안에 ChaCha20-Poly1305로 암호화된 L3 패킷을 싣고,

   양쪽 WireGuard 인터페이스에서 IP 패킷을 주고 받는 구조.

OS 레벨에서는 그냥 새로운 IP 인터페이스(예: wg0) 가 생기고, 거기에 라우팅을 얹는 느낌.

6-4. 보안 정도 & 특징

• 현대 암호학 관점에서 아주 높은 보안성 + 심플한 디자인.

• 선택 가능한 알고리즘이 항상 최신·강력한 것들로 강제된다는 점도 장점.

• 코어 코드가 작아서

  • 공격 표면이 작고

  • 구현 버그 검토도 상대적으로 용이.

7. 보안 정도 비교 & “가장 강력한 VPN은 무엇인가?”

7-1. “보안”을 어떻게 볼 것인가?

VPN 보안은 크게 두 축으로 봐야 한다고 함:

1. 암호 설계 자체의 강도

   • 사용하는 알고리즘이 충분히 안전한지

   • 프로토콜 설계가 현대 크립토 분석을 견디는지

2. 현실 세계에서의 안전성

   • 설정이 복잡해서 사람이 실수하기 쉬운가?

   • 코드가 너무 커서 구현 취약점이 많을 가능성이 큰가?

   • 오래된 클라이언트/장비들이 약한 스위트로 협상할 위험이 있는가?

이 관점으로 보면 대략 이렇게 정리할 수 있어.

7-2. 프로토콜별 보안 레벨 요약

(순수 프로토콜 관점에서, 현대 설정을 기준으로)

1. WireGuard

   • 최신 암호 알고리즘만 사용 (ChaCha20-Poly1305, Curve25519, BLAKE2s)

   • 프로토콜이 단순하고 코드베이스가 작아서 설정 실수/구현 취약점 가능성도 상대적으로 적음.

   • 아주 높은 수준의 기밀성·무결성·인증·PFS.

2. IPsec (특히 IKEv2 + ESP-AES-GCM/ChaCha20)

   • 다소 복잡하지만, 표준화/검증이 오래되었고,

     강력한 알고리즘을 선택하면 보안 자체는 WireGuard에 필적할 정도로 매우 강력.

   • 단, 잘못된 설정(낡은 알고리즘, 잘못된 정책)이 들어갈 여지가 커서 운영 난이도가 변수.

3. OpenVPN (최신 TLS + 강력한 cipher)

   • TLS 1.2/1.3 + AES-GCM 등 사용 시 보안성은 역시 최상급.

   • 코드가 크고 유연성이 높아서, 설정에 따라 강도가 천차만별일 수 있음.

4. L2TP/IPsec

   • 실제로는 “IPsec 위에 L2TP를 얹은 구조”라서, 보안은 사실상 IPsec 수준.

   • 설계가 조금 복잡하고, NAT 환경에서의 설정이 까다로워 실수 여지가 있음.

5. GRE

   • 암호화/인증 없음, 순수 터널링.

   • IPsec과 조합하면 상관없지만, GRE 단독으로는 보안이 없다고 보면 됨.

6. PPTP

   • MS-CHAPv2 취약점 등으로 인해, 오늘날 기준으로는 사실상 깨진 프로토콜로 취급.

   • 새 설계에서 사용하면 안 되는 수준.