VPN Gateway FAQ

  • 아티클

이 문서에서는 Azure VPN 게이트웨이 크로스-프레미스 연결, 하이브리드 구성 연결 및 VNet(가상 네트워크) 게이트웨이에 대한 질문과 대답을 제공합니다. 여기에는 IPsec(인터넷 프로토콜 보안) 및 IKE(인터넷 키 교환) 프로토콜을 포함하여 P2S(지점 및 사이트 간), S2S(사이트 간) 및 VNet 간 구성 설정에 대한 포괄적인 정보가 포함되어 있습니다.

가상 네트워크에 연결

다양한 Azure 지역에서 가상 네트워크를 연결할 수 있습니까?

예. 지역 제약 조건이 없습니다. 한 가상 네트워크는 동일한 Azure 지역 또는 다른 지역의 다른 가상 네트워크에 연결할 수 있습니다.

다른 구독의 가상 네트워크를 연결할 수 있습니까?

예.

VPN 게이트웨이를 구성할 때 VNet에서 프라이빗 DNS 서버를 지정할 수 있나요?

가상 네트워크를 만들 때 DNS(도메인 이름 시스템) 서버 또는 서버를 지정하는 경우 VPN(가상 사설망) 게이트웨이는 이러한 DNS 서버를 사용합니다. 지정된 DNS 서버가 Azure에 필요한 도메인 이름을 확인할 수 있는지 확인합니다.

단일 가상 네트워크에서 여러 사이트에 연결할 수 있습니까?

Windows PowerShell 및 Azure REST API를 사용하여 여러 사이트에 연결할 수 있습니다. 다중 사이트 및 VNet 간 연결 FAQ 섹션을 참조하세요.

VPN 게이트웨이를 활성-활성으로 설정기 위한 추가 비용이 있나요?

아니요. 그러나 추가 공용 IP에 대한 비용은 그에 따라 청구됩니다. IP 주소 가격 책정을 참조하세요.

내 프레미스 간 연결 옵션은 무엇입니까?

Azure VPN Gateway는 다음과 같은 프레미스 간 게이트웨이 연결을 지원합니다.

VPN 게이트웨이 연결에 대한 자세한 내용은 Azure VPN 게이트웨이란?을 참조하세요.

사이트 간 연결과 지점 및 사이트 간 연결의 차이점은 무엇인가요?

  • 사이트 간(IPsec/IKE VPN 터널) 구성은 온-프레미스 위치와 Azure 사이에 있습니다. 라우팅 및 사용 권한을 구성하는 방법에 따라 온-프레미스에 있는 모든 컴퓨터에서 가상 네트워크 내의 모든 VM(가상 머신) 또는 역할 인스턴스에 연결할 수 있습니다. 이 연결은 항상 사용할 수 있는 프레미스 간 연결에 유용한 옵션이며 하이브리드 구성에 적합합니다.

    이러한 유형의 연결은 IPsec VPN 어플라이언스(하드웨어 디바이스 또는 소프트 어플라이언스)를 사용합니다. 어플라이언스는 네트워크의 가장자리에 배포되어야 합니다. 이 형식의 연결을 만들려면 외부 연결 IPv4 주소가 있어야 합니다.

  • 지점 및 사이트 간(SSTP를 통한 VPN) 구성을 사용하면 모든 위치의 단일 컴퓨터에서 가상 네트워크에 있는 모든 컴퓨터에 연결할 수 있습니다. Windows 기본 제공 VPN 클라이언트를 사용합니다.

    지점 및 사이트 간의 구성의 일부로 인증서 및 VPN 클라이언트 구성 패키지를 설치합니다. 패키지에는 컴퓨터가 가상 네트워크 내의 모든 가상 머신 또는 역할 인스턴스에 연결할 수 있는 설정이 포함되어 있습니다.

    이 구성은 가상 네트워크에 연결하려고 하지만 온-프레미스에 없는 경우에 유용합니다. 사이트 간 연결에 필요한 VPN 하드웨어 또는 외부 연결 IPv4 주소에 액세스할 수 없을 때 유용한 옵션입니다.

게이트웨이에 대한 경로 기반 VPN 유형을 사용하여 사이트 간 연결을 만드는 한 사이트 간 및 지점 및 사이트 간 연결을 동시에 사용하도록 가상 네트워크를 구성할 수 있습니다. 경로 기반 VPN 유형은 클래식 배포 모델에서 동적 게이트웨이라고 합니다.

사용자 지정 DNS를 잘못 구성하면 VPN 게이트웨이의 정상적인 작동이 중단됩니까?

정상적인 작동을 위해 VPN 게이트웨이는 공용 IP 주소를 통해 용이하게 Azure 컨트롤 플레인과 보안 연결을 설정해야 합니다. 이 연결은 공용 URL을 통한 통신 엔드포인트 확인 여부에 따라 다릅니다. 기본적으로 Azure VNet은 기본 제공 Azure DNS 서비스(168.63.129.16)를 사용하여 이러한 공용 URL을 확인합니다. 이 기본 동작은 VPN 게이트웨이와 Azure 컨트롤 플레인 간의 원활한 통신을 보장하는 데 도움이 됩니다.

VNet 내에서 사용자 지정 DNS를 구현하는 경우 Azure DNS(168.63.129.16)를 가리키는 DNS 전달자를 구성하는 것이 중요합니다. 이 구성은 VPN 게이트웨이와 컨트롤 플레인 간의 중단 없는 통신을 유지하는 데 도움이 됩니다. Azure DNS에 DNS 전달자를 설정하지 못하면 Microsoft가 VPN 게이트웨이에서 작업 및 유지 관리를 수행하지 못하게 되어 보안 위험이 발생합니다.

VPN 게이트웨이에 대한 적절한 기능과 정상 상태를 보장하려면 VNet에서 다음 DNS 구성 중 하나를 고려합니다.

  • VNet 설정 내에서 사용자 지정 DNS를 제거하여 Azure DNS 기본값으로 되돌려 줍니다(권장 구성).
  • 사용자 지정 DNS 구성에 Azure DNS를 가리키는 DNS 전달자(168.63.129.16)를 추가합니다. 사용자 지정 DNS의 특정 규칙 및 특성에 따라 이 설정은 예상대로 문제를 해결하지 못할 수 있습니다.

지점 및 사이트 간 연결이 동일한 VPN 게이트웨이에 연결된 두 VPN 클라이언트가 통신할 수 있나요?

아니요. 지점 및 사이트에서 동일한 VPN 게이트웨이에 연결된 VPN 클라이언트는 서로 통신할 수 없습니다.

두 VPN 클라이언트가 동일한 지점 및 사이트 간 VPN 게이트웨이에 연결된 경우 게이트웨이는 각 클라이언트가 주소 풀에서 할당된 IP 주소를 확인하여 트래픽을 자동으로 라우팅할 수 있습니다. 그러나 VPN 클라이언트가 다른 VPN 게이트웨이에 연결된 경우 각 VPN 게이트웨이가 클라이언트에 할당된 다른 게이트웨이의 IP 주소를 인식하지 못하기 때문에 VPN 클라이언트 간의 라우팅은 불가능합니다.

"터널 비전"으로 알려진 잠재적 취약성이 지점 및 사이트 간의 VPN 연결에 영향을 줄 수 있나요?

Microsoft는 VPN 캡슐화를 우회하는 네트워크 기술에 대한 보고서를 알고 있습니다. 이것은 업계 전반의 문제입니다. RFC 사양에 따라 DHCP(동적 호스트 구성 프로토콜) 클라이언트를 구현하고 Windows를 포함한 DHCP 옵션 121 경로를 지원하는 모든 운영 체제에 영향을 줍니다.

연구에 따르면 완화에는 로컬 네트워크의 DHCP 서버가 경로를 모두 설치하지 못하도록 가상화된 DHCP 서버에서 임대를 가져오는 VM 내에서 VPN을 실행하는 것이 포함됩니다. 이 취약성에 대한 자세한 내용은 NIST 국가 취약성 데이터베이스에서 찾을 수 있습니다.

개인 정보 보호

VPN 서비스에서 고객 데이터를 저장하거나 처리하나요?

아니요.

가상 네트워크 게이트웨이

VPN Gateway는 가상 네트워크 게이트웨이인가요?

VPN Gateway는 가상 네트워크 게이트웨이의 유형입니다. VPN Gateway는 공용 연결을 통해 가상 네트워크와 온-프레미스 위치 간에 암호화된 트래픽을 전송합니다. 또한 VPN 게이트웨이를 사용하여 가상 네트워크 간에 트래픽을 전송할 수 있습니다. VPN 게이트웨이를 만들 때 -GatewayType 값 Vpn을 사용합니다. 자세한 내용은 VPN Gateway 구성 설정 정보를 참조하세요.

정책 기반 및 경로 기반 VPN 형식을 지정할 수 없는 이유는 무엇인가요?

2023년 10월 1일부터 Azure Portal을 통해 정책 기반 VPN 게이트웨이를 만들 수 없습니다. 모든 새 VPN 게이트웨이는 경로 기반으로 자동으로 만들어집니다. 정책 기반 게이트웨이가 이미 있으면 게이트웨이를 경로 기반으로 업그레이드할 필요가 없습니다. Azure PowerShell 또는 Azure CLI를 사용하여 정책 기반 게이트웨이를 만들 수 있습니다.

이전에는 이전 SKU(게이트웨이 제품 계층)에서 경로 기반 게이트웨이에 대해 IKEv1을 지원하지 않았습니다. 이제 대부분의 현재 게이트웨이 SKU에서 IKEv1 및 IKEv2 모두 지원합니다.

게이트웨이 VPN 유형 게이트웨이 SKU 지원되는 IKE 버전
정책 기반 게이트웨이 Basic IKEv1
경로 기반 게이트웨이 Basic IKEv2
경로 기반 게이트웨이 VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 및 IKEv2
경로 기반 게이트웨이 VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 및 IKEv2

정책 기반 VPN Gateway를 경로 기반으로 업데이트할 수 있나요?

아니요. 게이트웨이 형식은 정책 기반에서 경로 기반으로 변경하거나 경로 기반에서 정책 기반으로 변경할 수 없습니다. 게이트웨이 유형을 변경하려면 다음 단계를 수행하여 게이트웨이를 삭제하고 다시 만들어야 합니다. 이 프로세스는 60분 정도 걸립니다. 새 게이트웨이를 만들 때 원래 게이트웨이의 IP 주소를 유지할 수 없습니다.

  1. 게이트웨이와 연결된 모든 연결을 삭제합니다.

  2. 다음 문서 중 하나를 사용하여 게이트웨이를 삭제합니다.

  3. 원하는 게이트웨이 유형을 사용하여 새 게이트웨이를 만든 다음 VPN 설정을 완료합니다. 단계는 사이트 및 사이트 간의 자습서를 참조하세요.

자체 정책 기반 트래픽 선택기를 지정할 수 있나요?

예, New-AzIpsecTrafficSelectorPolicy Azure PowerShell 명령을 통한 연결에서 trafficSelectorPolicies 특성을 사용하여 트래픽 선택기를 정의할 수 있습니다. 지정한 트래픽 선택기를 적용하려면 정책 기반 트래픽 선택기를 사용하도록 설정해야 합니다.

사용자 지정 구성 트래픽 선택기는 VPN 게이트웨이가 연결을 시작하는 경우에만 제안됩니다. VPN 게이트웨이는 원격 게이트웨이(온-프레미스 VPN 디바이스)에서 제안한 모든 트래픽 선택기를 허용합니다. 이 동작은 모든 연결 모드(Default, InitiatorOnly 및 ResponderOnly)에서 일치합니다.

게이트웨이 서브넷이 필요한가요?

