Importi VPN-profilo en PowerShell per Add-VpnConnection

Add-VpnConnection konstruas nur indiĝenajn Windows-profilojn. Parigu la tunelon kaj la aŭtentikigon kun la kluzo, agordu la amplekson konscie, poste testu vojojn kaj DNS.

Ne ekzistas cmdlet Import-VpnProfile, kaj la plej proksima aspektanta, Add-VpnConnection, neniam legas dosieron .ovpn aŭ .conf. Ĝi kunmetas indiĝenan Windows-profilo el la parametroj, kiujn vi transdonas, kaj tial la unua kontrolpunkto ĉi tie estas la dosierformo kaj ne la komandlinio. Se la kluzo parolas SSTP, IKEv2, L2TP/IPsec aŭ PPTP, Windows povas posedi la profilon kaj la resto de la listo validas. Se oni donis al vi dosieron OpenVPN aŭ WireGuard, haltu ĉe la unua paŝo: tiuj klientoj havas proprajn importantojn.

Paŝo 1: Konfirmu, kiun profilon Windows vere povas posedi

Rulu Get-Command -Module VpnClient sur la maŝino antaŭ ĉio alia. Windows 10, Windows 11 kaj Server 2016 aŭ pli nova venas kun la modulo; se ĝi mankas, neniu kopiita skripto igos ĉi tiun gastiganton akcepti indiĝenan profilon. La gravaj cmdlets estas Add-VpnConnection, Get-VpnConnection kaj Remove-VpnConnection, kaj la parametrolisto en la referenco de Add-VpnConnection indas unufoje legi tutan.

Indiĝena signifas, ke la VPN-stako de Windows finas la tunelon. Tio kovras IKEv2, ofte kun maŝina atestilo; SSTP, kiu estas TLS kun uzanta aŭ atestila aŭtentikigo interne; kaj L2TP/IPsec kun antaŭe dividita ŝlosilo. Dosiero .ovpn estas OpenVPN-skripto, ne Windows-konekto: ĝi portas direktivojn kiel remote, cipher aŭ tls-auth, pri kiuj la Windows-stako scias nenion. WireGuard .conf estas la sama historio kun PrivateKey kaj AllowedIPs; konverti unu en la alian ne estas parametra elekto sed malsama tunela efektivigo.

Estas tria branĉo. Se administranto donas al vi VPNv2 CSP XML-dokumenton aŭ Intune-profilo, tio estas la MDM-vojo, aplikata de la proviz-stako kaj ne de Add-VpnConnection. Ne traduku tiujn nodajn nomojn en PowerShell-parametrojn; demandu, kiu mekanismo aplikas la XML.

Paŝo 2: Parigu la tunelan tipon kun la aŭtentikiga metodo

-TunnelType kaj -AuthenticationMethod estas apartaj parametroj, kaj la kluzo zorgas nur pri la kombino. Faru unu ĝuste kaj la alian malĝuste kaj vi ricevas profilon, kiu konektiĝas al nenio, aŭ haltas kun la tunelo jam supre. Agordu ambaŭ eksplicite anstataŭ fidi normvaloron elektitan por alia servo.

  • IKEv2 kun MachineCertificate: la kliento prezentas komputilan atestilon; agordu ankaŭ -EncryptionLevel Required.
  • SSTP kun Eap: unue TLS-tunelo, poste PEAP/MSCHAPv2 aŭ atestilo ene de EAP. Tio bezonas la XML en paŝo 3.
  • SSTP, L2TP aŭ PPTP kun MSChapv2, Chap aŭ Pap: ordinara uzantnomo kaj pasvorto, neniu EAP-bloko.
  • L2TP kun MSChapv2 kaj -Lt2pPsk: la PSK kovras la IPsec-duonon, la uzanto kovras PPP; ambaŭ devas kongrui kun la servilo.

Splat tenas la valorojn en unu loko:

$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 redonas la objekton, kiun Windows ĵus skribis, do vi povas inspekti ĝin sen dua voko. Se la nomo jam ekzistas, la cmdlet rifuzas ruli; -Force anstataŭigas ĝin, kio estas la malĝusta reflekso sur produktada tekokomputilo ĉar ĝi silente forĵetas tion, kion iu agordis permane.

Paŝo 3: Transdonu la akreditaĵan materialon ĝuste

Pasvortoj, antaŭe dividitaj ŝlosiloj kaj EAP-blokoj estas kie ĉi tiuj skriptoj kutime rompiĝas. -EapConfigXmlStream volas XmlDocument, ne vojon, do legu kaj konvertu la dosieron unue. Transdoni ĉenon produktas konvertan eraron, kiu aspektas kiel skema problemo kaj igas homojn reverki XML, kiu neniam estis malĝusta.

