GRE over IPSec Tunnel VPN(Site-to-Site) 구축하기

요즘엔 알고리즘이나 개발보다는 솔루션 아키텍트 및 시스템 설계에 대해서 스터디하고 있습니다.

이 본문의 내용을 구축하면 엔터프라이즈간의 네트워크를 연결하여 서로 사설 ip 로 통신하거나,
당신의 사무실과 AWS VPC 망을 연결하여, AWS 인스턴스를 private ip 로 접근할 수 있게 됩니다.

"사무실에서만 접속 가능한 시스템" 같은것을 운영하려고 할 때 좋습니다.
"Security Group 에 등록해서 방화벽 쓰면 되는것 아니냐?" 라고 말할 수도 있는데, 안되게 설정한 것(Security Group 설정)과 불가능(사설ip통신)의 차이라고 보면 됩니다.
또한 중간의 제 3자가 감청을 할 수 있냐 없냐의 차이도 있으며, 보안상으로는 엄청나게 차이가 납니다.

소프트웨어 개발 방법론(https://blog.lael.be/post/125 참고) 중 하나인 주먹구구식 개발(Build and Fix Model)로 만들어진 솔루션이 어느 정도 성공하게 되면, 고도화 작업을 하게 됩니다. (즉 시스템 개편을 해야함. 안하면 유지보수를 할 수 없게됨. 사람의 memory의 한계가 오게 됨.)

이 때 클라우드 서버를 사용 중인 경우 SA(Solution Architect)가 참여하여 전체적인 시스템을 개선하게 됩니다.

이 글에서는 지난번에 작성한 시스템 망분리 설계 방법(https://blog.lael.be/post/9144)에서 더 나아가, 망분리가 된 두개의 사설 네트워크를 VPN 설정을 통해 서로 연결하는 방법에 대해 설명합니다.

패킷 흐름을 제어해야하기 때문에 네트워크의 라우팅 테이블을 수정할 수 있어야 가능한 작업입니다. 그리고 라우터 장비나 라우터 장비 이미지 또는 라우터 소프트웨어가 설치된 인스턴스가 있어야 합니다.

패킷 흐름 제어를 받는 네트워크내의 개별 PC에는 아무런 설정을 변경 할 필요가 없으며, 그냥 평소대로 상대방의 사설 IP를 입력해서 통신하면 됩니다.

< IPSec Tunnel. CISCO ASA 장비를 사용할 경우 >

작은 규모의 기업에서는 이러한 것을 다루지 않지만, 대기업이나 보안이 필요한 기업에서는 필수적으로 사용해야하는 기술입니다.

원거리로 떨어진 여러 지점들을 보안 연결로 이어야 하는 경우나, 내부 직원만 접속해야 하는 사이트를 구성할 때 사용합니다. 이 경우 망분리(외부 망에서는 물리적으로 망내부에 접근할 수 없음)가 완벽히 된 것이며, 망 내의 PC 에서만 망 내의 사이트에 접속할 수 있게 됩니다.
네트워크 관리자를 제외하고, 망내부의 PC는 상대 원거리 지점의 Public IP 를 고려할 필요가 없습니다.

또한 잘 설정하면, 각 클라우드의 고유 서비스를 안전한 개인네트워크로 연결하여 사용할 수도 있습니다. (다음 링크의 설명이 아주 훌륭합니다.)
https://blog.kloud.com.au/2019/03/28/deploy-vpn-tunnel-between-azure-cloud-and-aws-cloud-environment/

이 Site-to-Site VPN을 다루려면 먼저 Subnet, Gateway, Router, SubnetMask, CIDR, Tunneling, GRE, IPSec, Network ACL 이라는 용어에 대해서 이해가 되어 있어야 한다.

또한 망분리 및 관련 서브넷 구성이 완료되어 있다고 가정한다.

즉, 기본적인 네트워크 용어 해석은 따로 하지 않으며, 이미 망분리된 시스템이 있고, 라우팅 장비가 있다고 가정하고 설명하겠다.

먼저 단어의 의미를 알아보도록 하자.

GRE(Generic Routing Encapsulation; 일반 라우팅 캡슐화) : 세계적인 네트워크 장비업체인 CISCO사에서 1994년에 제안한 개념입니다.
라우팅에 관한 정보(다양한 네트워크 통신정보)를 캡슐화 해서, 그 자체를 전송하는 것이다. 보통 Router 간에 이루어지며, 한쪽의 라우팅 패킷 정보는 다른쪽 라우터에 전달 된 후 Decapsulation 된 후에 처리된다.
이 GRE 는 암호화 기능이 없기 때문에(즉, 캡슐내용이 그냥 보임), IPSec 와 함께 사용한다.

IPSec (Internet Protocol Security; 인터넷 프로토콜 보안) : IP패킷을 암호화 및 인증하는 프로토콜이다.

GRE over IPSec Tunnel VPN 은 그 기능으로 인해, Site to Site VPN 이라고 부르기도 한다. 여기서 Site 란 Network망(장소)을 의미합니다.

따라서 이 IPSec 통신을 하기 위해서 알아야 할 것은, 암호화 방법, 인증 방법, 암호화 통신 방법에 대해 알아야 한다.
이 정보는 양쪽 라우터에 동일하게 설정해두어야 한다.

이렇게 구성하는 라우터는 서로 Peer 라고 부른다.
peer 라우터끼리 동등한 자격으로 통신하기 때문에, 어느 기기가 Site-to-Site 클라이언트 기능이 있다면, 그 기기는 당연히 서버 기능도 있는 것이다.

다만 Network 통신에서는 client-client 그런게 있을수 없으니, 어느 하나는 Server 역할을 해야 한다.

Site to Site VPN 에서 Server는 Responder 라고 부르고, Client는 Initiator 라고 부른다.

Responder 역할을 하는 장비는 UDP 500, UDP 4500 포트를 열어두어야 한다. Initiator 는 방화벽 설정이 딱히 필요 없다.
일반적으로는 Initiator 는 보안이 더 중요한 쪽이 맡는다.
망분리가 되어 있고, 또한 외부 방화벽을 열 수가 없고, 외부에서 내부 서버에 접속을 해야 할 때, 내부에 Initiator 를 구성하면, 방화벽을 열지 않았어도 외부->내부 접근이 가능해지고, 안정적으로 통신을 할 수 있게 된다.

Responder 든 Initiator 든 그 장비가 반드시 Public IP 를 가질 필요는 없다. (즉, 게이트웨이 밑의 사설IP 에서 동작도 가능)
물론 양쪽 장비가 Public IP를 직접 가지고 있는 Router 이어도 상관없지만, 나의 생각은 그런 역할의 라우터/방화벽 아래의 사설IP 내의 장비로 구성되기를 권장한다.

실제로 구축하는 방법 (Real World Example)

사무실의 사설망과 AWS 사설망 연결하는 방법.

우선 사무실의 네트워크 장비는 외부에서 IPTIME 공유기로 들어오고, 그 아래에 개별 PC 가 연결된다고 가정합니다.

1. iptime 장비는 EFM ipTIME T3008 유선공유기 이걸 쓰세요. (http://prod.danawa.com/info/?pcode=1533180 7만원 정도)
내부 네트워크는 192.168.99.0/24 로 구성했다고 가정합니다.

2. 내부에 router 장비가 있다고 가정합니다. 라우터 장비는 Synology 라우터 RT2600ac 유무선공유기 이걸 쓰세요. (http://prod.danawa.com/info/?pcode=6527107)

시놀로지 라우터 관리자에 로그인 한 다음, 1만원을 결제하면 site to site vpn 기능이 사용가능하게 됩니다.

3. AWS 에서 VPC 내의 VPN 메뉴로 이동합니다.

AWS 의 VPN 의 경우 연결시간당 0.05$ 청구됩니다. 만들어두고 사용안하면 청구되지 않습니다.

셋다 만들어야 합니다.

Customer Gateway : 위의 1번에서 사용한 사무실의 IPTIME 장비의 IP 를 입력하세요.

Virtual Private Gateways : AWS VPN 과 통신을 주고받을 게이트웨이 입니다. 적당한 이름으로 만들고, 내부 VPC 와 연결해주세요. (Attach to VPC)

Site-to-Site VPN Connection : 실제 VPN 서버를 만드는 메뉴입니다.

생성이 완료되면 정보를 다운받는다.

#1: Internet Key Exchange Configuration

Configure the IKE SA as follows:
- IKE version : IKEv1
- Authentication Method : Pre-Shared Key
- Pre-Shared Key : S0KwkTzvjB1F1Aw_Z0OVLhZ6qnNURtBZ
- Authentication Algorithm : sha1
- Encryption Algorithm : aes-128-cbc
- Lifetime : 28800 seconds
- Phase 1 Negotiation Mode : main
- Diffie-Hellman : Group 2

#2: IPSec Configuration

Configure the IPSec SA as follows:
- Protocol : esp
- Authentication Algorithm : hmac-sha1-96
- Encryption Algorithm : aes-128-cbc
- Lifetime : 3600 seconds
- Mode : tunnel
- Perfect Forward Secrecy : Diffie-Hellman Group 2

- DPD Interval : 10
- DPD Retries : 3

- TCP MSS Adjustment : 1379 bytes
- Clear Don't Fragment Bit : enabled
- Fragmentation : Before encryption

#3: Tunnel Interface Configuration

Outside IP Addresses:
- Customer Gateway : 121.131.72.193
- Virtual Private Gateway : 15.164.18.92

Inside IP Addresses
- Customer Gateway : 169.254.156.154/30
- Virtual Private Gateway : 169.254.156.153/30

Configure your tunnel to fragment at the optimal size:
- Tunnel interface MTU : 1436 bytes

#4: Static Routing Configuration:

Static Route Configuration Options:
- Next hop : 169.254.156.153

AWS 의 Site-to-Site VPN 은 Responder 로만 동작한다. 따라서 위의 정보를 Synology Router 에 입력하고 initiator 로 동작하게 해보자.

설정이 완료되면 AWS VPN 쪽에서 status 가 UP 으로 바뀌고 터널이 뚫린것을 확인할 수 있다.

이제 패킷이 이 터널을 통하도록 양쪽의 라우팅 테이블을 수정해야 한다.

4. 양쪽 라우터 간에 VPN 이 수립되었으니 패킷이 이 Router 를 거치도록 설정하기

1) 먼저 AWS VPC 에서 설정하기

Private Subnet 의 Routing Table 을 수정한다.

직접 라우팅 테이블을 입력해도 되지만, 간편한 전파(Propagation) 옵션이 있으니 사용하면 편리하다. (물론 수동입력 해도 됨)

2) 사무실 네트워크 (IPTime) 에서 상대방의 패킷이 라우터를 향하도록 설정하기

관리자 페이지에 접속 후 라우팅 관련 설정을 해줍니다.

5. 완성 및 테스트

이제 사무실 내부망과 AWS 내부망이 VPN 을 통해 연결되었습니다.

EC2 접속을 테스트 해보겠습니다.

적당히 EC2 를 생성해봅니다.

내부 IP 로 접속해봅니다.

참고로, Security Group 설정할 때에는 Private IP 를 사용하여 설정해야 합니다.

사무실 네트워크(IPTime) 내의 192.168.99.55 IP 를 가진 컴퓨터에서, 저 EC2 Private IP 10.20.30.10 에 접속해 보겠습니다.

이번에는 반대로, EC2 Private IP 10.20.30.10 에서, 사무실 네트워크의 192.168.99.55 PC 에 Ping 을 보내보겠습니다.

네트워크 내부의 PC는 별도의 설정 없이 서로의 Private IP 를 통해 통신할 수 있는 것이 확인되었습니다.
이상 망 분리 보안 통신을 하는 법에 대해 알아보았습니다.

< 위와 같은 통신을 확인하였다 >

끝!

keepalive 와 dead peer detection 이 있는데, 적용하려면 둘 중 반드시 하나만 적용해야 한다고 한다.

keepalive 는 phase 1 동작을 검사하는건데 HELLO 패킷을 주기적으로 보내서 체크하는 것이고 (cisco에서 기본값으로 이것만)

dead peer detection 은 phase 2 동작하는지 검사하는건데 R-U-THERE 패킷을 보낸다고 한다.

다르다는 것만 알겠음. 필수가 아니라고 함.

http://trionet.co.kr/board/bbs/board.php?bo_table=b2&wr_id=2

https://community.cisco.com/t5/security-documents/dead-peer-detection/ta-p/3111324

dpd 는 안하거나, one way 이거나 two way(서로 체크) 일 수 있다.

UDP 4500(NAT의 경우) 포트를 사용하는것 같고, 따라서 방화벽으로 막힌 사용자는 dpd 응답을 보낼 수 없으므로, 그 상대방은 dpd 를 사용하지 말아야 한다. 만약 사용한다면 10초간 3번(dpd 10 3) 실패시 터널 DELETE 명령을 내리게 되고 서로 연결이 끊어지게 된다.

2019-10-15 8:40	charon		05[IKE] <con1000|3> activating new tasks
2019-10-15 8:40	charon		05[IKE] activating ISAKMP_DPD task
2019-10-15 8:40	charon		05[IKE] <con1000|3> activating ISAKMP_DPD task
2019-10-15 8:40	charon		05[ENC] generating INFORMATIONAL_V1 request 241978703 [ HASH N(DPD) ]
2019-10-15 8:40	charon		05[ENC] <con1000|3> generating INFORMATIONAL_V1 request 241978703 [ HASH N(DPD) ]
2019-10-15 8:40	charon		05[NET] sending packet: from 10.20.30.110[4500] to 121.131.72.193[4500] (108 bytes)
2019-10-15 8:40	charon		05[NET] <con1000|3> sending packet: from 10.20.30.110[4500] to 121.131.72.193[4500] (108 bytes)
2019-10-15 8:40	charon		05[IKE] activating new tasks
2019-10-15 8:40	charon		05[IKE] <con1000|3> activating new tasks
2019-10-15 8:40	charon		05[IKE] nothing to initiate
2019-10-15 8:40	charon		05[IKE] <con1000|3> nothing to initiate
2019-10-15 8:40	charon		05[NET] received packet: from 121.131.72.193[4500] to 10.20.30.110[4500] (108 bytes)
2019-10-15 8:40	charon		05[NET] <con1000|3> received packet: from 121.131.72.193[4500] to 10.20.30.110[4500] (108 bytes)
2019-10-15 8:40	charon		05[ENC] parsed INFORMATIONAL_V1 request 2952951223 [ HASH N(DPD_ACK) ]
2019-10-15 8:40	charon		05[ENC] <con1000|3> parsed INFORMATIONAL_V1 request 2952951223 [ HASH N(DPD_ACK) ]

더 알아보기 1)

Site to Site 는 장소간 VPN 을 의미한다. 장소란 Network 를 의미함.

Point to Site VPN 은 우리가 일반적으로 L2TP, PPTP 등을 의미한다. 내 Point 가 상대방의 Network 로 들어가는 것이다.

Point to Point VPN 은 라우터끼리 연결을 맺을 때에만 사용한다.

더 알아보기 2)

