[Network] PN과 VPN

728x90

PN

PN(Private Network, 사설 네트워크)은 보안성을 위해 물리적으로 통제 가능한 네트워크로, 쉽게 말해 인터넷과 분리되어 외부 접근이 불가능한 폐쇄망이다.

예를 들어, 서울에서 운영 중인 서버에는 회사 기밀 자료가 있어서 외부에서 접근하지 못하도록 보안이 강화된 LAN 즉, PN을 구축해둘 필요가 있다.

그런데 문제는 PN으로 인해 회사원이더라도 물리적인 위치가 다른, 예를 들면 제주도와 같은 지역에서는 회사 네트워크에 접근할 수가 없다는 것이다. (PN의 장점이자 단점)

이를 해결하기 위해서 접근하고자 하는 위치에 ‘PN을 물리적으로 직접 구축’할 수도 있을 것이다. 보통은 직접 땅파고 회선을 연결할 수는 없으니 ISP에 비용을 지불하여 PN 구축을 위탁할 수 있다. ISP가 전국에 구축한 회선 중 몇 개를 빌려 우리 회사만의 PN을 구축하는 형태이다.

하지만 이는 매우 비용이 비싸고 네트워크 속도도 느리다는 단점이 있어 매우 비효율적이다.. 그래서 이를 극복하고자 등장한 방법이 VPN(Virtual PN)이다. VPN은 공용 네트워크(예: 인터넷) 상에 암호화된 사설 네트워크를 구현하여, 물리적으로 분리된 네트워크와 동일한 보안성과 프라이버시를 제공하는 기술이다, 여기서 ‘Virtualization’은 물리적인 네트워크를 가상적으로 확장하거나 모방한다는 의미이다. 외부망인 인터넷에서 흐르고 있는 데이터에 암호화를 취하여 일반인들이 해당 데이터를 봐도 식별하지 못하도록 보안성을 강화한다.

IPSec VPN

앞으로 설명할 VPN은 IPSec VPN이다. IPSec(IP Security)은 네트워크 계층에서 보안 기능을 제공하는 프로토콜로, 데이터 무결성, 기밀성, 인증, 재전송 방지 등의 보안 서비스를 제공한다. IPSec은 다양한 프로토콜로 구성되어 있으며, 주요 유형은 다음과 같다.

ISAKMP
- 역할
  - IPSec에서 보안 연결(Security Association, SA)을 설정하고 관리하기 위한 프로토콜
  - IPSec에서 사용되는 암호화 알고리즘, 인증 방식, 키 교환 방법 등을 협상한다.
- 세부 사항
  - IKE (Internet Key Exchange)라는 프로토콜을 통해 구현된다.
  - IKE는 두 단계로 작동한다
    - Phase 1: ISAKMP SA를 설정하여 두 장치 간에 보안 채널을 생성
    - Phase 2: 데이터 전송에 사용할 IPSec SA를 설정
- 주요 기능
  - 상호 인증
  - 암호화 키 교환
  - 암호화 알고리즘 및 인증 방식 협상
AH (Authentication Header)
- 역할
  - 데이터의 무결성과 송신자 인증을 보장한다.
  - 패킷의 변조 여부를 확인하지만, 암호화는 수행하지 않는다.
- 특징
  - IP 패킷 전체(헤더와 페이로드)를 보호하지만, IP 헤더의 가변적인 필드(예: TTL, 체크섬)는 제외된다.
  - 데이터의 신뢰성을 보장하지만 기밀성을 제공하지 않음.
- 헤더 추가 구조
  - AH는 기존 IP 패킷에 새로운 헤더를 추가한다. 이는 다음과 같은 정보를 포함:
    - Sequence Number: 재전송 공격 방지
    - Integrity Check Value (ICV): HMAC을 통해 데이터 무결성 검사
- 사용 사례: 암호화가 필요 없고, 데이터 변조 방지만 중요한 경우
ESP (Encapsulation Security Payload)
- 역할
  - 데이터에 기밀성, 무결성, 송신자 인증을 제공
  - 패킷의 페이로드를 암호화하여 데이터의 비밀성을 보장
- 특징
  - 페이로드와 일부 트레일러를 암호화
  - 선택적으로 무결성과 인증 기능 제공 (HMAC 사용)
- 헤더 추가 구조
  - ESP 헤더는 다음을 포함
    - Security Parameters Index (SPI): 어떤 SA와 연결되어 있는지 식별.
    - Sequence Number: 재전송 공격 방지.
    - Encrypted Payload: 암호화된 데이터.
    - Authentication Data: 무결성 보장 정보.
