Add-VpnConnection으로 PowerShell에서 VPN 프로필 가져오기

Add-VpnConnection은 Windows 네이티브 프로필만 만듭니다. 터널과 인증 쌍을 게이트웨이에 맞추고 범위를 의도적으로 정한 뒤 경로와 DNS를 테스트하세요.

Import-VpnProfile이라는 cmdlet은 없으며, 가장 비슷해 보이는 Add-VpnConnection도 .ovpn이나 .conf 파일을 읽지 않습니다. 전달한 매개변수로 Windows 네이티브 프로필을 조립하기 때문에 여기서 첫 번째 확인 지점은 명령줄이 아니라 파일 형식입니다. 게이트웨이가 SSTP, IKEv2, L2TP/IPsec, PPTP 중 하나를 지원한다면 Windows가 프로필을 소유할 수 있고 목록의 나머지가 적용됩니다. OpenVPN이나 WireGuard 파일을 받았다면 그 클라이언트들은 자체 가져오기를 가지므로 첫 단계에서 멈추십시오.

1단계: Windows가 실제로 소유할 수 있는 프로필 확인

무엇보다 먼저 머신에서 Get-Command -Module VpnClient 를 실행하십시오. Windows 10, Windows 11, Server 2016 이상에는 이 모듈이 포함되어 있으며, 없으면 복사한 스크립트로는 이 호스트가 네이티브 프로필을 받아들이게 할 수 없습니다. 중요한 cmdlet은 Add-VpnConnection, Get-VpnConnection, Remove-VpnConnection이며, Add-VpnConnection 참조 의 매개변수 목록은 한 번 전체를 읽어 볼 가치가 있습니다.

네이티브란 Windows VPN 스택이 터널을 종료한다는 뜻입니다. 여기에는 대개 머신 인증서를 쓰는 IKEv2, 내부에 사용자 또는 인증서 인증이 있는 TLS인 SSTP, 미리 공유한 키를 쓰는 L2TP/IPsec이 포함됩니다. .ovpn 파일은 OpenVPN 스크립트이지 Windows 연결이 아니며, remote, cipher, tls-auth 같은 지시문을 담고 있는데 Windows 스택에는 그런 개념이 없습니다. WireGuard의 .conf도 PrivateKey와 AllowedIPs를 동반한 같은 이야기이고, 하나를 다른 하나로 바꾸는 것은 매개변수 선택이 아니라 다른 터널 구현입니다.

세 번째 갈래도 있습니다. 관리자가 VPNv2 CSP XML 문서나 Intune 프로필을 건네준다면 그것은 MDM 경로이며, Add-VpnConnection이 아니라 프로비저닝 스택이 적용합니다. 그 노드 이름을 PowerShell 매개변수로 번역하지 말고, 어떤 메커니즘이 XML을 적용하는지 물으십시오.

2단계: 터널 종류와 인증 방법 연결

-TunnelType과 -AuthenticationMethod는 별개의 매개변수이고 게이트웨이는 조합만 봅니다. 하나는 맞고 하나는 틀리면 아무 데도 연결되지 않는 프로필이 되거나 터널이 올라간 채로 멈춥니다. 다른 서비스를 위해 선택된 기본값을 믿지 말고 둘 다 명시적으로 설정하십시오.

  • MachineCertificate와 IKEv2: 클라이언트가 컴퓨터 인증서를 제시하므로 -EncryptionLevel Required도 설정하십시오.
  • Eap와 SSTP: 먼저 TLS 터널, 그다음 PEAP/MSCHAPv2 또는 EAP 내부의 인증서입니다. 여기에는 3단계의 XML이 필요합니다.
  • MSChapv2, Chap, Pap와 SSTP, L2TP, PPTP: 사용자 이름과 암호만 쓰고 EAP 블롭은 없습니다.
  • MSChapv2와 -Lt2pPsk를 쓰는 L2TP: PSK가 IPsec 절반을, 사용자가 PPP를 담당하며 둘 다 서버와 일치해야 합니다.

splat을 쓰면 값이 한곳에 모입니다:

$p = @{
  Name                 = "Corp IKEv2"
  ServerAddress        = "vpn.example.com"
  TunnelType           = "Ikev2"
  AuthenticationMethod = "MachineCertificate"
  EncryptionLevel      = "Required"
  SplitTunneling       = $false
  DnsSuffix            = "corp.example.com"
}
Add-VpnConnection @p -PassThru

-PassThru는 Windows가 방금 기록한 개체를 반환하므로 두 번째 호출 없이 확인할 수 있습니다. 이름이 이미 있으면 cmdlet은 실행을 거부하고, -Force는 덮어쓰는데 누군가 수동으로 구성한 내용을 조용히 버리기 때문에 생산용 노트북에서는 잘못된 반사입니다.

3단계: 자격 증명 자료를 올바르게 넘기기

암호, 미리 공유한 키 와 EAP 블롭이 이 스크립트가 보통 깨지는 지점입니다. -EapConfigXmlStream은 경로가 아니라 XmlDocument를 원하므로 먼저 파일을 읽어 변환하십시오. 문자열을 넘기면 스키마 문제처럼 보이는 변환 오류가 나고, 한 번도 틀린 적 없는 XML을 다시 쓰게 만듭니다.

