지난 문서에서 SSL VPN의 정의와 구성 그리고 SSL 프로토콜이 VPN에서 어떻게 사용되었는지 살펴봤습니다. SSL VPN은 외부 인터넷에 접속한 사용자가 기업과 같은 내부 네트워크에 접속해야 할 경우에 많이 사용되는 VPN이라고 말씀드렸었죠. 이번 문서에서는 사용자가 SSL VPN에 접근하기 위해 사용하는 방법(with SSL 인증서)과 터널 생성 과정(접속 과정) 그리고 패킷 전달 과정에 대해 알아봅니다. 이 문서에서 알아보는 내용이 SSL VPN의 활용과 트러블슈팅에 매우 중요한 부분이기 때문에 자세히 알아두는 것이 좋습니다.
VPN 접근 방법 & SSL 인증서
먼저 살펴볼 것은 사용자가 SSL VPN에 접근(접속)하는 방법입니다. 앞서 SSL VPN 쉽게 이해하기 #1에서 SSL VPN은 SSL(TLS) Protocol을 이용해 SSL Handshake, 다시 말해 데이터를 암호화할 방법과 데이터를 암호화할 키를 마련하고 암호화 통신을 실시한다고 말씀드렸죠. 이를 위해서는 먼저 SSL VPN에 접근하는 것이 필요합니다. SSL VPN에 접근하는 보편적인 방법은 2가지가 있는데 하나는 HTTP, Web을 통해 접속하는 것이고 하나는 Client(이하 클라이언트)를 설치하는 것입니다.
1. Web(이하 웹)을 통한 접속
먼저 웹을 통한 접속입니다. 웹을 통한 접속은 말 그대로 Web Page(이하 웹페이지)를 통해 SSL VPN에 접근하는 방법입니다. SSL VPN의 IP와 연동한 도메인 네임을 입력하고 SSL VPN에 접근한 후, 자신의 사용자 정보를 이용하여 VPN에 접속합니다. 웹을 활용한다는 것은 HTTP 활용을 의미하기 때문에 HTTP에 암호화 통신 과정(SSL)을 더한 HTTP Over SSL(HTTPS)를 사용하여 접속하게 됩니다. 사용자는 웹페이지(SSL VPN)에 접속하는 과정에서 SSL VPN에 게재된 SSL 인증서를 검증하고 이 VPN이 진짜인지 가짜인지 구별합니다. 그리고 자신에게 주어진 ID, Password 등을 입력하여 자신을 증명하고 SSL VPN에 접속하게 되죠. 보통 아래 화면과 같이 말입니다.
2. Client 설치
Client(이하 클라이언트) 설치를 통한 접속은 말 그대로 SSL VPN으로부터 클라이언트 설치 파일을 다운로드하여 클라이언트를 통해 SSL VPN에 접속하는 방법입니다. 설치받은 클라이언트에 SSL VPN의 도메인 주소(보통 Server의 Domain 혹은 IP를 입력)를 입력하여 저장합니다. 그리고 해당 설정을 클릭하는 방식을 통해 활성화하고 SSL VPN에 게재된 SSL 인증서를 검증하고 이 VPN이 진짜인지 가짜인 구별합니다. 마지막으로 사용자 정보를 입력하여 자신을 증명하고 SSL VPN에 접속하죠. 아래 화면과 같이 말입니다.
SSL 인증서
SSL VPN에 접속하는 두 가지 방법을 살펴보면 모두 도메인이 사용된다는 것을 사용되는 것을 볼 수 있습니다. 이는 곧 SSL 인증서를 생성하고 게시하기 위한 목적이 큽니다. SSL 인증서는 SSL 인증서를 게시한 서버, 다시 말해 SSL VPN이 제삼자(Root CA)가 인증한, 검증된 존재임을 증명하기 위한 인증서입니다. 이 인증서를 게시하게 되면 사용자는 SSL 인증서를 가지고 Certificate Authority(CA)에 검증을 요청하고 CA는 이 인증서를 게시한 서버가 검증된 존재임을 사용자에 알려줍니다. 또한 SSL handshake에서 요긴하게 사용됩니다. 자세한 내용은 HTTPS 통신과정 쉽게 이해하기 #1(HTTPS의 개요), HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상), HTTPS 통신과정 쉽게 이해하기 #5(CA, 인증기관)을 참조하세요!
터널 생성 과정(접속 과정)
SSL VPN에 접속하는 방법을 알았으니 이제 과정을 보아야 합니다. SSL VPN의 터널 생성 과정은 곧 사용자의 접속 과정이라고 할 수 있습니다. 사용자가 SSL VPN에 접근하여 SSL 인증서를 통해 VPN을 검증하고 사용자 정보를 입력, SSL VPN으로부터 IP를 할당받고 통신을 준비하는 과정이지요. 아래 그림을 통해서 사용자가 어떻게 IP를 할당받고 SSL VPN 내부의 네트워크와 통신하는지 보도록 하겠습니다.
위 그림에서 사용자(192.168.0.100/24)가 속한 공유기 네트워크 192.168.0.1/24(175.196.211.15)와 SSL VPN(sslvpn.hwanyoung.com, 54.32.16.22, 172.16.10.10/24), 주변 네트워크를 확인할 수 있습니다. SSL VPN은 자신이 가진 공인 IP(54.32.16.22)에 대해 도메인과 도메인을 가지고 Certificate Authority(CA)에 요청하여 만든 SSL 인증서를 보유하고 있습니다. 또 방화벽과 SSL VPN 사이에는 공인 IP로 구성된 링크와 내부 네트워크 통신 목적의 사설 IP로 구성된 링크 각 1개씩이 존재합니다.
사용자는 내부 네트워크와 통신하기 위해 사설 IP와 SSL VPN 내부에 관한 Routing(이하 라우팅)을 할당받고자 SSL VPN에 접속을 시도합니다. 이 때 외부 통신을 위해 공유기가 가진 공인 IP로 Source IP NAT를 실시하고 SSL VPN에 접근합니다. 웹(혹은 클라이언트)을 통해 접속한 사용자는 SSL VPN의 SSL 인증서를 검증하여 SSL VPN이 진짜임을 확인합니다. 그리고 자신의 ID, Password 등을 입력하여 SSL VPN의 승인을 받습니다. 사용자와 SSL VPN이 서로를 검증하는 것을 마쳤으니 이제 사설 IP를 할당합니다.
위 그림에서 보시면 SSL VPN IP Pool(10.10.10.0/24)이 보이실겁니다. IP Pool은 SSL VPN이 사용자에게 할당할 사설 IP 대역을 의미합니다. 공유기 내부에서 사용자가 할당받은 IP와는 별개의 IP로 사용자가 SSL VPN이 할당한 사설 IP를 통해 내부 네트워크와 논리적으로 연결하고 통신하는 데 사용되는 IP입니다. 사용자는 SSL VPN까지 접근하기 위해 공유기가 할당한 사설 IP(공유기가 공인 IP로 Source IP NAT 실시)을 사용하고 SSL VPN 내부에 진입하기 위해 SSL VPN이 할당한 사설 IP로 내부 네트워크의 리소스와 통신하게 됩니다. 이제 사용자가 IP Pool의 사설 IP를 하나 할당받았으니 SSL VPN으로부터 내부 네트워크에 대한 라우팅을 전달받게 됩니다. 아래 그림처럼 말이죠.
1. 공유기의 사설 IP, 공인 IP(Source IP NAT) : SSL VPN 및 공인인터넷 접속 목적의 IP
2. SSL VPN의 사설 IP : SSL VPN 내부 네트워크 통신 목적의 IP
사설 IP와 내부 네트워크에 대한 라우팅을 전달받은 사용자를 표현한 그림을 하나씩 살펴보겠습니다. 먼저 사용자는 SSL VPN이 설정해둔 사설 IP Pool의 IP(10.10.10.100)를 하나 할당받았습니다. 이는 사설 IP 대역으로 이루어진 내부 네트워크와 통신할 때 사용되는 사설 IP입니다. 공유기 네트워크에 속한 사용자는 내부 네트워크 진입 시 실제로는 공인 IP를 통해 Firewall #1에 진입하지만 논리적으로는 자신이 가지고 있는 사설 IP(10.10.10.100)를 가지고 내부 네트워크와 통신하는 것입니다. 마치 사용자의 PC가 네트워크에 속한 것처럼 말이죠. 그리고 라우팅 정보에 변화가 있습니다. 기존에는 외부 인터넷과 통신하기 위한 라우팅만이 존재했다면 이젠 SSL VPN IP Pool의 Gateway IP(10.10.10.1)로 설정된 라우팅이 추가로 생겼습니다.
SSL VPN이 전달해준 라우팅 정보에는 "내부 네트워크의 172.16.10.100/24에 접근하기 위해서 Gateway IP인 10.10.10.1을 Next hop(이하 넥스트 홉)으로 잡을 것(ip route 172.16.10.0 255.255.255.0 10.10.10.1)"이라고 적혀 있습니다. 사용자는 SSL VPN 덕분에 내부 네트워크와 사설 연결한 것처럼 작동할 수 있어 사설 IP를 이용한 라우팅을 통해 사용자가 속한 IP Pool의 Gateway IP를 넥트스 홉 삼아 내부 네트워크로 진입하는 것이지요. 여담으로 대부분의 SSL VPN 벤더에서는 사용자가 속한 IP Pool의 Gateway(이하 게이트웨이)를 잡도록 설정하고 있습니다. 물론 Pulse Secure(Ivanti)처럼 Gateway IP를 "10.200.200.200"으로 고정하는 벤더도 있습니다.
여기까지 보셨다면 한 가지 의문이 드실 겁니다. "SSL VPN을 통해 접속했다면 사용자와 내부 네트워크는 이제 같은 네트워크인데 굳이 할당 IP 대역을 10.10.10.x/24와 같이 다른 대역을 써야 할 필요가 있을까? 172.16.10.x./24로 설정해 주면 되지 않을까?" 하는 생각이 드실 수 있습니다. 결론을 먼저 말씀드리면 이는 실현할 수 없습니다. 앞서 지속적으로 언급한 것처럼 SSL VPN을 통한 접속은 "논리적 연결"입니다. SSL VPN이라는 장비를 통해 마치 내부 네트워크에 속한 것과 같이 작동할 뿐 실제는 사용자가 내부 네트워크에 속한 것이 아닙니다. 이는 MAC 주소를 활용하는 ARP를 통해서도 알 수 있습니다. 사용자의 IP가 내부 네트워크가 같은 대역이라면 사용자의 MAC 주소 또한 공유가 되어야 통신이 가능할 것입니다. 하지만 사용자의 PC는 실제로 외부 네트워크에 존재하기 때문에 ARP를 통해 자신의 MAC을 광고할 수 없죠.
여담으로 SSL VPN이라고 하여 터널을 생성하기 위해 꼭 SSL 프로토콜을 써야 하는 것은 아닙니다. 정확히는 SSL VPN을 인증하기 위해서 SSL 인증서를 사용해야 하지만 패킷 암호화를 위해서 SSL 프로토콜만을 써야 하는 것은 아니라는 뜻입니다. 인증에는 SSL 프로토콜을 사용하더라도 터널 생성에는 IPSec과 같은 프로토콜을 사용할 수 있습니다. 대표적으로 Pulse Secure(Ivanti)가 터널 생성을 위해 IPSec을 쓸 수 있지요.
패킷 전달 과정
이번에는 사용자가 SSL VPN에 접속한 상태에서 어떠한 방식으로 패킷을 전달하는지 보고자 합니다. IPSec VPN만큼은 아니지만 SSL VPN 또한 패킷 전달 과정에 대해 이해하고 있어야 트러블슈팅하기에 좋습니다. 아래 그림은 사용자가 SSL VPN에 접속하여 사설 IP와 함께 내부 네트워크에 대한 라우팅을 할당받은 상황을 표현한 것입니다.
사용자는 SSL VPN으로부터 사설 IP를 할당받고 내부 네트워크로 향하는 라우팅을 전달받은 상태입니다. 그리고 172.16.10.100/24 IP를 보유한 스위치 #1에 접근하고자 합니다. 그럼 사용자는 SSL VPN이 할당해준 사 IP, 10.10.10.100/24를 Source IP 삼아 목적지인 172.16.10.100/24을 향해 나아갑니다. 물론 게이트웨이이자 넥스트홉인 10.10.10.1/24을 경로를 잡게 되죠. 이는 사용자가 보유한 Routing table(이하 라우팅 테이블)에도 잘 나와있습니다.
| 출발지 IP | 목적지 IP | Next hop |
| 10.10.10.100/24 | 172.16.10.100/24 | 10.10.10.1 |
이 패킷을 받아든 SSL VPN은 여타 네트워크 장비처럼 목적지를 확인합니다. 그리고 자신이 보유한 172.16.10.10/24 IP와 같은 대역임을 확인하고 패킷을 172.16.10.100/24에 전달하죠. 아래 그림처럼 말입니다.
여기서 기억해야 할 것은 사용자가 원하는 목적지가 172.16.10.100/24가 속한 내부 네트워크가 아닌 다른 목적지라면 사용자의 라우팅 테이블과 SSL VPN의 라우팅 테이블에 모두 그에 대한 라우팅이 있어야 한다는 것입니다. 가령 내부 네트워크의 스위치 아래 또다른 네트워크가 있고 IP 대역이 172.31.20.0/24이라면 사용자와 SSL VPN의 라우팅 테이블에는 아래와 같은 정보가 있어야겠죠.
| 사용자의 라우팅 테이블 | ip route 172.31.20.0 255.255.255.0 10.10.10.1 |
| SSL VPN의 라우팅 테이블 | ip route 172.31.20.0 255.255.255.0 172.160.10.100 |
| 출발지 | 목적지 | Next hop |
| 172.16.10.100/24 | 10.10.10.100/24 | 172.16.10.10 |
위 그림은 사용자가 전달한 패킷에 대해 스위치가 응답하기 위해 다시 패킷을 사용자에게 되돌려 보내는 과정을 그리고 있습니다. 그렇기에 출발지는 스위치 IP인 172.16.10.100/24를, 목적지는 사용자 IP인 10.10.10.100/24을 지정하고 있죠. 여기서 주의깊게 봐야 할 부분은 목적지입니다. 목적지를 SSL VPN가 사용자에게 할당해준 사설 IP인 10.10.10.100/24을 바라보고 있습니다. 내부 네트워크의 입장에서는 사용자가 사설 네트워크에 속하고 SSL VPN이 할당해준 IP Pool의 사설 IP를 보유하며 자신(내부 네트워크)과 통신하고 있기에 목적지를 10.10.10.100/24로 삼아 응답 패킷을 전송하는 것입니다. IP Pool이라는 특수성을 갖는 SSL VPN의 특징이니 기억해두는 것이 좋습니다.
마지막으로 IPSec VPN와 달리 패킷의 Encapsulation(이하 캡슐화) 과정에서 설명하지 않았는데요. "SSL VPN에 접속하는 과정 / 터널을 생성하여 통신하는 과정"을 설명했지만 시각을 달리하여 보면 서버와 사용자가 SSL이라는 프로토콜을 이용해 암호화 통신을 하는 것(HTTPS를 사용해 사용자와 서버가 암호화된 HTTP 통신을 하는 걸 떠올려보면 되겠죠)이기 때문에 굳이 거창하게 "패킷을 캡슐화하는 과정을 거친다"라는 언급을 하지 않았습니다.
여기까지가 사용자의 SSL VPN 접속 과정과 패킷 전달 과정입니다. SSL VPN에 접속한 사용자의 라우팅 테이블이 어떻게 변화하는가에 대해 다루었지만 사실 내용에 부족한 부분이 있습니다. 위에서는 일부 내부 네트워크에 대한 라우팅이 추가되는 과정에 대해 설명했지만 실제 SSL VPN 운영 환경에서는 위와 같이 단순하게 구성되지 않습니다. 이를 설명하기 위해서는 Split Tunneling에 대한 설명이 필요합니다. 다음편에서 부족한 내용을 보강함과 더불어 Split Tunneling과 SSL VPN의 정책 설정과 라이센스에 대해 다루겠습니다.
'Network Infra 쉽게 이해하기 > VPN 쉽게 이해하기' 카테고리의 다른 글
| SSL VPN 쉽게 이해하기 #3 (8) | 2023.05.06 |
|---|---|
| SSL VPN 쉽게 이해하기 #1 (15) | 2023.01.01 |
| IPSec VPN 쉽게 이해하기 #4 (20) | 2021.09.12 |
| IPSec VPN 쉽게 이해하기 #3 (10) | 2021.08.21 |
| IPSec VPN 쉽게 이해하기 #2 (6) | 2021.08.07 |
댓글