IPSec VPN 쉽게 이해하기 #4

마지막으로 알아볼 IPSec VPN에 관한 이야기는 바로 '패킷의 전달 과정'입니다. 앞선 문서에서는 패킷이 이동하는 터널과 그에 대한 프로토콜만을 알아보았고, 이번 문서에서는 패킷이 실제 어떻게 이동하는지에 대해 상세히 살펴보고자 합니다. 아래 그림에서 보이는 좌측의 'PC 1(10.10.10.10/24)'이 패킷을 전송하면 이 패킷이 VPN의 IPSec Tunnel(이하 IPSec 터널)을 지나 어떻게 우측의 'PC 3(10.10.20.10/24)'으로 전달되는지 확인해보겠습니다.
패킷의 전달 과정은 'IP Header의 변화', '목적지의 변화' 이 두 가지로 나누어 살펴볼 것인데요. 'IP Header(이하 IP 헤더)의 변화'에서는 VPN을 이동할 때 ESP Header(이하 ESP 헤더)가 어떻게 적용되는지를 확인해보고, '목적지의 변화'에서는 패킷이 각 장비를 이동하면서 Next Hop(이하 넥스트 홉)을 어떤 IP로 잡아 이동하는지 확인해보겠습니다. 이 모든 과정은 'Tunnel Mode(이하 터널 모드)'임을 가정하고 설명합니다.

<'PC 1'이 'PC 2'에게 패킷을 전송한다면?>

설명을 시작하기에 앞서 한 가지 짚고 넘어가야 할 중요한 것은 어느 VPN이든 내부에서 사용 중인 사설 네트워크 대역이 어느 VPN의 사설 네트워크 대역과 겹쳐서는 안 된다는 점입니다. 만약 위 그림에서 좌측 VPN이 10.10.10.x/24, 우측 VPN이 10.10.10.x/24 네트워크 대역을 사용한다면 통신이 불가능하게 됩니다. 양측이 서로 같은 네트워크 대역을 사용한다 한들 ARP Request가 VPN을 건너 상대방 VPN으로 넘어갈 수 없기에 상대방 VPN의 네트워크를 알 수 없어 통신에 문제가 발생합니다. IPSec VPN이 Layer 3인 IP 헤더를 이용해 논리적으로 사설망과 사설망을 연결하는 것이지 물리적인 사설망을 구성한 것이 아니기에 ARP Request가 VPN 건너 넘어갈 방법이 없지요. 이를 해결하기 위해 IP Routing(이하 라우팅)을 사용한다면 양쪽 네트워크가 같으니 넘어갈 수 없습니다. 또한 다수의 IPSec 터널이 구성된 환경이라면 위 두 VPN이 아닌 또 다른 VPN에서 10.10.10.x/24 네트워크로 이동하고자 할 때 어느 VPN을 목적지로 잡아야 할지 전혀 알 수 없게 됩니다. 그러므로 라우팅을 통해 상대방 VPN의 네트워크로 이동해야 하며 이를 위해서는 양측 간 다른 네트워크의 사용이 필수적이죠.
예를 들어 좌측 VPN 내 단말이 가진 라우팅 테이블에는 10.10.10.x/24는 분명 로컬 네트워크임을 명시되어있는데 10.10.10.20/24의 IP를 갖는 단말이 다른 VPN 건너편에 있다면 통신이 불가능할 것입니다. IPSec VPN을 사용함에 있어서 이는 대단히 중요한 점이므로 반드시 기억해야 합니다.(물론 NAT를 사용하거나 Subnet Mask를 적절히 조절하는 차선책이 존재하지만 이는 좋은 방법이 아니라고 생각합니다.)
 

패킷 전달 과정 - IP Header의 변화

ESP 헤더 / 터널 모드 사용을 전제로 설명합니다.

본사 _VPN 이하 네트워크인 10.10.10.x/24에 소속된 'PC 1'이 지사_VPN 이하 네트워크인 10.10.20.x/24에 소속된 'PC 2'에 패킷을 전달하고자 합니다. 그러기 위해서는 'PC 1'이 본사_VPN을 거쳐 지사_VPN으로 향해야 하므로 먼저 본사_Switch를 통해 본사_VPN으로 이동합니다. 10.10.10.x/24 네트워크는 Gateway(이하 게이트웨이)가 VPN 하나뿐이기 때문에 'PC 1'과 'PC 2'의 게이트웨이는 VPN으로 지정되어있습니다. 

<'PC 1'에서 출발하여 본사_VPN으로 이동하는 패킷>

이때 IP 헤더는 위 그림과 같습니다. Source IP는 'PC 1' 자신의 IP인 10.10.10.10/24이고 Destination IP는 목적지인 'PC 3'의 IP 10.10.20.10/24입니다. 'PC 1'이 데이터(가즈앗!)가 담긴 패킷의 헤더를 위 그림과 같이 설정한 후 게이트웨이인 본사_VPN으로 전송합니다. 

<IPSec VPN에 의해 암호화된 패킷>

본사_VPN에 의해 패킷이 암호화되었습니다. 위 패킷을 보시면 Origin IP와 데이터가 본사_VPN에 의해 암호화되었고 데이터를 암호화한 것에 해쉬 알고리즘을 적용한 'Auth'도 보이네요. 그리고 공인망을 통해 목적지까지 향하기 위한 New IP가 보이네요. 이제 패킷이 지사_VPN으로 향합니다.

<지사_VPN에서 'PC3'로 이동하는 패킷>

