Windows پر VPN واقعی کیا روٹ کرتا ہے، PowerShell میں کیسے جانچیں
منسلک VPN ٹائل کوریج ثابت نہیں کرتی۔ محفوظ شدہ پروفائل پرچم، زندہ روٹ جدول اور NRPT قواعد اسی ترتیب سے پڑھیں۔
میں نے Windows 11 لیپ ٹاپ پر VPN کلائنٹ جوڑا، ٹائل Connected ہو گئی، اندرونی فائل شیئرنگ کھلی، اور ایک عوامی سائٹ اب بھی دفتر کے Wi-Fi سے براہ راست لوڈ ہو رہی تھی۔ یہ امتزاج ٹوٹی ہوئی سرنگ جیسا لگتا ہے۔ لیکن یہ ایسے پروفائل کا معمول کا نتیجہ ہے جو کچھ ٹریفک VPN سے بھیجتا ہے اور باقی جسمانی ایڈاپٹر پر چھوڑ دیتا ہے۔ زبردستی سرنگ یہ بدلتی ہے کہ Windows کس ڈیفالٹ راستے کو ترجیح دیتا ہے؛ یہ زیادہ مخصوص راستے نہیں مٹاتی اور یہ وعدہ بھی نہیں کرتی کہ کنکشن ٹوٹنے پر ٹریفک رک جائے گی۔ آگے وہ ترتیب ہے جو میں اس وقت اپناتا ہوں جب کوئی کلائنٹ کوریج کا دعویٰ کرے: کلائنٹ کی حالت، محفوظ شدہ پروفائل، لاگو راستے، حل کنندہ، پھر اصل بہاؤ۔
کلائنٹ سے شروع کریں، پھر اس پر بھروسہ کرنا چھوڑ دیں
کلائنٹ شروع کرنے کی صحیح جگہ صرف اس لیے ہے کہ یہ بتاتا ہے کون سا پروفائل فعال ہے۔ کنکشن کی خصوصیات کھولیں اور درست پروفائل نام، یہ کہ یہ موجودہ صارف کے لیے بنا ہے یا مشین پر سب کے لیے، اور کنکشن کے بعد ncpa.cpl میں کون سا ایڈاپٹر نظر آتا ہے، نوٹ کریں۔ میرے ٹیسٹ لیپ ٹاپ پر ایڈاپٹر پروفائل کا نام رکھتا تھا، جس سے راستوں کی آؤٹ پٹ پڑھنا آسان ہو گیا۔ دوسری مشینوں پر یہ WAN Miniport اندراج کے طور پر دکھتا ہے اور نام آپ کو کچھ نہیں بتاتا۔
جو کلائنٹ نہیں بتا سکتا وہ کوریج ہے۔ منسلک ٹائل سرنگ کی حالت بیان کرتی ہے، منزلوں کی فہرست نہیں۔ فریق ثالث کلائنٹ بھی اپنی ترتیب رکھتے ہیں، اس لیے مقامی Windows پروفائل اور اس سے آپ جو بھی خصوصیت پڑھیں گے، اس کا تعلق اس کلائنٹ کی نصب کردہ چیز سے نہیں ہو سکتا۔ اگر VPN AnyConnect، OpenVPN GUI، WireGuard یا کسی وینڈر ایجنٹ کے ذریعے آیا ہے تو نیچے دی گئی PowerShell جانچیں زیادہ تر لاگو نہیں ہوتیں اور ان کی جگہ اس کلائنٹ کی اپنی split-tunnel اور روٹنگ سیٹنگز پڑھنی چاہئیں۔
محفوظ شدہ پروفائل پڑھیں، ٹائل نہیں
مقامی Windows پروفائل کے لیے (IKEv2، L2TP، SSTP یا MDM کی دھکیلی ہوئی) محفوظ شدہ split-tunnel فیصلہ ایک ہی خصوصیت ہے:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixجب پروفائل ڈیوائس پر سب کے لیے بنایا گیا ہو تو -AllUserConnection شامل کریں۔ اس کے بغیر آپ موجودہ صارف کی فہرست پڑھتے ہیں، جو خالی ہو سکتی ہے یا ملتے جلتے نام کا کوئی اور اندراج رکھ سکتی ہے۔ False قدر SplitTunneling میں ہونے کا مطلب ہے کہ پروفائل مکمل سرنگ کے طور پر محفوظ ہوا: Windows VPN ایڈاپٹر کے ذریعے ڈیفالٹ راستہ نصب کرتا ہے۔ True کا مطلب split tunnel ہے، اور کوریج پھر مکمل طور پر ان راستوں اور نام حل کرنے کے قواعد پر منحصر ہے جو وہ پروفائل دھکیلتا ہے۔
اس قدر کو ترتیب سمجھیں، مشاہدہ نہیں۔ یہ ریکارڈ کرتی ہے کہ کنکشن کے وقت پروفائل نے کیا مانگا۔ Windows مختلف لاگو راستوں کے ساتھ ختم ہو سکتا ہے، کسی دوسرے انٹرفیس کے زیادہ مخصوص راستے، پالیسی ترتیب یا پچھلے کنکشن کے بچے ہوئے اندراج کی وجہ سے، اس لیے بولین تنہا سوال حل نہیں کرتا۔
محفوظ قدر کا لاگو روٹ جدول سے موازنہ کریں
کنکشن کے بعد پورا جدول اسکرول کرنے کے بجائے سرنگ ایڈاپٹر پر راستے کی فہرست بنائیں:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute مفید نصف ہے۔ یہ اس سوال کا جواب دیتا ہے جو کلائنٹ کبھی نہیں دیتا: اس منزل کے لیے Windows واقعی کون سا انٹرفیس اور کون سا ماخذ پتہ استعمال کرے گا؟ اسے اندرونی ہوسٹ، عوامی ہوسٹ اور ہر اس چیز کے لیے چلائیں جسے آپ دانستہ استثنا سمجھتے ہیں۔ مکمل سرنگ پروفائل کو عوامی پتے کے لیے سرنگ انٹرفیس دکھانا چاہیے۔ split tunnel پروفائل وہاں عام طور پر جسمانی ایڈاپٹر دکھاتا ہے جبکہ اندرونی سابقے اب بھی VPN میں حل ہوتے ہیں۔
«یہ غلط سمت میں روٹ کرتا ہے» والی زیادہ تر رپورٹیں دو جال سمجھاتے ہیں۔ سب سے مخصوص سابقہ ہمیشہ جیتتا ہے، اس لیے جسمانی ایڈاپٹر پر /24 سرنگ کی میٹرک کتنی ہی کم ہو، VPN کے ڈیفالٹ راستے کو ہرا دیتا ہے۔ میٹرک صرف ایک ہی سابقے کے راستوں کے درمیان برابری طے کرتی ہے۔ اور IPv4 اور IPv6 الگ الگ طے ہوتے ہیں: 0.0.0.0/0 ڈھانپنے والا پروفائل IPv6 کو مقامی لنک پر چھوڑ سکتا ہے، جس سے دوہری اسٹیک سائٹ آدھی سرنگ والی دکھتی ہے۔ سرنگ درست ہے کا نتیجہ نکالنے سے پہلے Get-NetRoute -AddressFamily IPv6 جانچیں۔
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
NRPT کے ساتھ نام حل کرنا الگ سے جانچیں
اندرونی نام ناکام ہوں جبکہ اندرونی IP پتے کام کریں، تو یہ روٹنگ کی نہیں بلکہ حل کنندہ پالیسی کی طرف اشارہ کرتا ہے۔ Windows ہر نام کی جگہ کے لیے DNS نام حل کرنے کی پالیسی جدول کے ذریعے طے کرتا ہے، جو روٹ جدول سے آزاد ہے:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexجب کوئی قاعدہ *.corp.example سے میل کھاتا ہے تو اس نام کی جگہ کے سوالات سرنگ کے DNS سرورز کو جاتے ہیں، چاہے split tunnel موڈ میں ان سرورز تک ڈیٹا راستہ جسمانی ایڈاپٹر پر رہے۔ یہی ڈیزائن ہے، اور اسی لیے عوامی سائٹ کھولنے والا براؤزر ٹیسٹ اندرونی ناموں کے بارے میں کچھ نہیں بتاتا۔ اگر ایڈاپٹر متوقع سرورز کی فہرست دیتا ہے لیکن تلاش پھر بھی کہیں اور جاتی ہے، تو NRPT قواعد کی ترتیب موازنہ کریں اور دیکھیں کہ زیادہ مخصوص نام کی جگہ پہلے میل کھاتی ہے یا نہیں۔
بہاؤ کی تصدیق کریں، پھر طے کریں کہ آپ نے واقعی کیا مانگا
منزلوں کو مقررہ ترتیب میں دیکھیں تاکہ نتائج مشینوں کے درمیان موازنہ کے قابل ہوں: عوامی پتہ، اندرونی پتہ، اندرونی نام اور ایک دانستہ استثنا جیسے مقامی پرنٹر یا ویڈیو کال۔ ہر ایک کے لیے Find-NetRoute جو انٹرفیس اور ماخذ پتہ واپس کرتا ہے، نوٹ کریں۔ کسی بھی پالیسی تبدیلی کے بعد دوبارہ کنکٹ ہوں اور وہی چار جانچیں دہرائیں؛ دوبارہ کنکشن کے بعد کا روٹ جدول ہی واحد ثبوت ہے کہ نیا پروفائل نافذ ہوا۔
پھر روٹنگ کو نفاذ سے الگ کریں۔ زبردستی سرنگ سرنگ کے قائم رہنے تک ڈھانپے گئے ٹریفک کے لیے سرنگ کو ترجیح دیتی ہے۔ یہ kill switch نہیں۔ اگر ضرورت یہ ہو کہ سرنگ گرنے پر مشین سے کچھ باہر نہ جائے تو یہ روکنے والے ڈیزائن سے آنا چاہیے: سرنگ کی حالت سے بندھا firewall پروفائل، ٹریفک فلٹرز والا ہمیشہ-آن پروفائل یا وینڈر کلائنٹ کا اپنا ناکامی پر بند ہونے کا اختیار۔ زبردستی سرنگ کو VPN سرور کا اپنا پتہ بھی سرنگ سے باہر قابل رسائی رکھنا چاہیے، اور «سب کچھ زبردستی کرنے» کے نام پر اسے بلاک کرنا اس کنکشن سے خود کو باہر تالا لگانے کا بھروسے مند طریقہ ہے جسے آپ نافذ کرنا چاہتے ہیں۔
کچھ بھی بدلنے سے پہلے یہ فہرست دیکھیں۔ ناکام ہونے والی ہر چیز یہ تنگ کرتی ہے کہ اصل مسئلہ کہاں ہے۔
- پروفائل نام اور دائرہ تصدیق شدہ، مشین گیر پروفائلز کے لیے
-AllUserConnectionاستعمال ہوا۔ SplitTunnelingپڑھا گیا اور کوریج کا ثبوت نہیں، ترتیب سمجھا گیا۔- سرنگ ایڈاپٹر کے راستے IPv4 اور IPv6 کے لیے الگ الگ درج کیے گئے۔
- ایک عوامی، ایک اندرونی اور ایک استثنا منزل کے لیے
Find-NetRouteچلایا گیا۔ - نام کی ناکامی پر راستوں کو قصوروار ٹھہرانے سے پہلے NRPT قواعد جانچے گئے۔
- بلاک کرنے کی ضرورت دوبارہ پڑھی گئی: ترجیحی روٹنگ لاگو بلاک کے برابر نہیں۔
مکمل یا split سرنگ کا فیصلہ پروفائل کے مالک کا ہے، اور Microsoft کے روٹنگ نوٹس وہ رویہ بیان کرتے ہیں جو Windows لاگو کرتا ہے جب پروفائل اسے مقرر کرے۔ Microsoft: زبردستی اور split سرنگ وہ حوالہ ہے جو میں آؤٹ پٹ پڑھتے وقت کھلا رکھتا ہوں۔