다이어그램에는 지사에 인터넷 링크 두 개와 Azure VPN 게이트웨이 하나가 있으므로 로컬 네트워크 게이트웨이는 두 공용 주소를 모두 받습니다. 깔끔해 보이지만 다이어그램이 암시하는 대로 작동하지 않습니다. 각 온프레미스 VPN 장치는 별도의 피어 관계이며, Microsoft의 다중 장치 설계는 각 장치에 자체 로컬 네트워크 게이트웨이 리소스와 자체 연결을 부여합니다. 단일 리소스에 두 번째 주소를 추가해도 두 번째 피어가 생기지 않습니다. 두 장치 중 어느 것도 제대로 설명하지 못하는 리소스가 생길 뿐입니다.

신화: 게이트웨이 하나, 주소 두 개

로컬 네트워크 게이트웨이는 공용 엔드포인트 하나와 그 뒤의 프라이빗 접두사로 이루어진 원격 피어에 대한 설명입니다. 이 리소스가 «이 두 장치 중 어느 것이든»이라는 의미를 갖도록 하는 지원되는 방법은 없습니다.

같은 혼동이 반대 방향에도 있는데, Azure 공용 IP 두 개를 Azure 게이트웨이 두 개가 있다는 증거로 읽는 경우입니다.

개체를 세고, 그다음 터널을 세십시오

같은 프라이빗 네트워크에 대한 액세스와 자체 공용 주소를 가진 독립적으로 운영되는 온프레미스 장치 두 개와, 활성-활성 모드의 경로 기반 Azure 게이트웨이 하나를 준비합니다. Azure 게이트웨이에는 별도의 공용 IP를 가진 활성 인스턴스 두 개가 있습니다. 각 온프레미스 장치는 두 인스턴스 모두에 연결됩니다. 이것이 전체 메시이며, 개체 수는 다이어그램이 아니라 여기서 나옵니다.

계산은 설계 문서에 붙여 넣을 만큼 짧습니다:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

연결 리소스 하나가 기본 터널을 하나 이상 전달할 수 있으므로 터널 네 개가 가상 네트워크 게이트웨이 네 개를 의미하지는 않습니다. Azure 공용 IP 두 개도 원격 사이트를 설명하는 로컬 네트워크 게이트웨이 두 개와 같은 개체가 아닙니다.

활성-활성이 Azure 쪽에 추가하는 것

활성-활성은 Azure 게이트웨이를 활성 인스턴스 하나에서 두 개로 바꾸고 각각 자체 공용 IP를 갖게 하며, 바로 이것이 전체 메시를 가능하게 합니다. 단일 흐름의 처리량을 두 배로 늘리지는 않습니다. 두 장치가 동시에 전달하는 경우 온프레미스 쪽이 동일 비용 다중 경로를 지원해야 한다는 요구도 없애지 않습니다. 무언가를 프로비저닝하기 전에 게이트웨이 모드, SKU 및 원격 장치의 기능을 확인하십시오.

수동 대기 게이트웨이는 터널 수만 달라질 뿐 완전히 유효한 설계입니다.

BGP가 두 경로를 모두 사용 가능하게 만듭니다

다중 장치 설계에서는 두 온프레미스 장치 모두 BGP를 실행합니다. 각각에 고유한 BGP 피어 주소를 부여하고 동일한 의도된 프라이빗 접두사를 관련 경로에 알립니다. 프라이빗 접두사는 보호된 네트워크를 식별하고, 공용 주소는 암호화된 캐리어 연결이 끝나는 위치를 식별합니다. 이 둘을 혼동하면 모든 터널은 올라가 있는데 경로가 잘못된 설계가 됩니다.

반환 라우팅과 두 경로 중 어느 것이든 견뎌야 하는 상태 저장 검사를 계획하십시오. 각 엔드포인트의 정상 IKE 세션이 워크로드가 모든 광고된 경로를 사용할 수 있음을 증명하지는 않습니다.

흐름 기반 선택은 대역폭 풀링이 아닙니다

Azure는 흐름의 주소 지정과 포트에 대한 해시를 사용하여 흐름별로 경로를 선택합니다. 정상 상태에서 특정 TCP 또는 UDP 흐름의 패킷은 보통 같은 터널을 사용하며, 온프레미스 쪽은 반환 방향에 다른 터널을 선택할 수 있습니다. 따라서 장치 두 개와 터널 네 개는 가용성을 높이는 것이지 한 전송의 속도를 높이는 것이 아닙니다. 공급업체 슬라이드가 집계를 약속할 때 그것은 다른 기능이나 오해를 설명하는 것입니다.

경로가 분산되는 것을 보려면 병렬 흐름으로, 한계를 보려면 단일 흐름으로 테스트하십시오.

실제로 어떤 중복성을 제거했는가

장치 하나에 WAN 주소 두 개를 두면 액세스 링크 옵션은 좋아지지만 그 장치의 전원, 소프트웨어, 장애 상태를 공유합니다. 두 장치와 같지 않으며, Azure 쪽 구성으로는 그것이 바뀌지 않습니다. 주소 수에서 중복성을 추론하는 대신 공급업체가 지원하는 이중 WAN 또는 클러스터 설계를 따르십시오. 그런 다음 한 번에 경로 하나를 제거하고 남은 경로와 양방향의 실제 애플리케이션 교환을 확인하여 테스트하십시오.

감지 및 수렴 지연을 예상하고, 일부 기존 세션이 종료될 것도 예상하십시오.

관련 글