Windows সংযোগ ভাগ করছেন? এর নিচে VPN পথ বদলে যায়

একটি ল্যাপটপ তার Wi-Fi ভাগ করে, হোস্ট কোনো অভিযোগ ছাড়াই টানেল দিয়ে ব্রাউজ করে, আর সেই শেয়ারের ট্যাবলেট কিছুই পৌঁছায় না। শেয়ারিং চালু হওয়ার মুহূর্তেই হোস্ট শুধু ক্লায়েন্ট থাকা বন্ধ করেছে: এটি এখন রাউটার, এবং ফরওয়ার্ড করা প্যাকেট ভিন্ন নিয়মের সম্মুখীন হয়। হোস্টে যা কাজ করে তা তার পেছনের ডিভাইস সম্পর্কে কিছুই বলে না। ডাউনস্ট্রিম ক্লায়েন্ট থেকে পরীক্ষাগুলো চালান এবং পার্থক্যটি আর তাত্ত্বিক থাকে না।

হোস্টের সাফল্য কিছুই প্রমাণ করে না

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

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

কোন অ্যাডাপ্টার ভাগ করা, কোনটি ক্লায়েন্টদের সেবা দেয়

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

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

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

ফরওয়ার্ডিং, অনুবাদ এবং ফিল্টারিং

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

দূর প্রান্তের ভাগ করা সাবনেটের জন্য একটি রিটার্ন রুটও লাগতে পারে, এমন পরিসর যা VPN সার্ভার কখনও দেখেনি। যেখানে ক্লায়েন্ট অনুবাদ করে, সার্ভার কেবল টানেল ঠিকানা দেখে এবং রিটার্ন রুট লাগে না। যেখানে করে না, গেটওয়ের মালিককে সেই রুটটি সচেতনভাবে যোগ করতে হয়, আর এটা ক্লায়েন্ট সেটিং নয়, পরিবর্তনের অনুরোধ।

পরীক্ষা ক্লায়েন্টে করুন, হোস্টে নয়

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

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

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

ম্যানেজড মেশিনে নিশ্চিত করুন যে শেয়ারিং আদৌ অনুমোদিত, কারণ অন্য ডিভাইসে অ্যাক্সেস খোলা সুবিধার টগল নয়, প্রশাসনিক সিদ্ধান্ত। যেকোনো সমর্থিত পরিবর্তনের পরে পুনঃসংযোগে এবং আবার বিভ্রাটের সময় পরীক্ষাগুলো পুনরাবৃত্তি করুন। হোস্ট পরিষ্কারভাবে পুনঃসংযোগ করলেও ক্লায়েন্ট কখনও সমর্থন করেনি এমন ফরওয়ার্ড করা রুট ফিরে আসে না।