예. 게이트웨이 서브넷은 가상 네트워크 게이트웨이 서비스가 사용하는 IP 주소를 포함합니다. 가상 네트워크 게이트웨이를 구성하려면 가상 네트워크에서 사용할 게이트웨이 서브넷을 만들어야 합니다.

제대로 작동하려면 모든 게이트웨이 서브넷의 이름을 GatewaySubnet(으)로 지정해야 합니다. 게이트웨이 서브넷에 다른 이름을 지정하지 않습니다. 게이트웨이 서브넷에 VM 또는 다른 항목을 배포하지 않습니다.

게이트웨이 서브넷을 만드는 경우 서브넷이 포함하는 IP 주소의 수를 지정합니다. 게이트웨이 서브넷의 IP 주소는 게이트웨이 서비스에 할당됩니다.

일부 구성은 게이트웨이 서비스에 다른 구성보다 더 많은 IP 주소가 할당되어야 합니다. 게이트웨이 서브넷에 향후 증가 및 가능한 새 연결 구성을 수용할 수 있는 충분한 IP 주소가 포함되어 있는지 확인합니다.

게이트웨이 서브넷을 /29만큼 작게 만들 수 있지만 /27 이상의 게이트웨이 서브넷(/27, /26, /25 등)을 만드는 것이 좋습니다. 기존 게이트웨이 서브넷이 만들려는 구성에 대한 요구 사항을 충족하는지 확인합니다.

내 게이트웨이 서브넷에 가상 머신 또는 역할 인스턴스를 배포할 수 있나요?

아니요.

VPN 게이트웨이 IP 주소를 만들기 전에 내 VPN 게이트웨이 IP 주소를 가져올 수 있나요?

Azure Standard SKU 공용 IP 리소스는 정적 할당 방법을 사용해야 합니다. 사용하려는 표준 SKU 공용 IP 리소스를 만드는 즉시 VPN 게이트웨이에 대한 공용 IP 주소를 갖게 됩니다.

내 VPN 게이트웨이에 고정 공용 IP 주소를 요청할 수 있나요?

표준 SKU 공용 IP 주소 리소스는 정적 할당 방법을 사용합니다. 앞으로 새 VPN 게이트웨이를 만들 때 표준 SKU 공용 IP 주소를 사용해야 합니다. 이 요구 사항은 기본 SKU를 제외한 모든 게이트웨이 SKU에 적용됩니다. 기본 SKU는 현재 기본 SKU 공용 IP 주소만 지원합니다. 기본 SKU에 대한 표준 SKU 공용 IP 주소에 대한 지원을 추가하기 위해 노력하고 있습니다.

이전에 만든 비영역 중복 및 비영역 게이트웨이(이름에 AZ 없는 게이트웨이 SKU)의 경우 동적 IP 주소 할당이 지원되지만 단계적으로 폐지되고 있습니다. 동적 IP 주소를 사용하는 경우 IP 주소가 VPN 게이트웨이에 할당된 후에는 변경되지 않습니다. VPN 게이트웨이 IP 주소가 변경되는 유일한 경우는 게이트웨이를 삭제한 다음 다시 만드는 시간입니다. VPN 게이트웨이의 다른 내부 유지 관리 및 업그레이드의 크기를 조정, 다시 설정 또는 완료할 때 공용 IP 주소는 변경되지 않습니다.

기본 SKU 공용 IP 주소가 사용 중지되면 내 VPN 게이트웨이에 어떤 영향을 주나요?

2025년 9월 기본 IP가 사용 중지될 때까지 기본 SKU 공용 IP 주소를 사용하는 배포된 VPN 게이트웨이의 지속적인 작동을 보장하기 위한 조치를 취하고 있습니다. 이 사용 중지 전에 고객에게 기본에서 표준 IP로의 마이그레이션 경로를 제공합니다.

그러나 기본 SKU 공용 IP 주소는 단계적으로 폐지되고 있습니다. 앞으로 VPN 게이트웨이를 만들 때 표준 SKU 공용 IP 주소를 사용해야 합니다. Azure 업데이트 공지에서 기본 SKU 공용 IP 주소의 사용 중지에 대한 세부 정보를 확인할 수 있습니다.

내 VPN 터널은 어떻게 인증됩니까?

Azure VPN 게이트웨이는 PSK(사전 공유 키) 인증을 사용합니다. VPN 터널을 만들 때 PSK를 생성합니다. 미리 공유된 키 REST API 또는 PowerShell cmdlet을 사용하여 자동으로 생성된 PSK를 사용자 고유로 변경할 수 있습니다.

미리 공유된 키 REST API를 사용하여 정책 기반(정적 라우팅) 게이트웨이 VPN을 구성할 수 있나요?

예. 미리 공유된 키 REST API 및 PowerShell cmdlet을 사용하여 Azure 정책 기반(정적) VPN과 경로 기반(동적) 라우팅 VPN을 모두 구성할 수 있습니다.

다른 인증 옵션을 사용할 수 있습니까?

인증에 미리 공유된 키를 사용하는 것으로 제한됩니다.

VPN 게이트웨이를 통해 전송되는 트래픽을 지정하려면 어떻게 해야 합니까?

Azure Resource Manager 배포 모델의 경우:

  • Azure PowerShell: AddressPrefix(을)를 사용하여 로컬 네트워크 게이트웨이에 대한 트래픽을 지정합니다.
  • Azure Portal: 로컬 네트워크 게이트웨이>구성>주소 공간으로 이동합니다.

클래식 배포 모델:

  • Azure Portal: 클래식 가상 네트워크로 이동한 다음 VPN 연결>사이트간 VPN 연결>로컬 사이트 이름>로컬 사이트>클라이언트 주소 공간으로 이동합니다.

내 VPN 연결에서 NAT-T를 사용할 수 있나요?

예, NAT-T(네트워크 주소 변환 통과)가 지원됩니다. Azure VPN 게이트웨이는 IPsec 터널을 오가는 내부 패킷에서 NAT와 유사한 기능을 수행할 수 없습니다. 이 구성에서 온-프레미스 디바이스가 IPSec 터널을 시작하는지 확인합니다.

Azure에서 내 VPN 서버를 설정하여 온-프레미스 네트워크에 연결하는 데 사용할 수 있습니까?

예. Azure Marketplace에서 또는 사용자 고유의 VPN 라우터를 만들어 Azure에 고유한 VPN 게이트웨이 또는 서버를 배포할 수 있습니다. 트래픽이 온-프레미스 네트워크와 가상 네트워크 서브넷 간에 올바르게 라우팅되도록 가상 네트워크에서 사용자 정의 경로를 구성해야 합니다.

내 가상 네트워크 게이트웨이에서 특정 포트가 열리는 이유는?

Azure 인프라 통신을 위해 필요합니다. Azure 인증서는 인증서를 잠가 보호합니다. 적절한 인증서가 없으면 해당 게이트웨이의 고객을 포함한 외부 엔터티가 해당 엔드포인트에 영향을 줄 수 없습니다.

가상 네트워크 게이트웨이는 기본적으로 멀티호밍 디바이스입니다. 하나의 네트워크 어댑터가 고객 프라이빗 네트워크를 탭하고, 하나의 네트워크 어댑터가 공용 네트워크에 연결됩니다. Azure 인프라 엔터티는 규정 준수를 위해 고객 프라이빗 네트워크를 활용할 수 없으므로 인프라 통신에 공용 엔드포인트를 사용해야 합니다. Azure 보안 감사는 퍼블릭 엔드포인트를 주기적으로 검사합니다.

포털에서 기본 SKU를 사용하여 VPN 게이트웨이를 만들 수 있나요?

아니요. 기본 SKU를 포털에서 사용할 수 없습니다. Azure CLI 또는 Azure PowerShell 단계를 사용하여 기본 SKU VPN 게이트웨이를 만들 수 있습니다.

게이트웨이 유형, 요구 사항 및 처리량에 대한 정보를 어디서 찾을 수 있나요?

다음 문서를 참조하세요.

이전 SKU 사용 중단

표준 및 고성능 SKU는 2025년 9월 30일부터 사용되지 않습니다. Azure 업데이트 사이트에서 공지를 볼 수 있습니다. 제품 팀은 2024년 11월 30일까지 이러한 SKU에 마이그레이션 경로를 사용할 수 있도록 합니다. 자세한 내용은 VPN Gateway 레거시 SKU 문서를 참조하세요.

현재 수행해야 하는 작업은 없습니다.

2023년 11월 30일 사용 중단 공지 사항 이후 표준 또는 고성능 SKU를 사용하는 새 게이트웨이를 만들 수 있나요?

아니요. 2023년 12월 1일부터 표준 또는 고성능 SKU를 사용하는 게이트웨이를 만들 수 없습니다. 가격 책정 페이지에 각각 나열된 표준 및 고성능 SKU와 동일한 가격 책정으로 VpnGw1 및 VpnGw2 SKU를 사용하는 게이트웨이를 만들 수 있습니다.

표준 및 고성능 SKU에서 기존 게이트웨이가 얼마나 오랫동안 지원되나요?

표준 또는 고성능 SKU를 사용하는 모든 기존 게이트웨이는 2025년 9월 30일까지 지원됩니다.

지금 표준 또는 고성능 SKU에서 게이트웨이를 마이그레이션해야 하나요?

지금 수행해야 하는 작업은 없습니다. 2024년 12월부터 게이트웨이를 마이그레이션할 수 있습니다. Microsoft는 마이그레이션 단계에 대한 자세한 문서를 제공할 예정입니다.

게이트웨이를 마이그레이션할 수 있는 SKU는 무엇인가요?

게이트웨이 SKU 마이그레이션을 사용할 수 있게 되면 다음과 같이 SKU를 마이그레이션할 수 있습니다.

  • 표준에서 VpnGw1로
  • 고성능에서 VpnGw2로

AZ SKU로 마이그레이션하려면 어떻게 해야 하나요?

더 이상 사용되지 않는 SKU를 AZ SKU로 마이그레이션할 수 없습니다. 그러나 2025년 9월 30일 이후에도 표준 또는 고성능 SKU를 사용하는 모든 게이트웨이는 다음과 같이 자동으로 AZ SKU로 마이그레이션 및 업그레이드됩니다.

  • 표준에서 VpnGw1AZ로
  • 고성능에서 VpnGw2AZ로

이 전략을 사용하여 SKU를 자동으로 마이그레이션하고 AZ SKU로 업그레이드할 수 있습니다. 그런 다음, 필요한 경우 해당 SKU 제품군 내에서 SKU 크기를 조정할 수 있습니다. AZ SKU 가격 책정은 가격 책정 페이지를 참조하세요. SKU별 처리량 정보는 게이트웨이 SKU 정보를 참조하세요.

마이그레이션 후 게이트웨이 가격에 차이가 있나요?

2025년 9월 30일까지 SKU를 마이그레이션하는 경우에는 가격 차이가 없습니다. VpnGw1 및 VpnGw2 SKU는 각각 표준 및 고성능 SKU와 같은 가격으로 제공됩니다.

해당 날짜까지 마이그레이션하지 않으면 SKU가 자동으로 마이그레이션되고 AZ SKU로 업그레이드됩니다. 이 경우 가격 차이가 발생합니다.

이 마이그레이션을 통해 게이트웨이 성능이 영향을 받나요?

예. VpnGw1 및 VpnGw2를 사용하면 성능이 향상됩니다. 현재 650Mbps의 VpnGw1은 표준 SKU와 동일한 가격으로 6.5배 개선된 성능을 제공합니다. 1Gbps의 VpnGw2는 고성능 SKU와 동일한 가격으로 5배 개선된 성능을 제공합니다. SKU 처리량에 대한 자세한 내용은 게이트웨이 SKU 정보를 참조하세요.

2025년 9월 30일까지 마이그레이션하지 않으면 어떻게 되나요?

