ریموٹ کمپیوٹر کے VPN سے جڑنے پر RDP کیوں منجمد ہو جاتا ہے

آپ RDP ونڈو کے اندر ہیں، ڈیسک ٹاپ اسکرین پر ہے، اور اُس ریموٹ مشین پر چل رہے VPN کلائنٹ میں Connect دباتے ہیں۔ چند سیکنڈ بعد ونڈو منجمد ہو جاتی ہے اور پھر بند ہو جاتی ہے۔ ٹنل اوپر آ گیا، VPN لاگ بالکل یہی درج کرے گا، اور یہ پوری واردات کا سب سے کم کارآمد امر ہے۔ سیشن اس لیے مرا کہ جس مشین سے آپ بات کر رہے تھے اُس نے آپ کو جواب دینے کا طریقہ بدل دیا، اس لیے ٹنل کو چھونے سے پہلے واپسی راستہ دیکھیں۔

وہ اینڈ پوائنٹ درج کریں جو آپ کا سیشن واقعی استعمال کرتا ہے

آپ کے RDP کلائنٹ میں لکھا ایڈریس ضروری نہیں کہ وہی ہو جس پر ریموٹ کمپیوٹر جواب دیتا ہے۔ NAT، RD Gateway یا میزبان کے سامنے کا لوڈ بیلنسر اُسے دوبارہ لکھ سکتے ہیں، اور واپسی راستہ اُس ماخذ ایڈریس سے طے ہوتا ہے جو ریموٹ مشین قائم شدہ کنکشن پر دیکھتی ہے۔ یہاں غلطی کرنے پر آپ ایسے روٹ کی تلاش میں جائیں گے جو کبھی شامل ہی نہ تھا۔

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

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

اُس ایڈریس کو ایسی چیز سمجھیں جو قابل رسائی رہنی چاہیے۔ اگر یہ نظم و نسق والے VLAN پر نجی ایڈریس ہے تو ٹنل کو اُس راستے کو اکیلا چھوڑ دینا چاہیے۔ اگر عوامی ایڈریس ہے تو جواب اُسی انٹرفیس سے باہر جانا چاہیے جس نے درخواست اندر لائی تھی۔

اُس اینڈ پوائنٹ کا جواب دینے والا روٹ پڑھیں

Windows ہر منزل کے لیے ایک انٹرفیس منتخب کرتا ہے، اور Find-NetRoute ابھی جو فیصلہ کرے گا وہ دکھاتا ہے۔ جڑنے سے پہلے اُسے پیر ایڈریس پر چلائیں، پھر ٹنل اوپر ہونے پر دوبارہ، اور دونوں جوابوں میں انٹرفیس انڈیکس اور اگلا ہاپ موازنہ کریں۔ انٹرفیس کا بدلنا ہی آؤٹ پٹ کی ایک سطر میں پوری خرابی ہے۔

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

مکمل ٹنل پروفائل ٹنل کے ذریعے ڈیفالٹ روٹ نصب کرتا ہے، جیسا کہ Windows کا VPN روٹنگ گائیڈ بیان کرتا ہے، اس لیے اب ہر جواب VPN سے باہر جاتا ہے اور اس پر منحصر ہے کہ سامنے والا فریق آپ کے کلائنٹ کی طرف واپس روٹ کرتا ہے یا نہیں۔ تقسیم شدہ ٹنل پروفائل بطور ڈیفالٹ زیادہ محفوظ ہے مگر محفوظ مطلق نہیں، کیونکہ پیر ایڈریس کو ڈھکنے والا کوئی مخصوص روٹ اب بھی طبعی ڈیفالٹ روٹ کو ہرا سکتا ہے۔ بہرحال سوال ایک ہی ہے: ٹنل کے اوپر آنے کے بعد، کیا پیر ایڈریس اب بھی اُسی انٹرفیس پر حل ہوتا ہے جس نے سیشن اندر لایا تھا؟

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

فائر وال پروفائل کی تبدیلی پر نظر رکھیں

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

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

ٹنل انٹرفیس سے منسلک پروفائل کا موازنہ اُن پروفائلز سے کریں جنہیں Remote Desktop قواعد نشانہ بناتے ہیں۔ صرف Domain اور Private کے لیے فعال قاعدہ Public درجہ بند انٹرفیس کے لیے کچھ نہیں کرتا، اور کوئی روٹ اصلاح اُسے نہیں بدلتی۔ کچھ VPN کلائنٹ ڈیزائن کے مطابق مقامی ذیلی نیٹ تک رسائی بھی محدود کرتے ہیں، جو کسی دوسرے کنٹرول سے وہی ناکامی کی شکل پیدا کرتا ہے۔

تبدیلی کسی ایسی جگہ سے جانچیں جہاں سے آپ واپس آ سکیں

پورا تسلسل آؤٹ آف بینڈ کنسول یا دوسرے نظم و نسق کے راستے سے اِس ترتیب میں کریں: موجودہ سیشن کی تصدیق کریں، VPN جوڑیں، نیا سیشن کھولیں، پھر VPN کاٹیں اور ایک اور کھولیں۔ ہر مرحلہ الگ تبدیلی جانچتا ہے، اور پہلا ناکام مرحلہ بتاتا ہے کہ کون سا کنٹرول ذمہ دار ہے۔

شروع کرنے سے پہلے ہی رول بیک طے کریں، مثلاً کوئی مقررہ کام جو مقررہ وقفے کے بعد rasdial "Work VPN" /disconnect چلاتا ہے۔ یہ گمشدہ سیشن کو موقع پر جانے کے بجائے پانچ منٹ کی رکاوٹ میں بدل دیتا ہے، اور پوری کارروائی میں یہی سب سے سستا بیمہ ہے۔

سیشن پہلے ہی جا چکا ہو تو دوبارہ اندر آئیں

اگر میزبان پہلے ہی ناقابل رسائی ہے تو اُسی کلائنٹ سے نئے RDP کنکشن کی کوشش بند کریں اور وہ بحالی چینل استعمال کریں جو ماحول کے پاس پہلے سے ہے: RD Gateway، ہائپر وائزر کنسول، یا آؤٹ آف بینڈ نظم و نسق کا انٹرفیس۔ کنسول رسائی رکھنے والے شخص سے کہیں کہ وہی Find-NetRoute اور Get-NetConnectionProfile کمانڈز چلائے، تاکہ شواہد بحالی کے بعد بھی قائم رہیں۔

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