IPSec VPN 의 경우 두개의 Phase 가 있음.

이 Phase는 보안통신을 위해 Negotiation 을 하는 것으로 SA(Security Association)이라고 한다.

Phase 1 은 IKE(Internet Key Exchange) SA 를 한다. Phase 1 SA 의 역할은 VPN 을 하기에 정당한 권한이 있는지 검사하는 것을 한다. IP인증, 키인증, 암호화 교환을 한다.
비유하자면 로그인을 하는 것이다. Phase 1 을 통과하지 못하면, Phase 2 로 진행할 수 없다. Phase 1 이 성공하면 SA Life 시간동안 인증된다. 인증시간이 지나면 재 인증해야 한다.
Phase 1 키의 수명은 보통 14400(4시간) 28800(8시간)~ 86400(24시간) 이다.

Authentication — PSK, ID
Encryption — AES 128, SHA 256 hash,
SA Life — 28800(8시간)
Key Group — Diffie-Hellman Group 2(1024 bit)

Phase 2 는 IPSec (Internet Protocol Security) SA 를 한다. 이 단계가 실제로 통신하는 통신암호화 협상이다. Phase 1 Key를 가지고 Phase 2 인증을 협상한다. SSL 이라고 보면 되고 정해진 시간마다 Key를 변경하여 해킹을 막도록 한다. 일반적으로 3600(1시간)마다 키를 재생성(regen)한다. Phase 2 Regen 을 하려고 하는데 Phase 1 키가 만료되었다면 Phase 1 을 다시 맺는다.