여전히 표준 또는 고성능 SKU를 사용하는 모든 게이트웨이는 자동으로 마이그레이션되어 다음 AZ SKU로 업그레이드됩니다.

  • 표준에서 VpnGw1AZ로
  • 고성능에서 VpnGw2AZ로

게이트웨이에서 마이그레이션을 시작하기 전에 통신을 보내드립니다.

VPN 게이트웨이 기본 SKU도 사용 중지되나요?

아니요, VPN 게이트웨이 기본 SKU는 사용 중지되지 않습니다. Azure PowerShell 또는 Azure CLI를 통해 기본 SKU를 사용하여 VPN 게이트웨이를 만들 수 있습니다.

현재 VPN 게이트웨이 기본 SKU는 기본 SKU 공용 IP 주소 리소스(사용 중지 예정)만 지원합니다. VPN 게이트웨이 기본 SKU에 표준 SKU 공용 IP 주소 리소스에 대한 지원을 추가하기 위해 노력하고 있습니다.

사이트 간 연결 및 VPN 디바이스

VPN 디바이스를 선택할 때 고려할 사항은 무엇입니까?

디바이스 공급업체와 협력하여 표준 사이트 간 VPN 디바이스의 유효성을 검사했습니다. 알려진 호환 VPN 디바이스 목록, 해당 구성 지침 또는 샘플 및 디바이스 사양은 VPN 디바이스 정보 문서에서 찾을 수 있습니다.

호환하는 것으로 알려진 목록의 디바이스 제품군에 포함된 모든 디바이스는 Virtual Network에서 작동합니다. VPN 디바이스를 구성하려면 적절한 디바이스 제품군에 해당하는 디바이스 구성 샘플 또는 링크를 참조하세요.

VPN 디바이스 구성 설정을 어디서 찾을 수 있나요?

사용하고 있는 VPN 디바이스에 따라 VPN 디바이스 구성 스크립트를 다운로드할 수 있습니다. 자세한 내용은 VPN 디바이스 구성 스크립트 다운로드를 참조하세요.

다음 링크는 추가 구성 정보를 제공합니다.

VPN 디바이스 구성 샘플을 편집하려면 어떻게 하나요?

디바이스 구성 샘플 편집을 참조하세요.

IPsec 및 IKE 매개 변수를 어디서 찾을 수 있나요?

기본 IPsec/IKE 매개 변수를 참조하세요.

트래픽이 유휴 상태일 때 정책 기반 VPN 터널이 다운되는 이유는 무엇인가요?

이 동작은 정책 기반(정적 라우팅이라고도 함) VPN 게이트웨이에 대해 필요합니다. 터널을 통해 트래픽이 5 분 이상 유휴 상태이면 터널이 철거됩니다. 트래픽이 어느 방향으로든지 흐르기 시작되면 터널이 즉시 다시 설정됩니다.

소프트웨어 VPN을 사용하여 Azure에 연결할 수 있습니까?

사이트 간 크로스-프레미스 구성을 위해 Windows Server 2012 라우팅 및 원격 액세스 서버를 지원합니다.

다른 소프트웨어 VPN 솔루션은 업계 표준 IPsec 구현을 준수하는 한 게이트웨이에서 작동해야 합니다. 구성 및 지원 지침은 소프트웨어 공급업체에 문의하세요.

사이트 간 연결이 활성인 사이트에 있는 경우 지점 및 사이트 간을 통해 VPN 게이트웨이에 연결할 수 있나요?

예, 하지만 지점 및 사이트 간 클라이언트의 공용 IP 주소는 사이트 간 VPN 디바이스에서 사용하는 공용 IP 주소와 달라야 합니다. 그렇지 않으면 지점 및 사이트 간 연결이 작동하지 않습니다. IKEv2를 사용한 지점 및 사이트 간의 연결은 동일한 VPN 게이트웨이에서 사이트 및 사이트 간의 VPN 연결이 구성된 동일한 공용 IP 주소에서 시작할 수 없습니다.

지점 및 사이트 간 연결

지점 및 사이트 간 구성에서 VPN 클라이언트 엔드포인트를 몇 개까지 지정할 수 있나요?

게이트웨이 SKU에 따라 다릅니다. 지원되는 연결 수에 대한 자세한 내용은 게이트웨이 SKU를 참조하세요.

지점 및 사이트 간 연결에 사용할 수 있는 클라이언트 운영 체제는 무엇인가요?

다음과 같은 클라이언트 운영 체제가 지원됩니다.

  • Windows Server 2008 R2(64비트 전용)
  • Windows 8.1(32비트 및 64비트)
  • Windows Server 2012(64비트 전용)
  • Windows Server 2012 R2(64비트 전용)
  • Windows Server 2016(64비트 전용)
  • Windows Server 2019(64비트 전용)
  • Windows Server 2022(64비트만 해당)
  • Windows 10
  • Windows 11
  • macOS 버전 10.11 이상
  • Linux(strongSwan)
  • iOS

지점 및 사이트 간의 기능을 사용하여 프록시 및 방화벽을 트래버스할 수 있나요?

Azure에서는 세 가지 형식의 지점 및 사이트 간 VPN 옵션을 지원합니다.

  • SSTP(Secure Socket Tunneling Protocol): 대부분의 방화벽이 443 SSL에서 사용하는 아웃바운드 TCP 포트를 열기 때문에 방화벽을 관통할 수 있는 Microsoft 전용 SSL 기반 솔루션입니다.

  • OpenVPN: 대부분의 방화벽이 443 SSL에서 사용하는 아웃바운드 TCP 포트를 열기 때문에 방화벽을 관통할 수 있는 SSL 기반 솔루션입니다.

  • IKEv2 VPN: IP 프로토콜 번호 50과 함께 아웃바운드 UDP 포트 500 및 4500을 사용하는 표준 기반 IPsec VPN 솔루션입니다. 방화벽이 항상 이러한 포트를 열지는 않으므로 IKEv2 VPN이 프록시 및 방화벽을 트래버스할 수 없는 가능성이 있습니다.

지점 및 사이트로 구성한 클라이언트 컴퓨터를 다시 시작하면 VPN이 자동으로 다시 연결될까요?

자동 다시 연결은 사용하는 클라이언트의 함수입니다. Windows는 Always On VPN 클라이언트 기능을 통한 자동 다시 연결을 지원합니다.

지점 및 사이트 간 연결이 VPN 클라이언트에서 DDNS를 지원하나요?

DDNS(동적 DNS)는 현재 지점 및 사이트 간의 VPN에서 지원되지 않습니다.

사이트 및 지점 및 사이트 간의 구성이 동일한 가상 네트워크에 공존할 수 있나요?

예. Resource Manager 배포 모델의 경우 게이트웨이에 대한 경로 기반 VPN 유형이 있어야 합니다. 클래식 배포 모델의 경우 동적 게이트웨이가 필요합니다. 정적 라우팅 VPN 게이트웨이 또는 정책 기반 VPN 게이트웨이에 대한 지점 및 사이트 간의 지원은 없습니다.

지점 및 사이트 간 클라이언트를 여러 가상 네트워크 게이트웨이에 동시에 연결하도록 구성할 수 있나요?

사용하는 VPN 클라이언트 소프트웨어에 따라 여러 가상 네트워크 게이트웨이에 연결할 수 있습니다. 그러나 연결하려는 가상 네트워크에 해당 네트워크 간 또는 클라이언트가 연결하는 네트워크 간에 충돌하는 주소 공간이 없는 경우에만 해당됩니다. Azure VPN 클라이언트는 많은 VPN 연결을 지원하지만 언제든지 하나의 연결만 가질 수 있습니다.

지점 및 사이트 간 클라이언트를 동시에 여러 가상 네트워크에 연결되도록 구성할 수 있나요?

예. 다른 VNet과 피어된 VNet에 배포된 VPN 게이트웨이에 대한 지점 및 사이트 간 클라이언트 연결은 특정 구성 조건을 충족하는 한 피어된 다른 VNet에 액세스할 수 있습니다. 지점 및 사이트 간의 클라이언트가 피어된 VNet에 액세스할 수 있도록 하려면 피어된 VNet(게이트웨이가 없는 VNet)을 원격 게이트웨이 특성을 사용하여 구성해야 합니다. VPN 게이트웨이가 있는 VNet은 게이트웨이 전송 허용으로 구성해야 합니다. 자세한 내용은 지점 및 사이트 간 VPN 라우팅 정보를 참조하세요.

사이트 대 사이트 또는 지점 및 사이트 간의 연결을 통해 예상할 수 있는 처리량은 어느 정도인가요?

VPN 터널의 정확한 처리량을 유지하는 것은 어렵습니다. IPsec과 SSTP는 암호화 중심 VPN 프로토콜입니다. 또한 프레미스와 인터넷 간의 대기 시간 및 대역폭은 처리량을 제한할 수 있습니다.

IKEv2 지점 및 사이트간 VPN 연결만 있는 VPN 게이트웨이의 경우 예상할 수 있는 총 처리량은 게이트웨이 SKU에 따라 달라집니다. 처리량에 대한 자세한 내용은 게이트웨이 SKU를 참조하세요.

SSTP 또는 IKEv2를 지원하는 지점 및 사이트에 소프트웨어 VPN 클라이언트를 사용할 수 있나요?

아니요. SSTP용 Windows의 네이티브 VPN 클라이언트와 IKEv2용 Mac의 네이티브 VPN 클라이언트만 사용할 수 있습니다. 그러나 모든 플랫폼에서 OpenVPN 클라이언트를 사용하여 OpenVPN 프로토콜을 통해 연결할 수 있습니다. 지원되는 클라이언트 운영 체제 목록을 참조하세요.

지점 및 사이트 간 연결의 인증 유형을 변경하려면 어떻게 할까요?

예. 포털에서 VPN 게이트웨이>지점과 사이트 간 구성으로 이동합니다. 인증 유형에 사용하려는 인증 유형을 선택합니다.

인증 유형을 변경한 후에는 새 VPN 클라이언트 구성 프로필을 생성하고 다운로드하여 각 VPN 클라이언트에 적용할 때까지 현재 클라이언트가 연결되지 않을 수 있습니다.

VPN 클라이언트 프로필에 대한 새 구성 패키지를 생성해야 하는 경우는 언제인가요?

터널 유형 추가 또는 인증 유형 변경과 같이 P2S VPN 게이트웨이에 대한 구성 설정을 변경하는 경우 VPN 클라이언트 프로필에 대한 새 구성 패키지를 생성해야 합니다. 새 패키지에는 VPN 클라이언트가 P2S 게이트웨이에 연결하는 데 필요한 업데이트된 설정이 포함되어 있습니다. 패키지를 생성한 후 파일의 설정을 사용하여 VPN 클라이언트를 업데이트합니다.

Azure는 Windows에서 IKEv2 VPN을 지원합니까?

IKEv2는 Windows 10 및 Windows Server 2016에서 지원됩니다. 그러나 특정 OS 버전에서 IKEv2를 사용하려면 업데이트를 설치하고 레지스트리 키 값을 로컬로 설정해야 합니다. Windows 10 이전 OS 버전은 지원되지 않으며 SSTP 또는 OpenVPN 프로토콜만 사용할 수 있습니다.

참고 항목

Windows OS 빌드는 Windows 10 버전 1709 및 Windows Server 2016 버전 1607보다 최신 버전이며 다음 단계가 필요하지 않습니다.

IKEv2용 Windows 10 또는 Windows Server 2016을 준비하려면 다음을 수행합니다.

  1. OS 버전에 따라 업데이트를 설치합니다.

    OS 버전 날짜 번호/링크
    Windows Server 2016
    Windows 10 버전 1607    		 2018년 1월 17일 KB4057142
    Windows 10 버전 1703 2018년 1월 17일 KB4057144
    Windows 10 버전 1709 2018년 3월 22일 KB4089848

  2. 레지스트리 키 값을 설정합니다. 레지스트리에서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD 키를 만들거나 설정하여 1 합니다.

