Resource Manager 마이그레이션에 대한 VPN Gateway 클래식

이제 VPN Gateway를 클래식 배포 모델에서 Resource Manager 배포 모델로 마이그레이션할 수 있습니다. 자세한 내용은 Resource Manager 배포 모델을 참조하세요. 이 문서에서는 클래식 배포에서 Resource Manager 모델로 마이그레이션하는 방법을 자세히 설명합니다.

Important

클래식 배포 모델(서비스 관리) 가상 네트워크에 대한 새 가상 네트워크 게이트웨이를 더 이상 만들 수 없습니다. Resource Manager 가상 네트워크에 대해서만 새 가상 네트워크 게이트웨이를 만들 수 있습니다.

VPN Gateway는 클래식에서 Resource Manager로의 VNet 마이그레이션으로 시작됩니다. 이 마이그레이션은 고객이 한 번에 하나의 VNet 씩 수행합니다. VNet 마이그레이션을 시작하기 위한 도구나 사전 요구 사항 측면에서 추가 요구 사항은 없습니다. 마이그레이션 단계는 기존 VNet 마이그레이션과 동일하며 IaaS 리소스 마이그레이션 페이지에 설명되어 있습니다.

VNet 마이그레이션 중에는 데이터 경로 가동 중지 시간이 없으므로 기존 워크로드는 마이그레이션 중에 온-프레미스 연결 손실 없이 계속 작동합니다. VPN Gateway에 연결된 공용 IP 주소는 마이그레이션 프로세스 중에 변경되지 않습니다. 즉, 마이그레이션이 완료되면 온-프레미스 라우터를 다시 구성할 필요가 없습니다.

VNet 마이그레이션이 완료되면 Azure는 Resource Manager로 남아 있는 게이트웨이 마이그레이션을 완료하려고 시도합니다. 게이트웨이 마이그레이션이 성공하지 못하면 고객에게 VPN Gateway(클래식 배포)를 삭제하고 새 VPN 게이트웨이(Resource Manager)를 만들라는 알림이 표시될 수 있습니다. 고객이 조치를 취하지 않으면 기존 VPN Gateway(클래식 배포)의 서비스가 해제될 수 있습니다. 고객은 FAQ를 방문하여 추가 정보를 확인하고 클래식에서 Resource Manager로 마이그레이션하는 동안 가동 중지 시간을 최소화할 수 있습니다.

Resource Manager 모델은 클래식 모델과 다르며 가상 네트워크 게이트웨이, 로컬 네트워크 게이트웨이 및 연결 리소스로 구성됩니다. 이것들은 각기 VPN 게이트웨이 자체를, 온-프레미스 주소 공간을 나타내는 로컬 사이트 및 둘 간의 연결을 나타냅니다. 마이그레이션이 완료되면 게이트웨이는 클래식 모델에서 사용할 수 없게 되며 가상 네트워크 게이트웨이, 로컬 네트워크 게이트웨이 및 연결 개체에서의 모든 관리 작업은 Resource Manager 모델을 사용하여 수행되어야 합니다.

지원되는 시나리오

가장 일반적인 VPN 연결 시나리오는 클래식에서 Resource Manager 마이그레이션에서 다뤄집니다. 지원하는 시나리오는 다음과 같습니다.

• 지점 및 사이트 간 연결
• 온-프레미스 위치에 연결된 VPN Gateway를 사용한 사이트 간 연결
• VPN Gateway를 사용한 두 VNet 사이의 VNet 간 연결
• 온-프레미스 위치의 같은 곳에 연결된 다중 VNet
• 다중 사이트 연결
• 강제 터널링 사용 설정된 VNet

지원되지 않는 시나리오는 다음과 같습니다.

• ExpressRoute 게이트웨이와 VPN Gateway가 모두 있는 VNet은 현재 지원되지 않습니다.
• VM 확장이 온-프레미스 서버에 연결된 시나리오를 전송합니다. 전송 시 VPN 연결 제한은 다음 섹션에서 자세히 설명합니다.

참고 항목

Resource Manager 모델의 CIDR 유효성 검사는 기존 모델에 비해 더 엄격합니다. 마이그레이션하기 전에, 마이그레이션을 시작하기 전에 제공된 클래식 주소 범위가 유효한 CIDR 형식을 준수하는지 확인하세요. CIDR는 일반적인 CIDR 유효성 검사기를 사용하여 유효성을 검사할 수 있습니다. 마이그레이션할 때 잘못된 CIDR 범위가 있는 VNet 또는 로컬 사이트는 실패 상태가 됩니다.

