কেন একটি VPN অ্যাডাপ্টারের নাম ভিন্ন প্রোটোকল লুকাতে পারে
অ্যাডাপ্টারের পাশের লেবেলটি যে সফটওয়্যার এটি তৈরি করেছে তাকে বর্ণনা করে, নেটওয়ার্কের প্যাকেটকে নয়। সমাধান বাছার আগে ক্লায়েন্ট, প্রোফাইল ও পিয়ার যাচাই করুন।
একটি VPN অ্যাডাপ্টারের পাশের লেবেলটি যে সফটওয়্যার ইন্টারফেসটি তৈরি করেছে তাকে বর্ণনা করে, আর তা নেটওয়ার্ক পার হওয়া প্যাকেটের এক স্তর উপরে। একটি প্লাগইন এমন অ্যাডাপ্টার দেখাতে পারে যার নাম নেটওয়ার্কের এনক্যাপসুলেশন নয়, বরং প্লাগইনের নিজস্ব শ্রেণিবিন্যাস প্রতিফলিত করে। ক্লায়েন্ট, প্রোফাইল ও পিয়ার পড়লে যা বোঝা যায়, নাম তা বোঝাতে পারে না। সেটিংস মেনুতে একই রকম দেখানো দুটি সংযোগ ক্যাপচারে সম্পূর্ণ ভিন্ন আচরণ করতে পারে।
নামটি আসে প্রোভাইডারের কাছ থেকে, নেটওয়ার্ক থেকে নয়
Windows তার অন্তর্নির্মিত VPN ক্লায়েন্টের জন্য সংযোগের ধরনের একটি সংক্ষিপ্ত তালিকা নির্ধারণ করে, আর তৃতীয় পক্ষের পণ্য তাদের পাশে নিজেদের স্ট্যাক ইনস্টল করে। নেটওয়ার্ক তালিকায় যে অ্যাডাপ্টার দেখা যায় তা তৈরি করে যে ড্রাইভার সংযোগটির মালিক, তাই এর নাম ড্রাইভার সম্পর্কে প্রমাণ, বাইরের প্রোটোকল সম্পর্কে নিশ্চয়তা নয়। এ কারণেই একটি ক্লায়েন্ট আনইনস্টল করলে পেছনে একটি অ্যাডাপ্টারের নাম থেকে যেতে পারে।
VPN সংযোগের ধরন নিয়ে Microsoft-এর ডকুমেন্টেশন স্পষ্ট যে ধরনটি সেই সংযোগের জন্য ক্লায়েন্টের কনফিগারেশন বর্ণনা করে। প্লাগইন জড়িত থাকলে প্রদর্শিত ধরন প্লাগইন যা নিবন্ধন করে তা অনুসরণ করে, আর প্রকৃত এনক্যাপসুলেশন সম্পূর্ণ ভিন্ন কিছু হতে পারে।
একই স্তরবিন্যাস অন্যত্রও দেখা যায়। Linux হোস্টে একটি ভার্চুয়াল অ্যাডাপ্টার, একটি TAP ডিভাইস বা একটি মোবাইল VPN সেবা এক্সটেনশন—সবই সফটওয়্যার দ্বারা তৈরি ইন্টারফেস, আর ইন্টারফেসের নাম সার্ভারের সঙ্গে আলোচনা নয়, ওই সফটওয়্যারই বেছে নেয়।
পোর্ট ও ঠিকানা আপনাকে কী বলতে পারে আর কী পারে না
প্রতিটি স্তর ভিন্ন প্রমাণ রেখে যায়। সেগুলো আলাদা করে পড়ুন, তাহলে লেবেল আর রায় থাকে না:
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 হলো সবচেয়ে স্পষ্ট উদাহরণ। এটি SSTP, একটি OpenVPN TCP টানেল, একটি SoftEther SSL-VPN সেশন বা সাধারণ ওয়েব ট্রাফিক বহন করতে পারে, আর কেবল পোর্ট নম্বর দিয়ে সেগুলো আলাদা করা যায় না। তাই 443 অনুমোদনকারী ফায়ারওয়াল নিয়ম কোন ক্লায়েন্ট ব্যবহৃত হচ্ছে তার প্রমাণ নয়। বাইরের ইন্টারফেসে ক্যাপচার এটি নিষ্পত্তি করে, আর কয়েক সেকেন্ডেই করে।
প্রোফাইলের ফরম্যাট ও পিয়ার পড়ুন
কনফিগারেশন ফাইল অ্যাডাপ্টারের চেয়ে শক্তিশালী সূত্র। একটি OpenVPN প্রোফাইলে remote, proto ও ca-এর মতো নির্দেশ থাকে; একটি WireGuard কনফিগারেশনে ব্যক্তিগত কীসহ [Interface] বিভাগ এবং অনুমোদিত IP-সহ [Peer] বিভাগ থাকে; Windows ফোনবুক এন্ট্রি নিজের ফরম্যাটে সংযোগের ধরন সংরক্ষণ করে। প্রতিটি সিনট্যাক্স একটি বাস্তবায়নের।
তারপর পিয়ারের ডকুমেন্টেশন ও লগ দেখুন। সার্ভার জানে কোন প্রোটোকল হ্যান্ডলার সেশনটি গ্রহণ করেছে, আর তার লগ কোন ধাপটি সম্পন্ন হয়েছে তা নাম দেয়। এই প্রমাণ যেকোনো ডেস্কটপ লেবেলের চেয়ে শক্তিশালী, কারণ প্যাকেটগুলো যেখানে সত্যিই ব্যাখ্যা করা হয়েছে সেখানেই তা রেকর্ড হয়।
লেবেল নয়, প্রোটোকল অনুযায়ী ম্যানুয়াল বাছুন
একটি OpenVPN নির্দেশ OpenVPN-এর, WireGuard কী ও অনুমোদিত IP WireGuard-এর, আর একটি SSTP প্রোফাইল কোনোটিরই নয়। অ্যাডাপ্টারের নাম সামঞ্জস্যপূর্ণ শোনায় বলে এক ক্লায়েন্টের অপশন আরেকটিতে পেস্ট করা—এভাবেই একটি কাজ করা কনফিগারেশন ভাঙে।
প্রোটোকল শনাক্ত হওয়ার পর সংশ্লিষ্ট সমস্যা সমাধানের পথ বেছে নিন: ক্লায়েন্টের নিজের লগ, সার্ভারের প্রোটোকল-নির্দিষ্ট লগ এবং বাইরের বিনিময় দেখানো একটি ক্যাপচার। সেখান থেকে ব্যর্থতার একটি নাম থাকে, লেবেল নয়।