Внасяне на VPN профил в PowerShell с Add-VpnConnection

Няма команда Import-VpnProfile, а най-близката до нея, 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 или по-нов идват с модула; ако липсва, никакъв копиран скрипт няма да накара този хост да приеме собствен профил. Командите, които имат значение, са Add-VpnConnection, Get-VpnConnection и Remove-VpnConnection, а списъкът с параметри в справката за Add-VpnConnection си струва да се прочете веднъж изцяло.

Собствен означава, че VPN стекът на Windows прекратява тунела. Това покрива IKEv2, често с машинен сертификат; SSTP, който е TLS с потребителско или сертификатно удостоверяване отвътре; и 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 са отделни параметри и шлюзът се интересува само от комбинацията. Направете едното правилно, а другото грешно и получавате профил, който не се свързва с нищо или заспива с вече вдигнат тунел. Задайте и двете явно, вместо да се доверявате на стойност по подразбиране, избрана за друга услуга.

• IKEv2 с MachineCertificate: клиентът представя компютърен сертификат; задайте също -EncryptionLevel Required.
• SSTP с Eap: първо TLS тунел, после PEAP/MSCHAPv2 или сертификат в EAP. Това изисква XML от стъпка 3.
• SSTP, L2TP или PPTP с MSChapv2, Chap или Pap: обикновено потребителско име и парола, без EAP блок.
• L2TP с MSChapv2 и -Lt2pPsk: 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 току-що записа, така че можете да го прегледате без второ извикване. Ако името вече съществува, командата отказва да работи; -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

Дръжте тайните извън скрипт файла. PSK, подаден на командния ред или вграден в .ps1, попада в транскрипти, запазени сесии и споделени хранилища, а -RememberCredential кешира потребителските данни за по-късно, превръщайки еднократен тест в трайно разрешение.

Стъпка 4: Решете обхвата преди първото стартиране

Същата команда пише в два различни тефтера. Без -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 може да тунелира перфектно и пак да се проваля при всяко търсене в интранет. След това погледнете маршрута по подразбиране: при изключен split tunneling маршрутът 0.0.0.0/0 с най-ниска метрика трябва да сочи към VPN интерфейса, а при включен — само префиксите, които очаквате. Ако и двете изглеждат правилни, а трафикът все още умира, проблемът е отвъд профила, в политиката или филтъра на шлюза.

Когато връзката се провали напълно, кодът стеснява стъпката за връщане:

• 691: шлюзът отхвърли данните за достъп. Върнете се към стъпка 3, не към тунела.
• 809: IKEv2 ръкостискането така и не завърши. Проверете UDP 500 и 4500, както и доверието към сертификатите.
• 789: предварително споделеният ключ за L2TP/IPsec липсва или е грешен.
• 868: името на сървъра не се разреши. Оправете DNS, преди да редактирате профила.

Дръжте работещата команда до настройките, които кодира, за да може следващият човек да я пресъздаде, вместо да реверсинжинерства профила от интерфейса. Ако все пак трябва да пресъздадете, изтрийте записа и го създайте наново от същите параметри; кърпенето на полуконфигуриран профил оставя стари маршрути и състояние на удостоверяване. А ако файлът никога не е бил собствен, върнете се при клиента, който го притежава. .ovpn, преоблечен като IKEv2 профил, не е внос, а билет за поддръжка.