지점 및 사이트 간 연결을 위한 IKEv2 트래픽 선택기에는 어떤 제한이 있나요?

Windows 10 버전 2004(2021년 9월에 출시)에서 트래픽 선택기 제한이 255로 상향되었습니다. 이전 버전의 Windows에는 트래픽 선택기 제한이 25개입니다.

Windows의 트래픽 선택기 제한에 따라 가상 네트워크의 최대 주소 공간 및 로컬 네트워크의 최대 합계, VNet 간 연결 수, 게이트웨이에 연결된 피어링된 VNet 수가 달라집니다. 이 제한을 초과하면 Windows 기반 지점 및 사이트 간 클라이언트가 IKEv2를 통해 연결할 수 없습니다.

지점 및 사이트 간 연결에 대한 OpenVPN 트래픽 선택기 제한은 무엇인가요?

OpenVPN의 트래픽 선택기 제한은 1,000개 경로입니다.

P2S VPN 연결에 대해 SSTP 및 IKEv2를 모두 구성되면 어떻게 되나요?

Windows 및 Mac 디바이스로 구성된 혼합 환경에서 SSTP와 IKEv2를 모두 구성하는 경우 Windows VPN 클라이언트는 항상 IKEv2 터널을 먼저 시도합니다. IKEv2 연결이 실패하면 클라이언트가 SSTP로 돌아갑니다. MacOS는 IKEv2를 통해서만 연결됩니다.

게이트웨이에서 SSTP와 IKEv2를 모두 사용하도록 설정하면 지점 및 사이트 간 주소 풀이 둘 간에 정적으로 분할되므로 서로 다른 프로토콜을 사용하는 클라이언트는 두 하위 범위의 IP 주소입니다. 주소 범위가 /24보다 크더라도 SSTP 클라이언트의 최대 수는 항상 128입니다. 그 결과 IKEv2 클라이언트에서 사용할 수 있는 주소 수가 더 많아집니다. 더 작은 범위의 경우 풀은 똑같이 절반으로 줄어듭니다. 게이트웨이에서 사용하는 트래픽 선택기에는 지점 및 사이트 간 주소 범위에 대한 클래스리스 CIDR(도메인 간 라우팅) 블록이 포함되지 않지만 두 하위 범위에 대한 CIDR 블록을 포함할 수 있습니다.

Azure에서 P2S VPN에 대해 지원하는 플랫폼은 무엇입니까?

Azure는 P2S VPN에 대해 Windows, Mac 및 Linux를 지원합니다.

VPN 게이트웨이가 이미 배포되어 있습니다. RADIUS 또는 IKEv2 VPN을 사용하도록 설정할 수 있나요?

예. 사용 중인 게이트웨이 SKU가 RADIUS 또는 IKEv2를 지원하는 경우 Azure PowerShell 또는 Azure Portal을 사용하여 이미 배포한 게이트웨이에서 이러한 기능을 사용하도록 설정할 수 있습니다. 기본 SKU는 RADIUS 또는 IKEv2를 지원하지 않습니다.

Azure VPN 클라이언트에서 연결이 끊어지는 이유는 무엇인가요? 연결 끊김 빈도를 줄이기 위해 무엇을 할 수 있나요?

다음 메시지 중 하나가 표시 될 수 있습니다.

  • Windows 용 Azure VPN 클라이언트에서 3.4.0.0: "Microsoft Entra를 사용한 인증이 만료되었습니다. 새 토큰을 얻으려면 Entra에서 다시 인증해야 합니다. 관리자가 인증 시간 제한을 조정할 수 있습니다."
  • macOS 용 Azure VPN 클라이언트에서 2.7.101: "Microsoft Entra에 대한 인증이 만료되었으므로 새 토큰을 획득하려면 다시 인증해야 합니다. 다시 연결해 보세요. 인증 정책 및 시간 제한은 Entra 테넌트에서 관리자가 구성합니다."

Entra ID에서 가져온 Azure VPN 클라이언트의 현재 새로 고침 토큰이 만료되었거나 유효하지 않으므로 지점 및 사이트 간의 연결이 끊어집니다. 이 토큰은 약 1시간마다 갱신됩니다. Entra 테넌트 관리자는 조건부 액세스 정책을 추가하여 로그인 빈도를 확장할 수 있습니다. 새로 고침 토큰 만료 간격을 연장하려면 Entra 테넌트 관리자에게 문의하세요.

자세한 내용은 VPN 클라이언트 오류: Microsoft Entra 인증이 만료되었습니다.

P2S 연결 구성을 제거하는 방법은 무엇인가요?

다음 Azure PowerShell 또는 Azure CLI 명령을 사용하여 P2S 구성을 제거할 수 있습니다.

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

인증서 인증을 사용한 지점 및 사이트 간의 연결

지점 및 사이트 간의 인증서 인증 연결에 대한 인증서 불일치가 발생하면 어떻게 해야 하나요?

인증서 확인란의 유효성을 검사하여 서버 ID를 확인합니다. 또는 프로필을 수동으로 만들 때 인증서와 함께 서버의 FQDN(정규화된 도메인 이름)을 추가합니다. 명령 프롬프트에서 rasphone(을)를 실행하고 드롭다운 목록에서 프로필을 선택하여 이 작업을 수행할 수 있습니다.

일반적으로 서버 ID의 유효성 검사를 무시하지 않는 것이 좋습니다. 그러나 Azure 인증서 인증을 사용하면 VPN 터널링 프로토콜(IKEv2 또는 SSTP) 및 EAP(Extensible Authentication Protocol)의 서버 유효성 검사에 동일한 인증서가 사용됩니다. VPN 터널링 프로토콜이 서버 인증서 및 FQDN의 유효성을 이미 검사하고 있으므로 EAP에서 다시 유효성을 검사하는 것은 중복됩니다.

지점 및 사이트 간의 인증에 대한 속성을 보여 주는 스크린샷.

지점 및 사이트 간 연결을 위한 인증서를 생성하기 위해 내부 PKI 루트 CA를 사용할 수 있나요?

예. 이전에는 자체 서명된 루트 인증서만 사용할 수 있습니다. 여전히 20개의 루트 인증서를 업로드할 수 있습니다.

Azure Key Vault의 인증서를 사용할 수 있습니까?

아니요.

인증서를 만들려면 어떤 도구를 사용합니까?

엔터프라이즈 PKI(공개 키 인프라) 솔루션(내부 PKI), Azure PowerShell, MakeCert 및 OpenSSL을 사용할 수 있습니다.

인증서 설정 및 매개 변수에 대한 지침이 있나요?

.cer 및 .pfx 파일 형식은 다음을 참조하세요.

.pem 파일 형식은 다음을 참조하세요.

RADIUS 인증을 사용한 지점 및 사이트 간의 연결

모든 Azure VPN Gateway SKU에서 RADIUS 인증이 지원되나요?

RADIUS 인증은 기본 SKU를 제외한 모든 SKU에 대해 지원됩니다.

이전 SKU의 경우 RADIUS 인증은 표준 및 고성능 SKU에서 지원됩니다.

클래식 배포 모델에 RADIUS 인증이 지원되나요?

아니요.

RADIUS 서버로 전송된 RADIUS 요청의 제한 시간은 얼마인가요?

RADIUS 요청은 30초 후에 시간 초과로 설정됩니다. 사용자 정의 시간 제한 값은 현재 지원되지 않습니다.

타사 RADIUS 서버가 지원되나요?

예.

Azure 게이트웨이가 온-프레미스 RADIUS 서버에 연결할 수 있도록 하기 위한 연결 요구 사항은 무엇인가요?

적절한 경로가 구성된 온-프레미스 사이트에 대한 사이트 및 사이트 간의 VPN 연결이 필요합니다.

온-프레미스 RADIUS 서버(VPN 게이트웨이에서)로의 트래픽을 ExpressRoute 연결을 통해 라우팅할 수 있나요?

아니요. 사이트-사이트 연결을 통해서만 라우팅할 수 있습니다.

RADIUS 인증을 사용하는 지원되는 SSTP 연결 수에 변경이 있나요? 지원되는 SSTP 및 IKEv2 연결의 최대 수는 무엇인가요?

RADIUS 인증을 사용하는 게이트웨이에서 지원되는 SSTP 연결의 최대 수는 변경되지 않습니다. SSTP의 경우 128로 유지되지만 IKEv2용 게이트웨이 SKU에 따라 달라집니다. 지원되는 연결 수에 대한 자세한 내용은 게이트웨이 SKU를 참조하세요.

RADIUS 서버를 통한 인증서 인증과 신뢰할 수 있는 인증서 업로드를 통한 Azure 네이티브 인증서 인증의 차이점은 무엇인가요?

RADIUS 인증서 인증에서 인증 요청은 인증서 유효성 검사를 처리하는 RADIUS 서버로 전달됩니다. 이 옵션은 이미 RADIUS를 통해 인증서 인증 인프라와 통합하려는 경우에 유용합니다.

인증서 인증에 Azure를 사용하는 경우 VPN 게이트웨이는 인증서의 유효성 검사를 수행합니다. 게이트웨이에 인증서 공개 키를 업로드해야 합니다. 연결할 수 없는 해지된 인증서 목록을 지정할 수도 있습니다.

RADIUS 인증은 다단계 인증을 위한 네트워크 정책 서버 통합을 지원하나요?

다단계 인증이 텍스트 기반(예: SMS 또는 모바일 앱 확인 코드)이고 사용자가 VPN 클라이언트 UI에 코드 또는 텍스트를 입력해야 하는 경우 인증은 성공하지 못하며 지원되는 시나리오가 아닙니다. 다단계 인증을 위해 NPS 서버와 Azure VPN Gateway RADIUS 인증 통합을 참조하세요.

RADIUS 인증은 IKEv2 및 SSTP VPN 모두에서 작동하나요?

예, RADIUS 인증은 IKEv2 및 SSTP VPN 모두에서 지원됩니다.

RADIUS 인증은 OpenVPN 클라이언트에서 작동하나요?

RADIUS 인증은 OpenVPN 프로토콜에 대해 지원됩니다.

VNet 간 연결 및 다중 사이트 연결

이 섹션의 VNet-VNet 정보는 VPN 게이트웨이 연결에 적용됩니다. VNet 피어링에 대한 자세한 내용은 가상 네트워크 피어링을 참조하세요.

Azure는 VNet 간 트래픽에 요금을 청구하나요?

VPN 게이트웨이 연결을 사용하는 경우 동일한 지역 내의 VNet 간 트래픽은 양방향 모두에 대해 무료입니다. 지역 전체 VNet 간 송신 트래픽은 원본 지역을 기반으로 아웃바운드 VNet 간 데이터 전송 요금으로 청구됩니다. 자세한 내용은 Azure VPN 게이트웨이 가격 책정을 참조하세요. VPN 게이트웨이 대신 VNet 피어링을 사용하여 VNet을 연결하는 경우 Azure Virtual Network 가격 책정을 참조하세요.

VNet 간 트래픽은 인터넷을 거쳐서 이동하나요?

아니요. VNet 간 트래픽은 인터넷이 아닌 Microsoft Azure 백본을 거쳐서 이동합니다.

Microsoft Entra 테넌트에 VNet 간 연결을 설정할 수 있나요?

예. VPN 게이트웨이를 사용하는 VNet 간 연결은 Microsoft Entra 테넌트에서 작동합니다.

VNet 간 트래픽은 안전한가요?

IPsec 및 IKE 암호화를 사용하면 VNet-VNet 트래픽을 보호할 수 있습니다.

VNet을 함께 연결하려면 VPN 디바이스가 필요한가요?

아니요. 여러 Azure 가상 네트워크를 함께 연결해도 프레미스 간 연결이 필요하지 않으면 VPN 디바이스가 필요하지 않습니다.

