AWS Site-to-Site VPN 구성 및 이해하기 (Openswan 활용)


안녕하세요 베스핀글로벌 클라우드 기술 지원팀입니다.

금번에 소개해드리고 싶은 AWS 서비스는 Site-to-Site vpn 입니다 😉


생각보다 S2S VPN 관련하여 문의가 많이 들어오는데요!! 이번 시간에는 Site-to-Site VPN 개념과 설정 방법에 대해 포스팅해보도록 하겠습니다 🙂




VPN 이란?

공공 인터넷을 통해 가상의 사설 네트워크를 구성하여 프라이빗 통신을 제공하는 기술로 데이터 암호화, 전용 연결 등 여러 보안 요구 사항을 충족할 수 있습니다.

AWS에서 제공하는 관리형 VPN 서비스에는 Site-to-Site VPN , Client VPN이 있습니다.




Site-to-Site VPN

Site-to-Site VPN 이란?

두 개의 네트워크 도메인이 가상의 사설 네트워크 연결을 사용하여 프라이빗 통신을 가능하게 하는 서비스로 표준 IPSec VPN만 지원합니다.

AWS에서 제공하는 Managed 서비스로, 원격 네트워크와 통신할 수 있도록 합니다.



Site-to-Site VPN 구성 요소

S2S VPN 연결을 생성하면 AWS 가상 프라이빗 게이트웨이(VGW) 또는 Transit Gateway와 온프레미스 측 고객 게이트웨이(VPN Device) 사이에 두개의 VPN 터널을 생성합니다.

두 개의 터널은 각각 다른 가용 영역에 터널 엔드 포인트를 가지게 됩니다. (HA)


가상 프라이빗 게이트웨이 (Virtual Private Gateway, VGW)

Site-to-Site VPN 연결에서 아마존 측에 있는 Gateway로 VPC에 연결하는 데 사용되며 VPN 또는 Direct connect와 함께 작동할 수 있습니다.

VPG를 생성하여 S2S VPN 연결을 생성할 VPC에 연결합니다.

(온프레미스의 client gateway ↔ AWS의 VPC Edge에 VGW)



전송 게이트 웨이 (Transit Gateway)

가상 프라이빗 클라우드(VPC)와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 전송 허브.

VPC나 온프레미스등의 네트워크를 단일 지점으로 연결할 수 있습니다.

연결된 네트워크는 다른 네트워크에 연결할 필요 없이 전송 게이트웨이만 연결하면 되므로 관리를 간소화하고 운영 비용을 줄여 줍니다.

간소화된 연결, 단순화된 가시성 및 네트워크 제어 등 장점을 가지는 managed gateway 서비스이며 다양한 VRF가 가능합니다.

전송 게이트웨이의 연결로 Site-to-Site VPN 연결을 생성할 수 있습니다.


VGW vs TGW

  • TGW에서는 여러 라우팅 테이블을 추가할 수 있으므로 더 향상된 라우팅이 가능.
  • TGW는 여러 계정에서 사용이 가능(하지만 단일 리전)
  • VGW는 각 VPC에 연결되지만 TGW는 VPC에 연결되는 것이 아니라 라우팅 테이블을 통해 여러 VPC로 Routing 가능.


VPN 연결 시 VGW  vs TGW

♦️ VPN to VGW

  • 하나의 VPC 당 하나의 VPN 연결이 필요함.


♦️ VPN to TGW

  • 하나의 VPN 연결은 1.25Gpbs
  • 여러 VPC가 있더라도 하나의 Transit gateway만 사용하여 하나의 VPN 연결만 있으면 가능.


고객 게이트웨이 디바이스 (Customer Gateway Device)

Site-to-Site VPN 연결을 위해 고객 측에 설치된 물리적 디바이스 또는 소프트웨어 애플리케이션

사용자 또는 네트워크 관리자가 S2S VPN 연결 작업을 수행하도록 디바이스를 구성해야 합니다.

두 줄은 vpn 연결을 위한 터널

