AWS-Azure 사이트 간 VPN: 먼저 반환 경로를 작성하십시오
클라우드 사이에 연결된 터널은 각 워크로드 서브넷이 원격 프리픽스로 라우팅하기 전까지 아무것도 증명하지 못합니다. 계획을 순서대로 진행한 뒤 서비스를 시험하십시오.
터널은 올라온다. IKE는 일치하는 제안과 도달 가능한 피어 주소만 있으면 되기 때문이다. 그다음 실패하는 것은 반환 경로다. AWS 워크로드는 패킷을 터널로 보내지만 Azure 쪽에서는 10.10.0.0/16에 어떻게 응답해야 하는지 아무도 모르거나, Azure 경로가 워크로드 서브넷이 쓰지 않는 테이블에 들어 있다. 어느 콘솔이든 만지기 전에 경로 계획을 쓰면 터널은 작업에서 가장 흥미 없는 부분이 된다.
1단계: 주소 계획을 고정하십시오
구체적인 값으로 작업하십시오. AWS 워크로드는 10.10.0.0/16 안의 10.10.1.20에 있고 10.20.0.0/16 안의 10.20.1.30에 있는 Azure 서비스로 TCP 443이 필요하다. 두 범위는 겹치면 안 되며, 인수 시험은 터널이 아니라 서비스 쌍이다.
다른 무엇보다 먼저 그 네 가지 사실을 적으십시오. 이후의 모든 단계가 그것과 대조되기 때문이다.
2단계: 각 끝을 소유한 게이트웨이를 지목하십시오
AWS Site-to-Site VPN은 가상 사설 게이트웨이 또는 전송 게이트웨이에서 끝날 수 있고, 이 둘은 서로 다른 라우팅 소유자다. Azure는 관리형 VPN Gateway와 별도로 고객이 직접 운영하는 VM 기반 어플라이언스를 제공한다. 어느 조합인지 기록하십시오. 다음 홉이 조합마다 다르다.
관리형 게이트웨이라면 추정한 사설 어플라이언스 주소를 가리키는 경로를 복사하지 마십시오. 어플라이언스라면 클라우드 경로 전파가 게스트 운영 체제를 구성한다고 가정하지 마십시오. 실제로 구성하지 않는다.
여기서 틀리면 완전해 보이는 계획이 만들어지고 결코 응답하지 않는 주소로 패킷을 보낸다.
3단계: 각 워크로드가 실제로 쓰는 경로를 작성하십시오
아래의 각 경계는 별개의 조회이며, 그중 하나의 경로가 패킷의 경로는 아니다. 터널이 가동되기 전에 표를 자신의 값으로 채우십시오.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS에서는 BGP나 터널이 정상이 된 뒤에도 워크로드 서브넷의 경로 테이블은 직접 갱신해야 한다. 라우팅 개요도 이를 연결의 일부로 본다. Azure에서는 사용자 정의 경로 테이블이 가상 네트워크가 아니라 서브넷에 연결되므로, 유효 경로는 VNet 블레이드가 아니라 워크로드 NIC에서 확인하십시오.
관리형 Azure 게이트웨이는 게이트웨이 전파로 원격 프리픽스를 배울 수 있고, UDR은 그 결정을 덮어쓸 수 있다. UDR은 이유가 있을 때 추가하고 습관적으로 넣지 마십시오. 추가한다면 어플라이언스 주소를 지어내지 말고 게이트웨이가 VPN 경로용으로 게시하는 다음 홉을 가리키게 하십시오. 그런 다음 NIC의 유효 경로를 다시 읽으십시오. 결정은 실제로 거기서 내려진다.
4단계: 범위를 맞추십시오
BGP라면 각 측이 광고하는 것과 상대가 실제로 배운 것을 프리픽스 단위로 비교하십시오. 정적 라우팅이라면 구성한 원격 범위를 3단계에서 적은 워크로드 경로와 비교하십시오.
암호화에 합의한 IKE 관계는 어느 쪽이 10.10.0.0/16이나 10.20.0.0/16을 배웠다는 증거가 아니다. 계획한 /16 대신 단일 /24를 광고한 채 두 터널이 올라와 있을 수 있다. 프리픽스는 터널 상태가 아니라 라우팅 테이블에서 확인하십시오. 불일치는 나중에 동작하는 서브넷 하나와 결코 응답하지 않는 서브넷 하나로 드러난다.
5단계: 실제 원본에서 서비스를 시험하십시오
의도한 흐름을 AWS 보안 그룹과 네트워크 ACL, Azure NSG, 경로상의 어떤 어플라이언스 필터에서든 허용하십시오. 그런 다음 10.10.1.20에서 승인된 서비스 주소와 포트로 연결을 하나 열어 응답이 같은 원본으로 돌아오는지 확인하십시오.
클라우드 보안 그룹과 NSG는 모두 상태 저장이므로, 거부된 반환 패킷은 라우팅의 증상이지 반대 방향 규칙을 빠뜨린 것이 아니다.
어느 게이트웨이에서 보낸 ping도 아무것을 결정하지 못한다. 게이트웨이 주소로 가는 ICMP는 제어 평면 경로를 시험할 뿐, 워크로드가 필요로 하는 전달된 TCP 서비스를 시험하지 않는다.
롤백과 기록
경로 소유자를 터널 식별자 옆에 기록하고 변경 전 경로 테이블을 보관하십시오. 변경을 되돌려야 한다면 터널을 해체하기 전에 워크로드 경로를 제거하여, 더 이상 존재하지 않는 다음 홉을 가리키는 서브넷이 남지 않게 하십시오.
그러면 이후의 서브넷 이전이나 spoke 연결에는 갱신할 한 곳이 정해져 있고, 한 번도 소유한 적 없는 경로의 책임을 떠안는 가동 중인 터널이 남지 않는다.