Azure P2S 클라이언트 인증: Entra, 인증서 또는 RADIUS
Entra 로그인, 클라이언트 인증서, RADIUS에는 서로 다른 Azure VPN 클라이언트와 프로필이 필요합니다. 먼저 방법, 다음으로 클라이언트, 마지막으로 프로필을 선택하십시오.
설치 프로그램이 실행되고 프로필이 가져와지지만 로그인 단계에서 연결이 실패한다. 이런 문의 대부분은 클라이언트의 버그가 아니다. OpenVPN 호환 애플리케이션은 터널을 운반할 수 있지만 Microsoft Entra 로그인을 수행하는 방법은 모를 수 있다. 루프를 피하는 순서는 방법, 그다음 클라이언트, 그다음 프로필이다. 게이트웨이에 구성된 인증 방법을 선택하고, Microsoft가 그 방법에 대해 문서화한 클라이언트를 선택한 다음에야 해당 클라이언트가 기대하는 프로필을 생성한다. 아래 내용은 모두 이 순서를 따른다.
설치 프로그램이 아니라 방법에서 시작하십시오
게이트웨이는 하나 이상의 터널 유형과 인증 방법으로 구성된다. 데스크톱에 있는 파일 확장자가 아니라 이 조합이 어떤 클라이언트가 지원되는지를 결정한다.
무엇이든 내려받기 전에 이 조합을 적어 두십시오. 지원 매트릭스는 좁고 시작을 잘못하면 반나절이 사라진다.
배포 노트에 남겨 두는 매핑은 다음과 같다.
| Authentication | Tunnel type | Documented client |
|---|---|---|
| Microsoft Entra ID | OpenVPN | Azure VPN Client on Windows and macOS |
| Client certificate | OpenVPN or IKEv2 | Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux |
| RADIUS | IKEv2 or OpenVPN, per the current matrix | Native IKEv2 client, strongSwan, or the OpenVPN client the matrix names |
이 표를 메뉴가 아니라 제약으로 읽으십시오. 각 행은 문서화된 조합이며, 한 행의 클라이언트를 다른 행의 방법과 섞는 것이 이 글이 막으려는 바로 그 실패다.
Entra ID는 OpenVPN과 Azure VPN Client의 조합을 뜻한다
지점 및 사이트 간 Entra 인증에서 지원되는 구성은 OpenVPN 터널 유형과 Azure VPN Client를 사용한다. 일반적인 사용자 이름과 암호 대화 상자는 그 통합을 대신하지 못하며, Windows 기본 IKEv2도 같은 로그인을 수행하는 대체 수단이 아니다. 타사 클라이언트가 Entra 또는 Azure AD 옵션을 제공한다면 레이블이 아니라 현재 Microsoft 설명서로 확인하십시오. 레이블은 마케팅이고 문서화된 조합이 계약이다.
macOS에서도 Azure VPN Client가 이 방법의 문서화된 경로다.
인증서에는 루트만이 아니라 클라이언트 자격 증명이 필요하다
인증서 인증은 별도로 지원되는 모델이며, Microsoft가 문서화한 OpenVPN 클라이언트와 지원되는 플랫폼의 Azure VPN Client에서 작동한다. Windows의 Azure VPN Client는 Entra 전용이 아니다. 문서화된 인증서 워크플로도 있다. 필요한 것은 게이트웨이가 신뢰하는, 사용 가능한 개인 키가 있는 의도된 클라이언트 인증서다. 게이트웨이의 신뢰된 루트는 클라이언트 자격 증명이 아니며, 발급자의 서명 키는 클라이언트 패키지에 절대 속하지 않는다.
프로필을 디버그하기 전에 체인을 확인하십시오. 게이트웨이가 신뢰하지 않는 루트에서 발급한 인증서는 잘못된 프로필처럼 보이지만 실제로는 신뢰 문제인 실패를 만든다.
플랫폼이 허용하는 곳에서는 개인 키를 내보낼 수 없게 유지하고, 현재 사용자에게 실제로 설치된 인증서로 테스트하십시오.
RADIUS는 고유한 조합을 가진 백엔드 선택이다
RADIUS는 자격 증명 결정을 직접 운영하는 서버로 옮기며, 특정 터널 유형과 클라이언트에 대해 문서화되어 있다. 환경에 여러 운영 체제가 있다고 해서 자동으로 정답은 아니다. 게이트웨이의 인증 정책을 바꾸기 전에 실제 클라이언트가 무엇을 제시할 수 있는지 파악하십시오. 게이트웨이를 RADIUS로 전환해도 기존 프로필이 모두 맞춰지지는 않는다. 클라이언트는 여전히 그 자격 증명을 요청하거나 제공할 수 있어야 한다.
혼합 환경이 이유라면 모두를 위해 게이트웨이 정책을 약화시키지 말고 플랫폼별로 해결하십시오.
2026년 미리 보기 종료 이후의 Linux
Microsoft의 Linux 종료 지침 은 Linux용 Azure VPN Client 미리 보기의 종료 날짜를 2026년 팔월 31일로 제시하므로, 2026년 십일월 기준으로 그 미리 보기는 이미 지나갔다. 기존 설치가 계속 작동할 수는 있지만 더 이상 지원, 업데이트 또는 보안 수정을 받지 못한다. 오래된 Linux 설치 프로그램을 지원되는 새 배포로 나눠 주지 마십시오. 이것은 클라이언트의 종료이며 Azure VPN Gateway나 Windows 및 macOS 클라이언트의 종료가 아니다.
문서화된 Linux 대안은 인증서 인증을 사용하는 OpenVPN 클라이언트, 또는 IKEv2와 인증서 또는 RADIUS 인증을 사용하는 strongSwan이다. 둘 다 조직의 승인이 필요한 다른 구성이며, 오래된 Entra 프로필의 이름을 바꾸어 얻는 변환이 아니다.
정책상 Entra 로그인이 필수라면 소유자는 지원되는 플랫폼이나 승인된 대체 설계를 선택해야 한다. 그것은 결정이지 우회가 아니다.
프로필을 생성하고 네 가지 확인을 수행하십시오
조합이 정해지면 의도된 게이트웨이에서 클라이언트 구성을 생성하고, 해당 클라이언트와 방법에 대해 문서화된 표현을 가져오십시오. 일반 OpenVPN 폴더와 Azure VPN Client XML 프로필은 서로 바꿀 수 없다. 게이트웨이가 여러 인증 유형을 의도적으로 사용하도록 설정했다면 하나의 연결이 모두를 만족시키리라 기대하지 말고 일치하는 프로필과 자격 증명 경로를 선택하십시오. 그런 다음 다음 순서로 확인을 수행하십시오.
- 지원되는 클라이언트가 생성된 프로필을 편집하지 않고 가져온다.
- 의도된 ID가 해당 프로필이 기대하는 방법으로 인증된다.
- 필요한 경로 및 확인자 정책이 클라이언트에 나타난다.
- 허용된 애플리케이션이 자체 프라이빗 리소스에 도달한다.
가져오기 성공은 인증 호환성도 프라이빗 리소스 권한 부여도 증명하지 않으므로 그 네 가지 확인은 분리된 채로 둔다.