- 사용 사례: 데이터의 기밀성과 무결성이 모두 필요한 경우
IKE (Internet Key Exchange)
- 역할
  - ISAKMP의 구현으로, IPSec 통신을 위해 필요한 키 교환과 SA(Security Association) 설정을 처리합니다.
- 세부사항
  - IKE는 두 장치가 서로를 인증하고, IPSec에서 사용할 암호화 키를 안전하게 교환하는 과정을 자동화.
  - IKEv1과 IKEv2 버전이 있으며, IKEv2는 더 빠르고 안정적임.
- 작동 방식
  - Phase 1: 안전한 제어 채널 생성 (ISAKMP SA).
  - Phase 2: 데이터 암호화 및 인증에 사용될 SA 설정.
- 사용 사례: IPSec 터널 설정을 간소화하고 보안을 강화.

IPSec 동작 모드

ISAKMP, AH, ESP는 아래 두 가지 모드에서 작동한다.

Transport Mode
- 원본 IP Header를 그대로 사용하고, Payload(데이터 부분)만 암호화
- 별도의 Outer IP Header가 추가되지 않음
- G-to-E 연결에서 사용될 수 있지만, 이는 사설 네트워크 내부의 특정 애플리케이션 연결에 적합함
- 주로 엔드포인트의 공인 IP가 노출되어도 무방한 경우에 사용
Tunnel Mode
- 원본 패킷(헤더 + 데이터)을 전체 암호화하여 보호
- 새 Outer IP Header가 추가되어 인터넷 상의 통신을 안전하게 처리
- G-to-G 또는 G-to-E 모두에서 사용되며, 특히 공인 IP 주소가 노출되면 안 되는 경우 선호됨
- 일반적으로 VPN 클라이언트를 사용하는 원격 접속 환경(G-to-E)에서는 Tunnel Mode가 사용됨

여기서 ‘터널링(Tunneling)’이란, 네트워크에 흐르는 데이터를 암호화해서 식별할 수 없게 만드는 것이다. 터널링이란 말 그대로 서로 다른 두 구간을 터널을 뚫듯이 연결해주는 것이다. 그리고 여기서 암호화의 대상인 데이터는 ‘패킷’이다. IPSec 프로토콜이 IP 주소를 활용하고, IP 주소를 식별자로 하는 네트워크 계층에서의 데이터 단위가 패킷이기 때문이다.

이 때, 어떤 것들 간의 구간을 연결(터널링)하냐에 따라 2가지 유형으로 나뉜다. 터널링 시, ‘패킷’이 어떻게 변화하는지 주목하자.

VPN은 IPSec 외에도 PPTP, L2TP, OpenVPN, SSL VPN 등 다양한 방식이 있다. 여기서는 IPSec만 알아보도록 하자!

GtoG (Gateway-to-Gateway)

G는 라우터나 공유기와 같은 GW 서버를 의미한다. 즉, GtoG는 GW들 간 VPN 터널링을 수행하는 것이다.

제주도에 있는 PC(PC 1)에서 PN이 구축되어 있는 서울의 DB 서버에 접근하는 상황이라 생각하자. 이는 다음과 같은 단계를 거쳐 수행된다.

<터널 수립 단계(IKE Phase 1 & Phase 2) >

이 단계에서는 두 게이트웨이(GW) 사이에 안전한 통신 경로(VPN 터널)를 설정한다.

IKE Phase 1: 게이트웨이 인증 및 초기 연결 설정: 제주도 지사의 GW(IP: 3.3.3.1)와 서울 본사의 GW(IP: 5.5.5.1)는 IKE Phase 1을 통해 서로를 인증한 후, 두 GW 간에 초기 보안 연결(Security Association, SA)이 수립된다.
- 이때, 인증 방법으로는 사전 공유 키(PSK)나 디지털 인증서를 사용한다.
- Diffie-Hellman 키 교환 방식으로 암호화 키를 안전하게 생성한다
- 두 GW는 서로 사용할 암호화 알고리즘(AES/3DES), 해시 알고리즘(SHA-256/MD5) 등을 협상한다.
IKE Phase 2: IPSec 터널 설정: 실제 데이터를 전송할 때 사용할 구체적인 암호화 설정을 협상하고, IPSec 터널을 생성한다. 이제 데이터를 암호화하여 안전하게 전송할 준비가 완료된다.
- Phase 1에서 협상한 SA를 기반으로 두 GW는 구체적인 암호화 및 인증 설정을 정의한다.
- IPSec의 Transport Mode나 Tunnel Mode를 선택한다. 이때, GtoG 방식에서는 주로 Tunnel Mode가 사용한다.
- 암호화 키가 최종적으로 공유된다.

<실제 데이터 전송 단계>

