피어링된 Azure VNet에 자체 VPN 게이트웨이가 필요한가?

새 스포크 VNet이 나타나고 허브에는 이미 작동하는 사이트 간 게이트웨이가 있으며, 당연한 질문은 두 번째 게이트웨이에 비용을 지불해야 하는지다. 대개는 아니며, 게이트웨이 전송을 사용하면 스포크가 피어링을 통해 허브의 게이트웨이를 사용할 수 있다. 세 가지 조건이 그것이 작동하는지 결정하며, 그중 어느 것도 피어링 상태 배지에서는 보이지 않는다. 피어링 연결과 다른 사람의 게이트웨이 사용 권한은 별개의 설정이므로, 이미 서로 ping할 수 있는 두 VM은 VPN 경로에 대해 아무것도 증명하지 않는다.

첫 번째 조건: 게이트웨이, 그리고 스포크에 그것이 없음

Azure는 Basic 이외의 VPN Gateway SKU에 대해 게이트웨이 전송을 지원하며, 지역 및 글로벌 피어링 모두 이를 전달할 수 있다. 스포크는 자신이 소유하지 않은 게이트웨이를 사용하므로 자체 게이트웨이를 가질 수 없으며, 스포크에 이미 게이트웨이가 있거나 원격 게이트웨이 옵션이 이미 선택되어 있으면 원하는 전송 설정을 사용할 수 없거나 효과가 없다. 무엇이든 디버그하기 전에, 비활성화된 확인란이 증상이지 결함이 아니므로 이것을 확인하라. 먼저 SKU와 기존 게이트웨이를 읽고, 그다음 피어링 설정을 보라.

무엇이 그것에 의존하는지 알기 전까지는 옵션이 나타나게 하려고 기존 스포크 게이트웨이를 삭제하지 마라. 마이그레이션 순서가 확인란보다 중요하다.

두 번째 조건: 각 피어링 방향에 하나의 설정

피어링은 두 개의 개체이며 각 VNet에 하나씩 있고, 전송 설정은 그 쌍의 서로 다른 쪽에 있다. 허브에서 스포크로의 피어링은 허브 게이트웨이가 스포크를 서비스하도록 허용해야 하고, 스포크에서 허브로의 피어링은 허브의 게이트웨이를 수락해야 한다.Microsoft의 게이트웨이 전송 가이드는 방향별로 이름을 붙이며, 올바르게 유지하는 유일한 방법이 이것이다:

remote라는 레이블이 붙은 컨트롤은 어느 VNet의 피어링을 편집하는지에 따라 의미가 달라지므로 단어가 아니라 방향을 읽어라. 양쪽을 설정하고 저장한 뒤 두 곳 모두에서 피어링이 연결됨으로 보고되는지 확인하라.

세 번째 조건: 주소 공간과 권한 경계

전송은 동일한 대상 접두사가 두 네트워크를 의미하게 만들 수 없으므로, 허브, 스포크, 온프레미스 범위는 이 중 어느 것이 작동하기 전에 서로 겹치지 않아야 한다. VNet은 서로 다른 구독이나 서로 다른 테넌트에 있을 수도 있지만, 그것은 금지가 아니며, 각 피어링을 만들거나 업데이트하는 ID에는 해당 네트워크에 필요한 권한이 있어야 한다. 구독 간 변경은 권한 때문에 실패하는 경우가 많고, 그 오류를 토폴로지 문제로 잘못 읽기 쉽다.

변경 전에 범위와 소유자를 적어 두어라. 둘 중 하나를 추측하면 연결되지만 아무것도 라우팅하지 않는 피어링이 만들어진다.

피어링 상태가 아니라 유효 경로로 검증하라

스포크 워크로드의 네트워크 인터페이스에서 유효 경로를 보고 실제 온프레미스 접두사를 찾아라. 서브넷의 경로 테이블과, 사용자 정의 경로나 검사 어플라이언스가 피어링 플래그가 제안하는 경로를 덮어쓸 수 있으므로 게이트웨이 경로 전파가 비활성화되어 있는지 확인하라. 그다음, 온프레미스가 학습된 알림이나 명시적 경로 및 고객 장치의 일치하는 보호 네트워크 항목을 통해 사이트 간 연결로 스포크 접두사에 도달하는 방법을 아는지 반대 방향을 확인하라. 어느 한쪽에서 접두사가 빠져 있다면 피어링 플래그가 바꿔야 할 것이 아니다.

스포크 워크로드에서 서비스 하나를 테스트하고 응답을 따라가라. VPN 게이트웨이나 허브 VM에서의 테스트는 다른 원본 접두사와 다른 경로를 사용한다.

토폴로지가 지점 간 클라이언트도 서비스한다면 설치된 경로를 별도로 검증하라.토폴로지 변경 후 Windows 클라이언트 패키지를 다시 생성해야 할 수 있다, 그리고 그것은 게이트웨이 공유가 실패했다는 증거가 아니라 클라이언트 라우팅 작업이다.

게이트웨이 공유가 부여하지 않는 것

게이트웨이 전송은 라우팅 편의일 뿐 권한 부여가 아니다. 네트워크 보안 그룹, 온프레미스 필터, 서비스 수준 규칙이 여전히 스포크 워크로드가 무엇에 도달할 수 있는지 결정하므로, 공유 터널이 그 뒤의 모든 것을 허용한다고 가정하지 말고 특정 소스-대상 서비스를 활성화하라.

피어링은 사람들이 기대하는 방식으로 전이적이지도 않다. 스포크를 하나 더 추가하거나 프라이빗 엔드포인트를 추가하면 기존 전송 설정이 다루지 않는 자체 라우팅 및 액세스 요구 사항이 생긴다.