CloudFormation : S2S VPN
1교시
어제 코드 작성 시 착각한 점이 있다.
-> IDC-VPC 쪽은 고객의 온프레미스 환경이다. 클라우드 환경에서 사용하는 AWS::EC2::CustomerGateway Type을 작성할 필요 없다. 이미 인스턴스 설정에서 CGW로 작동할 수 있는 구성을 마친 것이다.
- S2S(Site-to-Site) VPN 구성의 6단계
1. VGW 생성
2. VGW-VPC 연결
3. CGW 생성
4. VGW-CGW 연결(VPN Connection)
5. AWS측에 라우팅 경로 생성
6. 경로 전파(Propagation)
2~3교시
일단 콘솔로 구성해 보자.
VPC > 좌측 목록의 VPN > 가상 프라이빗 게이트웨이 > 가상 프라이빗 게이트웨이 생성 > 이름 태그 작성(AWS-VPNGW), ASN은 기본 체크 후 생성 > detached 상태의 VGW가 만들어진다. > 작업 > VPC에 연결 > AWS-VPC에 연결
여기까지가 1, 2단계 64512
ARN(AWS Resource Name)
ASN(AWS Serial Number)
-> 국가 간 통신에 사용되는 BGP는 AS라는 숫자를 기준으로 각 네트워크를 식별한다. AS는 국제협약기구에서 지정해주는데, ASN는 AWS에서 BGP를 사용 시에 매칭 되는 AS 숫자다.
이제 3단계.
좌측 목록의 VPN 하위의 고객 게이트웨이 > 생성 > 이름 작성(IDC-VPN-CGW), 라우팅은 동적 체크, IP 주소에는 IDC-CGW 인스턴스의 퍼블릭 IP 작성, 나머지는 넘기고 생성
좌측 목록의 VPN 하위의 사이트 간 VPN 연결 > VPN 연결 생성 > 이름 작성, 대상 게이트웨이 유형은 가상 프라이빗 게이트웨이, 가상 프라이빗 게이트웨이는 아까 만든 것 선택, 고객 게이트웨이는 기존, 아까 만든 CGW ID 선택, 라우팅 옵션은 정적(접두사는 10.60.0.0/16), 터널 옵션의 터널 1/2의 사전 공유 키에 cloudneta 작성 후 생성
VPN 간 데이터 송신 시(본사->지사 송신) 데이터가 보이면 안 된다.
-> 데이터+헤더(송수신 터널의 IP)가 있는 본 패킷을 암호화하고, 인터넷을 통과할 동안 패킷 앞단에 목적지/출발지 주소가 있는 헤더를 붙인다.
-> 송수신 터널 IP는 VPN 식별 용도 : 송신 터널 IP가 알고 있는 것이 맞으면 일단 받고, 수신 터널 IP가 자신이면 완전히 받아들인다. 아니면 버리고.
-> 즉 실제로 터널을 뚫는 것이 아니라 패킷의 암호화된 데이터+터널 IP/공인 IP로 VPN을 찾아가는 방식의 통신이므로 터널과 다름없다는 의미.
-> 설정 옵션 중 로컬/원격 IPv4 네트워크 CIDR을 비워두면 송수신자가 협상을 통해 알아서 결정
-> 사전 공유 키(PSK)는 IDC-CGW에 이미 세팅되어 있다(패스워드 cloudneta). AWS 측에서도 연결할 때 같은 키를 사용해야 한다. 안 그러면 알아서 만들기 때문에 다른 키가 적용될 수 있다. 그러면 통신 불가.
연결 생성 후 터널 세부 정보 탭 > 터널 1, 2의 외부 IP 주소 복사
3.36.210.63
52.78.39.233
6단계 경로 전파
라우팅 테이블 > AWS-PublicRT 쪽에서 라우팅 전파 탭 편집 > 활성화 체크
이제 IDC-CGW 인스턴스의 /etc/ipsec.d/로 이동, vpnconfig.sh 파일을 찾는다.
-> openswan 패키지를 설치했다면 있을 것이다.
실행 > IDC-CGW 인스턴스의 퍼블릭 IP 입력, 터널 1 외부 IP 입력
이제 '사이트 간 VPN 연결'로 와서 확인해 보면 사용 가능, 작동으로 바뀌어 있다.
aws.conf를 보면
leftid가 idc, rightid가 aws
테스트는 IDC-EC2로 들어가서 AWS-VPC의 EC2 사설 주소로 핑을 날려본다.
??? CGW의 aws.secret 비어있는데 왜 작동하지?
일단 콘솔로 하는 실습은 여기까지.
사이트 간 VPN 연결 삭제 > 가상 프라이빗 게이트웨이 VPC에서 분리 후 삭제
라우팅 테이블의 라우팅 전파는 알아서 없어진다.
4교시
이제는 코드로 구축해 보자.
코드 구축 시 주의해야 할 점은 DependsOn이다. 특정 작업이 끝난 후에 진행되어야 하는 작업에 의존성 요소를 넣지 않으면 스택 생성/업데이트 시 에러가 발생한다.
-> AWS-VPC의 라우팅 경로에 IDC-CGW로 가는 경로를 추가해준다.
빠르면 기본 인프라 구축 내용은 내일 마무리될 예정. 그 후에 개인 프로젝트 브리핑, 구성 방법 질의 등을 진행할 예정이라고 한다. 다음 주부터는 DevOps인데... 시간이 빡빡하다. Terraform, Docker, Kubernetics 등이 남았다.
5교시
업데이트가 끝난 후 확인해 보면 연결이 안 되어 있다.
-> 터널의 외부 IP 주소가 바뀌었기에 VPN 연결이 안 됨
IDC-CGW에서 다시 vpnconfig.sh를 실행해서 IDC-CGW의 공인 IP와 터널 1의 외부 IP 주소를 입력.
지금 /etc/ipsec.d/ 디렉터리의 정보를 수정한 것인데, openswan 주 설정 파일인 /etc/ipsec.conf에 적용을 해줘야 한다.
-> ipsec 서비스 재시작 : systemctl restart ipsec
-> 이제 IDC-EC2에서 AWS-EC2로 핑을 날려 보면 반응이 온다. 성공!
- 1교시 작성 내용 중 수정
-> IDC-CGW가 있어서 고객 게이트웨이를 AWS에 만들 필요 없는 것이 아니라, IDC-CGW가 CGW라는 것을 AWS 측에 인지시켜 주기 위해 만드는 것
-> CGW 만들 때 IDC-CGW의 정보를 넣었으니 이 주소가 CGW다, 라는 것을 AWS에서 출발할 통신들에게 알려주는 것.
단일 VPC끼리면 Peering으로 되겠지만, 2개 이상의 VPC를 Peering으로 연결하려면 복잡해진다.
-> 전송 게이트웨이 사용
- 전송 게이트웨이(Transit Gateway) : AWS 내용 중 가장 중요한 부분.
VPC나 온프레미스 등의 네트워크를 단일 지점으로 연결할 수 있는 라우팅 서비스. 연결된 네트워크는 다른 네트워크에 연결할 필요 없이 AWS 전송 게이트웨이만 연결하면 되므로 관리를 크게 간소화하고 운영 비용을 크게 줄여준다.
-> 대충 라우터 같은 역할
인프라 구축 후 변경 사항이 없다면 피어링도 괜찮겠지만, 다른 네트워크를 추가할 상황이라면 전송 게이트웨이가 훨씬 편리하다.
- 전송 게이트웨이의 주요 기능
- 라우팅
3 계층 동적/정적 라우팅 지원
- 에지 연결
VPN을 사용하여 AWS 전송 게이트웨이와 온프레미스 게이트웨이 간 VPN 연결 생성
- VPC 기능 상호 운용성
VPC에 있는 인스턴스가 AWS 전송 게이트웨이에 연결된 다른 AWS VPC에 있는 서비스에 접근
- 모니터링
AWS CloudWatch, VPC Flow Log 등에서 사용하는 통계와 로그를 제공
- 리전 간 VPC 피어링
전송 게이트웨이 리전 간 피어링은 AWS 글로벌 네트워크를 사용하여 AWS 리전을 통해 트래픽을 라우팅 할 수 있도록 지원
- 멀티캐스트
고객이 클라우트에서 멀티캐스트 앱을 쉽게 구축하고 수많은 수신자까지 멀티캐스트 구성을 쉽게 모니터링, 관리, 확장할 수 있도록 지원
- 보안
전송 게이트웨이는 IAM과 통합되므로, AWS 전송 게이트웨이에 대한 접근을 안전하게 관리
- 지표
성능과 송수신된 패킷, 폐기된 패킷을 포함한 트래픽 지표를 통해 글로벌 네트워크를 모니터링
피어링만으로 여러 VPC를 연결하려면?
-> 1:1 피어링을 여러 번 해야 한다. 복잡한 개별 연결 필요.
예시) 4개의 VPC를 피어링으로 연결?
피어링 연결이 3 + 2 + 1 = 6개 필요
전송 게이트웨이를 사용한다면?
-> 중앙 집중형 연결 환경을 만들 수 있다.
- 전송 게이트웨이 관련 용어
- Transit Gateway(TGW)
연결의 접점이 되는 중앙 집중형 단일 게이트웨이. Hub & Spoke 환경에서 Hub의 역할
- Transit Gateway Attachment
전송 게이트웨이에 연결되는 방식
1. VPC 연결 : TGW와 동일 리전 내 VPC를 직접적으로 연결(다른 계정에 생성한 VPC도 가능)
2. VPN 연결 : TGW와 VPN을 연결(Site-to-Site VPN)
3. TGW Peering : TGW와 다른 리전의 TGW 간 연결(Inter-Region TGW Peering)
- Transit Gateway Routing Table
TGW에서 관리하는 라우팅 테이블
- Transit Gateway Sharing
TGW를 공유하며 다른 AWS 계정에게 전달하여 연결 가능(Resource Access Manager 활용)
- Transit Gateway Multicast
TGW를 통해 멀티캐스트 트래픽 전달
- Transit Gateway Network Manager
논리적 다이어그램 또는 지리적 맵과 중앙 대시보드에서 글로벌 네트워크를 시각화
6~7교시
VPC당 라우팅 테이블 2개
보안 그룹 설정
-> VPC0에 보안 그룹 2개 : 인스턴스에 사용할 것 + 엔드포인트에 사용할 것
-> 인스턴스용 : 22(ssh - tcp), 80(http - tcp), 443(https - tcp), 3128(squid - tcp), -1(icmp)
-> 엔드포인트용 : 80, 443, -1
-> VPC1, 2는 인스턴스에 사용할 보안 그룹 1개씩
-> 22, -1
총 4개
VPC 3개에 서브넷 12개, 라우팅 테이블 4개, 보안 그룹 4개, 인터페이스 엔드포인트, 인터넷 게이트웨이
지금까지 한 실습 중 규모가 가장 커서 좀 어지러웠다.
일단 전송 게이트웨이 설정 전이라 테스트할 수 있는 것은 한정적
-> 인터페이스 엔드포인트 확인, 콘솔로 구성 확인
지금 할 것은 전송 게이트웨이로 VPC 연결하기.
개인 프로젝트에서는 VPN 연결 + 전송 게이트웨이 피어링이 추가될 것이다.
배스천 호스트 : 대충 앞단에서 걸러내는 인스턴스. 내부 외 외부 사이에서 게이트 역할을 수행하는 호스트를 의미한다.
전송 게이트웨이 구축은 내일.
2, 3교시 VPN 설명 다시 듣기
'교육' 카테고리의 다른 글
| [54일 차] 21.10.08 : AWS 14 (0) | 2021.10.08 |
|---|---|
| [53일 차] 21.10.07 : AWS 13 (0) | 2021.10.07 |
| [51일 차] 21.10.05 : AWS 11 (0) | 2021.10.05 |
| [과제] 21.10.04 : DNS Resolver with CloudFormation (0) | 2021.10.04 |
| [50일 차] 21.10.01: AWS 10 (0) | 2021.10.01 |
댓글