CloudFormation : Transit Gateway
1교시
VPC0의 퍼블릭 서브넷에 있는 인스턴스(프락시 서버 역할을 하는 서버)를 배스천 호스트라고 한다.
-> 네트워크의 최전선에서 외부로부터 들어오는 트래픽을 받는 장비
프락시 관련 기술이 3가지가 있는데...
1. Transparent Proxy
우리가 실제 사용하고 있는 프락시 기능. 클라이언트 네트워크에서 라우터를 거쳐 나오는 특정 트래픽을 외부로 바로 내보내지 않고 프락시 서버로 전달. 자신의 캐시 메모리에 요청받은 해당 트래픽이 있다면 프락시 서버가 바로 응답하고, 없으면 프락시 서버가 외부 인터넷에게 요청을 대행.
-> 이러려면 일단 프록시 서버가 존재해야 하고, 게이트웨이/라우터에 특정 트래픽을 필터링해서 프락시 서버로 전달하는 설정이 되어 있어야 한다.
2. Forward Proxy
클라이언트 네트워크에서 나오는 특정 트래픽을 프록시 서버로 보내는 것은 유사하지만, 어떤 트래픽을 어디로 보낼 것인지에 대한 설정이 PC(클라이언트) 단계에서 되어 있다.
3. Reverse Proxy
위 2개는 클라이언트 사이드에서 작동하는 것이었는데, 이건 서버 사이드에서 작동하는 프락시. 서버 네트워크의 앞단에서 프락시 서버가 트래픽을 받는다. 해당 요청 정보를 자신이 가지고 있으면 바로 응답하고, 없으면 내부에 있는 웹 서버에 요청해서 정보를 받아 응답한다.
실습 6-8의 구성도에는 NAT 장비가 없다 = 프라이빗 서브넷은 외부와 통신 불가
-> 전송 게이트웨이와 연결, 프록시 장비를 설정하면 허용한 트래픽(웹 트래픽)은 받을 수 있다.
- 전송 게이트웨이 연결 방법
1. VPC 연결(동일 리전 + 동일 계정)
2. VPN 연결(AWS와 온프레미스 연결)
3. Peering 연결(다른 리전 or 다른 계정)
일단 콘솔에서 전송 게이트웨이 만들기
VPC > 좌측 목록의 Transit Gateway > Transit Gateway, Transit Gateway 연결, Transit Gateway 라우팅 테이블
기본적으로는 이 3개 메뉴를 사용하게 될 것이다.
Transit Gateway 연결에는 타입이라는 것이 있어서, VPC로 연결할지/VPN으로 연결할지/피어링으로 연결할지 정할 수 있는데, 코드(CloudFormation)로 설정할 때에는 그게 안된다고 한다.
-> 각 타입마다 코드 작성 방식이 다르다.
일단 VPC 연결부터. 대충 스위치/라우터를 구성한다고 생각하자.
Transit Gateway > 생성 > 이름 작성, 나머지는 기본값으로 두고 생성
일단 연결을 안 했으니 Pending 상태다.
우선 VPC0의 Subnet3, 4와 연결하자.
Transit Gateway 연결로 이동 > VPC0, 1, 2의 Subnet3, 4에 연결해야 한다 > 연결 생성
> 이름 작성, 방금 만든 TGW 선택, 연결 유형 선택(VPC), VPC ID는 연결할 VPC 선택, 연결할 서브넷 선택 > 생성 완료
(VPC0의 서브넷 3, 4에 연결 : 서브넷 선택은 3, 4)
이렇게 VPC1, 2의 서브넷 3, 4에도 연결
2교시
Transit Gateway 라우팅 테이블로 이동해 보면 기본 테이블이 하나 있다. 만들어진 라우팅 테이블의 연결 탭을 가보면 아까 연결한 VPC 목록이 있다.
-> 이제 각 서브넷에 있는 라우팅 테이블에 전송 게이트웨이로의 경로 엔트리를 추가해줘야 한다.
VPC0의 퍼블릭 라우팅 테이블에 10.0.0.0/8 - 전송 게이트웨이 엔트리를 추가
-> 왜 10.0.0.0/8인가? : 10.0.0.0/16으로 하면 10.20.0.0/16과 10.10.0.0/16도 추가해줘야 한다. 10.0.0.0/8로 2개 CIDR을 모두 포함 가능하기 때문
지금 라우팅 테이블이 좀 많은데, 각 VPC의 서브넷 1, 2에 연동되는 라우팅 테이블에만 엔트리 추가.
-> 서브넷 3, 4에 연동되는 라우팅 테이블에는 추가 X
-> 전송 게이트웨이와 연결할 용도의 서브넷/라우팅 테이블이므로 추가하든 말든 별 차이가 없다.
이제 VPC0-Instance1으로 접속해서 다른 VPC의 인스턴스로 핑을 날려 보자.
-> 모두 성공.
SSH 원격 접속을 해보자(패스워드 접속)
-> 모두 성공
VPC1-Instance1에 접속해서 8.8.8.8로 핑을 날려보면 반응이 오지 않는다.
하지만 curl www.google.com을 해보면 반응이 온다.
-> 해당 인스턴스의 /etc/bashrc 파일의 하단에
이 내용을 추가했다면 curl 반응이 올 것이다.
이 장비에서 발생하는 웹 관련 트래픽을 VPC0-Instance1(프락시 인스턴스)의 3128 포트(squid 프락시 프로세스)로 내보내는 내용
전송 게이트웨이 실습(6-8) 구조의 통신 흐름
-> 프록시 서버가 있는 서브넷의 퍼블릭 라우팅 테이블에 10.0.0.0/8 대역대의 통신은 전송 게이트웨이로 보내는 엔트리 추가
-> 이 포워딩에 의해 전송 게이트웨이로 온 패킷을 한 번 더 검증 : 전송 게이트웨이 라우팅 테이블에서 10.xx.xx.xx/16 관련 엔트리들을 추가. 각각 해당 VPC로 보내도록 엔트리 추가.
-> 전송 게이트웨이 라우팅 테이블에 의해 해당 VPC로 패킷이 가면, 해당 VPC의 라우팅 테이블에 의해 로컬에 있는 장비를 찾아간다.
3교시
cat <<EOT> 파일명
-> 실행하면 입력창이 뜨는데, 대충 입력 내용을 파일에 붙여 쓴다는 의미.
- 인터페이스 엔드포인트 테스트를 위해 2가지 DNS로 dig +short를 날려보는데...
1. VPC0-Instance1에서 테스트하면 2가지 DNS 모두 사설 주소가 응답이 온다.
2. VPC1-Instance1에서 테스트하면 엔드포인트 DNS로는 사설 주소가 응답이 오지만, 기본 DNS로는 공인 주소가 응답이 온다.
-> 인터페이스 엔드포인트 설정 시 프라이빗 DNS 활성화가 VPC0에만 적용되기 때문. VPC끼리 통신된다고 해서 VPC0에서의 설정이 통신되는 모든 VPC에 적용되는 것은 아니다.
이번에는 트래픽 제어를 위한 라우팅 테이블 차별화.
-> VPC0과 VPC1, 2는 통신이 가능하지만, VPC1, 2는 서로 통신 불가하도록
일단 콘솔로
Transit Gateway 라우팅 테이블 > 기본 라우팅 테이블의 연결 탭 > VPC1, 2와의 연결 삭제
라우팅 테이블 생성(Blue, Red) > 연결 탭으로 가서 Blue에 VPC1, Red에 VPC2 연결(연결 선택을 해당 VPC와의 연결 선택) > 전파 탭으로 가서 전파 생성 > VPC0과 해당 VPC에 전파 생성
VPC0-Instance1에서 다른 장비들에게 핑을 날려보면?
-> VPC2가 응답을 안 한다. 라우팅 테이블에서 연결을 끊어놨으니까
이번에는 TGW-Red-RT 생성해서 VPC2에 연결, VPC0, 2에 전파 생성
-> 이제 VPC0-Instance1에서 VPC2 응답이 다시 온다.
그럼 VPC1과 VPC2 간 통신은 안된다.
포워더 설정이 없기 때문에 VPC1->VPC0->VPC2 통신도 불가.
4교시
블랙홀 라우팅을 이용한 통신 차단 : 특정 패킷을 목적지로 가지 못하도록 설정
-> 특정 네트워크를 VPC 안에서만 통신이 가능하도록 고립시키기
-> 특정 대역대로 가는 패킷을 모두 블랙홀로 빠뜨리기
기본 전송 게이트웨이 라우팅 테이블의 경로 탭 > 정적 경로 생성 > 차단할 CIDR 입력, 유형은 블랙홀 > 생성
VPC0-Instance에서 다른 장비들로 핑을 날려 보면, 차단한 CIDR에 대해서는 응답이 오지 않는다.
관련 패킷이 오면 기본 라우팅 테이블을 가장 먼저 보니까 블랙홀로 빨려 들어간다.
이제 코드로 실습할 예정이니 콘솔로 구축한 것들 삭제
콘솔에서 했던 생성 단계 다시 되새기기
5교시
트래픽 제어를 위한 라우팅 테이블 설정(Blue/Red Routing Table) 실습을 하려는데... 그전에 라우팅 테이블 경로 삭제는 수동으로 하시네?
1. Blue/Red 라우팅 테이블을 각각 VPC1과 2에 연결한다.
2. VPC0, 1과 VPC0, 2를 각각 전파한다.
블랙홀 실습 시 기본 라우팅 테이블을 참조해야 하는 상황이 있다.
-> AWS CLI로 불러오든, 콘솔 창 들어가서 긁어오든 별 차이 없으니 그냥 기본 Transit Gateway Routing Table의 ID를 긁어서 사용한다.
6교시
전송 게이트웨이 간 피어링
-> TGW Connection이 아니라 VPN Connection으로
이전에 했던 AWS와 온프레미스 간 VPN 실습에서, VGW 대신 TGW를 사용하는 실습
-> VGW 지우기
-> AWS-VPC에 서브넷 1개 추가, 라우팅 테이블 1개 추가 : TGW 만들어서 이 서브넷과 연결
두세 번을 들어도 골 때린다. 아예 새로운 거면 모르겠는데 기존에 했던 걸 대충 갈아 끼우라고 하니 더 이해가 안 간다.
여기서 VGW 대신 TGW를 넣고, AWS-VPC2에 서브넷을 하나 만들어서 TGW와 연동하라고 한다.
-> 새로 만드는 서브넷은 프라이빗? 퍼블릭? : 일단 TGW에서 프라이빗과 연결했으니 프라이빗으로 만들었다.
-> AWS의 기존 퍼블릭 서브넷의 라우팅 테이블에는 뭘 추가해야 하는가? : TGW와 연결은 프라이빗 서브넷에서 했으니 일단 건드리지 말자.
-> CGW 설정은? : 예전에 코드에 작성했던 작업은 AWS-VPC에게 IDC-CGW가 CGW라는 것을 인지시키기 위해 작성했던 것이다. VGW와 무관하니 일단 패스
어우 짜증 나
8교시
일단 VGW 없이 CGW만 만들고 연결했다.
이러고 IDC-CGW로 접속, root 사용자로 /etc/ipsec.d/vpnconfig.sh 실행
-> IDC-CGW의 공인 IP 주소와 '사이트 간 VPN 연결'에서 터널 1의 외부 IP 주소 입력
-> 터널1의 상태가 작동으로 변경된다.
터널은 뚫렸는데, 정적 라우팅 문제 발생.
좋은 실습 같긴 한데 좀 급작스러운 느낌이 있다.
어쨌거나 문제 발생해서 내일 재개하기로.
1교시 초반의 프락시 3가지 설명 다시 듣기
2교시 후반 통신 흐름 설명 다시 듣기
'교육' 카테고리의 다른 글
| [55일 차] 21.10.12 : AWS 15 (0) | 2021.10.12 |
|---|---|
| [54일 차] 21.10.08 : AWS 14 (0) | 2021.10.08 |
| [52일 차] 21.10.06 : AWS 12 (0) | 2021.10.06 |
| [51일 차] 21.10.05 : AWS 11 (0) | 2021.10.05 |
| [과제] 21.10.04 : DNS Resolver with CloudFormation (0) | 2021.10.04 |
댓글