VNet이 동일한 지역에 있어야 하나요?

아니요. 가상 네트워크는 같은 Azure 지역(위치)에 있을 수도 있고 다른 Azure 지역(위치)에 있을 수도 있습니다.

VNet이 동일한 구독에 없는 경우 구독을 동일한 Microsoft Entra 테넌트에 연결해야 하나요?

아니요.

별도 가상 네트워크에 있는 Azure 인스턴스를 연결하는 데 VNet 간 연결을 사용할 수 있나요?

아니요. VNet 간 연결은 동일한 Azure 인스턴스 내에서 가상 네트워크 연결을 지원합니다. 예를 들어 글로벌 Azure와 중국어, 독일어 또는 미국 정부 Azure 인스턴스 간에 연결을 만들 수 없습니다. 이러한 시나리오에 사이트 및 사이트 간의 VPN 연결을 사용하는 것이 좋습니다.

VNet간 연결을 멀티 사이트 연결과 함께 사용할 수 있나요?

예. 다중 사이트 VPN과 동시에 가상 네트워크 연결을 사용할 수 있습니다.

하나의 가상 네트워크에 연결할 수 있는 온-프레미스 사이트 및 가상 네트워크 수는 어떻게 됩니까?

게이트웨이 요구 사항 테이블을 참조하세요.

VNet-VNet을 사용하여 VNet 외부의 VM 또는 클라우드 서비스를 연결할 수 있나요?

아니요. VNet 간 연결은 가상 네트워크 연결을 지원합니다. 가상 네트워크에 포함되지 않은 가상 머신 또는 클라우드 서비스 연결은 지원되지 않습니다.

클라우드 서비스 또는 부하 분산 엔드포인트가 VNet까지 이어지나요?

아니요. 클라우드 서비스 또는 부하 분산 엔드포인트는 가상 네트워크가 함께 연결되어 있더라도 가상 네트워크에 걸쳐 있을 수 없습니다.

VNet-VNet 또는 다중 사이트 연결에 정책 기반 VPN 유형을 사용할 수 있나요?

아니요. VNet-VNet 및 다중 사이트 연결에는 경로 기반(이전에 동적 라우팅) VPN 유형이 있는 VPN 게이트웨이가 필요합니다.

경로 기반 VPN 형식의 VNet을 정책 기반 VPN 형식의 다른 VNet에 연결할 수 있나요?

아니요. 두 가상 네트워크 모두 경로 기반(이전에 동적 라우팅) VPN을 사용해야 합니다.

VPN 터널은 대역폭을 공유하나요?

예. 가상 네트워크의 모든 VPN 터널은 VPN 게이트웨이에서 사용 가능한 대역폭과 Azure의 VPN 게이트웨이 작동 시간에 대한 동일한 서비스 수준 계약을 공유합니다.

중복 터널이 지원되나요?

하나의 가상 네트워크 게이트웨이를 active-active로 구성하면 한 쌍의 가상 네트워크 사이의 중복 터널이 지원됩니다.

VNet 간 구성에 대해 겹치는 주소 공간을 가질 수 있나요?

아니요. 겹치는 IP 주소 범위를 가질 수 있습니다.

연결된 가상 네트워크와 온-프레미스 로컬 사이트 사이에 겹치는 주소 공간이 있을 수 있나요?

아니요. 겹치는 IP 주소 범위를 가질 수 있습니다.

사이트 간 VPN 연결과 ExpressRoute 간에 라우팅을 사용하도록 설정하려면 어떻게 해야 하나요?

ExpressRoute에 연결된 분기와 사이트 간 VPN에 연결된 분기 간에 라우팅을 사용하도록 설정하려면 Azure Route Server를 설정해야 합니다.

VPN 게이트웨이를 사용하여 온-프레미스 사이트 간 또는 다른 가상 네트워크 간 트래픽을 전송할 수 있나요?

  • 리소스 관리자 배포 모델

    예. 자세한 내용은 BGP 및 라우팅 섹션을 참조하세요.

  • 클래식 배포 모델

    클래식 배포 모델을 사용하는 경우 VPN 게이트웨이를 통한 트래픽 전송이 가능하지만 네트워크 구성 파일에서 정적으로 정의된 주소 공간에 의존합니다. BGP(Border Gateway Protocol)는 현재 클래식 배포 모델을 통한 Azure 가상 네트워크 및 VPN 게이트웨이에서 지원되지 않습니다. BGP가 없으면 전송 주소 공간을 수동으로 정의하는 것은 오류가 발생하기 쉬우며 권장되지 않습니다.

Azure는 동일한 가상 네트워크의 모든 VPN 연결에 대해 동일한 IPsec/IKE 미리 공유한 키를 생성하나요?

아니요. 기본적으로 Azure는 서로 다른 VPN 연결에 대해 서로 다른 사전 공유 키를 생성합니다. 그러나 VPN 게이트웨이 키 REST API 또는 PowerShell cmdlet을 사용하여 원하는 키 값을 설정할 수 있습니다. 키는 공백, 하이픈(-) 또는 틸데(~)를 제외한 인쇄 가능한 ASCII 문자만 포함해야 합니다.

단일 가상 네트워크보다 더 많은 사이트 간 VPN을 사용하면 대역폭이 증가합니까?

아니요. 지점 및 사이트 간의 VPN을 비롯한 모든 VPN 터널은 동일한 VPN 게이트웨이와 사용 가능한 대역폭을 공유합니다.

다중 사이트 VPN을 사용하여 내 가상 네트워크와 온-프레미스 사이트 간에 여러 터널을 구성할 수 있나요?

예, 하지만 두 터널의 BGP를 동일한 위치로 구성해야 합니다.

Azure VPN 게이트웨이는 AS 경로 앞에 추가된 경로를 적용하여 온-프레미스 사이트에 대한 여러 연결 간의 라우팅 결정에 영향을 주나요?

예, Azure VPN 게이트웨이는 BGP를 사용하도록 설정할 때 라우팅 결정을 내리는 데 도움이 되는 AS(자치 시스템) 경로 앞에 적용됩니다. BGP 경로 선택에서 더 짧은 AS 경로가 선호됩니다.

새 VPN VirtualNetworkGateway 연결을 만들 때 RoutingWeight 속성을 사용할 수 있나요?

아니요. 이러한 설정은 ExpressRoute 게이트웨이 연결을 위해 예약됩니다. 여러 연결 간의 라우팅 결정에 영향을 주려면 AS 경로 앞에 추가를 사용해야 합니다.

여러 VPN 터널을 포함하는 내 가상 네트워크에서 지점 및 사이트 간 VPN을 사용할 수 있습니까?

예. 여러 온-프레미스 사이트 및 기타 가상 네트워크에 연결하는 VPN 게이트웨이에서 지점 및 사이트간 VPN을 사용할 수 있습니다.

IPsec VPN을 사용하는 가상 네트워크를 ExpressRoute 회로에 연결할 수 있습니까?

예, 지원됩니다. 자세한 내용은 ExpressRoute 및 사이트 간의 공존 연결 구성을 참조하세요.

IPsec/IKE 정책

모든 Azure VPN 게이트웨이 SKU에서 사용자 지정 IPsec/IKE 정책이 지원되나요?

사용자 지정 IPsec/IKE 정책은 기본 SKU를 제외한 모든 Azure VPN 게이트웨이 SKU에서 지원됩니다.

연결에서 얼마나 많은 정책을 지정할 수 있나요?

연결에 대해 하나의 정책 조합만 지정할 수 있습니다.

연결에 부분 정책을 지정할 수 있나요(예: IKE 알고리즘만 지정하지만 IPsec은 지정하지 않는지)?

아니요, IKE(주 모드) 및 IPsec(빠른 모드) 모두에 대한 모든 알고리즘 및 매개 변수를 지정해야 합니다. 부분적인 정책 사양은 허용되지 않습니다.

사용자 지정 정책에서 지원하는 알고리즘 및 주요 강점은 무엇인가요?

다음 표에는 직접 구성할 수 있는 지원되는 암호화 알고리즘 및 키 수준이 나와 있습니다. 모든 필드에 대해 한 가지 옵션을 선택해야 합니다.

IPsec/IKEv2 옵션
IKEv2 암호화 GCMAES256, GCMAES128, AES256, AES192, AES128
IKEv2 무결성 SHA384, SHA256, SHA1, MD5
DH 그룹 DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, 없음
IPsec 암호화 GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, 없음
IPsec 무결성 GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS 그룹 PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, 없음
빠른 모드 SA 수명 (선택 사항, 지정하지 않은 경우 기본값)
초(정수, 최소 300, 기본값 27,000)
킬로바이트(정수, 최소 1,024, 기본값 10,2400,000)
트래픽 선택기 UsePolicyBasedTrafficSelectors($True 또는 $False, 그러나 선택 사항, 지정되지 않은 경우 기본값은 $False)
DPD 제한 시간 초(정수, 최소 9, 최대 3,600, 기본값 45)

  • 온-프레미스 VPN 디바이스 구성은 Azure IPsec 또는 IKE 정책에서 지정한 다음 알고리즘 및 매개 변수가 일치하거나 포함해야 합니다.

    • IKE 암호화 알고리즘(기본 모드, 1단계)
    • IKE 무결성 알고리즘(기본 모드, 1단계)
    • DH 그룹(기본 모드, 1단계)
    • IPsec 암호화 알고리즘(빠른 모드, 2단계)
    • IPsec 무결성 알고리즘(빠른 모드, 2단계)
    • PFS 그룹(빠른 모드, 2단계)
    • 트래픽 선택기(UsePolicyBasedTrafficSelectors(을)를 사용하는 경우)
    • SA 수명(일치하지 않아도 되는 로컬 사양)

  • IPsec 암호화 알고리즘에 GCMAES를 사용하는 경우 IPsec 무결성을 위해 동일한 GCMAES 알고리즘과 키 길이를 선택해야 합니다. 예를 들어, 두 가지 모두에 GCMAES128을 사용합니다.

  • 알고리즘 및 키 표에서:

    • IKE는 주 모드 또는 1단계에 해당합니다.
    • IPsec은 빠른 모드 또는 2단계에 해당합니다.
    • DH 그룹은 기본 모드 또는 1단계에서 사용되는 Diffie-Hellman 그룹을 지정합니다.
    • PFS 그룹은 빠른 모드 또는 2단계에서 사용되는 Diffie-Hellman 그룹을 지정했습니다.

  • IKE 주 모드 SA 수명은 Azure VPN Gateways에서 28,800초로 고정됩니다.

  • UsePolicyBasedTrafficSelectors(은)는 연결에 대한 선택적 매개 변수입니다. 연결에서 UsePolicyBasedTrafficSelectors(을)를 $True(으)로 설정하면 VPN 게이트웨이가 온-프레미스 정책 기반 VPN 방화벽에 연결되도록 구성됩니다.

    UsePolicyBasedTrafficSelectors(을)를 사용하도록 설정하는 경우 VPN 디바이스에 다대다 대신 Azure 가상 네트워크 접두사에 대한 온-프레미스 네트워크(로컬 네트워크 게이트웨이) 접두사의 모든 조합으로 정의된 일치하는 트래픽 선택기가 있는지 확인합니다. VPN 게이트웨이는 VPN 게이트웨이에 구성된 내용에 관계없이 원격 VPN 게이트웨이가 제안하는 모든 트래픽 선택기를 허용합니다.

    예를 들어 온-프레미스 네트워크 접두사가 10.1.0.0/16 및 10.2.0.0/16이고 가상 네트워크 접두사가 192.168.0.0/16 및 172.16.0.0/16이면 다음 트래픽 선택기를 지정해야 합니다.

    • 10.1.0.0/16 <====> 192.168.0.0/16
    • 10.1.0.0/16 <====> 172.16.0.0/16
    • 10.2.0.0/16 <====> 192.168.0.0/16
    • 10.2.0.0/16 <====> 172.16.0.0/16

    정책 기반 트래픽 선택기에 대한 자세한 내용은 여러 온-프레미스 정책 기반 VPN 디바이스에 VPN 게이트웨이 연결을 참조하세요.

  • 시간 제한을 더 짧은 기간으로 설정하면 IKE가 더 적극적으로 키를 다시 입력하게 됩니다. 그러면 어떤 경우에는 연결이 끊어진 것처럼 보일 수 있습니다. 온-프레미스 위치가 VPN 게이트웨이가 있는 Azure 지역에서 멀리 떨어져 있거나 실제 링크 조건으로 인해 패킷 손실이 발생할 수 있는 경우에는 이러한 상황이 바람직하지 않을 수 있습니다. 일반적으로 시간 제한을 30~45초로 설정하는 것이 좋습니다.

