Import profilu VPN v PowerShellu pomocí Add-VpnConnection
Add-VpnConnection sestavuje jen nativní profily Windows. Spárujte tunel a ověřování s bránou, záměrně nastavte rozsah a pak otestujte trasy a DNS.
Neexistuje žádný cmdlet Import-VpnProfile a ten, který vypadá nejblíž, Add-VpnConnection, nikdy nečte soubor .ovpn ani .conf. Sestavuje nativní profil Windows z parametrů, které mu předáte, a proto je první kontrolou tady formát souboru, ne příkazový řádek. Pokud brána mluví SSTP, IKEv2, L2TP/IPsec nebo PPTP, Windows může profil vlastnit a zbytek seznamu platí. Pokud jste dostali soubor OpenVPN nebo WireGuard, zastavte se u prvního kroku: tito klienti mají vlastní importéry.
Krok 1: Ověřte, který profil Windows skutečně může vlastnit
Spusťte Get-Command -Module VpnClient na stroji dřív než cokoli jiného. Windows 10, Windows 11 a Server 2016 nebo novější modul obsahují; pokud chybí, žádný zkopírovaný skript tohoto hostitele nepřiměje přijmout nativní profil. Důležité jsou cmdlety Add-VpnConnection, Get-VpnConnection a Remove-VpnConnection a seznam parametrů v referenci Add-VpnConnection stojí za jedno celé přečtení.
Nativní znamená, že tunel ukončuje VPN stack Windows. To zahrnuje IKEv2, často s certifikátem počítače; SSTP, což je TLS s ověřením uživatele nebo certifikátu uvnitř; a L2TP/IPsec s předsdíleným klíčem. Soubor .ovpn je skript OpenVPN, ne připojení Windows: nese direktivy jako remote, cipher nebo tls-auth, o kterých stack Windows nic neví. WireGuard .conf je stejný příběh s PrivateKey a AllowedIPs; převést jedno na druhé není volba parametru, ale jiná implementace tunelu.
Existuje třetí větev. Pokud vám správce předá dokument VPNv2 CSP XML nebo profil Intune, je to cesta MDM, kterou aplikuje zřizovací stack, ne Add-VpnConnection. Nepřekládejte názvy těch uzlů do parametrů PowerShellu; zeptejte se, který mechanismus XML aplikuje.
Krok 2: Spárujte typ tunelu s metodou ověřování
-TunnelType a -AuthenticationMethod jsou samostatné parametry a bránu zajímá jen kombinace. Jedno nastavte správně a druhé špatně a dostanete profil, který se nikam nepřipojí, nebo zůstane viset s už zvednutým tunelem. Nastavte oba explicitně, místo abyste věřili výchozí hodnotě zvolené pro jinou službu.
- IKEv2 s MachineCertificate: klient předkládá certifikát počítače; nastavte také -EncryptionLevel Required.
- SSTP s Eap: nejprve tunel TLS, pak PEAP/MSCHAPv2 nebo certifikát uvnitř EAP. To vyžaduje XML z kroku 3.
- SSTP, L2TP nebo PPTP s MSChapv2, Chap nebo Pap: obyčejné uživatelské jméno a heslo, žádný blob EAP.
- L2TP s MSChapv2 a -Lt2pPsk: PSK pokrývá část IPsec, uživatel pokrývá PPP; obojí musí odpovídat serveru.
Splat drží hodnoty na jednom místě:
$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 vrací objekt, který Windows právě zapsal, takže ho můžete prohlédnout bez druhého volání. Pokud jméno už existuje, cmdlet odmítne běžet; -Force ho přepíše, což je na produkčním notebooku špatný reflex, protože tiše zahodí, co někdo nastavil ručně.
Krok 3: Předejte materiál pověření správně
Hesla, předsdílené klíče a bloby EAP jsou místem, kde se tyto skripty obvykle lámou. -EapConfigXmlStream chce XmlDocument, ne cestu, takže soubor nejdřív přečtěte a přetypujte. Předání řetězce vyvolá chybu převodu, která vypadá jako problém se schématem a nutí lidi přepisovat XML, které nikdy špatné nebylo.
$eap = [xml](Get-Content -Raw .\peap-mschapv2.xml)
Add-VpnConnection -Name "Corp SSTP" -ServerAddress "sstp.example.com" `
-TunnelType Sstp -AuthenticationMethod Eap `
-EapConfigXmlStream $eap -EncryptionLevel RequiredToto XML není něco, co se vymýšlí z úryvku blogu. Pojmenovává typ metody EAP a vnitřní ověřování a brána obojí porovnává se svou politikou. Neodpovídající vnitřní metoda selže po dokončení TLS handshake, což vypadá přesně jako špatné heslo a není. Vezměte XML od toho, kdo bránu provozuje, nebo ho exportujte z profilu, který už funguje.
U IKEv2 je certifikátová část hledání v úložišti. -MachineCertificateIssuerFilter bere objekt certifikátu a Windows ho použije k nalezení použitelného klientského certifikátu v LocalMachine\My. Certifikát potřebuje soukromý klíč a řetěz, kterému server věří; když chybí kterékoli, ověřování selže bez užitečného detailu, takže nejdřív zkontrolujte úložiště:
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
Select-Object Subject, Issuer, Thumbprint, NotAfterDržte tajemství mimo soubor skriptu. PSK předaný na příkazovém řádku nebo zapečený do .ps1 skončí v přepisech, uložených relacích a sdílených repozitářích a -RememberCredential ukládá uživatelská pověření na později, čímž z jednorázového testu dělá trvalé oprávnění.
Krok 4: Rozhodněte o rozsahu před prvním spuštěním
Stejný cmdlet zapisuje do dvou různých telefonních seznamů. Bez -AllUserConnection patří profil vám a žije v %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk. S ním, ze zvýšeného příkazového řádku, jde profil do %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk a je viditelný pro každý účet, včetně přihlašovací obrazovky.
Rozsah není kosmetika. Profil pro všechny uživatele je to, co může použít servisní účet, naplánovaná úloha nebo scénář před přihlášením; profil pro jednoho uživatele je pro všechny tři neviditelný. Objekty se také čtou jinak: Get-VpnConnection vypisuje položky aktuálního uživatele, Get-VpnConnection -AllUserConnection ty celostrojové. Vyberte jeden teď a pozdější změnu berte jako smazání a nové vytvoření, ne jako úpravu:
# elevated prompt
Remove-VpnConnection -Name "Corp IKEv2" -Force
Add-VpnConnection -Name "Corp IKEv2" -ServerAddress "vpn.example.com" `
-TunnelType Ikev2 -AuthenticationMethod MachineCertificate `
-EncryptionLevel Required -AllUserConnectionKrok 5: Otestujte, co má tunel skutečně dodat
Připojená ikona dokazuje, že tunel naskočil, a nic víc. Připojte se nejdřív z příkazového řádku, aby poruchy přicházely jako text, ne jako dialog, a pak si přečtěte, co Windows zaznamenal:
rasdial "Corp IKEv2"
Get-VpnConnection -Name "Corp IKEv2" |
Select-Object Name, ServerAddress, TunnelType, ConnectionStatus, SplitTunneling
Get-NetRoute -DestinationPrefix "0.0.0.0/0"Dvě poruchy, o kterých uživatelé hlásí, zatímco stav ještě říká Connected, jsou DNS a směrování. Přeložte interní jméno a zkontrolujte, který server odpověděl; profil bez -DnsSuffix může tunelovat perfektně a přesto selhat při každém vyhledávání v intranetu. Potom podívejte se na výchozí trasu: s vypnutým split tunneling má trasa 0.0.0.0/0 s nejnižší metrikou ukazovat do rozhraní VPN, se zapnutým jen prefixy, které očekáváte. Pokud obojí vypadá správně a provoz přesto umírá, problém je za profilem, v politice nebo filtru brány.
Když připojení selže úplně, kód zúží krok, ke kterému se vrátit:
- 691: brána odmítla pověření. Vraťte se ke kroku 3, ne k tunelu.
- 809: handshake IKEv2 se nikdy nedokončil. Zkontrolujte UDP 500 a 4500 a důvěru v certifikáty.
- 789: předsdílený klíč L2TP/IPsec chybí nebo je špatný.
- 868: jméno serveru se nepřeložilo. Opravte DNS, než budete profil upravovat.
Držte funkční příkaz vedle nastavení, která kóduje, aby příští člověk mohl znovu sestavit, místo aby reverzně inženýroval profil z rozhraní. Pokud opravdu musíte sestavovat znovu, smažte položku a vytvořte ji znovu ze stejných parametrů; záplatování polokonfigurovaného profilu nechává zastaralé trasy a stav ověřování. A pokud soubor nikdy nebyl nativní, vraťte se ke klientovi, který ho vlastní. .ovpn převlečený za profil IKEv2 není import, je to tiket podpory.