PowerShell में Add-VpnConnection से 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 आता है, अक्सर मशीन प्रमाणपत्र के साथ; 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 अलग पैरामीटर हैं, और गेटवे को केवल संयोजन से मतलब है। एक सही और दूसरा गलत रखें तो ऐसा प्रोफ़ाइल मिलता है जो कहीं जुड़ता नहीं, या सुरंग पहले से ऊपर होने पर अटक जाता है। दोनों को स्पष्ट रूप से सेट करें, किसी दूसरी सेवा के लिए चुने गए डिफ़ॉल्ट पर भरोसा करने के बजाय।

  • 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 आयात नहीं है, सहायता टिकट है।

संबंधित लेख