포인트 투 사이트에 라우트 기반 Azure VPN 게이트웨이가 필요한 이유

정책 기반 게이트웨이는 트래픽 선택기로 선택되는 IPsec 터널을 구축하며, 클라이언트 라우트를 넘겨줄 인터페이스가 없습니다. 포인트 투 사이트는 라우팅 기능이며, 게이트웨이는 클라이언트 주소 풀을 소유하고 가상 네트워크에서 해당 클라이언트로 향하는 라우트를 설치합니다. 이런 불일치 때문에 포털에 이를 추가하는 옵션이 표시되지 않습니다. 기존 게이트웨이에서 인터페이스를 생성하도록 전환할 수 있는 것은 없으므로 이 변경은 구성 편집이 아니라 교체입니다.

개별 단계보다 순서가 더 중요합니다. 순서를 잘못 잡으면 사이트 간 중단이 유지 관리 기간을 넘어갑니다.

정책 기반 게이트웨이가 실제로 하는 일

정책 기반 게이트웨이는 연결에 구성된 트래픽 선택기와 패킷을 대조하고 일치 항목을 하나의 터널로 보냅니다. 주소가 있는 터널 인터페이스는 없으며 가상 네트워크 어디에도 클라이언트별 라우트가 나타나지 않습니다. 라우트 테이블은 게이트웨이를 가리키는 온프레미스 접두사만 받습니다. 이 모델은 두 개의 고정 주소 공간 사이의 사이트 간 연결에 충분합니다.

라우트 기반 게이트웨이는 반대로 작동하여, 터널 인터페이스를 제공하고 라우트가 그 안으로 무엇이 들어올지 결정합니다. 포인트 투 사이트와 피어 집합이 바뀌는 모든 설계는 그 인터페이스의 존재에 의존합니다.

클라이언트 풀에 그 인터페이스가 필요한 이유

노트북이 연결되면 게이트웨이는 포인트 투 사이트 풀에서 주소를 할당합니다. 그러면 가상 네트워크에는 이 주소가 게이트웨이를 통해 도달 가능하다는 라우트가 필요합니다. 터널 인터페이스가 없으면 그 라우트를 붙일 대상이 없습니다.

풀은 지정한 범위에서 나오며 게이트웨이가 그곳에서 할당합니다. 그 범위가 온프레미스 네트워크나 피어링된 가상 네트워크와 겹치면 충돌은 클라이언트가 연결된 뒤에야 드러나며, 이는 발견하기에 나쁜 시점입니다. 마이그레이션을 시작하기 전에 풀을 예약하십시오.

유형도 연결별 설정이 아닙니다. 하나의 게이트웨이에는 하나의 유형이 있고 그것이 보유한 모든 연결이 그에 따라 동작하므로, 혼합 설계에는 두 번째 연결이 아니라 두 번째 게이트웨이가 필요합니다.

유형은 생성 시 고정됩니다

Microsoft는 가상 네트워크 게이트웨이를 배포 후 정책 기반과 라우트 기반 사이에서 변경할 수 없다고 밝힙니다. 변환 명령도 없고 포털의 전환 스위치도 없습니다. 같은 서브넷에 두 번째 게이트웨이를 만드는 것도 Azure가 가상 네트워크당 하나의 게이트웨이만 허용하기 때문에 우회책이 아닙니다. 따라서 마이그레이션은 제거, 재구축, 재연결입니다.

이는 SKU 결정도 같은 구축에 포함합니다. 나중에 더 큰 SKU로 옮기는 것은 또 다른 중단을 수반하는 또 다른 게이트웨이 교체입니다.

하나의 게이트웨이, 하나의 GatewaySubnet

게이트웨이는 GatewaySubnet이라는 서브넷에 있으며 하나의 게이트웨이만 그곳을 차지합니다. 그 서브넷의 크기 산정은 더 큰 SKU에는 더 많은 주소가 필요하고 서브넷은 나중에 줄일 수 없기 때문에 준비 단계에 속합니다. 무엇이든 건드리기 전에 현재 사이트 간 설정, 공유 키, 로컬 네트워크 게이트웨이, 유효 라우트를 기록하십시오. 그런 다음 새 연결이 구성될 때까지 사이트 간 터널이 내려가 있으므로 해당 기간을 중단으로 간주하십시오.

중단을 제한적으로 유지하는 재구축 순서: 라우트 기반 게이트웨이를 만들고, 같은 로컬 네트워크 게이트웨이로 사이트 간 연결을 다시 만들고, 터널과 호스트 간 요청 하나를 확인한 다음에야 포인트 투 사이트를 추가하고 새 클라이언트 패키지를 생성합니다.

교체로 해결되지 않는 것

두 번째 제약은 Azure가 아니라 피어에 속합니다. 정책 기반 온프레미스 장치는 연결된 가상 네트워크에만 도달할 수 있고, 같은 게이트웨이를 통해 다른 온프레미스 네트워크나 다른 가상 네트워크로 전환할 수 없습니다. Azure 쪽을 교체해도 피어가 무엇을 선택할 수 있는지는 바뀌지 않습니다.

요구 사항이 정말 사이트 간 전환이라면 답은 라우트 기반 피어 장치이거나 각 목적지가 개별적으로 종료되는 토폴로지입니다. 게이트웨이 교체만으로는 그것을 제공하지 못하므로 날짜를 약속하기 전에 이를 확정하십시오.

작업과 점검의 순서

각 기능을 개별적으로 검증하십시오. 먼저 사이트 간 터널 상태와 호스트 간 요청 하나, 다음으로 포인트 투 사이트 연결과 프라이빗 리소스 하나, 다음으로 설계가 주장하는 모든 전환 경로입니다. 녹색 게이트웨이 상태는 보안 연결이 올라왔다는 것만 증명하며 그 이상은 아닙니다. 점검을 그 순서로 유지해야 실패가 그것을 도입한 단계를 가리킵니다.

토폴로지가 바뀔 때마다 클라이언트 패키지를 다시 생성하고, 풀을 모든 온프레미스 및 피어링된 범위에서 멀리 유지하십시오. 제약과 SKU 차이는 Azure VPN Gateway 설정 참조에 정리되어 있습니다.