VPN profila importēšana PowerShell vidē ar Add-VpnConnection

Nav neviena cmdlet ar nosaukumu Import-VpnProfile, un tuvākais, Add-VpnConnection, nekad nelasa .ovpn vai .conf failu. Tas saliek Windows vietējo profilu no parametriem, ko nododat, un tāpēc pirmā pārbaudes vieta šeit ir faila formāts, nevis komandrinda. Ja vārteja runā SSTP, IKEv2, L2TP/IPsec vai PPTP, Windows var pārvaldīt profilu un pārējais saraksts attiecas. Ja jums iedeva OpenVPN vai WireGuard failu, apstājieties pirmajā solī: šiem klientiem ir savi importētāji.

1. solis: pārliecinieties, kuru profilu Windows patiešām var pārvaldīt

Pirms visa cita datorā palaidiet Get-Command -Module VpnClient. Windows 10, Windows 11 un Server 2016 vai jaunāka versija ietver šo moduli; ja tā nav, neviens nokopēts skripts neliks šim datoram pieņemt vietējo profilu. Svarīgākie cmdlet ir Add-VpnConnection, Get-VpnConnection un Remove-VpnConnection, un Add-VpnConnection atsauces parametru sarakstu ir vērts vienreiz izlasīt pilnībā.

Vietējais nozīmē, ka Windows VPN steks pabeidz tuneli. Tas ietver IKEv2, bieži ar datora sertifikātu; SSTP, kas ir TLS ar lietotāja vai sertifikāta autentifikāciju iekšpusē; un L2TP/IPsec ar iepriekš koplietotu atslēgu. .ovpn fails ir OpenVPN skripts, nevis Windows savienojums: tajā ir tādas direktīvas kā remote, cipher vai tls-auth, par kurām Windows stekam nav ne jausmas. WireGuard .conf ir tas pats stāsts ar PrivateKey un AllowedIPs; pārvērst vienu otrā nav parametra izvēle, bet cita tuneļa implementācija.

Ir arī trešais zars. Ja administrators jums iedod VPNv2 CSP XML dokumentu vai Intune profilu, tas ir MDM ceļš, ko piemēro nodrošināšanas steks, nevis Add-VpnConnection. Netulkojiet šos mezglu nosaukumus PowerShell parametros; tā vietā jautājiet, kurš mehānisms piemēro XML.

2. solis: saskaņojiet tuneļa tipu ar autentifikācijas metodi

-TunnelType un -AuthenticationMethod ir atsevišķi parametri, un vārtejai svarīga ir tikai kombinācija. Viens pareizs, otrs nepareizs, un jūs iegūstat profilu, kas nekur nepievienojas, vai iestrēgst, kad tunelis jau ir uzcelts. Iestatiet abus skaidri, nevis paļaujieties uz noklusējumu, kas izvēlēts citam pakalpojumam.

• IKEv2 ar MachineCertificate: klients uzrāda datora sertifikātu; iestatiet arī -EncryptionLevel Required.
• SSTP ar Eap: vispirms TLS tunelis, pēc tam PEAP/MSCHAPv2 vai sertifikāts EAP iekšpusē. Tam vajadzīgs 3. soļa XML.
• SSTP, L2TP vai PPTP ar MSChapv2, Chap vai Pap: vienkāršs lietotājvārds un parole, bez EAP bloka.
• L2TP ar MSChapv2 un -Lt2pPsk: PSK sedz IPsec pusi, lietotājs sedz PPP; abiem jāsakrīt ar serveri.

Splat tur vērtības vienā vietā:

$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 atgriež objektu, ko Windows tikko ierakstīja, tāpēc varat to apskatīt bez otrā izsaukuma. Ja nosaukums jau eksistē, cmdlet atsakās darboties; -Force to pārraksta, un tā ir nepareiza refleksija ražošanas portatīvajā datorā, jo klusi izmet visu, ko kāds konfigurējis ar roku.

3. solis: nododiet akreditācijas materiālu pareizi

Paroles, iepriekš koplietotās atslēgas un EAP bloki ir vieta, kur šie skripti parasti lūzt. -EapConfigXmlStream grib XmlDocument, nevis ceļu, tāpēc vispirms izlasiet un konvertējiet failu. Nododot virkni, rodas konvertēšanas kļūda, kas izskatās kā shēmas problēma un liek cilvēkiem pārrakstīt XML, kas nekad nav bijis nepareizs.

$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