AWS 디바이스 장애 혹은 VPN 연결에 대한 정기 유지 관리 시 두 번째 터널로 자동으로 장애 조치되므로 연결이 끊기지 않습니다.

따라서 고객 게이트웨이 디바이스를 구성할 때 두개의 터널을 구성하는 것이 중요합니다.


고객 게이트웨이 (Customer Gateway, CGW)

온프레미스 네트워크의 고객 게이트웨이 디바이스를 나타내는 AWS에서 생성하는 리소스로 온프레미스의 장비 정보를 지정합니다.

고객 게이트웨이를 생성할 때 디바이스에 대한 정보를 제공합니다.

Site-to-Site VPN 연결에서 Amazon VPC를 사용하려면 사용자가 원격 네트워크(온프레미스)에서 고객 게이트웨이 디바이스 또는 애플리케이션도 구성해야합니다.



VPN 특징

✅ VPN 협상은 항상 고객 게이트웨이 디바이스(클라이언트 측)에서 연결을 시도해야 합니다.

🏷 IKE 2를 사용하면 VGW가 통신 요청자가 될 수 있도록 설정 가능

✅ VPN 터널의 Idle Timeout

VPN 터널 연결 후 터널에 트래픽이 10초 이상 흐르지 않는 경우 해당 터널은 Down 됩니다.

→ 터널 유지를 위해 온프레미스에서 Dead Peer Detect를 설정하거나 ping을 주기적으로 보내도록 합니다.



VPN 트래픽 흐름

🔶 데이터센터에서 AWS로


🔶 AWS에서 데이터센터로

  • 단일 터널을 사용하는 것이 선호됨.
  • VPN 터널 당 1.23 Gbps



VPN 라우팅 옵션

위와 같이 S2S VPN을 생성할 때 라우팅 옵션을 선택하셔야 합니다.

라우팅 옵션은 고객 게이트웨이 디바이스의 제조업체와 모델에 따라 선택할 수 있으며  주로 BGP 를 지원하면 동적으로 선택합니다.

  • 동적 (Dynamic Routing)BGP 라우팅 프로토콜을 사용하여 상대방으로부터 전달되는 네트워크 경로를 자동으로 인지하여 통신 할 수 있다. 즉, 네트워크 정보를 필요할 때마다 수동으로 설정할 필요 없이 동적으로 네트워크 정보를 관리할 수 있다는 이점이 있다.
  • 정적 (Static Routing)사용자가 직접 네트워크 경로에 대해 라우팅을 설정하는 옵션.



실습

IDC 를 AWS 다른 region 에 구성한 뒤, ec2로 openswan 을 설치한 cgw를 만드는 실습을 진행해보겠습니다.

이후 AWS VPC에서 SITE-TO-SITE VPN을 연결하는 실습을 진행합니다.



IDC 구성

임의로 IDC 를 구성해보았다. 오레곤 region에 openswam을 설치한 customer gateway device를 생성 하여 구성하였습니다.

  • Region : 오레곤


VPC 생성

  • name : hanna-idc-vpc
  • CIDR : 10.60.0.0/16
  • 테넌시 : Default


subnet 생성

Public subnet


Private subnet


routing table 생성 및 서브넷 연결

Public routing table

  • name : hanna-idc-public-rt
  • 0.0.0.0/0 → IGW


Private routing table

  1. routing table 생성
  2. 서브넷 연결
  • name : hanna-idc-private
  • 10.50.0.0/16 → IDC CGW EC2의 eni


Internet Gateway 생성

IDC VPC의 Public subnet 전용 인터넷 게이트웨이를 생성합니다.

  1. 인터넷 게이트웨이 생성
  2. VPC에 연결

  • name : hanna-idc-IGW


라우팅 테이블 편집

Public subnet routing table 편집

public subnet에 IGW를 추가합니다.


CGW 인스턴스 생성

인스턴스 생성


보안그룹 생성

Openswarm 은 udp 4500 포트 사용