자세한 내용은 VPN 게이트웨이를 여러 온-프레미스 정책 기반 VPN 디바이스에 연결을 참조하세요.

사용자 지정 정책이 지원하는 Diffie-Hellman 그룹은 무엇입니까?

다음 표에서는 사용자 지정 정책이 지원하는 해당 Diffie-Hellman 그룹을 나열합니다.

Diffie-Hellman 그룹 DHGroup PFSGroup 키 길이
1 DHGroup1 PFS1 768비트 MODP
2 DHGroup2 PFS2 1024비트 MODP
14 DHGroup14
DHGroup2048		 PFS2048 2048비트 MODP
19 ECP256 ECP256 256비트 ECP
20 ECP384 ECP384 384비트 ECP
24 DHGroup24 PFS24 2048비트 MODP

자세한 내용은 RFC3526 및 RFC5114를 참조하세요.

사용자 지정 정책이 VPN 게이트웨이에 대한 기본 IPsec/IKE 정책 집합을 대체하나요?

예. 연결에 사용자 지정 정책을 지정한 후 Azure VPN 게이트웨이는 연결에서 해당 정책만 IKE 초기자 및 IKE 응답자로 사용합니다.

사용자 지정 IPsec/IKE 정책을 제거하면 연결이 보호되지 않나요?

아니요, IPsec/IKE는 여전히 연결을 보호하는 데 도움이 됩니다. 연결에서 사용자 지정 정책을 제거한 후 VPN 게이트웨이는 IPsec/IKE 제안의 기본 목록으로 되돌아가 온-프레미스 VPN 디바이스를 사용하여 IKE 핸드셰이크를 다시 시작합니다.

IPsec/IKE 정책을 추가 또는 업데이트하는 것이 VPN 연결에 방해가 될까요?

예. VPN 게이트웨이가 기존 연결을 중단하고 IKE 핸드셰이크를 다시 시작하여 새 암호화 알고리즘 및 매개 변수를 사용하여 IPsec 터널을 다시 설정하면 약간의 중단(몇 초)이 발생할 수 있습니다. 중단을 최소화하기 위해 일치하는 알고리즘 및 키 강도로 온-프레미스 VPN 디바이스도 구성되었는지 확인합니다.

다른 연결에 다른 정책을 사용할 수 있나요?

예. 사용자 지정 정책은 연결별로 적용됩니다. 다른 연결에 서로 다른 IPsec/IKE 정책을 만들어 적용할 수 있습니다.

또한 연결의 하위 집합에 대해 사용자 지정 정책을 적용하도록 선택할 수도 있습니다. 나머지는 Azure 기본 IPsec/IKE 정책 집합을 사용합니다.

VNet-VNet 연결에서 사용자 지정 정책을 사용할 수 있나요?

예. IPsec 크로스-프레미스 연결 및 VNet 간 연결 모두에 사용자 지정 정책을 적용할 수 있습니다.

두 VNet 간 연결 리소스에 동일한 정책을 지정해야 하나요?

예. Azure에서 VNet 간 터널은 두 개의 연결 리소스(각 방향당 하나씩)로 구성됩니다. 두 연결 리소스에 동일한 정책이 있는지 확인합니다. 그렇지 않으면 VNet-VNet 연결이 설정되지 않습니다.

기본 DPD 시간 제한 값이란 무엇인가요? 다른 DPD 시간 제한을 지정할 수 있나요?

기본 DPD 시간 제한은 VPN 게이트웨이에서 45초입니다. 각 IPsec 또는 VNet 간 연결에서 9초에서 3,600초까지 다른 DPD 시간 제한 값을 지정할 수 있습니다.

참고 항목

시간 제한을 더 짧은 기간으로 설정하면 IKE가 더 적극적으로 키를 다시 입력하게 됩니다. 그러면 어떤 경우에는 연결이 끊어진 것처럼 보일 수 있습니다. 온-프레미스 위치가 VPN 게이트웨이가 있는 Azure 지역에서 멀리 떨어져 있거나 실제 링크 조건으로 인해 패킷 손실이 발생할 수 있는 경우에는 이러한 상황이 바람직하지 않을 수 있습니다. 일반적으로 시간 제한을 30~45초로 설정하는 것이 좋습니다.

사용자 지정 IPsec/IKE 정책이 ExpressRoute 연결에서 작동하나요?

아니요. IPsec/IKE 정책은 VPN 게이트웨이를 통한 S2S VPN 및 VNet-VNet 연결에서만 작동합니다.

IKEv1 또는 IKEv2 프로토콜 형식을 사용하여 연결을 만들려면 어떻게 해야 하나요?

기본 SKU, 표준 SKU 및 이전 SKU 및 다른 이전 SKU를 제외한 모든 경로 기반 VPN 형식 SKU에서 IKEv1 연결을 만들 수 있습니다.

연결을 만드는 동안 연결 프로토콜 유형(IKEv1 또는 IKEv2)을 지정할 수 있습니다. 연결 프로토콜 유형을 지정하지 않으면 해당하는 경우 기본 옵션으로 IKEv2가 사용됩니다. 자세한 내용은 Azure PowerShell cmdlet 설명서를 참조하세요.

SKU 유형 및 IKEv1 및 IKEv2 지원에 대한 자세한 내용은 VPN 게이트웨이를 여러 온-프레미스 정책 기반 VPN 디바이스에 연결을 참조하세요.

IKEv1과 IKEv2 연결 간의 전송이 허용되나요?

예.

경로 기반 VPN 유형에 대한 기본 SKU에서 IKEv1 사이트간 연결을 사용할 수 있나요?

아니요. 기본 SKU는 이 구성을 지원하지 않습니다.

연결을 만든 후 연결 프로토콜 유형을 변경할 수 있나요? (IKEv1에서 IKEv2로 또는 그 반대로)

아니요. 연결을 만든 후에는 IKEv1 및 IKEv2 프로토콜을 변경할 수 없습니다. 원하는 프로토콜 형식을 사용하여 새 연결을 삭제하고 다시 만들어야 합니다.

내 IKEv1 연결이 자주 다시 연결되는 이유는 무엇인가요?

정적 라우팅 또는 경로 기반 IKEv1 연결이 일상적인 간격으로 연결이 끊어지는 경우 VPN 게이트웨이가 현재 위치 다시 키를 지원하지 않기 때문일 수 있습니다. 기본 모드의 키를 다시 입력하면 IKEv1 터널의 연결이 끊기고 다시 연결하는 데 최대 5초가 걸립니다. 기본 모드 협상 시간 제한 값은 키의 빈도를 결정합니다. 이러한 재연결을 방지하기 위해 인플레이스 키 다시 입력을 지원하는 IKEv2를 사용하도록 전환할 수 있습니다.

연결이 임의로 다시 연결되는 경우 문제 해결 가이드를 따릅니다.

구성에 대한 자세한 정보 및 단계는 어디에서 찾을 수 있나요?

다음 문서를 참조하세요.

BGP 및 라우팅

BGP가 모든 Azure VPN Gateway SKU를 지원하나요?

BGP는 기본 SKU를 제외한 모든 Azure VPN 게이트웨이 SKU에서 지원됩니다.

Azure Policy VPN 게이트웨이에서 BGP를 사용할 수 있나요?

아니요. BGP는 경로 기반 VPN 게이트웨이에서만 지원됩니다.

어떤 ASN을 사용할 수 있나요?

온-프레미스 네트워크와 Azure 가상 네트워크 모두에 고유한 공용 ASN(자치 시스템 번호) 또는 프라이빗 ASN을 사용할 수 있습니다.

예약된 다음 ASN은 사용할 수 없습니다.

  • Azure에서 예약:

    • 공용 ASN: 8074, 8075, 12076
    • 프라이빗 ASN: 65515, 65517, 65518, 65519, 65520

  • IANA에서 예약됨:

    • 23456, 64496-64511, 65535-65551, 429496729

VPN 게이트웨이에 연결할 때는 온-프레미스 VPN 디바이스에 대해 이러한 ASN을 지정할 수 없습니다.

32비트(4바이트) ASN을 사용할 수 있나요?

예, Azure VPN 게이트웨이는 이제 32비트(4 바이트) ASN을 지원합니다. 10진수 형식으로 ASN을 사용하여 구성하려면 Azure PowerShell, Azure CLI 또는 Azure SDK를 사용합니다.

사용할 수 있는 프라이빗 ASN은 무엇인가요?

사용 가능한 프라이빗 ASN의 범위는 다음과 같습니다.

  • 64512-65514 및 65521-65534

IANA와 Azure는 이러한 ASN을 예약하지 않으므로 VPN 게이트웨이에 할당할 수 있습니다.

Azure VPN 게이트웨이는 BGP 피어 IP에 어떤 주소를 사용하나요?

기본적으로 Azure VPN 게이트웨이는 활성 대기 VPN 게이트웨이에 대해 GatewaySubnet 범위의 단일 IP 주소 또는 활성-활성 VPN 게이트웨이에 대해 두 개의 IP 주소를 할당합니다. 이러한 주소는 VPN 게이트웨이를 만들 때 자동으로 할당됩니다.

Azure PowerShell 또는 Azure Portal을 사용하여 할당된 BGP IP 주소를 찾을 수 있습니다. PowerShell에서 Get-AzVirtualNetworkGateway(을)를 사용하고 bgpPeeringAddress 속성을 찾습니다. Azure Portal의 게이트웨이 구성 페이지에서 BGP ASN 구성 속성을 확인합니다.

온-프레미스 VPN 라우터가 APIPA(자동 개인 IP 주소 지정) IP 주소(169.254.x.x)를 BGP IP 주소로 사용하는 경우 VPN 게이트웨이에서 하나 이상의 Azure APIPA BGP IP 주소를 지정해야 합니다. Azure VPN Gateway는 로컬 네트워크 게이트웨이에 지정된 온-프레미스 APIPA BGP 피어와 함께 사용할 APIPA 주소를 선택하거나 비 APIPA 온-프레미스 BGP 피어에 대한 개인 IP 주소를 선택합니다. 자세한 내용은 Azure VPN 게이트웨이에 대한 BGP 구성을 참조하세요.

VPN 디바이스에서 BGP 피어 IP 주소에 대한 요구 사항은 무엇인가요?

온-프레미스 BGP 피어 주소는 VPN 디바이스의 공용 IP 주소 또는 VPN 게이트웨이의 VNet 주소 공간과 동일하지 않아야 합니다. VPN 디바이스에서 BGP 피어 IP에 다른 IP 주소를 사용하세요. 이는 디바이스의 루프백 인터페이스에 할당된 주소, 일반 IP 주소 또는 APIPA 주소일 수 있습니다.

디바이스에서 BGP에 APIPA 주소를 사용하는 경우 Azure VPN 게이트웨이에 대한 BGP 구성에 설명된 대로 VPN 게이트웨이에서 하나 이상의 APIPA BGP IP 주소를 지정해야 합니다. 위치를 나타내는 해당 로컬 네트워크 게이트웨이에서 이러한 주소를 지정합니다.

