কেন একটি বিস্তৃত VPN রুট কিছু পাবলিক সাইট ভেঙে দেয়

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

ব্যর্থ নামটি রিজলভ করুন, তারপর ব্রাউজারের বদলে রাউটিং টেবিলে তাকান।

ওয়েবসাইটের নাম নয়, ঠিকানা তুলনা করুন

ক্লায়েন্ট আসলে যে ঠিকানায় চেষ্টা করেছে তা খুঁজুন, তারপর দেখুন কোন রুটটি তার সাথে মেলে। 45.61.20.10-এর ভিতরের কোনো গন্তব্য 45.0.0.0/8-এর অধীনে পড়ে যদি সেই প্রিফিক্স উপস্থিত থাকে, যদিও ওয়েবসাইটের নিজের সাথে টানেলের কোনো সম্পর্ক না থাকে। ব্যর্থ ঠিকানাটিকে ইনস্টল করা প্রিফিক্সগুলোর সাথে তুলনা করা একটি বিয়োগের হিসাব, অনুমান নয়।

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

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

প্রিফিক্স, তার ইন্টারফেস ও রিজলভ হওয়া ঠিকানা লিখে রাখুন। এই তিনটি মানই পুরো রোগনির্ণয়।

রুটটি কে ইনস্টল করেছে তা খুঁজুন

রুট চার জায়গা থেকে আসে: নিজস্ব VPN প্রোফাইল, একটি ব্যবস্থাপনা নীতি, একটি সংযোগ স্ক্রিপ্ট, কিংবা সম্পূর্ণ অন্য ক্লায়েন্ট। জীবন্ত এন্ট্রিটি মুছে ফেলা এর প্রাসঙ্গিকতা নিশ্চিত করতে পারে, কিন্তু পরবর্তী সংযোগটি সংরক্ষিত কনফিগারেশন থেকে এটি আবার তৈরি করে, তাই উৎসটিই বদলাতে হবে।

প্রথমে প্রোফাইলের রুট তালিকা দেখুন, তারপর ব্যবস্থাপনা নীতি, তারপর সংযোগের সময় চলা যেকোনো স্ক্রিপ্ট। এই ক্রমটি প্রতিটি কত ঘন ঘন দায়ী হয় তার সাথে মেলে। এটি পরিবর্তনটিকে তিন স্তরের বদলে এক স্তরে সীমাবদ্ধ রাখেও সাহায্য করে।

নেটিভ ক্লাস-ভিত্তিক আচরণ মন দিয়ে পড়ুন

নেটিভ Windows প্রোফাইলে একটি নথিভুক্ত সেটিং আছে, NativeProfile/DisableClassBasedDefaultRoute, যা ইন্টারফেস ঠিকানা থেকে অনুমিত একটি স্বয়ংক্রিয় রুট নিয়ন্ত্রণ করে। 45 দিয়ে শুরু হওয়া প্রোফাইল ঠিকানা ওই আচরণে একটি 45.0.0.0/8 এন্ট্রি তৈরি করতে পারে, আর এভাবেই একটি পাবলিক ঠিকানা পুরো একটি ক্লাস-A রেঞ্জ ধরে ফেলে।

প্রপার্টির নামটি ভুল পড়ার আমন্ত্রণ দেয়: এটি true করলে অনুমানটি বন্ধ হয়, আর false করলে চালু হয়। এটি ডিফল্ট রুটের মতো একই বস্তু নয়, আর নিজস্ব প্রিফিক্স ইনস্টল করা তৃতীয় পক্ষের ক্লায়েন্টদেরও নিয়ন্ত্রণ করে না।

অনুমানটিই প্রমাণিত কারণ হলে প্রোফাইলটি তার ব্যবস্থাপনা মালিকের মাধ্যমে ঠিক করুন এবং অভীষ্ট প্রাইভেট প্রিফিক্সগুলো স্পষ্টভাবে দিন। কোনো স্ক্রিপ্ট এন্ট্রিটি যোগ করে থাকলে স্ক্রিপ্টটি ঠিক করুন। একটি অব্যাখ্যাত প্রশস্ত রুটের বদলে আরেকটি বসানো প্রশ্নের উত্তর না দিয়েই উপসর্গ বদলায়।

উৎস ঠিক করুন, তারপর দুই পথই আবার যাচাই করুন

পরিবর্তনের পর আবার সংযোগ করুন এবং একটি ব্যর্থ পাবলিক সাইট ও টানেল ব্যবহার করা উচিত এমন একটি রিসোর্সের জন্য লুকআপটি পুনরাবৃত্তি করুন। প্রথমটি এখন ফিজিক্যাল ইন্টারফেসে রিজলভ হওয়া উচিত, আর দ্বিতীয়টির এখনও VPN নির্বাচন করা উচিত। প্রথম সাফল্যেই থামবেন না; যে সমাধান প্রাইভেট অ্যাক্সেসও ভাঙে সে এক ত্রুটির বদলে আরেকটি এনেছে।

একই সময়ে সার্ভারের ঠিকানা পরিকল্পনাও পর্যালোচনা করুন। পাবলিক স্পেসের সাথে ওভারল্যাপ করা পুল এই ধরনের সমস্যা বারবার ঘটায়। অপারেটর ইচ্ছাকৃতভাবে বেছে নেওয়া রেঞ্জ স্বয়ংক্রিয় পুনঃসংখ্যায়নের বদলে ভিন্ন আলোচনার দাবি রাখে।

MTU বাড়ানো বা DNS ফ্লাশ করা সেই প্রিফিক্সকে ঠিক করবে না যা এখনও ওই ঠিকানাকে টানেলে পাঠায়। আগে নির্বাচন যাচাই করুন, তারপর পথ।