PING을 위해 ICMP를 허용하였으며, 터미널 접속을 위해 SSH Port 역시 열어두겠습다.


eip 연결


인스턴스 접속 후 openswan 설치

public subnet에 있는 ec2에 cgw를 구성하기 위함.

sudo su -
yum install -y openswan


/etc/sysctl.conf 파일을 수정하고, network를 다시 시작한다.

# vi /etc/sysctl.conf
 
net.ipv4.ip_forward=1
 net.ipv4.conf.all.accept_redirects = 0
 net.ipv4.conf.all.send_redirects = 0
 net.ipv4.conf.default.send_redirects = 0
 net.ipv4.conf.eth0.send_redirects = 0
 net.ipv4.conf.default.accept_redirects = 0
 net.ipv4.conf.eth0.accept_redirects = 0
 net.ipv4.conf.ip_vti0.rp_filter = 0
 net.ipv4.conf.eth0.rp_filter = 0
 net.ipv4.conf.default.rp_filter = 0
 net.ipv4.conf.all.rp_filter = 0
 
# systemctl restart network 


Private subnet에 EC2 생성

해당 EC2는 VPN 구성 테스트를 위한 용도이다.

보안 그룹은 SSH와 ICMP만 허용


라우팅 테이블 편집

Private subnet의 라우팅 테이블 편집

이후 생성 할 VPN의 VPC CIDR과 방금 전 public subnet에 생성한 CGW EC2의 ENI를 설정합니다.

(대상 → 네트워크 인터페이스 → hanna-idc-public)



AWS 측

Site-to-Site vpn을 생성하여 고객 IDC와 연결을 맺는 AWS측 구성. Seoul 리전에 구성하였습다.


VPC 생성

  • name : hanna-aws-vpc
  • CIDR : 10.50.0.0/16


Subnet 생성


라우팅 테이블 생성


서브넷 연결


인터넷 게이트웨이 생성


VPC 연결


ec2 생성




Site-to-Site VPN 연결

고객 게이트웨이 생성 (CGW)

  • 이름 : hanna-cgw
  • 라우팅 : 정적 (static)
  • ip 주소 : idc cgw 의 eip
  • 나머지는 설정하지 않아도 됩니다.


가상 게이트웨이 생성 (VGW)

VGW 생성 후 → vpc 에 연결


Site-to-Site vpn 연결 생성

  • 앞서 만들어 둔 가상 프라이빗 게이트웨이와 고객 게이트 웨이를 입력합니다.
  • 라우팅 옵션 : 정적
  • 정적 IP 접두사
    • 10.60.0.0/16 (IDC의 VPC CIDR을 입력한다)

생성이 완료되면 사용가능 상태가 되지만, 터널 모두 작동 중지 상태인 것을 확인할 수 있습니다.

터널을 UP 하기 위해서는 CGW에 구성을 따로 해주어야 한다.


라우팅테이블 설정

AWS VPC의 public subnet의 라우팅 테이블에서 라우팅 전파를 활성화 시켜주어야 합니다.

site-to-site vpn을 생성하기 전에 vgw 생성만 완료하고 라우팅 전파를 해줘야합니다.

만약 vpn 을 생성하고 라우팅 테이블을 설정하면 라우팅 테이블 설정이 변경되지 않으며 tunnel 이 올라오지 않습니다.

라우팅 테이블의 idc vpc와 관련된 규칙은(맨 아래) 이후 자동으로 업데이트 됩니다.


구성 다운로드

본격적으로 터널을 구성하기 위한 작업입니다.

site-to-site vpn 을 선택하여 맨 왼쪽 위의 구성 다운로드를 선택하여 다운받으시길 바랍니다.



IDC VPC의 CGW에서 구성

구성 다운로드 파일로 CGW 설정

aws.conf 파일 생성

# vi /etc/ipsec.d/aws.conf
 