VNet 간 연결 마이그레이션

클래식 배포 모델의 VNet 간 연결은 연결된 VNet의 로컬 사이트 표현을 만들어 구현하였습니다. 고객은 함께 연결해야 하는 두 VNet을 나타내는 두 개의 로컬 사이트를 만들어야 했습니다. 그런 다음 이 사이트들은 두 Vnet간 연결을 설정하기 위해 IPsec 터널을 사용하여 해당 Vnet에 연결되었습니다. 이 모델에서는 하나의 VNet에서 주소 범위가 변경되는 경우 해당 로컬 사이트 표시에서도 유지되어야 하므로 관리 효율성 문제가 있습니다. Resource Manager 모델에서 이 해결 방법은 더 이상 필요하지 않습니다. 두 VNet 간의 연결은 연결 리소스에서 'Vnet2Vnet' 연결 형식을 사용하여 직접 구현할 수 있습니다.

VNet 마이그레이션 중에 현재 VNet의 VPN 게이트웨이에 연결된 엔터티가 다른 VNet임을 감지합니다. 두 VNet의 마이그레이션이 완료되면 다른 VNet을 나타내는 두 개의 로컬 사이트가 더 이상 표시되지 않습니다. 두 VPN Gateway, 두 로컬 사이트 및 이들 간의 두 연결로 이뤄진 클래식 모델은 두 VPN Gateway 및 Vnet2Vnet 형식의 두 연결로 이뤄진 Resource Manager 모델로 변환됩니다.

전송 시 VPN 연결

VNet에 대한 온-프레미스 연결이 온-프레미스에 직접 연결된 또 다른 VNet에 연결하여 구현되도록 토폴로지에서 VPN 게이트웨이를 구성할 수 있습니다. 이는 첫 번째 VNet의 인스턴스가 온-프레미스에 직접 연결된 VNet의 VPN Gateway로의 전송을 통해 온-프레미스 리소스에 연결되는 전송 VPN 연결입니다. 클래식 배포 모델에서 이 구성을 구현하려면 연결된 VNet 및 온-프레미스 주소 공간을 나타내는 집계된 접두사가 있는 로컬 사이트를 만들어야 합니다. 그런 다음 이 대표적 로컬 사이트는 전송 연결을 구축하기 위해 VNet에 연결됩니다. 또한 이 클래식 모델에는 온-프레미스 주소 범위의 변경 내용이 VNet 및 온-프레미스의 집계를 나타내는 로컬 사이트에도 유지되어야 하므로 비슷한 관리 효율성 문제가 있습니다. Resource Manager가 지원되는 게이트웨이에서 BGP 지원 도입은 연결된 게이트웨이가 접두사를 수동 수정하지 않고도 온-프레미스에서 경로를 알 수 있으므로 관리 효율성을 간소화합니다.

로컬 사이트 없이 VNet 간 연결을 변환하기 때문에, 전송 시나리오에서는 온-프레미스에 간접 연결된 VNet에 대한 온-프레미스 연결이 손실됩니다. 연결 손실은 마이그레이션이 완료된 후 다음 두 가지 방법으로 완화될 수 있습니다.

• 함께 연결된 VPN Gateway 및 온-프레미스 위치에서 BGP를 사용하도록 설정합니다. BGP를 사용하도록 설정하면 경로가 VNet 게이트웨이 간에 학습되고 보급되기 때문에 다른 구성 변경 없이 연결이 복원됩니다. BGP 옵션은 표준 및 상위 SKU에서만 사용할 수 있습니다.
• 영향을 받는 VNet에서 온-프레미스 위치를 나타내는 로컬 네트워크 게이트웨이로 명시적 연결을 설정합니다. 또한 IPsec 터널을 만들고 구성하기 위해 온-프레미스 라우터에서 구성을 변경해야 합니다.

다음 단계

VPN 게이트웨이 마이그레이션 지원에 대해 학습한 후에 시작하려면 클래식에서 Resource Manager로 IaaS 리소스의 플랫폼 지원 마이그레이션으로 이동합니다.