صرف ونڈوز فائر وال بطور VPN بند کرنے کا سوئچ: کیا یہ قائم رہتا ہے؟

پوچھیں کہ کیا ونڈوز فائر وال اکیلا ہنگامی سوئچ کے طور پر کام کر سکتا ہے تو آپ کو دو پختہ اور متضاد جواب ملیں گے۔ ایک کہتا ہے کہ انٹرفیس قسم کا قاعدہ سارا کام کرتا ہے؛ دوسرا کہتا ہے کہ اسکرپٹ کے بغیر یہ کام نہیں کرتا۔ دونوں ایک ہی طریقہ کار کا آدھا حصہ بیان کرتے ہیں۔ فائر وال بلاک کا اظہار کر سکتا ہے، اور کیا نتیجہ واقعی بند حالت میں ناکام ہوتا ہے تین باتوں پر منحصر ہے: ونڈوز ٹنل اڈاپٹر کی درجہ بندی کیسے کرتا ہے، اختتامی نقطے کی استثنا برقرار رہتی ہے یا نہیں، اور ناموں کی تحلیل اور IPv6 ڈھکے گئے ہیں یا نہیں۔ ان میں سے کوئی ایک غلط ہو تو مشین یا تو لیک کرے گی یا ساری رابطہ کھو دے گی۔

تین شرطیں، اسی ترتیب میں

پہلی شرط درجہ بندی ہے، اور یہ طے کرتی ہے کہ آپ جو قاعدہ چاہتے ہیں وہ بنیادی طور پر بیان ہو سکتا ہے یا نہیں۔ ونڈوز فائر وال کے قواعد انٹرفیس قسم کے مطابق محدود کیے جا سکتے ہیں: تار والے، بے تار یا دور دراز رسائی۔ جو پالیسی جسمانی اقسام پر باہر جانے والا ٹریفک بلاک کرتی ہے اور ٹنل کی اجازت دیتی ہے وہ صرف اسی صورت میں کام کرتی ہے جب ونڈوز ٹنل کو دور دراز رسائی کے طور پر پہچانے۔

دوسری شرط اختتامی نقطے کی استثنا ہے۔ کسی بھی ٹنل سے پہلے کلائنٹ کو جسمانی اڈاپٹر کے ذریعے VPN سرور تک پہنچنا ہوتا ہے، اس لیے اس اڈاپٹر پر مکمل بلاک اسی رابطے کو روکتا ہے جو بلاک کو غیر ضروری بنا دیتا۔ استثنا میں سرور اور اس کا پورٹ نامزد ہونا چاہیے، اور پیکٹ کو جسمانی گیٹ وے سے باہر جانا چاہیے، ابھی نہ اٹھی ٹنل میں نہیں۔

تیسری کوریج ہے۔ جو قواعد کا مجموعہ IPv4 بلاک کرتا ہے اور IPv6 بھول جاتا ہے، یا اختتامی نقطے کی تلاش کے لیے مقامی حل کنندہ کو اجازت دے کر ہر دوسری تلاش کو بھی اجازت دیتا ہے، وہ ٹھیک اسی کھڑکی میں کھل کر ناکام ہوتا ہے جس کے لیے سوئچ موجود ہے۔ یہ ڈیزائن کی خلا ہے، فائر وال کی خرابی نہیں۔ یہ وہی خلا ہے جو میز پر ہر جانچ سے بچ نکلتی ہے۔

درجہ بندی پہلا دروازہ ہے

ایک بھی قاعدہ لکھنے سے پہلے دیکھیں کہ ونڈوز اڈاپٹروں کے بارے میں کیا سوچتا ہے۔ ونڈوز کا اصل VPN رابطہ عام طور پر دور دراز رسائی کے طور پر دکھائی دیتا ہے۔ اپنا مجازی اڈاپٹر بنانے والا تیسرے فریق کا کلائنٹ اکثر تار والا دکھائی دیتا ہے، یعنی تار والے اڈاپٹروں تک محدود بلاک ٹنل کو بھی بلاک کرتا ہے۔

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

تیسرا کمانڈ بتاتا ہے کہ ڈیفالٹ آؤٹ باؤنڈ بلاک پہلے سے نافذ ہے یا نہیں، جو ڈیزائن کی پوری شکل بدل دیتا ہے۔ اگر ڈیفالٹ پہلے سے بلاک ہے تو آپ اجازت دینے والی بنیاد کی استثنائیں نہیں بلکہ اجازت کے قواعد لکھ رہے ہیں، اور اس پر غور کرنا کہیں آسان ہے۔

اگر آپ کا ٹنل اڈاپٹر تار والا بتاتا ہے تو بند ناکامی والے ڈیزائن کے لیے اکیلے فائر وال درست ذریعہ نہیں، اور کتنے ہی قواعد بدلیں یہ نہیں بدلے گا۔ یہی وہ صورت ہے جس میں ہر فورم دھاگے کی دوسری رائے درست ہے۔

اختتامی نقطے کی استثنا کو قاعدے کے ساتھ راستہ بھی درکار ہے

فرض کریں درجہ بندی کام کرتی ہے۔ استثنا دو ٹکڑوں کی ہے، اور وہ الگ ذیلی نظاموں میں رہتے ہیں۔ فائر وال قاعدہ ٹریفک کی اجازت دیتا ہے؛ میزبان راستہ ٹنل نیچے ہونے پر اسے درست انٹرفیس سے باہر بھیجتا ہے۔

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

