CloudFormation : DNS Resolver, VPC Peering
VPN
1~2교시
개인 프로젝트는 다음 주부터 시작, 마감은 대충 11월 말. 팀 프로젝트는 12월
일단 과제 리뷰. 미제출자가 많아서 이걸 리뷰라고 해야 할지, 그냥 진행이라고 해야 할지?
-> IDC VPC(온프레미스)를 클라우드로 만들어 가정했는데, 이런 방식은 프로젝트에서도 동일할 것.
DNS Resolver 실습
-> 2개 VPC에 있는 프라이빗 호스팅 영역에 대해 쿼리를 주고받을 수 있다.
강사님의 방식과 내가 작성한 내용을 비교해 보자.
DependsOn 지시자 : 특정 작업 이후에 이 작업을 실시한다면 필요
-> 나는 의존성이 있는 작업을 뒤로 미뤄버려서 해결했지만, DependsOn을 쓰는 것이 더 안전해 보인다.
AWS-VPC는 DNS 관련 설정을 꺼놨다.
Route 53 아웃바운드 엔드포인트
-> 특정 도메인에 대한 질문이 들어온다면 어디로 보낼 것인지 설정
-> IP 설정 시 콘솔 실습 때에는 주소를 다르게 했었다(251). 그런데 같게 해도 별 상관없어 보인다.
-> 아니나 다를까 같게 하니 에러 발생. 251로 수정하셨다.
3교시
AWS 공인 강사님이 진행하는 수업은 대략 2주. 콘솔에서 진행할 듯하고, 비용 책정이나 서비스 구성 등에 대해 수업하실 것 같다고 한다.
그때는 녹화 없으니 주의
우리가 특정 장비로 다른 장비에 접속할 때, 공인 IP와 외부 인터넷을 통해 통신했다. 이 과정에서 ISP 업체가 만들어 놓은 장비/회선을 따라 목적지로 가는데...
목적지가 멀리 있으면 당연히 오래 걸릴 것이다. 오래 걸린다는 것은 응답을 받는 시간이 길어진다는 것이다.
그래서 적용하는 것이 Global Accelerator.
-> 목적지의 공인 IP가 아닌 Anycast IP로 접속 : AWS의 내부 네트워크의 에지 로케이션을 사용
엣지 로케이션 - 글로벌 엑셀러레이터 - 엔드포인트 그룹/서비스로의 연결이 되어 있다면?
-> 애니캐스트 주소로 보내면 가장 인접한 엣지 로케이션이 반응, AWS 내부망을 통해 목적지로 전송
AWS 자체적으로 깔아놓은 내부망을 사용하니 훨씬 더 빠르다.
어느 국가는 어느 GA를 사용한다는 의미가 아니다. 우리가 내부 구조를 알 필요는 없다.
* 애초에 애니캐스트 통신 방식이 가장 인접한 장비로 보내는 방식이다.
수업에서 코드 구현은 진행하지 않았다. 따로 해봐야 할 듯?
4교시
이제 AWS 고급으로 넘어간다고 한다.
Transit Gateway, VPC Peering 등
다른 네트워크 간 연결은 프로젝트에서 무조건 사용되는 부분이니 잘 정리해 두자.
- VPC Peering
서로 다른 두 VPC 간 연결을 구성하여 프라이빗 IP 주소를 통해 통신을 할 수 있는 기능 제공.
마치 동일한 네트워크에 있는 것처럼 통신 가능.
-> 각 VPC 내부에 다수의 서비스가 있다면 하나하나 엔드포인트로 연결하기는 번거롭다.
-> 동일 리전의 단일 VPC 간 연결 : 1:1 연결
(다중 VPC 간 연결은 불가)
- VPN(Virtual Private Network)
공용 인터넷을 통해 가상의 사설 네트워크를 구성, 프라이빗 통신 제공(공용망을 사설망처럼 동작시키는 것).
데이터 암호화, 전용 연결 등 여러 보안 요구사항을 충족 가능
AWS에서 제공하는 관리형 VPN 서비스에는 Site-to-Site VPN과 클라이언트 VPN을 제공.
-> 전자는 온프레미스 상의 사이트와 AWS 사이트 간의 프라이빗 연결, 후자는 클라이언트의 AWS 네트워크 접속
기능
-> 통신 상대방 확인 : 인증 방식을 지원해야 한다.
PSK(Pre-Shared Key) 방식과 디지털 인증서(전자서명) 방식 등이 있다.
-> 데이터 기밀성 유지/무결성 확인 : 데이터 암호화(대칭키) 및 변조 방지
-> 재생 방지 : 공격자가 패킷을 도중에 끼워 넣는 것 방지
- IKE
Peer 인증, 보안 정책 집합인 SA 결정, 암호 결정 프로토콜
- SA(Security Association)
송수신 측이 보안 통신을 위해 협의하는 정책의 모음
- ESP(Encapsulating Security Payload)
실제 데이터를 암호화하는 프로토콜
5교시
- 전송 게이트웨이(Transit Gateway)
VPC나 온프레미스 등의 네트워크를 단일 지점으로 연결할 수 있는 라우팅 서비스. 연결된 네트워크는 다른 네트워크에 연결할 필요 없이 AWS 전송 게이트웨이만 연결하면 되므로, 관리를 간소화하고 운영 비용을 크게 줄여준다.
Direct Connect : 데이터 센터, 사무실 같은 Co-location 환경과 같은 장소에서 AWS와의 전용 네트워크 연결을 제공하는 전용선 서비스
VPC Peering : 점대점 연결에서 연결하고 있는 줄을 Peer라고 한다.
-> 고속 네트워크, 트래픽 암호화, 비용 절감
트래픽은 AWS 백본 네트워크를 경유하여 고속의 통신을 제공 받음
-> 리전 간 피어링 지원
피어링을 위한 제약조건
1. 서로 다른 VPC CIDR 사용 필요
-> VPC 피어링을 구성하는 각 VPC의 CIDR이 동일하거나 겹치면 피어링 구성 불가
2. Transit Routing 지원하지 않음
-> 상대방 VPC의 CIDR 대역 외에 다른 네트워크 대역과 통신 불가.
-> VPC 3개가 1-2-3 방식으로 연결되었다 하더라도, 1, 3 VPC 간의 통신은 불가.
-> 상대방 VPC에 구성된 IGW, NAT 게이트웨이, Direct Connect로 연결된 온프레미스와의 통신을 지원하지 않음
3. VPC 피어링 최대 연결 제한
-> 동일한 VPC 간 연결은 하나의 연결을 제외하고는 연결 불가.
-> 하나의 VPC는 기본적으로 50개의 피어링 가능
6교시
VPC Peering 실습
기본 환경은 2개의 VPC에 인스턴스를 1개씩 만든다.
목표는 각 인스턴스가 프라이빗 주소로 통신이 가능하게 하는 것.
그림으로만 보면 각 VPC에 Peering이 하나씩 있는 것으로 보이지만, 실제로는 가운데 걸쳐 있다고 보는 것이 좋다.
이후 인스턴스에 접속 후 상대 인스턴스의 사설 주소로 통신을 시도해보면 성공하는 것을 확인할 수 있다.
※ 연결하는 VPC가 하나의 계정 안에 있어서 따로 요청 수락에 관련된 코드가 필요 없다.
이번에 사용할 Type은 잘 알아둘 것. 프로젝트에서 반드시 사용될 기술이다.
AWS::EC2::VPNConnection
AWS::EC2::VPNConnectionRoute
AWS::EC2::VPNGateway
AWS::EC2::VPNGatewayRoutePropagation
이 부분이 오늘 배울 내용의 핵심이라고 한다.
AWS Site-toSite(S2S) VPN의 전제 조건
-> AWS 내부의 서비스(VPC)와 IDC의 네트워크를 연결하는 것
S2S VPN은 2개의 네트워크 도메인이 가상의 사설 네트워크 연결(VPN)을 사용하여 프라이빗 통신을 제공
-> AWS에서 제공하는 S2S VPN은 표준 IPSec VPN만 지원한다.
- 관리형 서비스
AWS에서 서버와 OS를 제공하지만 설치 및 운영에 대해서는 관여하지 않는다. 백업이나 가용성에 대해서도 사용자가 관리해야 한다.
- 완전 관리형 서비스
사용자가 세부 설정을 할 필요 없이 AWS가 자체 관리. 내부 구성이 밖으로 드러나지 않으며, 사용자가 가용성에 대해 생각할 필요가 없다.
-> 이 서비스에 원격 접속하거나, 사용자의 필요에 따라 수정하는 것도 불가.
EC2 인스턴스로 DNS 서버를 만들어 사용하거나(관리형 서비스), Route 53으로 DNS 서비스를 사용하는(완전 관리형 서비스) 것의 차이.
-> 전자는 내가 관리를 잘못해서 장애가 발생할 수 있지만, 후자는 설정을 잘못하지 않는 이상 장애가 발생할 일이 없다.
7교시
오늘은 콘솔로 VPN 구축, 내일은 IaC로 구축
VPN 연결을 생성하게 되면 제공되는 2개의 터널 엔드포인트는 고가용성을 위해 서로 다른 가용 영역에 생성된다.
-> VPN 연결을 하면 가상의 전용 회선이 생성된다. 이것이 터널
- 주요 용어
- VPN Connection : 온프레미스 장치(IDC)와 AWS VPC 간의 보안 연결
- VPN Tunnel : AWS VPC 네트워크와 온프레미스 네트워크 간 주고받을 수 있는 암호화된 링크
- Virtual Private Gateway(VGW) : AWS 관리형 S2S VPN
- Customer Gateway : 온프레미스 장비에 대한 정보를 특정 AWS VGW와 S2S 연결 설정을 위해 지정(IPSec 연결에 필요한 정보)
- Customer gateway device(CGW) : 온프레미스 장비 혹은 SW App
VPN 특징
1. VPN 동작 시 항상 응답자(Responder)로 동작한다.
가상 프라이빗 게이트웨이는 통신 요청자가 아니기 때문에 항상 고객 게이트웨이 장치에서 연결을 시도해야 한다.
IKE 버전 2를 사용할 경우 가상 프라이빗 게이트웨이가 통신 요청자가 될 수 있도록 설정 가능.
2. VPN 터널의 Idle Timeout
VPN 터널 연결 후, 터널에 트래픽이 10초 이상 흐르지 않는 경우 해당 터널은 다운된다. 터널 유지를 위해서는 온프레미스에서 DPD(Dead Peer Detect)를 설정하거나, ping을 일정 간격으로 발생시켜서 유지해야 한다.
3. 표준 IPSec 지원
데이터를 암호화하고 인증에 관여하는 다양한 알고리즘 지원
4. NAT-Traversal 지원
고객 게이트웨이 장치가 NAT 내부에 배치된 경우에도 NAT Traversal을 지원하여 VPN 연결이 가능
VPN 라우팅 옵션
1. Static Routing
사용자가 직접 원격 네트워크의 경로에 대해 설정
2. Dynamic Routing
BGP라는 라우팅 프로토콜을 사용하여 상대측으로부터 전달되는 네트워크 경로를 자동으로 인지하여 통신
8교시
VPN 실습 기본 환경 구축 - CGW 구축까지
내일 가상 프라이빗 게이트웨이 실습 전 환경 갖춰놓기.
스택 구성 성공!
-> VPC1, 2간 사설 통신은 안 되는 게 맞고
-> IDC-CGW를 통해 IDC-EC2 접속해보고, 서로 통신이 작동하는지 확인
3교시 Global Accelerator 설명 다시 듣기
7교시 VPN 설명 다시 듣기
'교육' 카테고리의 다른 글
[53일 차] 21.10.07 : AWS 13 (0) | 2021.10.07 |
---|---|
[52일 차] 21.10.06 : AWS 12 (0) | 2021.10.06 |
[과제] 21.10.04 : DNS Resolver with CloudFormation (0) | 2021.10.04 |
[50일 차] 21.10.01: AWS 10 (0) | 2021.10.01 |
[49일 차] 21.09.30 : AWS 9 (0) | 2021.09.30 |
댓글