একটি পাবলিক VPN হোস্টনেম কী প্রমাণ করতে পারে আর কী পারে না
হোস্টনেম একটি এন্ডপয়েন্টের দিক দেখায়, তার বেশি কিছু নয়। এটি প্রোটোকল, এক্সিট লোকেশন বা অপারেটরের সংরক্ষণ নীতির প্রমাণ দেয় না, কোনও নির্দিষ্ট দিনে।
হোস্টনেম আর দেশের পতাকা সার্ভার সম্পর্কে তথ্য বলে মনে হয়, অথচ দুটির কোনওটিই তা নয়। একটি নাম এমন ঠিকানার দিকে নির্দেশ করে যা বদলে যেতে পারে, আর ভেতরের শব্দগুলো বেছেছেন যিনি এটি নিবন্ধন করেছেন। প্রোটোকল, এক্সিট লোকেশন ও লগিং আচরণের প্রতিটির জন্য আলাদা প্রমাণ দরকার। নামটি আসলে কীসে রিজলভ হয় তা দিয়ে শুরু করুন, তারপর ঠিক করুন কী এখনও অজানা।
নামটি রিজলভ হয়, আর কিছুই নির্ধারিত হয় না
হোস্টনেম হল DNS-এর দিকে একটি পয়েন্টার, আর এর পেছনের রেকর্ড রিজলভারভেদে, দিনের সময়ভেদে এবং ক্লায়েন্ট যে অ্যাড্রেস ফ্যামিলি পছন্দ করে তার ভেদে আলাদা হতে পারে। একই ডিরেক্টরি তালিকা পড়া দুজন মানুষ বৈধভাবেই আলাদা মেশিনে পৌঁছাতে পারেন। নামটি বলে আপনি কী চাইবেন, কী উত্তর দেবে তা নয়।
লুকআপ ফলাফলও না জানিয়ে বদলায়, যা গুরুত্বপূর্ণ যখন একটি প্রোফাইল নামের বদলে একটি ঠিকানা পিন করে। যে প্রোফাইল পুরনো ঠিকানাটি হার্ডকোড করে, অপারেটর সেবা সরানোর পরেও তা ব্যর্থ হতে থাকে, আর ব্যর্থতাটি বন্ধ পোর্টের মতো দেখায়। রিজলভ হওয়া ঠিকানাগুলো প্রোফাইলের পাশে রাখুন, যাতে পরের তুলনার একটি ভিত্তি থাকে। এর কোনওটিই বলে না অন্য প্রান্তটি কে চালায়।
dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1
ট্রান্সপোর্ট ও পরিচয় আলাদা প্রশ্ন
হোস্টনেমে একটি খোলা ওয়েব পেজ একটি পোর্টে একটি লিসেনার পরীক্ষা করে। OpenVPN, IPsec ও SSTP অন্য জায়গায়, নিজেদের পোর্ট ও প্রোটোকলে শোনে, তাই পৌঁছানো যায় এমন একটি ওয়েব সার্ভার তাদের সম্পর্কে কিছুই বলে না।
ডিরেক্টরি এন্ট্রি ও প্রোফাইলকে ট্রান্সপোর্ট, পোর্ট ও ক্রেডেনশিয়ালে একমত হতে হবে। পরিচয় যাচাই হয় সার্টিফিকেট চেইন বা ক্লায়েন্ট যে পিয়ার কী ফিঙ্গারপ্রিন্ট দিয়ে কনফিগার হয়েছিল তা দিয়ে, হোস্টের বানান দিয়ে নয়। পরিচিত প্রকল্পের শব্দ থাকা একটি নাম কেবল প্রমাণ করে যে কেউ এটি নিবন্ধন করেছে। সেবাটি যে সার্টিফিকেট উপস্থাপন করে তা পড়ুন এবং ইস্যুয়ার ও সাবজেক্ট প্রোফাইল যা আশা করে তার সঙ্গে মিলিয়ে দেখুন।
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates
দেশের শব্দ অবস্থানের নিরীক্ষা নয়
ডিরেক্টরিতে jp বা de লেবেল একটি নিবন্ধন, আর IP ভূ-অবস্থান ডেটাবেস যথেষ্ট ঘন ঘন ভিন্ন হয়, তাই কোনওটিকেই চূড়ান্ত সত্য হিসেবে ধরা উচিত নয়। শেয়ার্ড হোস্টিং, anycast ও সাধারণ ভুল কনফিগারেশন সবই পর্যবেক্ষিত অবস্থানকে লেবেল থেকে সরিয়ে দেয়।
ব্যবহারিক পরীক্ষা হল অ্যাপ্লিকেশনের নিজের পথ: এটি কোন ঠিকানায় পৌঁছায়, আর সেশন থেকে এক্সিট-অ্যাড্রেস পরীক্ষা কী দেখায়। পর্যবেক্ষিত এক্সিট ঠিকানা ওই মুহূর্তে রুটের একটি বৈশিষ্ট্য, নামের সঙ্গে যুক্ত কোনও নিশ্চয়তা নয়। স্বেচ্ছাসেবক ডিরেক্টরি আরও একটি স্তর যোগ করে, কারণ যিনি একটি তালিকা নিবন্ধন করেছেন তিনি মেশিনটি চালান এমন নাও হতে পারেন। আপনি কী মেপেছেন আর কখন, তা লিখে রাখুন, তালিকা যা প্রতিশ্রুতি দিয়েছিল তা নয়।
প্রস্তাবিত সেবা পরীক্ষা করুন, তারপর অপারেটর
ট্রান্সপোর্ট ও পরিচয় নির্ধারিত হলে বাকি প্রশ্ন অপারেটরের আচরণ, আর এর জন্য অনুমানের বদলে দলিলভিত্তিক প্রমাণ দরকার। গোপনীয়তা নীতি, প্রকাশিত যোগাযোগ ঠিকানা ও স্বচ্ছতা বিজ্ঞপ্তি অভিপ্রায়ের প্রমাণ; এর কোনওটিই অনুশীলন প্রমাণ করে না, আর তিনটিরই অনুপস্থিতিও একটি তথ্য।
পাবলিক বা স্বেচ্ছাসেবক-চালিত নোডের ক্ষেত্রে ধরে নিন এক্সিট শেয়ার করা এবং যিনি এটি চালান তিনি ভেতর দিয়ে যা যায় তা দেখতে পারেন। হোস্টনেম নয়, এই ধারণাটিই ঠিক করা উচিত টানেল দিয়ে আপনি কী পাঠাবেন।
curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'
নামটিকে তার কাজের জন্য রাখুন: একটি এন্ডপয়েন্ট খোঁজা ও তাতে সংযোগ করা। এর বাইরের সবকিছু আলাদাভাবে পরীক্ষা করতে হবে, যেদিন তা গুরুত্বপূর্ণ সেদিন।