AWS Site-to-Site VPN에서 NAT Gateway로: VGW와 Transit Gateway 비교

처음 설계할 때 모두 같은 다이어그램을 그립니다. VPC로 VPN을 넣고 NAT gateway로 인터넷에 나가면 끝이라고 생각합니다. 그러나 VPN이 virtual private gateway에서 종료되면 AWS는 그 경로를 지원하지 않으며, 실패는 너무 조용해서 팀이 여러 번 다시 만듭니다. 동작하는 설계에는 transit gateway가 필요하고, 이는 양쪽의 gateway와 라우트 테이블을 바꿉니다. 그리기 전에 두 형태를 비교하십시오.

당연해 보이지만 지원되지 않는 토폴로지

AWS의 NAT gateway 문서는 단일 VPC 설계만 해 본 사람을 놀라게 하는 선을 긋습니다. Site-to-Site VPN 연결의 트래픽은 virtual private gateway를 거쳐 NAT gateway로 라우팅될 수 없습니다. VPN이 종료되는 gateway 유형이 변환 경로의 존재 자체를 결정합니다. 이 실수가 남는 이유는 터널 상태가 UP이고 같은 subnet의 EC2 인스턴스가 문제없이 인터넷에 도달하기 때문입니다. 두 관찰 모두 끊긴 방향을 검증하지 않습니다.

실제로 패킷은 온프레미스 소스 주소로 도착하고, 이를 변환할 지원되는 다음 홉을 찾지 못합니다. 테이블에 따라 egress 경계에서 폐기되며, 터널은 UP으로 남고 같은 subnet의 인스턴스는 인터넷에 도달하므로 장애는 온프레미스 firewall 문제로 보고됩니다.

virtual private gateway와 transit gateway

virtual private gateway는 하나의 VPC에 속합니다. VPN을 종료하고 그 VPC의 라우트 테이블에 라우트를 설치한 뒤 거기서 멈춥니다. attachment 모델이 없어 다른 VPC나 공유 egress 세그먼트로 트래픽을 넘길 수 없습니다. 이 단일 VPC 범위가 전체 제약이며, VPC 안에 추가하는 어떤 라우트도 이를 바꾸지 못합니다.

transit gateway는 리전 허브로, VPN과 각 spoke VPC, 공유 서비스 VPC가 모두 attachment로 나타납니다. 자체 라우트 테이블을 가지며 어떤 attachment가 주어진 prefix를 받을지 선택합니다.

이 허브가 중앙 집중 egress를 가능하게 합니다. VPN이 하나의 attachment로 착지하고 egress VPC가 또 하나로 착지하며, transit gateway 라우트 테이블이 인터넷 방향 prefix를 첫 번째에서 두 번째로 보냅니다. virtual private gateway에는 보낼 두 번째 attachment가 없으므로 나중에 덧대어 만들 수 없습니다.

지원되는 egress 경로, 홉별로

참조 설계는 다섯 홉이며 화살표 하나하나가 구성해야 할 라우팅 결정입니다. 트래픽은 온프레미스 네트워크에서 Site-to-Site VPN attachment로 나가고, transit gateway 라우트 테이블이 이를 egress VPC attachment로 전달하며, 그곳의 subnet 테이블이 공용 NAT gateway로 보냅니다. NAT gateway가 소스를 변환하고 internet gateway가 패킷을 밖으로 내보냅니다.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

마지막 홉이 동작하는지는 두 가지 세부 사항이 결정합니다. NAT gateway는 공용이어야 하고 elastic IP와 internet gateway로 가는 라우트가 있어야 합니다. 사설 NAT gateway는 네트워크 사이를 변환할 뿐 인터넷 출구가 되지 않기 때문입니다.

서비스하려는 각 Availability Zone마다 NAT gateway 하나를 계획하고, 각 subnet 테이블이 로컬을 가리키게 하십시오. 노트에서 transit gateway 테이블과 VPC 테이블을 별도 객체로 유지하십시오. 하나는 attachment를, 다른 하나는 VPC 내부 리소스를 선택하기 때문입니다. 둘 중 하나에만 기본 라우트가 있으면 경로의 절반이 정의되지 않고, 원인을 귀속시키기 가장 어려운 부분 장애가 생깁니다.

이 설계는 반환 경로에서 실패합니다

NAT gateway는 이미 본 흐름에 대해 상태를 유지하므로 아웃바운드 연결의 응답은 새 인바운드 규칙 없이 돌아옵니다. 그 속성은 온프레미스 서비스를 인터넷에 게시하지 않으며, 그렇게 취급하면 팀이 결코 성립하지 않을 연결을 디버깅하느라 하루를 잃습니다. 클라이언트가 시작한 트래픽에는 네 개의 라우트가 일치해야 합니다. 온프레미스 정책, transit gateway 테이블, egress subnet 테이블, NAT subnet 테이블입니다. 마지막을 놓치면 요청은 건물을 떠나지만 응답은 AWS 안에서 죽습니다.

VPN 뒤의 실제 클라이언트로 검증하고 그것이 제시하는 공인 소스 주소를 확인하십시오. 그것이 NAT gateway의 elastic IP라면 변환이 일어나고 있고, 다른 것이라면 다른 출구를 측정하고 있는 것입니다.

이 장애의 비대칭 버전은 일찍 알아두는 편이 좋습니다. 한 Availability Zone의 NAT subnet 테이블에 클라이언트 prefix로 가는 반환 라우트가 있고 다른 존에는 없으면, 새 연결은 흐름이 떨어지는 존에 따라 성공하거나 실패하며 그 패턴은 불안정한 인터넷으로 오독됩니다. 티켓이 열린 존을 고치는 대신 서비스하는 모든 존의 subnet 테이블을 비교하십시오. 빠진 라우트가 장애의 전부이며 반대편에서는 아무것도 바꿀 필요가 없습니다.

명시적 proxy가 더 나은 설계일 때

egress VPC의 인스턴스에 둔 HTTP proxy는 정당한 대안이며 종종 더 저렴합니다. 클라이언트가 이를 사용하도록 구성되고, proxy가 자체 연결을 열어 밖으로 나가며, 반환 경로는 대칭 라우팅 퍼즐이 아니라 proxy의 문제가 됩니다. 소수 애플리케이션이라면 transit gateway 작업의 대부분이 사라집니다. NAT gateway가 만들 수 없는 사용자별 로깅도 제공합니다.

다만 투명하지는 않습니다. proxy 설정을 무시하는 모든 것과 HTTP가 아닌 모든 프로토콜은 그 경로를 따르지 않습니다.

선택은 애플리케이션이 실제로 말하는 프로토콜과 로그에 필요한 식별 정보의 양에 달려 있습니다. HTTP를 말한다면 proxy가 제자리를 얻습니다. 임의 프로토콜을 위한 일반 egress가 필요하다면 AWS가 지원하는 설계는 transit gateway입니다. 이를 미리 정하는 편이 라우트 테이블을 만든 뒤 발견하는 것보다 저렴합니다.