BGP를 사용할 때 로컬 네트워크 게이트웨이의 내 주소 접두사로 무엇을 지정해야 하나요?

Important

이는 이전에 문서화된 요구 사항에서 변경된 사항입니다.

Azure VPN Gateway는 내부적으로 IPsec 터널을 통해 온-프레미스 BGP 피어 IP에 호스트 경로를 추가합니다. 중복되므로 주소 공간 필드에 /32 경로를 추가하지 마세요. APIPA 주소를 온-프레미스 VPN 디바이스 BGP IP로 사용하는 경우 이 필드에 추가할 수 없습니다.

주소 공간 필드에 다른 접두사를 추가하는 경우 BGP를 통해 학습된 경로 외에도 Azure VPN 게이트웨이에 정적 경로로 추가됩니다.

온-프레미스 VPN 네트워크와 Azure 가상 네트워크에 동일한 ASN을 사용할 수 있나요?

아니요. BGP와 함께 연결하는 경우 온-프레미스 네트워크와 Azure 가상 네트워크 간에 다른 ASN을 할당해야 합니다.

크로스 프레미스 연결에 대한 BGP 활성화 여부에 관계없이 Azure VPN 게이트웨이에 할당되는 기본 ASN은 65515입니다. VPN 게이트웨이를 만들 때 다른 ASN을 적용하여 이 기본값을 다시 정의하거나, 게이트웨이를 만든 후 ASN을 변경할 수 있습니다. 해당 Azure 로컬 네트워크 게이트웨이에 온-프레미스 ASN을 할당해야 합니다.

Azure VPN 게이트웨이에서 나에게 보급하는 주소 접두사는 무엇인가요?

이 게이트웨이는 온-프레미스 BGP 디바이스에 다음 경로를 보급합니다.

  • VNet 주소 접두어
  • VPN Gateway에 연결된 각 로컬 네트워크 게이트웨이에 대한 주소 접두사
  • VPN 게이트웨이에 연결된 다른 BGP 피어링 세션에서 학습된 경로(가상 네트워크 접두사와 겹치는 기본 경로 또는 경로 제외)

Azure VPN Gateway에 접두사를 몇 개나 보급할 수 있나요?

Azure VPN 게이트웨이는 최대 4,000개의 접두사를 지원합니다. 접두사의 수가 제한을 초과하는 경우 BGP 세션은 삭제됩니다.

기본 경로(0.0.0.0/0)를 VPN 게이트웨이에 보급할 수 있나요?

예. 기본 경로를 보급하면 모든 VNet 송신 트래픽이 온-프레미스 사이트로 강제 전송됩니다. 또한 가상 네트워크 VM이 인터넷에서 VM으로 RDP(원격 데스크톱 프로토콜) 또는 SSH(Secure Shell)와 같은 인터넷의 공용 통신을 직접 수락하지 못하게 합니다.

내 가상 네트워크 접두사와 똑같은 접두사를 보급할 수 있나요?

아니요. Azure는 VNet 주소 접두사 중 하나와 동일한 접두사 광고를 차단하거나 필터링합니다. 그러나 가상 네트워크 내부에 있는 항목의 상위 집합인 접두사를 보급할 수 있습니다.

예를 들어 가상 네트워크에서 주소 공간 10.0.0.0/16을 사용하는 경우 10.0.0.0/8을 보급할 수 있습니다. 10.0.0.0/16 또는 10.0.0.0/24는 보급할 수 없습니다.

가상 네트워크 간 연결에 BGP를 사용할 수 있나요?

예. 프레미스 간 연결 및 가상 네트워크 간의 연결 모두에 BGP를 사용할 수 있습니다.

BGP를 비 BGP 연결과 혼합하여 내 Azure VPN 게이트웨이에 사용할 수 있나요?

예. BGP와 비 BGP 연결을 동일한 Azure VPN 게이트웨이에 혼합 사용할 수 있습니다.

Azure VPN Gateway가 BGP 전송 라우팅을 지원하나요?

예. VPN 게이트웨이가 다른 BGP 피어에 기본 경로를 보급하지 않는다는 점을 제외하고 BGP 전송 라우팅이 지원됩니다. 여러 VPN 게이트웨이에서 전송 라우팅을 사용하도록 설정하려면 가상 네트워크 간의 모든 중간 연결에서 BGP를 사용하도록 설정해야 합니다. 자세한 내용은 BGP 및 VPN 게이트웨이를 참조하세요.

VPN 게이트웨이와 온-프레미스 네트워크 간에 둘 이상의 터널을 가질 수 있나요?

예, VPN 게이트웨이와 온-프레미스 네트워크 간에 둘 이상의 사이트 간 VPN 터널을 설정할 수 있습니다. 이러한 모든 터널은 Azure VPN 게이트웨이에 대한 총 터널 수에 대해 계산되며 두 터널에서 BGP를 사용하도록 설정해야 합니다.

예를 들어 VPN 게이트웨이와 온-프레미스 네트워크 중 하나 사이에 두 개의 중복 터널이 있는 경우 VPN 게이트웨이에 대한 총 할당량에서 두 개의 터널을 사용합니다.

두 Azure 가상 네트워크와 BGP 간에 여러 터널이 있을 수 있나요?

예, 하지만 가상 네트워크 게이트웨이 중 하나 이상이 활성-활성 구성에 있어야 합니다.

Azure ExpressRoute 및 S2S VPN 공존 구성에서 S2S VPN에 BGP를 사용할 수 있나요?

예.

BGP 피어링 세션에 대해 온-프레미스 VPN 디바이스에 무엇을 추가해야 하나요?

VPN 디바이스에 Azure BGP 피어 IP 주소의 호스트 경로를 추가합니다. 이 경로는 IPsec S2S VPN 터널을 가리킵니다.

예를 들어, Azure VPN 피어 IP가 10.12.255.30이라면 VPN 디바이스에서 일치하는 IPsec 터널 인터페이스의 다음 홉 인터페이스와 10.12.255.30에 대한 호스트 경로를 추가해야 합니다.

가상 네트워크 게이트웨이가 BGP를 사용한 S2S 연결에 BFD를 지원하나요?

아니요. BFD(양방향 전달 감지)는 BGP와 함께 표준 BGP 유지 간격을 사용하여 보다 빠르게 인접 가동 중지 시간을 감지하는 데 사용할 수 있는 프로토콜입니다. BFD는 LAN 환경에서 작동하도록 설계된 1초 미만의 타이머를 사용하지만 공용 인터넷 또는 WAN 연결에서는 작동하지 않습니다.

공용 인터넷을 통한 연결의 경우 특정 패킷이 지연되거나 삭제되는 일이 자주 발생하기 때문에, 이렇게 빠른 타이머를 도입하면 불안정성이 생길 수 있습니다. 이러한 불안정으로 인해 BGP가 경로를 약화시킬 수 있습니다.

또는 기본 60초 유지 간격보다 낮거나 180초 보류 타이머보다 낮은 타이머를 사용하여 온-프레미스 디바이스를 구성할 수 있습니다. 이 구성으로 인해 수렴 시간이 더 빨라질 수 있습니다. 그러나 기본 60초 유지 간격 이하 또는 기본 180초 보존 타이머 미만의 타이머는 신뢰할 수 없습니다. 타이머를 기본값 이상으로 유지하는 것이 좋습니다.

VPN 게이트웨이가 BGP 피어링 세션 또는 연결을 시작하나요?

VPN 게이트웨이는 VPN 게이트웨이의 개인 IP 주소를 사용하여 로컬 네트워크 게이트웨이 리소스에 지정된 온-프레미스 BGP 피어 IP 주소에 대한 BGP 피어링 세션을 시작합니다. 이 프로세스는 온-프레미스 BGP IP 주소가 APIPA 범위에 있는지 또는 일반 개인 IP 주소인지에 관계없이 수행됩니다. 온-프레미스 VPN 디바이스가 APIPA 주소를 BGP IP로 사용하는 경우 연결을 시작하도록 BGP 스피커를 구성해야 합니다.

강제 터널링을 구성할 수 있나요?

예. 강제 터널링 구성을 참조하세요.

NAT

NAT가 모든 Azure VPN Gateway SKU에서 지원되나요?

NAT는 VpnGw2에서 VpnGw25로, VpnGw2AZ에서 VpnGw5AZ로 지원됩니다.

VNet-VNet 또는 P2S 연결에서 NAT를 사용할 수 있나요?

아니요.

VPN Gateway에서 사용할 수 있는 NAT 규칙은 몇 개인가요?

VPN 게이트웨이에서 최대 100개의 NAT 규칙(수신 및 송신 규칙 결합)을 만들 수 있습니다.

NAT 규칙 이름에 슬래시(/)를 사용할 수 있나요?

아니요. 오류가 표시됩니다.

NAT가 VPN Gateway의 모든 연결에 적용되나요?

NAT는 NAT 규칙이 있는 연결에 적용됩니다. 연결에 NAT 규칙이 없으면 NAT가 해당 연결에 적용되지 않습니다. 동일한 VPN 게이트웨이에서 NAT가 적용된 연결과 NAT가 적용되지 않은 연결이 함께 작동할 수 있습니다.

VPN 게이트웨이는 어떤 유형의 NAT를 지원하나요?

VPN 게이트웨이는 정적 1:1 NAT 및 동적 NAT만 지원합니다. NAT64를 지원하지 않습니다.

NAT가 활성-활성 VPN Gateway에서 작동하나요?

예. NAT는 활성-활성 VPN Gateway와 활성-대기 VPN Gateway 모두에서 작동합니다. 각 NAT 규칙은 VPN 게이트웨이의 단일 인스턴스에 적용됩니다. 활성-활성 게이트웨이에서 IP 구성 ID 필드를 통해 각 게이트웨이 인스턴스에 대해 별도의 NAT 규칙을 만듭니다.

NAT는 BGP 연결에서 작동하나요?

예, NAT와 함께 BGP를 사용할 수 있습니다. 몇 가지 중요한 고려 사항:

  • 학습된 경로와 보급된 경로가 연결과 관련된 NAT 규칙에 따라 NAT 이후 주소 접두사(외부 매핑)로 변환되도록 하려면 NAT 규칙의 구성 페이지에서 BGP 경로 변환 사용을 선택하세요. 온-프레미스 BGP 라우터는 IngressSNAT 규칙에 정의된 대로 정확한 접두사를 보급해야 합니다.

  • 온-프레미스 VPN 라우터가 일반 비 APIPA 주소를 사용하고 VNet 주소 공간 또는 다른 온-프레미스 네트워크 공간과 충돌하는 경우 IngressSNAT 규칙이 BGP 피어 IP를 겹치지 않는 고유한 주소로 변환하는지 확인합니다. NAT 이후 주소를 로컬 네트워크 게이트웨이의 BGP 피어 IP 주소 필드에 배치합니다.

  • NAT는 BGP APIPA 주소에서 지원되지 않습니다.

SNAT 규칙에 대해 일치하는 DNAT 규칙을 만들어야 하나요?

아니요. 단일 SNAT(원본 네트워크 주소 변환) 규칙은 특정 네트워크의 양 방향에 대한 변환을 정의합니다.

  • IngressSNAT 규칙은 온-프레미스 네트워크에서 VPN 게이트웨이로 들어오는 원본 IP 주소의 변환을 정의합니다. 또한 가상 네트워크에서 같은 온-프레미스 네트워크로 나가는 대상 IP 주소 변환을 처리합니다.

  • EgressSNAT 규칙은 VPN 게이트웨이에서 온-프레미스 네트워크로 나가는 VNet 원본 IP 주소의 변환을 정의합니다. 또한 EgressSNAT 규칙이 있는 연결을 통해 가상 네트워크로 들어오는 패킷의 대상 IP 주소 변환을 처리합니다.

