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 الگ پیرامیٹر ہیں، اور گیٹ وے صرف مجموعے کی پرواہ کرتا ہے۔ ایک درست اور دوسرا غلط ہو تو ایسا پروفائل ملتا ہے جو کہیں نہیں جڑتا، یا ٹنل پہلے ہی کھڑی ہونے کے باوجود لٹک جاتا ہے۔ کسی دوسری سروس کے لیے چنے گئے ڈیفالٹ پر بھروسا کرنے کے بجائے دونوں صریحاً مقرر کریں۔
- IKEv2 بمعہ MachineCertificate: کلائنٹ کمپیوٹر سرٹیفکیٹ پیش کرتا ہے؛ ساتھ ہی -EncryptionLevel Required بھی مقرر کریں۔
- SSTP بمعہ Eap: پہلے TLS ٹنل، پھر PEAP/MSCHAPv2 یا EAP کے اندر سرٹیفکیٹ۔ اس کے لیے مرحلہ 3 والی XML درکار ہے۔
- 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 نے ابھی لکھا، تاکہ دوسری کال کے بغیر اسے دیکھ سکیں۔ اگر نام پہلے سے موجود ہو تو 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"دو ناکامیاں جو صارف بتاتے ہیں جب حالت اب بھی جڑا ہوا کہتی ہے، DNS اور روٹنگ ہیں۔ اندرونی نام حل کریں اور دیکھیں کون سا سرور جواب دے؛ -DnsSuffix کے بغیر پروفائل بہترین ٹنل بنا سکتا ہے اور پھر بھی ہر انٹرانیٹ تلاش ناکام رہتا ہے۔ پھر ڈیفالٹ روٹ دیکھیں: تقسیم شدہ ٹنلنگ بند ہو تو کم ترین میٹرک والا 0.0.0.0/0 روٹ VPN انٹرفیس کی طرف ہونا چاہیے، اور آن ہو تو صرف وہی سابقے جو آپ توقع کرتے ہیں۔ اگر دونوں درست لگیں اور ٹریفک پھر بھی مر جائے تو مسئلہ پروفائل سے آگے، پالیسی یا گیٹ وے فلٹر میں ہے۔
جب کنکشن بالکل ناکام ہو تو کوڈ اس مرحلے کو مختصر کر دیتا ہے جس پر واپس جانا ہے:
- 691: گیٹ وے نے اسناد مسترد کیں۔ ٹنل پر نہیں، مرحلہ 3 پر واپس جائیں۔
- 809: IKEv2 مصافحہ کبھی مکمل نہیں ہوا۔ UDP 500 اور 4500، اور سرٹیفکیٹ بھروسا جانچیں۔
- 789: L2TP/IPsec کی پہلے سے شیئر کی گئی کلید غائب یا غلط ہے۔
- 868: سرور کا نام حل نہیں ہوا۔ پروفائل ترمیم کرنے سے پہلے DNS درست کریں۔
کام کرنے والا حکم اس کی انکوڈ کردہ ترتیبات کے پاس رکھیں تاکہ اگلا شخص UI سے پروفائل کی الٹ انجینئرنگ کے بجائے دوبارہ تعمیر کر سکے۔ اگر واقعی دوبارہ تعمیر کرنا پڑے تو اندراج حذف کریں اور انہی پیرامیٹرز سے دوبارہ بنائیں؛ آدھے ترتیب شدہ پروفائل پر پیوند لگانا پرانے روٹس اور تصدیق کی حالت پیچھے چھوڑ دیتا ہے۔ اور اگر فائل کبھی مقامی نہ تھی تو اس کلائنٹ پر واپس جائیں جو اس کا مالک ہے۔ IKEv2 پروفائل کے لباس میں .ovpn درآمد نہیں، یہ سپورٹ ٹکٹ ہے۔