কেন একটি VPN ডিরেক্টরি তার পেছনের নোডের জামিন দিতে পারে না
একটি তালিকা একটি সংযোগ এবং তা প্রকাশকারী ডিরেক্টরি বর্ণনা করে। সংগ্রহ ও সংরক্ষণ অপারেটরের, যিনি ভিন্ন পক্ষ হতে পারেন।
যে ডিরেক্টরি এন্ট্রিগুলো হোস্টনেম, দেশ ও প্রোটোকলের একটি সেট তালিকাভুক্ত করে, সেগুলো সংযোগ সম্পর্কে প্রমাণ, অন্য প্রান্তের মেশিন কী রেকর্ড করে সে সম্পর্কে নয়। এখানে যে সিদ্ধান্তটি গুরুত্বপূর্ণ তা নয় যে সাধারণভাবে তালিকাকে বিশ্বাস করা উচিত কি না। বরং কোন পক্ষ আপনার প্রকৃত প্রশ্নের উত্তর দেওয়ার অবস্থানে আছে।
একটি এন্ট্রির পেছনে চার পক্ষ
কোনো প্রতিশ্রুতি পড়ার আগে ভূমিকাগুলো আলাদা করুন। ডিরেক্টরি এন্ট্রি প্রকাশ করে, সফটওয়্যার প্রকল্প প্রোটোকল বাস্তবায়ন জোগায়, হোস্টিং প্রদানকারী মেশিন ও নেটওয়ার্ক জোগায়, আর নোড অপারেটর সেবাটি কনফিগার করে। চারজনের যেকোনো একজন ভিন্ন প্রতিষ্ঠান হতে পারেন, এবং প্রত্যেকে কেবল নিজের অংশের কথা বলতে পারেন।
এই বিভাজন ব্যাখ্যা করে কেন একটি বক্তব্য সত্য হয়েও অকেজো হতে পারে। যে ডেভেলপার নথিভুক্ত করেন যে প্রোটোকল পেলোড লগ করে না, তিনি এমন অপারেটরের বিষয়ে কিছু বলেন না যিনি একটি রিলেতে বিস্তারিত সংযোগ লগ চালু করেছেন। দুটি বক্তব্যই কোনো বিরোধ ছাড়া একসাথে থাকতে পারে। ঠিক এ কারণেই প্রশ্নটি নামধারী কোনো পক্ষকে করতে হয়।
কিছু সেবা নিজেরাই নিজেদের এন্ডপয়েন্ট চালায়, তখন এন্ট্রি ও নীতি একই পক্ষ থেকে আসে। এটি শক্তিশালী অবস্থান, তবে পৃষ্ঠার ফরম্যাট থেকে অনুমান না করে তা প্রতিষ্ঠা করতে হয়। বিবৃতিটি চান, এবং যাচাই করুন যে এটি সেই সেবার নাম বলে যেদিকে এন্ট্রি ইঙ্গিত করে।
দাবির সাথে মেলে এমন নথি চান
সংগ্রহ সম্পর্কিত দাবির জন্য এমন নথি দরকার যা সিস্টেম, ডেটা শ্রেণি ও সময়কালের নাম বলে। সংরক্ষণ সম্পর্কিত দাবির জন্য একটি সংখ্যা ও পরিধি দরকার। স্বাধীনতা সম্পর্কিত দাবির জন্য কে কী মালিকানায় রাখে তার বর্ণনা দরকার, কোনো বিশেষণ নয়।
| Field in a listing | What it evidences | What it cannot evidence |
|---|---|---|
| Hostname or address | A reachable endpoint existed when the entry was published | Who runs it, or what it stores |
| Protocols offered | Which client configurations should interoperate | Whether logging was disabled on that deployment |
| Country | Where the endpoint claims to be located | Which legal process could reach the operator |
| Availability score | How often the entry answered a probe | Anything about data handling |
স্বেচ্ছাসেবী প্রকল্পগুলো প্রায়শই সবচেয়ে স্পষ্ট উদাহরণ, কারণ কিছু প্রকল্প তারা যে নোড গ্রহণ করে তার জন্য স্পষ্ট লগিং শর্ত প্রকাশ করে। সেই নথি প্রকল্পের নিয়ম সম্পর্কে প্রাথমিক প্রমাণ, এবং তা এখনও এমন কোনো ব্যক্তিগত অপারেটর সম্পর্কে প্রমাণ নয় যিনি সেগুলো উপেক্ষা করেছেন।
নিরীক্ষা ভিন্ন মাপে একই যুক্তি অনুসরণ করে। যে প্রতিবেদন একটি নির্দিষ্ট স্থাপনা নির্দিষ্ট সময়সীমায় পরীক্ষা করেছে, তা সেই সীমার ভেতরে উপযোগী। একই সফটওয়্যারের প্রতিটি স্বাধীন ইনস্ট্যান্স জুড়ে টেনে দিলে তা এমন নিশ্চয়তা হয়ে যায় যা কেউ দেয়নি। সিদ্ধান্ত পড়ার আগে পরিধি অনুচ্ছেদটি পড়ুন।
যখন কোনো বিক্রেতার গোপনীয়তা বিবৃতি তাদের নিজের সেবাকে কভার করে, তখন তা সেই বিক্রেতার নিজের সিস্টেম সম্পর্কে বিবৃতি হিসেবে পড়ুন। তৃতীয় পক্ষের রিলে বর্ণনা করতে তা পুনর্ব্যবহার করা শ্রেণিগত ভুল, প্রোটোকল অভিন্ন হলেও।
প্রতিটি বিকল্পে আপনি কী কিনছেন তা ঠিক করুন
একটি পাবলিক নোড জবাবদিহির বিনিময়ে নাগাল ও বৈচিত্র্য কেনে। যে অপারেটর আপনার কাছে কোনো ঋণী নয় সে হারিয়ে যেতে, কনফিগারেশন বদলাতে বা নোটিশ ছাড়াই রেকর্ড রাখতে পারে, আর আপনার উপায় সীমিত থাকে এন্ডপয়েন্ট বদলানোয়। এই বিনিময় কিছু কাজের জন্য গ্রহণযোগ্য, অন্যগুলোর জন্য নয়।
একটি অর্থপ্রাপ্ত সেবা প্রকাশিত নীতি ও হারানোর মতো কিছু আছে এমন এক প্রতিপক্ষ কেনে। এটি কারিগরি নিশ্চয়তা কেনে না, নীতিটি পড়ার প্রয়োজনও মেটায় না, তবে সংরক্ষণ বিবৃতিসহ নামধারী প্রতিষ্ঠান বেনামি রিলের চেয়ে সহজে মূল্যায়ন করা যায়।
উভয় ক্ষেত্রেই টিকে থাকা সিদ্ধান্তের নিয়ম হলো প্রমাণকে ঝুঁকির সাথে মেলানো। কাজটি যদি ঘূর্ণায়মান এন্ডপয়েন্ট সহ্য করে, ডিরেক্টরি একটি দক্ষ হাতিয়ার। আর যদি তা নির্দিষ্ট ডেটা-ব্যবস্থাপনার প্রতিশ্রুতির ওপর নির্ভর করে, কেবল সেই পক্ষই প্রাসঙ্গিক যে সেই প্রতিশ্রুতি দিতে পারে, এবং ডিরেক্টরি তখন নিশ্চয়তা নয়, পথনির্দেশের সুবিধা।
curl -s --interface tun0 https://example.net/ -o /dev/null -w '%{remote_ip}
'
উপরের একটি কমান্ড চালানোই সার্থক, কারণ এটি দুটি প্রশ্ন পরিষ্কারভাবে আলাদা করে। এটি দেখায় আপনার ট্রাফিক আসলে কোন ঠিকানা ব্যবহার করেছে, যা সংযোগের তথ্য, এবং সেই ঠিকানার অপারেটর সংযোগের মেটাডেটা নিয়ে কী করেছে সে সম্পর্কে কিছু বলে না।
ক্লায়েন্ট পক্ষের প্রশ্নগুলো আলাদা রাখুন
অপারেটরের নীতি একটি স্তর, আর টানেলের ওপর আপনি যা করেন তার নিরাপত্তা আরেকটি। গন্তব্যে HTTPS, ব্রাউজারে সেশন ব্যবস্থাপনা এবং আপনি যে অ্যাকাউন্টে ঢুকেছেন তার শক্তি আপনার নিয়ন্ত্রণেই থাকে, আর উদার রিলে তা দুর্বল করে না যেমনটি চমৎকার রিলে তা শক্তিশালী করে না।
এই বিচ্ছেদ দুটি সাধারণ ভুল ঠেকায়। কঠোর অপারেটর নীতিকে HTTPS এড়ানোর কারণ ভাবা একটি, আর কাজ করা HTTPS সংযোগকে রিলে কে চালায় তা উপেক্ষা করার কারণ ভাবা অন্যটি। দুটি ভুলই দুটি স্তরকে এক করে ফেলে এবং তারপর ভুলটি নিয়ে তর্ক করে।
সংক্ষিপ্ত লিখিত মূল্যায়ন দুটোই সামলায়। প্রতিটি প্রতিশ্রুতি যে পক্ষ দেয় তার নাম বলুন, তাকে সমর্থনকারী নথি সংযুক্ত করুন, এবং তারিখ লিখুন। তারপর ঠিক করুন কাজটির শক্তিশালী দাবি দরকার, না কেবল কাজ করা একটি পথ।
এন্ট্রিটি তার কাজ করেছে যেই মুহূর্তে এটি বলেছে আপনি কোথায় সংযুক্ত হতে পারেন। প্রশ্নের বাকি অংশটি সেই এন্ডপয়েন্ট চালানো ব্যক্তির, আর সৎ উত্তর প্রায়ই এই যে আপনি জানতে পারবেন না এবং সেই অনুযায়ী বেছে নেওয়া উচিত।