VPN کے ذریعے RDP کا جم جانا: ان پٹ اب بھی کام کرتا ہے، اس لیے ٹرانسپورٹ جانچیں
کام کرتے ان پٹ کے ساتھ جمی ہوئی RDP تصویر گرتی ہوئی سرنگ نہیں ہے۔ راستے بدلنے سے پہلے کلائنٹ ٹرانسپورٹ، UDP پالیسی اور ایک ہوسٹ کا معاملہ جانچیں۔
جب تصویر اپ ڈیٹ ہونا بند کر دے لیکن ماؤس اب بھی دور کے ڈیسک ٹاپ پر پھسلتا رہے، تو واضح نتیجہ یہ ہے کہ VPN گر گیا۔ یہ نتیجہ عام طور پر غلط ہوتا ہے۔ کام کرتے ان پٹ کے ساتھ جمی ہوئی فریم کا مطلب ہے کہ سیشن اور اس کا ان پٹ چینل زندہ ہیں، جو خرابی کو روٹنگ یا اسناد کی بجائے گرافکس ٹرانسپورٹ کی طرف دھکیلتا ہے۔ دو فوری مشاہدے ان تین ناکامیوں کو الگ کرتے ہیں جنہیں صارفین ایک ہی لفظ سے بیان کرتے ہیں۔
جمنا آپ کو کیا نہیں بتاتا
دور کا ڈیسک ٹاپ ان پٹ اور اسکرین اپ ڈیٹ TCP 3389 پر لے جاتا ہے، اور موجودہ Windows کلائنٹس اسٹریم کے گرافکس بھاری حصے کے لیے UDP ٹرانسپورٹ شامل کر سکتے ہیں۔ جس سرنگ میں بڑے ڈیٹا گرام تقسیم ہوں یا گر جائیں، وہاں قابل اعتماد چینل کی اسٹروک لے جانا جاری رکھتا ہے جبکہ گرافکس چینل رک جاتا ہے۔ نتیجہ اٹکی تصویر اور جواب دینے والے کی بورڈ کا عجیب امتزاج ہے۔ یہ یہ بھی بتاتا ہے کہ دوبارہ کنیکٹ کرنا کبھی کبھی علامت کو ایک منٹ کے لیے ٹھیک کر کے پھر واپس کیوں لے آتا ہے۔
جو سیشن منقطع ہو کر دوبارہ جڑتا ہے وہ دوسری خرابی ہے، اور جو بالکل نہیں کھلتا وہ تیسری ہے۔ پہلے شکل کا نام دینا آپ کو غلط پرت جانچنے سے روکتا ہے۔
دو کمانڈوں سے تین ناکامیاں الگ کریں
رسائی کو خارج کرنا سستا ہے۔ کلائنٹ سے RDP پورٹ جانچیں، پھر ہوسٹ پر سیشن کی حالت پڑھیں۔
Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-hostناکام TCP ٹیسٹ کا مطلب ہے کہ سیشن کبھی نہیں کھلا، اس لیے اسے جمنا نہیں بلکہ فائر وال، دائرہ یا سروس کا مسئلہ سمجھیں۔ فعال سیشن کے ساتھ کامیاب ٹیسٹ تصدیق کرتا ہے کہ کنٹرول چینل موجود ہے، جو بالکل جمی ہوئی تصویر کا معاملہ ہے۔ ہوسٹ کی استفسار ایسے اکاؤنٹ سے چلائیں جسے سیشن دیکھنے کی اجازت ہو، کیونکہ اجازت کی خرابی خالی فہرست جیسی دکھتی ہے۔ سیشن ID اور حالت درج کریں، کیونکہ اپنی ID رکھنے والا منقطع سیشن فعال سیشن کے برابر نہیں۔
UDP ٹرانسپورٹ بند کریں اور موازنہ کریں
اگر صرف ڈسپلے رکتا ہے تو ایک وقت میں ایک تبدیلی کے ساتھ کلائنٹ ٹرانسپورٹ کا موازنہ کریں۔ بلٹ ان کلائنٹ اور Store کلائنٹ ایک ہی اسٹیک شیئر نہیں کرتے، اور نیچے کی پالیسی بلٹ ان کلائنٹ سے UDP ہٹا دیتی ہے۔
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDPقیمت 1 کا مطلب ہے کہ اس کلائنٹ کے لیے UDP پہلے ہی بند ہے، اس لیے اس سیٹنگ کے بعد بھی جمنا UDP راستے کا مسئلہ نہیں۔ جب قیمت موجود نہ ہو تو پالیسی فعال کریں، دوبارہ کنیکٹ کریں اور پہلے جمی ہوئی بالکل وہی کارروائی دہرائیں۔ دونوں تبدیلیاں ملانے کی بجائے Store کلائنٹ کو الگ مرحلے کے طور پر جانچیں، ورنہ آپ کو معلوم نہیں ہوگا کہ کون سی اہم تھی۔ کلائنٹ ورژن اپنے نوٹس میں رکھیں، کیونکہ Windows ریلیز کے درمیان ٹرانسپورٹ رویہ بدلا ہے۔
جب ایک ہوسٹ جم جائے لیکن باقی ٹھیک ہوں
باقی صحت مند سب نیٹ پر ایک ہی ناکام ہوسٹ سرنگ سے دور اشارہ کرتا ہے۔ VPN سیٹنگز کو چھونے سے پہلے راستے کا MTU اور دور کے ڈسپلے کا اسٹیک جانچیں۔
ping -f -l 1472 rdp-host.example.comایک جواب ثابت کرتا ہے کہ راستہ اس سائز پر تقسیم کے بغیر پورے سائز کا پیکٹ لے جاتا ہے، جبکہ تقسیم نہ کریں پرچم کے ساتھ ناکامی بتاتی ہے کہ سرنگ کے MTU پر توجہ درکار ہے۔ اگر 1472 بائٹ گزر جائیں اور صرف وہی ہوسٹ جمے تو نیٹ ورک کی بجائے اس کے گرافکس ڈرائیور اور بوجھ کو دیکھیں۔ اسی مشین پر تیز فائل کاپی تھرو پٹ کے بارے میں کچھ کہتی ہے، RDP گرافکس چینل کے بارے میں نہیں۔ ایک وقت میں ایک متغیر بدلیں اور وہی اسکرین کارروائی دہرائیں تاکہ موازنہ معنی رکھے۔
اگر سیشن بالکل نہ کھلے تو یہیں رکیں، کیونکہ یہ جمنا نہیں بلکہ رسائی ہے۔ ورنہ وہ ٹرانسپورٹ سیٹنگ رکھیں جس نے علامت بدلی اور اسے کلائنٹ ورژن کے ساتھ درج کریں۔