راستے کے بغیر استثنا صرف اس وقت مدد دیتی ہے جب تک ڈیفالٹ راستہ جسمانی گیٹ وے کی طرف اشارہ کرتا ہے۔ کلائنٹ اپنا ڈیفالٹ راستہ نصب کر کے مر جائے تو اجازت یافتہ پیکٹوں کے پاس جانے کی کوئی معقول جگہ نہیں بچتی اور رابطہ دوبارہ قائم نہیں ہو سکتا۔ وہ ناکامی ٹوٹے کلائنٹ جیسی دکھتی ہے اور دراصل گم شدہ راستہ ہے۔

استثنا کو اتنا تنگ رکھیں جتنا کلائنٹ اجازت دیتا ہے۔ ایک پتہ اور ایک پورٹ قابلِ جائزہ ہے؛ فراہم کنندہ کا پورا نیٹ ورک ڈھکنے والی حد نہیں۔ وہ وسیع قاعدہ اسی فراہم کنندہ کے پاس میزبانی شدہ باقی ہر چیز کو بھی اجازت دیتا ہے، جو عام طور پر آپ کے ارادے سے زیادہ ہوتا ہے۔

DNS اور IPv6 وہی جگہیں ہیں جہاں یہ کھل کر ناکام ہوتا ہے

ناموں کی تحلیل عام لیک ہے۔ اگر اختتامی نقطہ میزبان نام ہے تو ٹنل سے پہلے کلائنٹ کو اسے حل کرنا ہوگا، یعنی جسمانی اڈاپٹر کو حل کنندہ تک پہنچنے کی اجازت دینی ہوگی۔ وہی اجازت ٹنل نیچے ہونے پر ہر دوسری تلاش کو باہر جانے دیتی ہے، اور ایک تلاش ہی بتانے کے لیے کافی ہے کہ آپ کیا دیکھنے والے تھے۔

IPv6 دوسرا ہے۔ IPv4 کے لیے لکھے قواعد دوسرے خاندان کو نہیں ڈھکتے، اور بہت سے کلائنٹ صرف IPv4 راستے نصب کرتے ہیں۔ اس لیے اصل IPv6 رابطے والی مشین IPv4 طرف سختی سے بلاک ہونے کے باوجود انٹرنیٹ سے بات جاری رکھ سکتی ہے، اور سوئچ ہر وقت کامیابی بتاتا رہتا ہے۔

تیسری سطر کو ٹالنے کے بجائے سمجھنا چاہیے۔ فائر وال پیکٹوں پر فیصلہ کرتا ہے، اس پر نہیں کہ کسی ایپلیکیشن نے کون سا انٹرفیس استعمال کرنے کو کہا، اور واضح طور پر بائنڈ ہونے والے پروگرام کو قابو میں رکھنا مشکل ہو سکتا ہے۔ یہ ایپلیکیشن کے نیچے کام کرنے والے کلائنٹ طرفہ سوئچ کے حق میں دلیل ہے، زیادہ قواعد کے حق میں نہیں۔

تار کھینچ کر نہیں، کلائنٹ روک کر جانچیں

واحد بامعنی جانچ وہی ہے جو آپ کے بچاؤ والی ناکامی کی نقل کرے۔ سروس روکیں، عمل کو مار ڈالیں، یا کلائنٹ کا بنایا اڈاپٹر غیر فعال کریں، پھر انٹرنیٹ اور کسی نام تک پہنچنے کی کوشش کریں:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

تینوں ناکام ہونے چاہئیں۔ اگر پہلا کامیاب ہو تو بلاک نافذ نہیں؛ اگر پہلا ناکام ہوا جہاں دوسرا کامیاب ہو تو آپ کے پاس DNS لیک ہے؛ اگر تیسرا کامیاب ہو تو IPv6 ڈھکا نہیں۔ ہر نتیجہ اوپر کی خلاوں میں سے بالکل ایک کی طرف اشارہ کرتا ہے۔

نیند اور جاگنے کے بعد جانچ دہرائیں، کیونکہ جب ونڈوز فیصلہ کرتا ہے کہ نیٹ ورک عوامی ہے یا نجی، تو فائر وال پروفائل بدل سکتی ہے، اور پروفائل تک محدود قواعد اس کی پیروی کرتے ہیں۔ جو ڈیزائن میز پر قائم رہتا ہے اور ریل میں ناکام ہوتا ہے وہ ایک بار جانچا گیا ڈیزائن ہے۔

اگر درجہ بندی کا دروازہ یا DNS کی ضرورت صرف-فائر-وال نقطہ نظر کو ناقابلِ عمل بنائے تو کلائنٹ طرفہ سوئچ ہی دیانت دار جواب ہے۔ اگر ٹنل اس کے بجائے راؤٹر پر ختم ہو تو پالیسی راؤٹر کی ہونی چاہیے، کیونکہ وہاں ایک قاعدہ اس کے پیچھے کے ہر آلے کو ڈھکتا ہے اور اس پر منحصر نہیں کہ ونڈوز اڈاپٹر کو کیا نام دیتا ہے۔