두 경우 모두 DNAT(대상 네트워크 주소 변환) 규칙이 필요하지 않습니다.

내 VNet 또는 로컬 네트워크 게이트웨이 주소 공간에 두 개 이상의 접두사가 있는 경우 어떻게 해야 합니까? NAT를 모든 항목에 적용할 수 있나요, 아니면 하위 항목에만 적용할 수 있나요?

각 NAT 규칙은 하나의 주소 접두사만 포함할 수 있으므로 각 접두사에 대해 하나의 NAT 규칙을 만들어야 합니다. 예를 들어 로컬 네트워크 게이트웨이의 주소 공간이 10.0.1.0/24와 10.0.2.0/25로 구성된 경우 다음 두 규칙을 만들 수 있습니다.

  • IngressSNAT 규칙 1: 10.0.1.0/24를 100.0.1.0/24에 매핑.
  • IngressSNAT 규칙 2: 10.0.2.0/25를 100.0.2.0/25에 매핑.

두 규칙은 해당 주소 접두사의 접두사 길이와 일치해야 합니다. VNet 주소 공간에 대한 EgressSNAT 규칙에 동일한 지침이 적용됩니다.

Important

위의 연결에 하나의 규칙만 연결하는 경우 다른 주소 공간은 변환되지 않습니다.

외부 매핑에 사용할 수 있는 IP 범위는 무엇인가요?

공용 및 개인 IP를 포함하여 원하는 모든 적합한 IP 범위를 외부 매핑에 사용할 수 있습니다.

다른 EgressSNAT 규칙을 사용하여 내 VNet 주소 공간을 온-프레미스 네트워크에 대한 다른 접두사로 변환할 수 있나요?

예. 동일한 VNet 주소 공간에 대해 여러 EgressSNAT 규칙을 만든 다음 EgressSNAT 규칙을 다른 연결에 적용할 수 있습니다.

다른 연결에서 동일한 IngressSNAT 규칙을 사용할 수 있나요?

예. 일반적으로 동일한 온-프레미스 네트워크에 대한 연결이 중복성을 제공해야 할 때 동일한 IngressSNAT 규칙을 사용합니다. 서로 다른 온-프레미스 네트워크에 대한 연결인 경우 동일한 수신 규칙을 사용할 수 없습니다.

NAT 연결에 수신 규칙과 송신 규칙이 모두 필요한가요?

온-프레미스 네트워크 주소 공간이 VNet 주소 공간과 겹치는 경우 동일한 연결에서 수신 규칙과 송신 규칙이 모두 필요합니다. VNet 주소 공간이 연결된 네트워크 전체에서 고유한 경우 해당 연결에 대한 EgressSNAT 규칙이 필요하지 않습니다. 수신 규칙을 사용하여 온-프레미스 네트워크 간의 주소 겹침을 방지할 수 있습니다.

IP 구성 ID로 무엇을 선택해야 하나요?

IP 구성 ID는 NAT 규칙을 사용하려는 IP 구성 개체의 이름일 뿐입니다. 이 설정을 사용하면 NAT 규칙에 적용할 게이트웨이 공용 IP 주소를 선택하기만 하면 됩니다. 게이트웨이를 만들 때 사용자 지정 이름을 지정하지 않은 경우 게이트웨이의 기본 IP 주소는 기본 IP 구성에 할당되고 보조 IP는 activeActive IP 구성에 할당됩니다.

크로스-프레미스 연결 및 VM

가상 컴퓨터가 가상 네트워크에 있고 프레미스 간 연결을 사용하는 경우 VM에 연결하려면 어떻게 해야 합니까?

VM에 RDP를 사용하도록 설정한 경우 개인 IP 주소를 사용하여 가상 머신에 연결할 수 있습니다. 이 경우 개인 IP 주소와 연결하려는 포트(일반적으로 3389)를 지정합니다. 트래픽에 대한 가상 머신의 포트를 구성해야 합니다.

동일한 가상 네트워크에 있는 다른 가상 머신의 개인 IP 주소를 통해 가상 머신에 연결할 수도 있습니다. 가상 네트워크 외부의 위치에서 연결하는 경우 개인 IP 주소를 사용하여 가상 머신에 RDP할 수 없습니다. 예를 들어 지점 및 사이트 간 가상 네트워크를 구성하고 컴퓨터에서 연결을 설정하지 않은 경우 개인 IP 주소를 통해 가상 머신에 연결할 수 없습니다.

내 가상 머신이 프레미스 간 연결을 사용하는 가상 네트워크에 포함된 경우 내 VM의 모든 트래픽이 해당 연결을 통해 이동됩니까?

아니요. 지정한 가상 네트워크의 로컬 네트워크 IP 주소 범위에 포함된 대상 IP가 있는 트래픽만 가상 네트워크 게이트웨이를 통과합니다.

가상 네트워크 내에 있는 대상 IP가 있는 트래픽은 가상 네트워크 내에 유지됩니다. 다른 트래픽은 부하 분산 장치를 통해 공용 네트워크로 전송됩니다. 또는 강제 터널링을 사용하는 경우 트래픽이 VPN 게이트웨이를 통해 전송됩니다.

VM에 대한 RDP 연결 문제를 해결하려면 어떻게 하나요?

VPN 연결을 통해 가상 머신에 연결하는 데 문제가 있으면 다음 항목을 확인합니다.

  • VPN 연결이 성공했는지 확인합니다.
  • VM의 개인 IP 주소에 연결하고 있는지 확인합니다.
  • 컴퓨터 이름이 아닌 개인 IP 주소를 사용하여 VM에 연결할 수 있는 경우 DNS를 올바르게 구성했는지 확인합니다. VM에서 이름 확인이 작동하는 방법에 대한 자세한 내용은 Azure 가상 네트워크의 리소스에 대한 이름 확인을 참조하세요.

지점 및 사이트간에 연결하는 경우 다음 추가 항목을 확인합니다.

  • ipconfig(을)를 사용하여 연결 중인 컴퓨터의 이더넷 어댑터에 할당된 IPv4 주소를 확인합니다. IP 주소가 연결하려는 가상 네트워크의 주소 범위 내에 있거나 VPN 클라이언트 주소 풀의 주소 범위 내에 있는 경우 겹치는 주소 공간입니다. 이러한 방식으로 주소 공간이 겹치면 네트워크 트래픽이 Azure에 도달하지 않습니다. 로컬 네트워크에 유지됩니다.
  • 가상 네트워크에 대한 DNS 서버 IP 주소를 지정한 후 VPN 클라이언트 구성 패키지가 생성되었는지 확인합니다. DNS 서버 IP 주소를 업데이트한 경우 새 VPN 클라이언트 구성 패키지를 생성하고 설치합니다.

RDP 연결의 문제를 해결하는 방법에 대한 자세한 내용은 VM에 대한 원격 데스크톱 연결 문제 해결을 참조하세요.

고객 제어 게이트웨이 유지 관리

네트워크 게이트웨이 범위의 유지 관리 구성에는 어떤 서비스가 포함되나요?

네트워크 게이트웨이 범위에는 네트워킹 서비스의 게이트웨이 리소스가 포함됩니다. 네트워크 게이트웨이 범위에는 4가지 형식의 리소스가 있습니다.

  • ExpressRoute 서비스의 가상 네트워크 게이트웨이
  • VPN Gateway 서비스의 가상 네트워크 게이트웨이
  • Azure Virtual WAN 서비스의 VPN 게이트웨이(사이트 간)
  • Virtual WAN 서비스의 ExpressRoute 게이트웨이

고객 관리 유지 관리는 어떤 유지 관리를 지원하나요?

Azure 서비스는 기능, 안정성, 성능 및 보안을 향상시키기 위해 정기적으로 유지 관리 업데이트를 수행합니다. 리소스에 대한 유지 관리 기간을 구성한 후 해당 기간 동안 게스트 OS 유지 관리 및 서비스 유지 관리가 수행됩니다. 고객이 제어하는 ​​유지 관리에는 호스트 업데이트(예: Power에 대한 호스트 업데이트 이외) 및 중요 보안 업데이트가 포함되지 않습니다.

유지 관리에 대한 사전 알림을 가져올 수 있나요?

현재 네트워크 게이트웨이 리소스 유지 관리에 대한 고급 알림을 가져올 수 없습니다.

유지 관리 기간을 5시간 미만으로 구성할 수 있나요?

이때 원하는 표준 시간대에서 최소 5시간의 창을 구성해야 합니다.

일별 일정 이외의 유지 관리 기간을 구성할 수 있나요?

이때 일별 유지 관리 기간을 구성해야 합니다.

특정 업데이트를 제어할 수 없는 경우가 있나요?

고객 제어 유지 관리는 게스트 OS 및 서비스 업데이트를 지원합니다. 이러한 업데이트는 고객에게 우려를 불러일으키는 대부분의 유지 관리 항목을 설명합니다. 호스트 업데이트를 포함한 일부 다른 형식의 업데이트는 고객 제어 유지 관리 범위를 벗어납니다.

심각도가 높은 보안 문제가 고객을 위험에 빠뜨릴 수 있는 경우 Azure는 유지 관리 기간에 대한 고객 제어를 재정의하고 변경 내용을 적용해야 할 수 있습니다. 이러한 변경은 극단적인 경우에만 사용되는 드문 경우입니다.

유지 관리 구성 리소스는 게이트웨이 리소스와 동일한 지역에 있어야 하나요?

예.

고객 제어 유지 관리를 사용하도록 구성할 수 있는 게이트웨이 SKU는 무엇인가요?

모든 Azure VPN 게이트웨이 SKU(기본 SKU 제외)는 고객 제어 유지 관리를 사용하도록 구성할 수 있습니다.

유지 관리 구성 정책이 게이트웨이 리소스에 할당된 후 적용되는 데 시간이 얼마나 걸리나요?

유지 관리 정책이 게이트웨이 리소스와 연결된 후 네트워크 게이트웨이가 유지 관리 일정을 따르는 데 최대 24시간이 걸릴 수 있습니다.

기본 SKU 공용 IP 주소를 기반으로 고객 제어 유지 관리를 사용하는 데 제한 사항이 있나요?

예. 서비스 업데이트의 경우를 제외하고 기본 SKU 공용 IP 주소를 사용하는 리소스에는 고객 제어 유지 관리가 작동하지 않습니다. 이러한 게이트웨이의 경우 게스트 OS 유지 관리는 인프라 제한 사항으로 인해 고객이 제어하는 ​​유지 관리 일정을 따르지 않습니다.

공존 시나리오에서 VPN과 ExpressRoute를 사용할 때 유지 관리 기간을 어떻게 계획해야 하나요?

공존 시나리오에서 VPN 및 ExpressRoute를 사용하는 경우 또는 백업 역할을 하는 리소스가 있을 때마다 별도의 유지 관리 기간을 설정하는 것이 좋습니다. 이 방식을 사용하면 유지 관리가 동시에 백업 리소스에 영향을 주지 않습니다.

리소스 중 하나의 유지 관리 기간을 향후 날짜로 예약했습니다. 그때까지 이 리소스에 대한 유지 관리 작업이 일시 중지되나요?

아니요, 예약된 유지 관리 기간 전 기간 동안 리소스에 대한 유지 관리 작업은 일시 중지되지 않습니다. 유지 관리 일정에 포함되지 않은 날짜에는 리소스에 대한 유지 관리가 평소와 같이 계속됩니다.

고객 제어 게이트웨이 유지 관리를 자세히 알아보려면 어떻게 해야 하나요?

자세한 내용은 VPN Gateway에 대한 고객 제어 게이트웨이 유지 관리 구성 문서를 참조하세요.

관련 콘텐츠

"OpenVPN"은 OpenVPN Inc.의 상표입니다.