지사_VPN이 본사_VPN으로부터 받은 패킷을 복호화하고 해쉬 알고리즘을 이용해 데이터가 변질되었는지를 확인합니다. 이는 터널 생성과정에서 동일한 대칭키(비밀키)를 획득하였기에 가능하는 것이죠. 패킷을 검증한 지사_VPN이 목적지 IP를 확인하고 'PC 3'에 전송합니다. 그리고 'PC 3'은 패킷을 받고 데이터를 확인합니다.

반응형

패킷 전달 과정 - 목적지의 변화

패킷이 이동하기 위해 Next Hop(이하 넥스트 홉)을 어떻게 지정하는지 설명합니다.

이번에는 패킷의 헤더가 아닌 패킷 전송을 맡은 각 장비가 넥스트 홉을 어느 장비로 잡아 어떻게 이동하는지 보고자 합니다. 현업에서는 패킷의 헤더를 보기보단 장비의 설정과 넥스트 홉을 주로 보며 설정을 하고 장애처리를 하는 데다 IPSec VPN은 Layer 3에서 작동하는 VPN인 만큼 라우팅을 어떻게 하는지를 알아두는 것이 매우 중요합니다. 

<넥스트 홉을 게이트웨이로 잡아 전송하는 'PC 1'>

위에서 말씀드린 것처럼 본사_VPN 이하 네트워크는 외부로 나아갈 통로가 본사_VPN 뿐인지라 넥스트 홉을 게이트웨이로 잡습니다. 패킷을 받은 본사_VPN은 목적지인 지사_VPN으로 이 패킷을 전달할 것입니다. 이때 본사_VPN은 넥스트 홉을 어떻게 잡을까요? 공인 IP를 넥스트 홉으로 잡아 전송할까요? 만약에 VPN에 할당된 공인 IP가 주기적으로 바뀌는 IP라면 그땐 어떻게 해야 할까요? 바뀔 때마다 IP에 맞춰 넥스트 홉 IP를 변경해주어야 할 텐데 이것 또 일인 데다가 바꾸기 전까지는 장애가 발생할 수밖에 없죠. 이러한 점을 감안하기라도 하듯 IPSec VPN에서는 Tunnel IP(이하 터널 IP)를 사용합니다.
터널 IP는 IPSec VPN과 IPSec VPN 사이에서 상대방 VPN을 넥스트 홉을 지정하기 위해 사용하는 IP를 뜻합니다. 터널 내에서 사용하기 위한 혹은 터널을 통해 상대방 VPN을 목적지로 잡기 위한 IP라 '터널 IP'로 부르는 듯합니다. 터널 IP에는 원하는 IP를 사용하여 지정할 수 있지만 일정한 규칙을 있는 IP 대역을 사용하는 것이 좋습니다.(가령 172.16.0.0 ~ 172.16.128.0까지만 사용하기) 또한 터널 IP도 고유해야 하기 때문에 다른 터널 IP와 겹쳐서는 안 됩니다. 예를 들어 AWS의 IPSec VPN에 해당하는 Site to Site VPN에서는 '169.254.0.0/16' 범위에서 '/30'로 지정하여 터널 IP를 사용합니다. 각 터널마다 다른 30비트의 IP를 터널 IP로 사용하며 이 터널 IP를 넥스트 홉으로 잡아 상대방 VPN으로 이동하는 것이죠. 30비트인 이유는 양쪽 VPN 2개를 지정하기 위해서는 IP 2개를 지정할 수 있는 30비트가 가장 적절하기 때문이며 굳이 30비트가 아니어도 됩니다. 아래 그림은 AWS Site to Site VPN의 터널 IP 범위를 설명한 문서의 일부입니다.

<AWS Site to Site VPN의 터널 IP(https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/VPNTunnels.html)>

본론으로 돌아와 예시를 계속 보도록 하겠습니다. 아래 그림에서 본사_VPN과 지사_VPN 모두 터널 IP가 할당되어 있는 것을 볼 수 있습니다. 터널 IP에 172.16.1.0/30을 할당했으며 본사_VPN에는 172.16.1.1/30을, 지사_VPN을 172.16.1.2/30을 지정하고 각각의 IP를 넥스트 홉으로 활용하였습니다.

<지사_VPN의 터널 IP를 넥스트 홉으로 삼아 패킷을 라우팅하는 본사_VPN>

'PC 1'로부터 받은 패킷을 본사_VPN이 이를 지사_VPN에 라우팅하기 위해 넥스트 홉을 172.16.1.2/30로 지정합니다. 이를 구현하기 위해 본사_VPN에는 'ip route 10.10.20.0 255.255.255.0 172.16.1.2'와 같은 라우팅 설정이 들어가 있어야 하겠지요. 

<본사_VPN으로부터 전달받은 패킷을 'PC 3'에게 전달하는 지사_VPN>

본사_VPN으로부터 패킷을 전달받은 지사_VPN이 이를 'PC 3'에게 전달합니다. 그리고 'PC 3'는 이 패킷을 전달받고 데이터를 확인합니다.
여기까지가 IPSec VPN에 관한 이야기입니다. IPSec VPN의 프로토콜과 헤더 그리고 동작 과정, 전달 과정 등을 잘 알아둔다면 수많은 벤더의 VPN뿐만 아니라 클라우드의 IPSec VPN인 Site to Site VPN의 사용과 장애처리에 있어 많은 도움이 될 거라고 생각합니다. 다음 문서에서는 SSL VPN에 대해 다루도록 하겠습니다. 감사합니다.