Šo XML neizdomā no bloga fragmenta. Tas nosauc EAP metodes tipu un iekšējo autentifikāciju, un vārteja abus salīdzina ar savu politiku. Nesakrītoša iekšējā metode neizdodas pēc tam, kad TLS rokasspiediens ir pabeigts, un tas izskatās tieši kā nepareiza parole, bet tā nav. Ņemiet XML no tā, kas pārvalda vārteju, vai eksportējiet to no profila, kas jau darbojas.

IKEv2 gadījumā sertifikāta puse ir meklēšana krātuvē. -MachineCertificateIssuerFilter pieņem sertifikāta objektu, un Windows to izmanto, lai atrastu lietojamu klienta sertifikātu LocalMachine\My. Sertifikātam vajag privāto atslēgu un ķēdi, kurai serveris uzticas; kad kāda trūkst, autentifikācija neizdodas bez noderīgas informācijas, tāpēc vispirms pārbaudiet krātuvi:

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

Turiet noslēpumus ārpus skripta faila. Komandrindā nodota vai .ps1 iekšā iebūvēta PSK nonāk transkriptos, saglabātās sesijās un koplietotās krātuvēs, un -RememberCredential kešo lietotāja akreditācijas datus vēlākam laikam, pārvēršot vienreizēju testu pastāvīgā atļaujā.

4. solis: izlemiet tvērumu pirms pirmās palaišanas

Tas pats cmdlet raksta divās dažādās telefona grāmatās. Bez -AllUserConnection profils ir jūsu un atrodas %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk. Ar to, no paaugstinātas komandrindas, profils nonāk %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk un ir redzams katram kontam, ieskaitot pieteikšanās ekrānu.

Tvērums nav kosmētisks. Visu lietotāju profils ir tas, ko var izmantot pakalpojuma konts, ieplānots uzdevums vai scenārijs pirms pieteikšanās; viena lietotāja profils tiem trim nav redzams. Objekti tiek lasīti arī citādi: Get-VpnConnection uzskaita pašreizējā lietotāja ierakstus, Get-VpnConnection -AllUserConnection visai mašīnai. Izvēlieties vienu tagad, un vēlāku izmaiņu uztveriet kā dzēšanu un atkārtotu izveidi, nevis rediģēšanu:

# 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. solis: pārbaudiet, kas tunelim patiešām jāpiegādā

Pievienota ikona pierāda, ka tunelis ir uzcelts, un neko vairāk. Vispirms pievienojieties no komandrindas, lai kļūmes nāk kā teksts, nevis dialogs, un pēc tam izlasiet, ko Windows ierakstīja:

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

Divi defekti, par kuriem lietotāji ziņo, kamēr statuss vēl saka Connected, ir DNS un maršrutēšana. Atrisiniet iekšējo nosaukumu un pārbaudiet, kurš serveris atbildēja; profils bez -DnsSuffix var lieliski tunelēt un tomēr izgāzties katrā intraneta meklēšanā. Pēc tam apskatiet noklusējuma maršrutu: kad sadalītais tunelis ir izslēgts, maršrutam 0.0.0.0/0 ar zemāko metriku jārāda uz VPN saskarni, bet kad ieslēgts tikai tie prefiksi, ko gaidāt. Ja abi izskatās pareizi un trafiks tomēr mirst, problēma ir aiz profila, politikā vai vārtejas filtrā.

Kad savienojums pilnībā neizdodas, kods sašaurina soli, pie kura atgriezties:

• 691: vārteja noraidīja akreditācijas datus. Atgriezieties pie 3. soļa, nevis pie tuneļa.
• 809: IKEv2 rokasspiediens nekad netika pabeigts. Pārbaudiet UDP 500 un 4500 un sertifikāta uzticēšanos.
• 789: L2TP/IPsec iepriekš koplietotā atslēga trūkst vai ir nepareiza.
• 868: servera nosaukums netika atrisināts. Izlabojiet DNS pirms profila rediģēšanas.

Turiet strādājošo komandu blakus iestatījumiem, ko tā kodē, lai nākamais cilvēks varētu pārbūvēt, nevis nojaukt profilu atpakaļ no saskarnes. Ja tiešām jāpārbūvē, izdzēsiet ierakstu un izveidojiet to no jauna ar tiem pašiem parametriem; daļēji konfigurēta profila lāpīšana atstāj novēlotus maršrutus un autentifikācijas stāvokli. Un ja fails nekad nav bijis vietējais, atgriezieties pie klienta, kuram tas pieder. Par IKEv2 profilu pārģērbts .ovpn nav imports, tas ir atbalsta biļete.