VPN-এর মাধ্যমে রিমোট ডেস্কটপ: আপনি কোন ব্যর্থতায় আছেন?
টানেল আপনাকে একটি রুট দেয়; ডেস্কটপ সেবাকে এখনও আপনাকে গ্রহণ করতে হবে। নাম রেজলিউশন, TCP নাগাল, হোস্ট ফায়ারওয়াল ও লগইন আলাদা করুন।
আপনার টানেল চালু, অভ্যন্তরীণ উইকি লোড হয়, তবুও রিমোট ডেস্কটপ সংযোগ করতে অস্বীকার করে। এই সমন্বয় স্বাভাবিক, কারণ VPN হোস্টে একটি রুট দেয়, কিন্তু ডেস্কটপ সেবাকে শুনতে হবে, নিজের ফায়ারওয়ালে অনুমোদিত হতে হবে এবং অ্যাকাউন্ট যাচাই করতে রাজি হতে হবে। কাজ করা টানেল ও ব্যবহারযোগ্য সেশনের মধ্যে চারটি ব্যর্থতার ধাপ আছে, এবং প্রতিটি ভিন্ন বার্তা দিয়ে ব্যর্থ হয়। প্রথমে বার্তাটি পড়ুন, কারণ এটি ধাপটির নাম বলে।
চারটি ব্যর্থতা যা একটির মতো দেখায়
ধাপগুলো ক্রমানুসারে: নামটি ডিজাইনের প্রত্যাশিত ব্যক্তিগত ঠিকানায় সমাধান হয়, পোর্টটি TCP হ্যান্ডশেকের উত্তর দেয়, হোস্টটি নিজের নীতির অধীনে সংযোগ গ্রহণ করে, এবং সেশন লগইন সফল হয়। প্রতিটি ধাপ পরেরটিকে পরীক্ষার অযোগ্য করে, তাই নেটওয়ার্ক স্থির হওয়ার আগে RDP সেটিংস বদলালে কেবল গোলমাল তৈরি হয়। চারটি ক্ষেত্রেই ব্যবহারকারীর দিক থেকে লক্ষণ একই দেখায়। কেবল ক্লায়েন্টের বার্তা তাদের আলাদা করে।
কাজ করা অভ্যন্তরীণ ওয়েবসাইট চারটির একটিও প্রমাণ করে না। এটি প্রমাণ করে যে একই নেটওয়ার্কের একটি হোস্ট ভিন্ন পোর্টে ভিন্ন সেবা দিয়ে উত্তর দিয়েছে। এটিকে রাউটিং সম্পর্কে প্রমাণ হিসেবে ধরুন, এর বেশি কিছু নয়।
ক্রম অনুযায়ী পরীক্ষা করুন এবং ফলাফল লিখে রাখুন। পোর্ট উত্তর দিয়েছে বলে লগইন স্ক্রিনে ঝাঁপ দেওয়া মানে প্রথম ধাপেই যে ফায়ারওয়াল সমস্যা খুঁজে পেয়েছে, সেটিতেই পুরো বিকেল নষ্ট করা।
3389-এ কি কিছু শুনছে?
নাম দিয়ে শুরু করুন, কারণ ভুল ঠিকানায় সমাধান হওয়া নাম পরবর্তী প্রতিটি পরীক্ষাকে অকার্যকর করে। টানেলের রিজলভারকে জিজ্ঞেস করুন নামটির অর্থ কী, তারপর উত্তরটি সফল প্রতিক্রিয়ার সঙ্গে নয়, ডিজাইনের প্রত্যাশিত ব্যক্তিগত ঠিকানার সঙ্গে তুলনা করুন। পাবলিক ঠিকানায় সমাধান হওয়া নামই পুরো সমস্যা, এবং কোনো RDP পরিবর্তন তা ঠিক করবে না:
nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example
তারপর হোস্ট নয়, পোর্ট পরীক্ষা করুন। 3389-এ সম্পূর্ণ TCP হ্যান্ডশেক নাগালকে তার উপরের সবকিছু থেকে আলাদা করে:
Test-NetConnection -ComputerName desktop.corp.example -Port 3389
এই পরীক্ষাটি LAN থেকে এবং টানেল থেকে চালান, কারণ দুটি ফলাফলের পার্থক্যই ত্রুটিকে VPN পথে সীমাবদ্ধ করে। পথে দুটি ফায়ারওয়াল আছে এবং এদের গুলিয়ে ফেলা সহজ: নেটওয়ার্ককে ক্লায়েন্টের টানেল ঠিকানাকে হোস্টে পৌঁছাতে দিতে হবে, এবং হোস্টের নিজের ফায়ারওয়ালকে শোনা পোর্টে ওই একই উৎসকে অনুমতি দিতে হবে। LAN সাবনেটে সীমাবদ্ধ নিয়ম VPN ক্লায়েন্ট পুলকে কভার করে না, এবং কেবল দূরবর্তী ব্যবহারকারীরা যে টাইমআউটের কথা জানান তার এটিই সবচেয়ে সাধারণ কারণ। নিয়মের অস্তিত্ব নয়, তার পরিধি যাচাই করুন।
ফেরার পথও একই যাচাই দাবি করে। উত্তরগুলোর ক্লায়েন্ট পুলে ফেরার রুট দরকার, LAN-এ নয়, আর হোস্টের সামনে ট্রান্সলেশন আপনার লগে যে উৎস দেখাবে তা বদলে দেয়। পোর্ট এক দিকে উত্তর দিলে আর অন্য দিকে না দিলে, অনুপস্থিত অর্ধেকটি সাধারণত ফেরার রুট।
কনফিগ পড়ার আগে বার্তাটি পড়ুন
তৃতীয় ধাপ হলো হোস্ট নিজের নীতিতে সংযোগ প্রত্যাখ্যান করা, যা প্রায়ই সঙ্গে সঙ্গে খুলে বন্ধ হওয়া পোর্টের মতো দেখায়। কিছু একটা উত্তর দিয়েছে, আর এটি নীরবতার চেয়ে উপযোগী তথ্য। হ্যান্ডশেক সম্পূর্ণ হয়ে সেশন সঙ্গে সঙ্গে মরে গেলে নেটওয়ার্ক ঠিক আছে এবং সিদ্ধান্ত নিচ্ছে হোস্ট। আবার নেটওয়ার্কে হাত দেওয়ার আগে রিমোট ডেস্কটপ অনুমতিগুলো দেখুন।
ফিচারটি মেশিনের জন্য চালু থাকতে পারে অথচ নির্দিষ্ট গ্রুপে প্রবেশ সীমিত, আর লিসেনার এমনভাবে বাঁধা থাকতে পারে যা আপনি যে ঠিকানা দিয়ে এসেছেন তা বাদ দেয়। নেটওয়ার্ক লেভেল অথেন্টিকেশন এমন একটি গেট যোগ করে যা ডেস্কটপ লোড হওয়ার আগেই ব্যর্থ হয়, এবং তার ত্রুটি বার্তা ভুল পাসওয়ার্ডের থেকে আলাদা। ক্লায়েন্টের বার্তার সঙ্গে হোস্টের ইভেন্ট লগ মিলিয়ে দেখুন, কারণ বার্তাটি গেটের নাম বলে আর লগটি অ্যাকাউন্টের।
সেশন লগইন নিজেই একটি সীমা
অথেন্টিকেশন ডেস্কটপ সেবার, VPN-এর নয়। টানেলের পরিচয় ও ডেস্কটপ অ্যাকাউন্ট আলাদা শংসাপত্র, আলাদা লকআউট নীতি, তাই কাজ করা টানেল কেবল প্রমাণ করে টানেল আপনাকে গ্রহণ করেছে। ডেস্কটপ অ্যাকাউন্ট লক করা টানেলে ব্যাঘাত ঘটায় না, আর উল্টোটাও সত্য।
দুটোই অক্ষত রাখুন। ব্যক্তিগত রুট না থাকলে রুট ঠিক করুন, কারণ লিসেনার ইন্টারনেটে প্রকাশ করা নাগালের বাগের বদলে একটি উন্মুক্ত ডেস্কটপ দেয়। একই সময়ে দেখা দেওয়া সার্টিফিকেট সতর্কবার্তা পেরোতে সেশনের পরিচয় যাচাইও দুর্বল করবেন না। RDP লিসেনারে স্ব-স্বাক্ষরিত সার্টিফিকেট ডিজাইন অনুযায়ীই সতর্কবার্তা দেয়, তাই তা গ্রহণ করা পদক্ষেপ নয়, সিদ্ধান্ত।
আবার চেষ্টার আগে চেষ্টাগুলো গুনুন। ডেস্কটপ লকআউট থ্রেশহোল্ড ব্যর্থ লগইন VPN ব্যর্থতা থেকে আলাদা গোনে, এবং টাইমারে আবার চেষ্টা করা ক্লায়েন্ট আপনি যখন এখনো নিয়ম সম্পাদনা করছেন তখনই থ্রেশহোল্ড ছাড়িয়ে যেতে পারে। পাসওয়ার্ড বদলের পর অ্যাকাউন্ট লক করা একই সমান্তরাল পুনঃচেষ্টা প্রক্রিয়া।
সেশন কী বহন করতে পারে, আর কোথায় থাকে
প্রয়োজনের আগেই অনুমোদিত সাইন-আউট পদ্ধতি শিখুন। জানালা বন্ধ করলে কেবল ভিউ বিচ্ছিন্ন হতে পারে, সেশনটি তার কনফিগার করা নীতিতে চলতে থাকে, যা ভাগ করা বা নিরীক্ষিত হোস্টে গুরুত্বপূর্ণ। নীতি যখন প্রত্যাশা করে তখন সেশনের ভিতর থেকেই সাইন আউট করুন।
তারপর ঠিক করুন সেশন কী বহন করতে পারবে, কারণ ক্লিপবোর্ড, রিডাইরেক্ট করা ড্রাইভ, প্রিন্টার রিডাইরেকশন ও ফাইল ট্রান্সফার সবই নীতি যেখানে অনুমতি দেয় সেখানে স্থানীয় ও দূরবর্তী সিস্টেমের মধ্যে ডেটা সরায়। দূরের দিকে চলা প্রকাশিত অ্যাপ্লিকেশন স্বয়ংক্রিয়ভাবে ডাউনলোড-নিষিদ্ধ সীমা নয়, আর কেবল-পাঠ্য দেখতে হওয়া সেশনও ক্লিপবোর্ড বহন করতে পারে। সংযোগ নয়, আসল কাজটি পরীক্ষা করুন: ফাইলটি খুলুন, অ্যাপ্লিকেশনটি ব্যবহার করুন এবং আপনার প্রয়োজনীয় রিডাইরেকশন নিশ্চিত করুন। বাইরে থেকে রিমোট ডেস্কটপে পৌঁছানোর Microsoft নির্দেশিকা সমর্থিত প্রকাশের বিকল্পগুলো বর্ণনা করে, এবং চাপের মধ্যে যোগ করা পাবলিক লিসেনারের চেয়ে এটি ভালো তথ্যসূত্র।