여기서는 서로의 subnet 을 교환한다. 또한 protocol 설정한다. (거의 ESP). 암호화 알고리즘과 인증 해쉬를 설정한다. PFS(Perfect Forward Security)를 사용한다면 난수 생성을 위해서 DH 그룹을 선택해야 한다. Phase 2 의 SA Life 를 설정한다.

Type — ESP
Authentication - SHA 256
Encryption - AES 128
Force Key Expiration(SA Key Life) - 3600(1시간)

실제 동작을 지켜봤는데 3600 으로 해두었어도 10분~15분 전에 regen 하여 교체하여 사용하더라. 이 경우 2개의 Phase 2 Key 가 Live 하게 됨.

이것을 Rekey Margin Time 이라고 부르더라.

How long before connection expiry or keying-channel expiry should attempt to negotiate a replacement begin.

더 알아보기 3)

좀 더 많은 상황에 대처하기 위해서 다양한 라우터 설정에 대해 설명하겠다.

1] Strong Swan

Ubuntu 기본 패키지 목록에 있어서 이것을 사용한다.

알다시피 Ubuntu 18.04 LTS 는 2028년까지 10년간 유지보수 이기 때문에, 이 운영체제를 선택하고, 이 운영체제의 기본 패키지 목록에 있는 소프트웨어를 사용하는 것은 유지보수 측면에서도 편리하다.

