지점 및 사이트 간 VPN 연결 정보
P2S(지점 및 사이트 간) VPN 게이트웨이 연결을 사용하면 개별 클라이언트 컴퓨터에서 가상 네트워크에 대한 안전한 연결을 만들 수 있습니다. P2S 연결은 클라이언트 컴퓨터에서 시작하여 설정됩니다. 이 솔루션은 집 또는 회의실과 같은 원격 위치에서 Azure VNet에 연결하려는 재택 근무자에게 유용합니다. 또한 P2S VPN은 VNet에 연결해야 하는 클라이언트가 몇 개만 있는 경우 S2S VPN 대신 사용할 수 있는 유용한 솔루션입니다. 지점 및 사이트 간 구성에는 경로 기반 VPN 형식이 필요합니다.
이 문서는 현재 배포 모델에 적용됩니다. 레거시 배포에 대한 P2S - 클래식 을 참조하세요.
P2S는 어떤 프로토콜을 사용하나요?
지점 및 사이트 간 VPN에서는 다음 프로토콜 중 하나를 사용할 수 있습니다.
OpenVPN® 프로토콜로, SSL/TLS 기반 VPN 프로토콜입니다. 대부분의 방화벽에서 TLS가 사용되는 TCP 포트 443 아웃바운드를 열기 때문에 TLS VPN 솔루션이 방화벽을 통과할 수 있습니다. OpenVPN은 Android, iOS(버전 11.0 이상), Windows, Linux, Mac 디바이스(macOS 버전 10.13 이상)에서 연결하는 데 사용할 수 있습니다.
SSTP(Secure Socket Tunneling Protocol) - 독점적인 TLS 기반 VPN 프로토콜입니다. 대부분의 방화벽에서 TLS가 사용되는 TCP 포트 443 아웃바운드를 열기 때문에 TLS VPN 솔루션이 방화벽을 통과할 수 있습니다. SSTP는 Windows 디바이스에서만 지원됩니다. Azure는 SSTP가 설치되고 TLS 1.2를 지원하는 모든 Windows 버전(Windows 8.1 이상)을 지원합니다.
IKEv2 VPN - 표준 기반 IPsec VPN 솔루션입니다. IKEv2 VPN은 Mac 디바이스(macOS 버전 10.11 이상)에서 연결하는 데 사용할 수 있습니다.
P2S VPN 클라이언트는 어떻게 인증되나요?
Azure에서 P2S VPN 연결을 허용하기 전에 먼저 사용자를 인증해야 합니다. P2S 게이트웨이를 구성할 때 선택할 수 있는 인증 유형은 세 가지입니다. 옵션은 다음과 같습니다.
- Azure 인증서
- Microsoft Entra ID
- RADIUS 및 Active Directory 도메인 서버
P2S 게이트웨이 구성에 대해 여러 인증 유형을 선택할 수 있습니다. 여러 인증 유형을 선택하는 경우 사용하는 VPN 클라이언트는 하나 이상의 인증 유형과 해당 터널 유형에서 지원되어야 합니다. 예를 들어 터널 유형에 대해 “IKEv2 및 OpenVPN”을 선택하고 인증 유형에 대해 “Microsoft Entra ID 및 Radius” 또는 “Microsoft Entra ID 및 Azure Certificate”를 선택하는 경우 Microsoft Entra ID는 IKEv2에서 지원되지 않으므로 OpenVPN 터널 유형만 사용합니다.
다음 표에서는 선택한 터널 유형과 호환되는 인증 메커니즘을 보여 줍니다. 각 메커니즘을 사용하려면 VPN 클라이언트 프로필 구성 파일에서 사용할 수 있는 적절한 설정으로 연결 디바이스의 해당 VPN 클라이언트 소프트웨어를 구성해야 합니다.
| 터널 유형 | 인증 메커니즘 |
|---|---|
| OpenVPN | Microsoft Entra ID, Radius Auth 및 Azure 인증서의 하위 집합 |
| SSTP | Radius Auth/ Azure 인증서 |
| IKEv2 | Radius Auth/ Azure 인증서 |
| IKEv2 및 OpenVPN | Radius Auth/ Azure 인증서/ Microsoft Entra ID 및 Radius Auth/ Microsoft Entra ID 및 Azure 인증서 |
| IKEv2 및 SSTP | Radius Auth/ Azure 인증서 |
인증서 인증
인증서 인증을 위해 P2S 게이트웨이를 구성하는 경우 신뢰할 수 있는 루트 인증서 공개 키를 Azure 게이트웨이에 업로드합니다. 엔터프라이즈 솔루션을 사용하여 생성된 루트 인증서를 사용하거나 자체 서명된 인증서를 생성할 수 있습니다.
인증하려면 연결하는 각 클라이언트에 신뢰할 수 있는 루트 인증서에서 생성된 설치된 클라이언트 인증서가 있어야 합니다. 이는 VPN 클라이언트 소프트웨어에 추가됩니다. 클라이언트 인증서의 유효성 검사는 VPN 게이트웨이에서 수행되며, P2S VPN 연결을 설정하는 동안 발생합니다.
인증서 워크플로
상위 수준에서 다음 단계를 수행하여 Azure AD 인증을 구성해야 합니다.
- P2S 게이트웨이에서 추가 필수 설정(클라이언트 주소 풀 등)과 함께 인증서 인증을 사용하도록 설정하고 루트 CA 공개 키 정보를 업로드합니다.
- VPN 클라이언트 프로필 구성 파일(프로필 구성 패키지)을 생성하고 다운로드합니다.
- 각 연결 클라이언트 컴퓨터에 클라이언트 인증서를 설치합니다.
- VPN 프로필 구성 패키지에 있는 설정을 사용하여 클라이언트 컴퓨터에서 VPN 클라이언트를 구성합니다.
- 연결.
Microsoft Entra ID 인증
VPN 사용자가 Microsoft Entra ID 자격 증명을 사용하여 인증할 수 있도록 P2S 게이트웨이를 구성할 수 있습니다. 네이티브 Microsoft Entra ID 인증을 사용하면 VPN에 Microsoft Entra 조건부 액세스 및 MFA(다단계 인증) 기능을 사용할 수 있습니다. Microsoft Entra ID 인증은 OpenVPN 프로토콜에 대해서만 지원됩니다. 인증하고 연결하려면 클라이언트가 Azure VPN Client를 사용해야 합니다.
VPN Gateway는 이제 새로운 Microsoft 등록 앱 ID와 최신 버전의 Azure VPN Client에 대한 해당 대상 그룹 값을 지원합니다. 새 대상 그룹 값을 사용하여 P2S VPN Gateway를 구성하는 경우 Microsoft Entra 테넌트에 대한 Azure VPN Client 앱 수동 등록 프로세스를 건너뜁니다. 앱 ID는 이미 만들어져 있으며 테넌트는 추가 등록 단계 없이 자동으로 사용할 수 있습니다. 이 프로세스는 전역 관리자 역할을 통해 앱에 권한을 부여하거나 권한을 할당할 필요가 없기 때문에 Azure VPN Client를 수동으로 등록하는 것보다 더 안전합니다.
이전에는 Azure VPN Client 앱을 Microsoft Entra 테넌트에 수동으로 등록(통합)해야 했습니다. 클라이언트 앱을 등록하면 Azure VPN Client 애플리케이션의 ID를 나타내는 앱 ID가 만들어지며 전역 관리자 역할을 사용하여 권한을 부여해야 합니다. 애플리케이션 개체 형식 간의 차이점을 더 잘 이해하려면 애플리케이션이 Microsoft Entra ID에 추가되는 방법과 이유를 참조하세요.
가능하면 Azure VPN Client 앱을 테넌트에 수동으로 등록하지 않고 Microsoft에 등록된 Azure VPN Client 앱 ID 및 해당 대상 그룹 값을 사용하여 새 P2S 게이트웨이를 구성하는 것이 좋습니다. Microsoft Entra ID 인증을 사용하는 이전에 구성한 Azure VPN Gateway가 있는 경우 게이트웨이와 클라이언트를 업데이트하여 새로운 Microsoft 등록 앱 ID를 활용할 수 있습니다. Linux 클라이언트를 연결하려면 P2S 게이트웨이를 새 대상 그룹 값으로 업데이트해야 합니다. Linux용 Azure VPN Client는 이전 대상 그룹 값과 호환되지 않습니다. 새 대상 그룹 값을 사용하기 위해 업데이트하려는 기존 P2S 게이트웨이가 있는 경우 P2S VPN Gateway의 대상 그룹 변경을 참조하세요.
고려 사항 및 제한 사항:
P2S VPN Gateway는 하나의 대상 그룹 값만 지원할 수 있습니다. 여러 대상 그룹 값을 동시에 지원할 수 없습니다.
현재 최신 Microsoft 등록 앱 ID는 수동으로 등록된 이전 앱만큼 많은 대상 그룹 값을 지원하지 않습니다. Azure Public 또는 사용자 지정 이외의 대상 그룹 값이 필요한 경우 이전에 수동으로 등록한 방법 및 값을 사용합니다.
Linux용 Azure VPN Client는 수동으로 등록된 앱에 맞는 이전 대상 그룹 값을 사용하도록 구성된 P2S 게이트웨이와 이전 버전과 호환되지 않습니다. Linux용 Azure VPN Client는 사용자 지정 대상 그룹 값을 지원합니다.
-
Linux용 Azure VPN Client는 다른 Linux 배포판 및 릴리스에서 작동할 수 있지만 Linux용 Azure VPN Client는 다음 릴리스에서만 지원됩니다.
- Ubuntu 20.04
- Ubuntu 22.04
macOS 및 Windows용 Azure VPN Client는 수동으로 등록된 앱에 맞는 이전 대상 그룹 값을 사용하도록 구성된 P2S 게이트웨이와 이전 버전과 호환됩니다. 이러한 클라이언트에서는 사용자 지정 대상 그룹 값을 사용할 수도 있습니다.
다음 표에는 각 앱 ID에 대해 지원되는 Azure VPN Client 버전과 사용 가능한 해당 대상 그룹 값이 나와 있습니다.
| 앱 ID | 지원되는 대상 그룹 값 | 지원되는 클라이언트 |
|---|---|---|
| Microsoft 등록 | - Azure Public: c632b3df-fb67-4d84-bdcf-b95ad541b5c8 |
- Linux - Windows - macOS |
| 수동으로 등록됨 | - Azure Public: 41b23e61-6c1e-4545-b367-cd054e0ed4b4- Azure Government: 51bb15d4-3a4f-4ebf-9dca-40096fe32426- Azure 독일: 538ee9e6-310a-468d-afef-ea97365856a9- 21Vianet에서 운영하는 Microsoft Azure: 49f817b6-84ae-4cc0-928c-73f27289b3aa |
- Windows - macOS |
| 사용자 지정 | <custom-app-id> |
- Linux - Windows - macOS |
Microsoft Entra ID 워크플로
상위 수준에서 다음 단계를 수행하여 Microsoft Entra ID 인증을 구성해야 합니다.
- 수동 앱 등록을 사용하는 경우 Entra 테넌트에서 필요한 단계를 수행합니다.
- 추가 필수 설정(클라이언트 주소 풀 등)과 함께 P2S 게이트웨이에서 Microsoft Entra ID 인증을 사용하도록 설정합니다.
- VPN 클라이언트 프로필 구성 파일(프로필 구성 패키지)을 생성하고 다운로드합니다.
- 클라이언트 컴퓨터에서 Azure VPN Client를 다운로드, 설치, 구성합니다.
- 연결.
AD(Active Directory) 도메인 서버
AD 도메인 인증을 사용하면 사용자가 자신의 조직 도메인 자격 증명을 사용하여 Azure에 연결할 수 있습니다. AD 서버와 통합되는 RADIUS 서버가 필요합니다. 또한 조직에서 기존 RADIUS 배포를 사용할 수도 있습니다.
RADIUS 서버를 온-프레미스 또는 Azure VNet에 배포할 수 있습니다. 인증하는 동안 Azure VPN Gateway에서 통과 역할을 수행하여 RADIUS 서버와 연결된 디바이스 간에 인증 메시지를 전달합니다. 따라서 RADIUS 서버에 대한 게이트웨이 연결 가능성이 중요합니다. RADIUS 서버가 온-프레미스에 있는 경우 연결 가능성을 위해 Azure에서 온-프레미스 사이트로의 VPN S2S 연결이 필요합니다.
RADIUS 서버는 AD 인증서 서비스와 통합할 수도 있습니다. 이렇게 하면 Azure 인증서 인증 대신 P2S 인증서 인증용 RADIUS 서버 및 엔터프라이즈 인증서 배포를 사용할 수 있습니다. 장점은 루트 인증서와 해지된 인증서를 Azure에 업로드할 필요가 없다는 것입니다.
또한 RADIUS 서버는 다른 외부 ID 시스템과 통합할 수도 있습니다. 이렇게 하면 다단계 옵션을 포함하여 P2S VPN에 대한 많은 인증 옵션이 제공됩니다.
P2S 게이트웨이 구성 단계는 P2S - RADIUS 구성을 참조하세요.
클라이언트 구성 요구 사항은 무엇인가요?
클라이언트 구성 요구 사항은 사용하는 VPN 클라이언트, 인증 유형 및 프로토콜에 따라 달라집니다. 다음 표에서는 사용 가능한 클라이언트 및 각 구성에 대한 해당 문서를 보여 줍니다.
| 인증 | 터널 종류 | 클라이언트 OS | VPN 클라이언트 |
|---|---|---|---|
| 인증서 | |||
| IKEv2, SSTP | Windows | 네이티브 VPN 클라이언트 | |
| IKEv2 | macOS | 네이티브 VPN 클라이언트 | |
| IKEv2 | Linux | strongSwan | |
| OpenVPN | Windows | Azure VPN 클라이언트 OpenVPN 클라이언트 |
|
| OpenVPN | macOS | OpenVPN 클라이언트 | |
| OpenVPN | iOS | OpenVPN 클라이언트 | |
| OpenVPN | Linux | Azure VPN Client OpenVPN 클라이언트 |
|
| Microsoft Entra ID | |||
| OpenVPN | Windows | Azure VPN 클라이언트 | |
| OpenVPN | macOS | Azure VPN Client | |
| OpenVPN | Linux | Azure VPN Client |
어떤 게이트웨이 SKU에서 P2S VPN을 지원하나요?
다음 표에서는 터널, 연결, 처리량별 게이트웨이 SKU를 설명합니다. 자세한 내용은 게이트웨이 SKU 정보를 참조하세요.
| VPN 게이트웨이 생성 |
SKU | S2S/VNet-to-VNet 터널 |
P2S SSTP 연결 |
P2S IKEv2/OpenVPN Connections |
집계 처리량 벤치마크 |
BGP | Zone-redundant | Virtual Network에서 지원되는 VM 수 |
|---|---|---|---|---|---|---|---|---|
| 생성 1 | 기본 | 최대 10 | 최대 128 | 지원되지 않음 | 100Mbps | 지원되지 않음 | 아니요 | 200 |
| 생성 1 | VpnGw1 | 최대 30 | 최대 128 | 최대 250 | 650Mbps | 지원됨 | 아니요 | 450 |
| 생성 1 | VpnGw2 | 최대 30 | 최대 128 | 최대 500 | 1Gbps | 지원됨 | 아니요 | 1300 |
| 생성 1 | VpnGw3 | 최대 30 | 최대 128 | 최대 1000 | 1.25Gbps | 지원됨 | 아니요 | 4000 |
| 생성 1 | VpnGw1AZ | 최대 30 | 최대 128 | 최대 250 | 650Mbps | 지원됨 | 예 | 1000 |
| 생성 1 | VpnGw2AZ | 최대 30 | 최대 128 | 최대 500 | 1Gbps | 지원됨 | 예 | 2000 |
| 생성 1 | VpnGw3AZ | 최대 30 | 최대 128 | 최대 1000 | 1.25Gbps | 지원됨 | 예 | 5000 |
| 생성 2 | VpnGw2 | 최대 30 | 최대 128 | 최대 500 | 1.25Gbps | 지원됨 | 아니요 | 685 |
| 생성 2 | VpnGw3 | 최대 30 | 최대 128 | 최대 1000 | 2.5Gbps | 지원됨 | 아니요 | 2240 |
| 생성 2 | VpnGw4 | 최대 100* | 최대 128 | 최대 5,000 | 5Gbps | 지원됨 | 아니요 | 5300 |
| 생성 2 | VpnGw5 | 최대 100* | 최대 128 | 최대 10000 | 10Gbps | 지원됨 | 아니요 | 6700 |
| 생성 2 | VpnGw2AZ | 최대 30 | 최대 128 | 최대 500 | 1.25Gbps | 지원됨 | 예 | 2000 |
| 생성 2 | VpnGw3AZ | 최대 30 | 최대 128 | 최대 1000 | 2.5Gbps | 지원됨 | 예 | 3300 |
| 생성 2 | VpnGw4AZ | 최대 100* | 최대 128 | 최대 5,000 | 5Gbps | 지원됨 | 예 | 4400 |
| 생성 2 | VpnGw5AZ | 최대 100* | 최대 128 | 최대 10000 | 10Gbps | 지원됨 | 예 | 9000 |
참고 항목
기본 SKU는 제한 사항이 적용되며 IKEv2, IPv6 또는 RADIUS 인증을 지원하지 않습니다. 자세한 내용은 VPN Gateway 설정을 참조하세요.
P2S용 VPN 게이트웨이에 구성된 IKE/IPsec 정책은 무엇인가요?
이 섹션의 표에는 기본 정책의 값이 표시됩니다. 그러나 사용자 지정 정책에 사용 가능한 지원되는 값은 반영되지 않습니다. 사용자 지정 정책은 New-AzVpnClientIpsecParameter PowerShell cmdlet에 나열된 허용되는 값을 참조하세요.
IKEv2
| 암호화 | 무결성 | PRF | DH 그룹 |
|---|---|---|---|
| GCM_AES256 | GCM_AES256 | SHA384 | GROUP_24 |
| GCM_AES256 | GCM_AES256 | SHA384 | GROUP_14 |
| GCM_AES256 | GCM_AES256 | SHA384 | GROUP_ECP384 |
| GCM_AES256 | GCM_AES256 | SHA384 | GROUP_ECP256 |
| GCM_AES256 | GCM_AES256 | SHA256 | GROUP_24 |
| GCM_AES256 | GCM_AES256 | SHA256 | GROUP_14 |
| GCM_AES256 | GCM_AES256 | SHA256 | GROUP_ECP384 |
| GCM_AES256 | GCM_AES256 | SHA256 | GROUP_ECP256 |
| AES256 | SHA384 | SHA384 | GROUP_24 |
| AES256 | SHA384 | SHA384 | GROUP_14 |
| AES256 | SHA384 | SHA384 | GROUP_ECP384 |
| AES256 | SHA384 | SHA384 | GROUP_ECP256 |
| AES256 | SHA256 | SHA256 | GROUP_24 |
| AES256 | SHA256 | SHA256 | GROUP_14 |
| AES256 | SHA256 | SHA256 | GROUP_ECP384 |
| AES256 | SHA256 | SHA256 | GROUP_ECP256 |
| AES256 | SHA256 | SHA256 | GROUP_2 |
IPsec
| 암호화 | 무결성 | PFS 그룹 |
|---|---|---|
| GCM_AES256 | GCM_AES256 | GROUP_NONE |
| GCM_AES256 | GCM_AES256 | GROUP_24 |
| GCM_AES256 | GCM_AES256 | GROUP_14 |
| GCM_AES256 | GCM_AES256 | GROUP_ECP384 |
| GCM_AES256 | GCM_AES256 | GROUP_ECP256 |
| AES256 | SHA256 | GROUP_NONE |
| AES256 | SHA256 | GROUP_24 |
| AES256 | SHA256 | GROUP_14 |
| AES256 | SHA256 | GROUP_ECP384 |
| AES256 | SHA256 | GROUP_ECP256 |
| AES256 | SHA1 | GROUP_NONE |
P2S용 VPN 게이트웨이에 구성된 TLS 정책은 무엇인가요?
TLS
| 정책 |
|---|
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
| **TLS_AES_256_GCM_SHA384 |
| **TLS_AES_128_GCM_SHA256 |
**OpenVPN을 사용하여 TLS1.3에서만 지원됨
P2S 연결은 어떻게 구성하나요?
P2S 구성에는 몇 가지 특정한 단계가 필요합니다. 다음 문서에는 일반적인 P2S 구성을 수행하는 단계가 포함되어 있습니다.
P2S 연결 구성 제거
PowerShell 또는 CLI를 사용하여 연결의 구성을 제거할 수 있습니다. 예제를 보려면 FAQ를 참조하세요.
P2S 라우팅은 어떻게 작동하나요?
다음 문서를 참조하세요.
FAQ
지점 및 사이트에 대한 FAQ 항목이 여러 가지 있습니다. VPN Gateway FAQ를 참조하고 특히 인증서 인증과 RADIUS 섹션에 주의합니다.
다음 단계
- P2S 연결 구성 - Azure 인증서 인증
- P2S 연결 구성 - Microsoft Entra ID 인증“OpenVPN”은 OpenVPN Inc.의 상표입니다.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기