VPN-এ RDP জমে যাওয়া: ইনপুট এখনও কাজ করে, তাই ট্রান্সপোর্ট পরীক্ষা করুন

ছবি আপডেট হওয়া বন্ধ হয়ে গেলেও মাউস যদি দূরবর্তী ডেস্কটপ জুড়ে চলতে থাকে, তাহলে সুস্পষ্ট উপসংহার হয় VPN পড়ে গেছে। এই উপসংহার সাধারণত ভুল। কাজ করা ইনপুটসহ জমে যাওয়া ফ্রেম মানে সেশন ও তার ইনপুট চ্যানেল জীবিত, আর এটি ত্রুটিকে রাউটিং বা ক্রেডেনশিয়ালের দিকে নয়, গ্রাফিক্স ট্রান্সপোর্টের দিকে ঠেলে দেয়। দুই দ্রুত পর্যবেক্ষণ ব্যবহারকারীরা একই শব্দে বর্ণনা করা তিনটি ব্যর্থতাকে আলাদা করে।

জমে যাওয়া আপনাকে যা বলছে না

রিমোট ডেস্কটপ TCP 3389-এর উপর ইনপুট ও স্ক্রিন আপডেট বহন করে, আর বর্তমান Windows ক্লায়েন্ট স্ট্রিমের গ্রাফিক্স-ভারী অংশের জন্য UDP ট্রান্সপোর্ট যোগ করতে পারে। যে টানেল বড় ডেটাগ্রাম ফ্র্যাগমেন্ট করে বা ফেলে দেয়, সেখানে নির্ভরযোগ্য চ্যানেল কীস্ট্রোক বহন করতে থাকে, অথচ গ্রাফিক্স চ্যানেল আটকে যায়। ফলাফল হলো আটকে থাকা ছবি আর সাড়াদায়ী কিবোর্ডের অদ্ভুত সমন্বয়। এটি আরও ব্যাখ্যা করে কেন পুনরায় সংযোগ কখনও এক মিনিটের জন্য উপসর্গ সারিয়ে আবার ফিরিয়ে আনে।

যে সেশন সংযোগ বিচ্ছিন্ন হয়ে আবার যুক্ত হয় সেটি আলাদা ত্রুটি, আর যেটি একেবারেই খোলে না সেটি তৃতীয়। আগে আকারের নাম দিলে ভুল স্তর পরীক্ষা করা থেকে বাঁচবেন।

দুটি কমান্ডে তিনটি ব্যর্থতা আলাদা করুন

পৌঁছানোযোগ্যতা বাদ দেওয়া সস্তা। ক্লায়েন্ট থেকে RDP পোর্ট পরীক্ষা করুন, তারপর হোস্টে সেশনের অবস্থা পড়ুন।

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

ব্যর্থ TCP পরীক্ষা মানে সেশন কখনও খোলেনি, তাই এটিকে জমে যাওয়া নয়, বরং ফায়ারওয়াল, স্কোপ বা সেবার সমস্যা হিসেবে ধরুন। সক্রিয় সেশনসহ সফল পরীক্ষা নিশ্চিত করে নিয়ন্ত্রণ চ্যানেল আছে, যা ঠিক জমে যাওয়া ছবির ঘটনা। যে অ্যাকাউন্ট সেশন দেখার অনুমতি পায় সেখান থেকে হোস্ট কোয়েরি চালান, কারণ অনুমতির ত্রুটি খালি তালিকার মতো দেখায়। সেশন আইডি ও অবস্থা লিখে রাখুন, কারণ নিজের আইডি ধরে রাখা বিচ্ছিন্ন সেশন সক্রিয় সেশনের সমান নয়।

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 গ্রাফিক্স চ্যানেল সম্পর্কে নয়। একবারে একটি চলক বদলান এবং একই অন-স্ক্রিন কাজ পুনরাবৃত্তি করুন যাতে তুলনার অর্থ থাকে।

সেশন যদি একেবারেই না খোলে, এখানেই থামুন, কারণ এটি জমে যাওয়া নয় বরং পৌঁছানোযোগ্যতা। নইলে যে ট্রান্সপোর্ট সেটিং উপসর্গ বদলেছে তা রেখে দিন এবং ক্লায়েন্ট সংস্করণের সাথে লিখে রাখুন।