$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

Tiu XML ne estas io elpensebla el blogapeco. Ĝi nomas la EAP-metodan tipon kaj la internan aŭtentikigon, kaj la kluzo komparas ambaŭ kun sia politiko. Miskongrua interna metodo malsukcesas post kiam la TLS-manpremo finiĝis, kio aspektas precize kiel malbona pasvorto kaj ne estas. Prenu la XML de tiu, kiu funkciigas la kluzon, aŭ eksportu ĝin el profilo, kiu jam funkcias.

Por IKEv2 la atestila duono estas serĉo en la konservejo. -MachineCertificateIssuerFilter prenas atestilan objekton, kaj Windows uzas ĝin por trovi uzeblan klientan atestilon en LocalMachine\My. La atestilo bezonas privatan ŝlosilon kaj ĉenon, kiun la servilo fidas; kiam mankas iu el ili, aŭtentikigo malsukcesas sen utila detalo, do kontrolu la konservejon unue:

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

Tenu sekretojn ekster la skriptdosiero. PSK transdonita sur la komandlinio aŭ bakita en .ps1 finiĝas en transskriboj, konservitaj sesioj kaj dividitaj deponejoj, kaj -RememberCredential kaŝmemorigas uzantajn akreditaĵojn por poste, transformante unufojan teston en daŭran permeson.

Paŝo 4: Decidu la amplekson antaŭ la unua rulo

La sama cmdlet skribas al du malsamaj telefonlibroj. Sen -AllUserConnection la profilo apartenas al vi kaj loĝas sub %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk. Kun ĝi, el altigita komandprompto, la profilo iras al %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk kaj estas videbla al ĉiu konto, inkluzive de la ensaluta ekrano.

Amplekso ne estas kosmetika. Profilo por ĉiuj uzantoj estas tio, kion servokonto, planita tasko aŭ antaŭ-ensaluta scenaro povas uzi; profilo por unu uzanto estas nevidebla al ĉiuj tri. La objektoj ankaŭ legeblas malsame: Get-VpnConnection listigas la rikordojn de la nuna uzanto, Get-VpnConnection -AllUserConnection la tutmaŝinajn. Elektu unu nun, kaj traktu postan ŝanĝon kiel forigi kaj rekrei anstataŭ redakti:

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

Paŝo 5: Testu, kion tunelo efektive devas liveri

Konektita ikono pruvas, ke la tunelo supremiĝis kaj nenion alian. Konektiĝu unue el la komandlinio por ke fiaskoj alvenu kiel teksto, ne kiel dialogo, poste legu, kion Windows registris:

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

La du fiaskoj, pri kiuj uzantoj raportas dum la stato ankoraŭ diras Connected, estas DNS kaj enkursigado. Solvu internan nomon kaj kontrolu, kiu servilo respondis; profilo sen -DnsSuffix povas tuneli perfekte kaj tamen fiaski ĉe ĉiu intranet-serĉo. Poste rigardu la defaŭltan vojon: kun split tunneling malŝaltita la vojo 0.0.0.0/0 kun la plej malalta metriko devus montri en la VPN-interfacon, kaj kun ĝi ŝaltita nur la prefiksoj, kiujn vi atendas. Se ambaŭ aspektas ĝuste kaj trafiko tamen mortas, la problemo estas preter la profilo, en politiko aŭ la kluzo-filtro.

Kiam la konekto tute fiaskas, la kodo mallarĝigas la paŝon por reveni:

  • 691: la kluzo rifuzis la akreditaĵojn. Reiru al paŝo 3, ne al la tunelo.
  • 809: la IKEv2-manpremo neniam finiĝis. Kontrolu UDP 500 kaj 4500, kaj atestilan fidon.
  • 789: la antaŭe dividita ŝlosilo por L2TP/IPsec mankas aŭ estas malĝusta.
  • 868: la servila nomo ne solviĝis. Riparu DNS antaŭ ol redakti la profilon.

Tenu la funkciantan komandon apud la agordoj, kiujn ĝi kodas, por ke la sekva persono povu rekonstrui anstataŭ retro-inĝenierigi la profilon el la interfaco. Se vi devas rekonstrui, forigu la rikordon kaj rekrea ĝin el la samaj parametroj; fliki duonagorditan profilon lasas malnovajn vojojn kaj aŭtentikigan staton. Kaj se la dosiero neniam estis indiĝena, reiru al la kliento, kiu posedas ĝin. .ovpn vestita kiel IKEv2-profilo ne estas importo, ĝi estas subtena bileto.

Rilataj artikoloj