운영체제에 라우팅 소프트웨어를 설치하여 구동하는 것이다. 가장 도입이 쉽고, Ubuntu 운영체제를 사용하기 때문에 친숙하다. 디버깅이 간편하다.

strongswan 설치

# apt install strongswan

이 소프트웨어를 설치하면 ipsec 관련 명령어 및 기능이 활성화 된다.

ipsec 관련 기능들이 strongswan 과 연결된다.

# service ipsec status 와

# service strongswan status 가 동일하다.

ipsec 명령으로 실행할 것.

# ipsec status

# ipsec statusall

Linux 의 ip forward 기능을 켜야 한다.

** TODO - strong swan 세팅법

2] pfSense

거의 유일한 오픈소스 라우터 소프트웨어이다. Apache 2.0 라이센스이므로 현업에서 사용하기 적합하다.
유명한 네트워크 장비 Netgate 를 만드는 Rubicon Communications 에서 개발, 유지보수 한다.
운영체제에 설치하는 소프트웨어가 아니라, 시스템 product 이미지로 배포하기 때문에 가상화 소프트웨어가 먼저 필요하다.

AWS 의 경우 https://aws.amazon.com/marketplace/pp/B076TCMRWJ 페이지에서 Subscription 이 가능하다.
내가 만약 망 분리 및 망VPN 구축 의뢰를 받는다면 pfsense 를 선택해서 구축하겠다. 왜냐하면 이렇게 훌륭한 웹 인터페이스가 있기 때문이다.