2.4 Customer Gateway 주소 확인 ( IDC )
2.5 Customer Gateway 생성 ( AWS )
2.6 VGW(Virtual Private gateways) 생성
개요
두 사설망 간의 연결을 위해선 크게 두 가지 방법이 존재합니다.
1. 물리적인 전용선을 설치하여 연결하는 방식
2. 가상의 네트워크 망을 구성하여 연결하는 방식
전용선을 직접 연결하면 다른 이용자에 영향을 받지 않고 빠르고 보다 안정적인 통신이 가능하지만
그만큼 물리적인 연결이 필요하기 때문에 거리가 멀어질수록 회선 비용이 증가하게 됩니다.
대신 VPN(Virtual Private Network)이라는 가상의 통신만을 통해 네트워크를 연결하는 방식을 주로 활용합니다.
이번 포스팅에선 AWS의 Site-to-Site VPN 설정을 위한 과정을 설명합니다.
AWS와 IDC를 구분하기 위해 두 리전(서울-AWS, 오레곤-IDC) 간 환경을 구성하고, IDC에 Openswan을 설치하여 vpn을 위한 설정을 진행합니다.
Openswan이란 리눅스 상에서 구현된 IPSec VPN 오픈소스이며, IPSec VPN에 대한 자세한 내용은 여기를 참고해주세요.
최종 아키텍처는 아래와 같습니다.
환경 구성
아래 github 링크를 통해 HOL에 필요한 환경 구성을 위한 Terraform 코드를 준비합니다.
user@MZC01-WOWJD:~/Terraform_HOL$ git clone https://github.com/aboova/HOL_S2S-VPN.git
Key pair 생성
테라폼 코드 배포 전 미리 key-demo 이름을 가진 Key Pairs를 구성해놓습니다. (두 리전 모두)
Private key file format은 .pem 으로 설정합니다.
서울 리전은 AWS 환경, 오레곤 리전은 IDC 환경이라고 생각하면 됩니다.
user@MZC01-WOWJD:~/Terraform_HOL/HOL_S2S-VPN/terraform_AWS_seoul$ terraform applyuser@MZC01-WOWJD:~/Terraform_HOL/HOL_S2S-VPN/terraform_IDC_oregon$ terraform apply
인프라 아키텍처
위 코드로 인프라 구성 시 아래 아키텍처와 같은 환경 구성이 완료됩니다.
Ping 테스트
아직 VPN 설정이 되지 않았으므로, 동일 리전 간 통신은 가능, 서로 다른 리전 간 통신은 불가능한 상태임을 알 수 있습니다.
이제 HOL을 위한 기본 인프라가 준비됐으니, 아래 과정을 통해 VPN 구성을 진행합니다.
Customer Gateway 주소 확인 ( IDC )
먼저 IDC 측의 서버 IP를 확인합니다.
CGW는 Site-to-Site(이하 s2s) VPN 연결에 필요한 온프레미스 측의 Gateway 디바이스를 나타내는 AWS 리소스입니다.
Oregon 리전의 'Public-IDC-Server'의 퍼블릭 IP를 확인하시면 됩니다.
Customer Gateway 생성 ( AWS )
서울 리전에서 [VPC]-[VPN]-[Customer gateways] 항목에서 새로운 CGW를 생성해줍니다.
[Name tag] 값과 [IP address] 값을 입력해줍니다.
여기서 BGP ASN이란, 각기 다른 오퍼레이터가 관리하는 IP 서브넷을 식별하기 위해 고유하게 부여된 번호인데
이번 실습에선 default로 진행합니다.
VGW(Virtual Private gateways) 생성
[VPC]-[VPN]-[Virtual private gateways] 항목에서 새로운 VGW를 생성해줍니다.
CGW가 IDC를 위한 Gateway라면, VGW는 AWS를 위한 Gateway라고 생각하시면 됩니다.
[Name tag]를 입력하고 ASN은 default로 선택 후 생성을 진행해줍니다.
생성된 VGW를 VPC에 attach 시켜줍니다.
*VGW는 하나의 VPC에만 연결이 가능합니다.
VPN Connection 설정
[VPC]-[VPN]-[Site-to-Site VPN Connections] 항목에서 새 vpn 연결을 생성합니다.
Name tag와 함께 조금 전 생성했던 VGW, CGW를 선택합니다.Static IP prefixes는 IDC의 VPC IP 대역을 입력해줍니다.
- Local IPv4 network CIDR은 VPN을 통해 통신이 가능한 IDC 측의 추가 IP 대역
- Remote IPv4 network CIDR은 AWS 측의 추가 IP 대역을 의미하는데 여기선 default로 설정을 진행합니다.
설정을 완료하고 일정 시간이 지나면 State가 Available 상태로 변경됩니다.
아래 Tunnel details를 확인하면 VPN 터널의 Status가 Down으로 표시돼있는데, 이는 IDC 측의 VPN 장비 설정이 아직 이루어지지 않았기 때문입니다.
VPN 구성 다운로드
[Download configuration]을 클릭하여 vpn 구성에 필요한 정보를 다운받습니다.
[Vendor]를 Openswan으로 변경 후 Download를 클릭합니다.(.txt 파일이 다운로드 됩니다)
AWS 측에서 설정해야 할 작업은 끝났습니다.
이제 VPN 설정을 위해 IDC 측의 서버로 이동하여 필요한 작업을 진행하겠습니다.
Openswan 설치 ( IDC )
IDC(오레곤)의 퍼블릭 서브넷에 위치한 서버에 접속합니다. (Public-IDC-Server)
이미 userdata 스크립트를 통해 서버 구동 시 설치가 완료됐으므로, 해당 과정은 넘어가셔도 됩니다.
(깡통 서버에서 openswan 설치 시 yum -y install openswan 명령어를 사용하시면 됩니다.)
Network 설정
/etc/ipsec.conf 파일에서 include /etc/ipsec.d/*.conf 부분이 주석처리 되어 있지 않은지 확인해줍니다.
만약 주석처리가 되어 있다면 주석을 해제해주시면 됩니다.
[root@ip-10-50-0-41 ~]# cat /etc/ipsec.conf | grep "include /etc/ipsec.d"
include /etc/ipsec.d/*.conf
/etc/sysctl.conf 파일을 확인하여 아래 내용이 기입돼있는지 확인합니다.
(서버 구동 시 userdata를 통해 입력된 상태입니다.)
- net.ipv4.ip_forward를 활성화시킴으로써, 해당 시스템 안에서 커널이 처리하는 패킷에 대하여 외부로 forwarding 가능
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
IPSec 설정
Tunnel 설정
/etc/ipsec.d/ 경로에 aws.conf 파일을 생성하고, vpn connection 생성 후 다운로드 받았던 txt 파일을 클릭합니다.
클릭하면 conn Tunnel1과 conn Tunner2 부분이 있습니다.
아래 표를 참고하여 해당 부분에 필요한 값을 기입해줍니다.
- leftid, right 항목은 각 사용자별 상이하므로 위 캡쳐본의 값과 다를 수 있습니다.
- 암호화 알고리즘의 변경으로 인해 phase2alg, ike 항목을 우측 표와 같이 변경합니다.
- leftsubnet은 IDC의 IP 대역, rightsubnet은 AWS의 IP 대역으로 수정합니다.
- 두 개의 터널에서 동일한 IP 대역을 설정하기 위해선 overlapip=yes 옵션이 필요합니다.
| Before | After |
| phase2alg=aes128-sha1;modp1024 | phase2alg=aes_gcm |
| ike=aes128-sha1;modp1024 | ike=aes256-sha1;modp1024 |
| auth=esp | #auth=esp |
| leftsubnet=<LOCAL NETWORK> | leftsubnet=10.50.0.0/16 |
| rightsubnet=<REMOTE NETWORK> | rightsubnet=10.60.0.0/16 |
| 맨 아랫줄에 overlapip=yes 추가 |
필요한 값을 수정하면 tunnel에 대한 설정은 아래와 같습니다.
...생략
#auth=esp
keyingtries=%forever
keyexchange=ike
leftsubnet=10.50.0.0/16
rightsubnet=10.60.0.0/16
dpddelay=10
dpdtimeout=30
dpdaction=restart_by_peer
overlapip=yes
Secret 값 저장
/etc/ipsec.d/ 경로에 aws.secrets 파일을 생성한 후 .txt 파일을 참고하여 VPN 통신에 필요한 비밀 키를 저장합니다.
(vpn 구성 파일의 5) 항목을 확인하면 됩니다.)
[root@ip-10-50-0-41 ~]# cat /etc/ipsec.d/aws.secrets
44.228.63.198 3.36.136.43: PSK "PqJxLZwOjqpJW9gf6Npxu3qotylhokkS"
44.228.63.198 15.164.186.113: PSK "O1wH8pzOxYCwQVb6FWouOPyzzskfk0n5"
설정을 모두 완료했다면 IPSec 서비스를 재시작시켜줍니다.
[root@ip-10-50-0-41 ~]# systemctl restart ipsec.service
아래와 같이 loaded 2, active 2가 표시되면 터널 구성이 정상적으로 완료된 겁니다.
웹 콘솔에서 터널의 Status가 UP으로 변경된 것을 확인할 수 있습니다.
라우팅 테이블 수정
먼저 IDC 환경의 라우팅 테이블을 수정하겠습니다.현재 라우팅 세팅은 아래와 같습니다.
| Destination | Target | |
|---|---|---|
| Public | 0.0.0.0/0 | igw-0ecf20c7ae6db7d5a |
| 10.50.0.0/16 | local | |
| Private | 0.0.0.0/0 | nat-0d4b912a1d3d4ca89 |
| 10.50.0.0/16 | local |
VPN 구성을 완료했으므로, IDC 서버에서 AWS 측으로 전달되는 트래픽은 CGW, 즉 Openswan이 설치된 Public-IDC-Server로 향해야 합니다.
Public과 Private 라우팅 테이블에 Destination: 10.60.0.0/16, Target: [Instance]-[Public-IDC-Server] 항목을 추가해줍니다.
인스턴스 설정에서 [Public-IDC-Server]-[Networking]-[Change source/destination check]를 클릭합니다.
[Source / destination checking] 항목에서 Stop을 체크 후 Save 해줍니다.
해당 옵션은 해당 인스턴스 자체가 송수신되는 트래픽의 source/destination인지를 묻는 옵션인데,
NAT, VPN 등의 용도로 EC2 인스턴스를 사용하는 경우에는 해당 옵션을 Stop으로 변경해주어야 합니다.
AWS 환경의 라우팅 테이블 수정은 간단합니다.
Public과 Private 모두 트래픽이 VGW로 향하게 설정하면 됩니다.
Destination: 10.50.0.0/16, Target: [Virtual Private Gateway]-[vpntest-vgw]
결과
이제 각각의 서버에 접속해서 타 리전에 위치한 서버로 ping을 날려봅시다.
IDC Public -> AWS Public&Private
IDC Private -> AWS Public&Private
AWS Public -> IDC Public&Private
AWS Private -> IDC Public&Private
지정된 Gateway로 트래픽이 잘 향하는지 확인하려면 아래와 같이 라우팅 테이블에서 해당 항목을 추가/제거하는 방식으로 확인할 수 있습니다.
이것으로 Openswan을 활용한 AWS Site-to-Site VPN 설정 과정을 마무리하겠습니다.
오류/수정사항이 있다면 피드백 부탁드립니다. 긴 글 읽어주셔서 감사합니다.
'AWS' 카테고리의 다른 글
| AWS Lambda@Edge를 활용한 실시간 이미지 리사이징 (0) | 2023.12.01 |
|---|---|
| Session Manager를 통해 EC2 인스턴스 접속하기(feat. CentOS) (0) | 2022.09.14 |
| EC2에 Jenkins 구축하기 (0) | 2022.05.03 |
| EC2에 harbor 설치하기 (0) | 2022.05.02 |
| EC2에 MySQL 설치하기 (0) | 2021.12.13 |