패킷 생성: PC 1은 인터넷에 연결되어 있는 제주도 지사의 GW로 요청을 보낸다. 이 때의 패킷 정보는 다음과 같다.
- 출발지: 3.3.3.10 (PC 1의 IP 주소)
- 도착지: 5.5.5.5 (서울 본사의 DB 서버 주소)
제주도 지사의 GW에서 암호화 및 터널링: 제주도 지사의 GW에서 서울 본사의 GW로 패킷을 보내는 순간 터널링 기술이 적용된다. 다음과 같은 과정을 거쳐 터널링 기법을 적용하고 암호화된 패킷을 전송한다.
1. ’Outer IP 헤더’라는 것을 새롭게 하나 생성하여 패킷에 추가하는 기법이다. Outer IP 헤더에는 출발지가 제주도 지사의 GW 서버의 IP 주소인 3.3.3.1이, 도착지엔 서울 본사의 GW 서버의 IP 주소인 5.5.5.1이 적혀있다. Outer IP 헤더는 패킷을 인터넷을 통해 목적지 GW로 라우팅하는 데 사용된다.
2. 패킷에서 Outer IP 헤더를 제외한 나머지 부분을 모두 암호화 시킨다. 즉, 원본 패킷 전체(원래의 IP 헤더와 페이로드)가 암호화되고, 여기에 새로운 IP 헤더(Outer IP 헤더)가 추가
3. 제주도 지사의 GW는 인터넷을 통해 암호화된 패킷을 서울 본사의 GW(5.5.5.1)로 전송한다. 인터넷 상에서는 패킷의 Outer IP 헤더(3.3.3.1 → 5.5.5.1)만 보이며, 데이터 내용은 암호화되어 외부에서 확인할 수 없다.
서울 본사의 GW에서 복호화: 패킷이 서울 본사 GW에 도착하면 Outer IP 헤더를 제거하고 IPSec Tunnel Mode로 암호화된 부분은 복호화한다. 그러면 서울 본사의 GW에서 보고있는 패킷에 들어있는 출발지, 도착지 정보는 각각 3.3.3.10, 5.5.5.5이다. 이후 복호화된 원본 패킷은 최종 목적지인 서울 본사의 DB 서버(5.5.5.5)로 전달된다. 이렇게 해서 결국 PC 1은 제주도에 있지만 서울에 있는 DB 서버에 접근할 수 있게 된다.

요약하자면 다음과 같다.

IKE Phase 1: 제주도 GW와 서울 GW가 인증 및 암호화 설정을 협상하여 보안 연결을 수립합니다.
IKE Phase 2: IPSec 터널이 설정되고, 데이터 암호화 방식(Tunnel Mode)을 결정합니다.
데이터 전송:
- 제주도 GW에서 패킷에 Outer IP 헤더를 추가하고 원본 패킷을 암호화하여 서울 GW로 전송합니다.
- 서울 GW에서 암호화된 패킷을 복호화하고 최종 목적지로 전달합니다.

GtoG는 기업의 여러 지사 간 통신에서 특히 유용하며, 라우팅 및 네트워크 트래픽 제어가 핵심이다. 그러나 GtoG는 엔드포인트와의 개별적인 암호화는 수행하지 않으므로, VPN 클라이언트와 연계된 경우에만 안전하다.

GtoE (Gateway-to-Endpoint)

GtoE(Gateway-to-Endpoint) 방식의 VPN은 게이트웨이(Gateway)와 엔드포인트(Endpoint, 사용자 PC) 사이에 VPN 터널을 설정하여 데이터를 안전하게 전송하는 방식이다. 이 방식은 사용자가 원격지에서 회사의 내부 네트워크(Private Network, PN)에 접근할 때 주로 사용된다. 제주도 지사 직원이 울릉도에 있는 상황에서 본인의 노트북(PC 99)으로 서울 본사 PN에 접근하고 싶을 수 있다. 이때의 접근 단계는 다음과 같다.

<터널 수립 단계>