conn Tunnel1
     authby=secret
     auto=start
     left=%defaultroute
     leftid=52.42.3.179
     right=3.34.222.44
     type=tunnel
     ikelifetime=8h
     keylife=1h
     phase2alg=aes128-sha1;modp1024
     ike=aes128-sha1;modp1024
     # auth=esp
     keyingtries=%forever
     keyexchange=ike
     leftsubnet=<LOCAL NETWORK>
     rightsubnet=<REMOTE NETWORK>
     dpddelay=10
     dpdtimeout=30
     dpdaction=restart_by_peer

HTML

구성 파일을 다운로드하면 .txt 파일로 다운되어 안에 위와 같은 정보와 구성 방법이 안내 되어 있습니다.

먼저 openswan을 설치한 cgw ec2의 /etc/ipsec.d/ 폴더에 aws.conf 와 같이 뒤에 .conf 로 끝나는 설정 파일을 생성하여 위의 내용을 복사 붙여 넣기 합니다.

‼️ 주의할 점

✅ leftid, rightid는 구성파일에 적혀있으므로 고대로 복사하면 되지만, leftsubnetrightsubnet 은 입력해야합니다.

  • leftsubnet : IDC VPC CIDR (10.60.0.0/16)
  • rightsubnet : AWS VPC CIDR (10.50.0.0/16) 즉, S2S VPN 을 생성한 곳.

✅ openswan 사용 시 구성 파일을 그대로 복붙하면 아마 터널이 작동되지 않을 것입니다. 구성파일에서 "auth=esp" 이 부분을 제거해주면 됩니다.


aws.secrets 파일 생성

/etc/ipsec.d/aws.secrets
 
**52.42.3.179 3.34.222.44: PSK "hanna_tunnel1"**

HTML

.secrets 로 된 파일을 생성하여 구성 파일에 있는 Pre-shared key 값을 복사 붙여넣습니다.


openswan(ipsec) 서비스 재시작

systemctl status ipsec.service
systemctl start ipsec.service
systemctl enabel ipsec.service

HTML

# ipsec status
 000 Total IPsec connections: loaded 1, active 1

HTML

위와 같이 출력되면 제대로 터널이 up 된 것입니다.

[ec2-user@ip-10-60-0-134 ~]$ sudo netstat -nptul
 Active Internet connections (only servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
 tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      2477/rpcbind
 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3094/sshd
 tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      2892/master
 tcp6       0      0 :::111                  :::*                    LISTEN      2477/rpcbind
 tcp6       0      0 :::22                   :::*                    LISTEN      3094/sshd
 udp        0      0 127.0.0.1:4500          0.0.0.0:*                           17823/pluto
 udp        0      0 10.60.0.134:4500        0.0.0.0:*                           17823/pluto
 udp        0      0 0.0.0.0:951             0.0.0.0:*                           2477/rpcbind
 udp        0      0 127.0.0.1:500           0.0.0.0:*                           17823/pluto
 udp        0      0 10.60.0.134:500         0.0.0.0:*                           17823/pluto
 udp        0      0 0.0.0.0:68              0.0.0.0:*                           17406/dhclient
 udp        0      0 0.0.0.0:111             0.0.0.0:*                           2477/rpcbind
 udp        0      0 127.0.0.1:323           0.0.0.0:*                           2507/chronyd
 udp6       0      0 :::951                  :::*                                2477/rpcbind
 udp6       0      0 ::1:500                 :::*                                17823/pluto
 udp6       0      0 fe80::5b:2bff:fe6b::546 :::*                                17453/dhclient
 udp6       0      0 :::111                  :::*                                2477/rpcbind
 udp6       0      0 ::1:323                 :::*                                2507/chronyd

HTML

4500 port에서도 정상적으로 서비스가 실행되는 것을 확인할 수 있습니다.


결과 확인

터널이 정상적으로 올라온 것을 확인할 수 있습니다.

베스핀 글로벌 고객 기술지원 홈페이지에는 더 많고 유용한 솔루션들이 있으니 접속하여 확인해주시면 감사드겠습니다 🙂


댓글 남기기