$eap = [xml](Get-Content -Raw .\peap-mschapv2.xml)
Add-VpnConnection -Name "Corp SSTP" -ServerAddress "sstp.example.com" `
  -TunnelType Sstp -AuthenticationMethod Eap `
  -EapConfigXmlStream $eap -EncryptionLevel Required

그 XML은 블로그 조각에서 지어낼 것이 아닙니다. EAP 방식 유형과 내부 인증을 지정하고, 게이트웨이는 둘 다를 자체 정책과 비교합니다. 맞지 않는 내부 방식은 TLS 핸드셰이크가 끝난 뒤 실패하는데, 이는 잘못된 암호와 똑같이 보이지만 그렇지 않습니다. XML은 게이트웨이를 운영하는 사람에게 받거나 이미 작동하는 프로필에서 내보내십시오.

IKEv2에서 인증서 절반은 저장소 조회입니다. -MachineCertificateIssuerFilter는 인증서 개체를 받고 Windows는 그것으로 LocalMachine\My에서 사용 가능한 클라이언트 인증서를 찾습니다. 인증서에는 개인 키와 서버가 신뢰하는 체인이 필요해 둘 중 하나가 없으면 인증이 유용한 세부 정보 없이 실패하므로 먼저 저장소를 확인하십시오:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
  Select-Object Subject, Issuer, Thumbprint, NotAfter

비밀은 스크립트 파일 밖에 두십시오. 명령줄로 넘기거나 .ps1에 구워 넣은 PSK는 기록, 저장된 세션, 공유 저장소에 남고, -RememberCredential은 사용자 자격 증명을 나중을 위해 캐시하여 일회성 테스트를 지속적인 권한으로 바꿉니다.

4단계: 첫 실행 전에 범위 결정

같은 cmdlet이 서로 다른 두 전화번호부에 씁니다. -AllUserConnection이 없으면 프로필은 본인 것이고 %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk 아래에 있습니다. 이것을 붙이면 관리자 권한 프롬프트에서 프로필이 %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk로 가고 로그인 화면을 포함한 모든 계정에 보입니다.

범위는 겉치레가 아닙니다. 모든 사용자 프로필은 서비스 계정, 예약된 작업, 로그인 전 시나리오가 쓸 수 있는 것이고, 사용자별 프로필은 그 셋 모두에게 보이지 않습니다. 개체를 읽는 방식도 다른데, Get-VpnConnection은 현재 사용자 항목을 나열하고, Get-VpnConnection -AllUserConnection은 머신 전체 항목을 나열합니다. 지금 하나를 고르고, 나중 변경은 편집이 아니라 삭제 후 재생성으로 다루십시오:

# elevated prompt
Remove-VpnConnection -Name "Corp IKEv2" -Force
Add-VpnConnection -Name "Corp IKEv2" -ServerAddress "vpn.example.com" `
  -TunnelType Ikev2 -AuthenticationMethod MachineCertificate `
  -EncryptionLevel Required -AllUserConnection

5단계: 터널이 실제로 제공해야 하는 것 테스트

연결됨 아이콘은 터널이 올라왔다는 것만 증명합니다. 먼저 명령줄에서 연결해 실패가 대화 상자가 아니라 텍스트로 오게 한 다음, Windows가 기록한 내용을 다시 읽으십시오:

rasdial "Corp IKEv2"
Get-VpnConnection -Name "Corp IKEv2" |
  Select-Object Name, ServerAddress, TunnelType, ConnectionStatus, SplitTunneling
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

상태가 여전히 Connected라고 말하는데 사용자가 보고하는 두 가지 실패는 DNS와 라우팅입니다. 내부 이름을 확인하고 어느 서버가 응답했는지 보면 되는데, -DnsSuffix가 없는 프로필은 터널은 완벽해도 인트라넷 조회가 모두 실패할 수 있습니다. 그다음 기본 경로를 보십시오: 분할 터널링이 꺼져 있으면 메트릭이 가장 낮은 0.0.0.0/0 경로가 VPN 인터페이스를 가리켜야 하고, 켜져 있으면 예상한 접두사만 가리켜야 합니다. 둘 다 맞아 보이는데 트래픽이 계속 죽는다면 문제는 프로필 너머, 정책이나 게이트웨이 필터에 있습니다.

연결이 완전히 실패하면 코드가 되돌아갈 단계를 좁혀 줍니다:

  • 691: 게이트웨이가 자격 증명을 거부했습니다. 터널이 아니라 3단계로 돌아가십시오.
  • 809: IKEv2 핸드셰이크가 완료되지 않았습니다. UDP 500과 4500, 인증서 신뢰를 확인하십시오.
  • 789: L2TP/IPsec 미리 공유한 키가 없거나 잘못되었습니다.
  • 868: 서버 이름이 확인되지 않았습니다. 프로필을 편집하기 전에 DNS를 고치십시오.

작동하는 명령을 그것이 담고 있는 설정 옆에 두어 다음 사람이 UI에서 프로필을 역설계하지 않고 다시 만들 수 있게 하십시오. 정말 다시 만들어야 한다면 항목을 삭제하고 같은 매개변수로 새로 만드십시오. 반쯤 구성된 프로필을 덧대면 오래된 경로와 인증 상태가 남습니다. 그리고 그 파일이 애초에 네이티브가 아니었다면 그것을 소유한 클라이언트로 돌아가십시오, IKEv2 프로필로 분장한 .ovpn은 가져오기가 아니라 지원 티켓이기 때문입니다.

관련 글