VPN 클라이언트 설치 및 초기 설정: 원격지에 있는 사용자(울릉도의 PC 99)는 VPN 클라이언트 소프트웨어를 설치한 후, 이를 실행하여 제주도 지사의 GW(3.3.3.1)에 연결한다.
- VPN 클라이언트는 회사 내부 네트워크에 접근할 수 있도록 GW와 통신을 수행한다
- 사용자는 클라이언트에 회사에서 제공한 인증 정보(예: 사용자 계정, 인증서 등)를 입력한다.
IKE Phase 1: 사용자와 GW 간 초기 연결 설정: PC 99와 제주도 지사의 GW 간에 인증 및 신뢰 관계를 설정하고, 초기 보안 연결(Security Association, SA)을 설정한다.
- 이때, 인증 방법으로는 사전 공유 키(PSK)나 디지털 인증서를 사용한다.
- Diffie-Hellman 키 교환 방식으로 암호화 키를 안전하게 생성한다
- 두 GW는 서로 사용할 암호화 알고리즘(AES/3DES), 해시 알고리즘(SHA-256/MD5) 등을 협상한다.
IKE Phase 2: IPSec 터널 설정: PC 99와 제주도 GW 간에 데이터를 암호화하고 인증할 수 있는 IPSec 터널을 생성한다. 이로써 PC 99와 제주도 GW 간에 데이터 전송이 이루어질 준비가 완료된다.
- IKE Phase 1에서 협상한 SA를 기반으로 PC 99와 제주도 지사의 GW는 IPSec 설정을 협상한다.
- 암호화 키가 최종적으로 공유된다.
가상 IP 주소 할당: 제주도 GW는 PC 99에 회사 내부 네트워크와 동일한 가상 IP 주소(예: 3.3.3.50)를 할당된다. 결과적으로, PC 99는 내부 네트워크 자원(예: 서울 본사의 DB 서버)에 접근할 수 있게된다.
- 이 IP는 회사 내부 네트워크의 주소 범위에 속합한다(예: 제주도 지사의 네트워크 범위: 3.3.3.0/24).
- 이를 통해 PC 99는 물리적으로 울릉도에 있지만, 네트워크 상에서는 제주도 지사의 내부 네트워크에 연결된 것처럼 동작한다.

이때 중요한 것은, 터널링의 주체가 공유기가 아닌 [울릉도 노트북 - 제주도 지사의 GW]라는 것이다. 이유는 터널링은 VPN 클라이언트와 VPN Gateway 간에 암호화된 세션을 형성하는데, 공유기는 이 세션을 이해하거나 관리하지 않으며, 공유기는 단순히 암호화된 데이터 패킷을 라우팅하는 역할만 수행할 뿐, 터널링의 주체가 아니다.

<데이터 전송 단계>

패킷 생성: PC 99(가상 IP: 3.3.3.50)는 서울 본사의 DB 서버(5.5.5.5)에 접근하려는 요청을 생성한다. 생성된 패킷의 정보는 다음과 같다.
- 원본 출발지 IP: 3.3.3.50 (PC 99의 가상 IP 주소)
- 원본 목적지 IP: 5.5.5.5 (DB 서버의 IP 주소)
VPN 클라이언트의 처리: VPN 클라이언트는 패킷을 인터넷에 바로 보낼 수 없으니 IPSec Tunnel Mode를 통해 패킷의 IP 헤더와 Payload 전체를 암호화하고, 새로운 Outer IP 헤더를 추가(터널링)한다.
- Outer IP 헤더 출발지 IP: 울릉도의 공유기 외부 IP (예: 9.9.9.1)
- Outer IP 헤더 목적지 IP: 제주도 GW의 IP (예: 3.3.3.1)
- 암호화된 데이터: (원본 IP 헤더 + 데이터)
울릉도 공유기의 처리: PC 99는 현재 울릉도의 인터넷 회선(예: KT 인터넷)을 공유기로 연결하여 외부망에 연결되어 있다. 패킷은 이 울릉도의 공유기(IP: 9.9.9.1)를 거쳐 인터넷으로 전송된다.
- VPN 클라이언트가 이미 출발지 IP를 공인 IP로 설정했으므로, NAT는 수행되지 않는다. 이 경우 공융기는 단순히 패킷을 라우팅한다
제주도 GW의 처리: 울릉도에서 전송된 패킷이 제주도 GW(3.3.3.1)에 도착하면,
- Outer IP Header를 제거하고, 암호화된 데이터 부분을 복호화하여 원본 패킷을 복원한다.
- IPSec Tunnel Mode를 사용하여 복원된 패킷(출발지: 3.3.3.50, 목적지: 5.5.5.5)을 다시 암호화하고, 새 Outer IP Header를 추가하여 서울 본사 GW로 전송한다
  - 새 Outer IP 헤더 출발지: 3.3.3.1 (제주도 GW의 IP 주소)
  - 새 Outer IP 헤더 목적지: 5.5.5.1 (서울 본사 GW의 IP 주소)
서울 본사의 GW에서 복호화 및 데이터 전달: 서울 본사의 GW(5.5.5.1)는 패킷의 Outer IP 헤더를 제거한 후, IPSec Tunnel Mode로 암호화된 데이터(Payload와 원본 IP 헤더)를 복호화하여 원본 패킷을 복원한다. 이후 복호화된 패킷을 최종 목적지인 서울 본사의 DB 서버(5.5.5.5)로 전달한다.

이로써 울릉도에 있는 PC 99는 GtoE와 GtoG를 거쳐 서울 본사의 DB 서버로 접근이 가능해진다.