나에겐 항상 가장 어려운 네트워크...

AWS를 다루면서.. 아니 그 이전부터 항상 네트워크를 이해하는데 어려움이 많았다.
특히 클라우드에서 네트워크란 더더욱 이해하기 어렵고 감이 잘 오지 않아 늘 공부를 하겠다고 마음을 먹는다 😂

그래서 이번에는 가장 나를 괴롭히던 VPN에 대해 공부한 내용을 적어보았다!!
고객들에게 문의도 많이 들어오던 서비스라 기초부터 탄탄히 해야할 필요성을 느꼈다.

참고한 책은 "따라하며 배우는 aws 네트워크 입문" 이 책이며 진짜 설명도 너무 잘 나오고, 실습도 잘되어 있어서 굉장히 만족했다.
뿐만 아니라 다양한 블로그들을 참고하여 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

구성 요소에 대해 공부하면서 문득 VGW 와 TGW 를 사용하는 차이점에 대해 궁금해졌다.

요약하자면,

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

VPC가 많을 때는 TGW를 사용하는 것이 훨씬 효율적인 것 같다.
VGW 와 TGW를 사용한 S2S VPN 통신 과정은 아래와 같다.

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)

사용자가 직접 네트워크 경로에 대해 라우팅을 설정하는 옵션.

---

Site-to-Site VPN 실습

IDC 를 AWS 다른 region 에 구성한 뒤, ec2로 openswan 을 설치한 cgw를 만든다.

이후 AWS VPC에서 SITE-TO-SITE VPN을 연결하는 실습을 해본다.

(실습은 책 "따라하며 배우는 aws 네트워크 입문" 을 참고하였습니다. )

IDC 구성

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

• Region : 오레곤

VPC 생성

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

subnet 생성

Public subnet

• CIDR : 10.60.0.0/24

Private subnet

• CIDR : 10.60.1.0/24

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 생성

• CIDR : 10.50.1.0/24

라우팅 테이블 생성

서브넷 연결

인터넷 게이트웨이 생성

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 이 올라오지 않는다.

(이거 때문에 계속 ec2에서 구성을 했는데 터널이 올라오지 않았었다.. s2s vpn 과 rt를 삭제하고 다시 생성하였다. 확실한 방법인지는 모르겠으니 만약 다른 원인이였다면 알려주세욧..🙏🏻)

라우팅 테이블의 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

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

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

📍 주의할 점

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

• 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

# 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에서도 정상적으로 서비스가 실행되는 것을 확인할 수 있다.

결과 확인

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

마치며...

생각보다 구성하는 것은 어렵지 않았다.(완전 고생했던건 안비밀...ㅎㅎ) 하지만 직접 운영 환경에 도입하면 꽤나 장애가 많이 발생하던데 trouble shooting을 하기 위해서는 여러 사례를 접하고 정리해보도록 해야겠다.
아직 아키텍처를 그리지 않았는데, 다음부터는 아키텍처를 그리고 실습을 구성하는 연습을 해야겠다.
client vpn 과 Transit gateway까지 얼른 공부해봐야겠다!!