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

দুটি রেকর্ড, এবং এদের মধ্যে কেবল একটি বিদ্যমান

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

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

বিকল্প ক: এক্সিট ঠিকানা নিজে ক্যাপচার করুন

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

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

দুটি খুঁটিনাটি ওই অংশটিকে সাজসজ্জা নয়, কাজের করে তোলে। সময়চিহ্ন ও ঠিকানা একই লাইনে থাকে, তাই পরের বিশ্লেষণকে রেকর্ড জোড়া লাগাতে হয় না, এবং umask 077 ফাইলটি তৈরি হওয়ার মুহূর্ত থেকেই ব্যক্তিগত রাখে। এটি প্রতি সংযোগে একবার চালান, প্রতি বুটে একবার নয়, এবং প্রতি ডিভাইসে একটি ফাইল রাখুন।

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

বিকল্প খ: প্রদানকারীর কাছে ইতিহাস চান

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

যারা লগ রাখে না বলে বিজ্ঞাপন দেয় তারা চাইলেই এটি দিতে পারে না, আর ক্লায়েন্টের দিকের সাম্প্রতিক জায়গার তালিকা আলাদা বিষয়। লগহীন প্রদানকারীর কাছে এক্সিট ঠিকানা চাওয়া সাধারণত এই ব্যাখ্যায় শেষ হয় যে তথ্যটি কেন নেই।

সাপোর্ট কেসে প্রতিটি রেকর্ড কী প্রমাণ করতে পারে

দুটি রেকর্ড ভিন্ন প্রশ্নের উত্তর দেয়, এবং সারণিতেই তুলনাটি আর নিছক তত্ত্ব থাকে না।

QuestionYour local logProvider record
Which address did the traffic leave from?Yes, for the moment it was capturedUsually not disclosed
Was the tunnel in use at 14:20?Yes, if the capture ranYes, within the retention window
Why did a location get slower?Yes, by comparing addresses over timeSometimes, as an infrastructure note
Who sent this specific request?NoNo

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

যেকোনো একটিতে ভরসা করার আগে দুটিকেই ভিত্তিরেখার সঙ্গে তুলনা করুন

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

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

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

সম্পর্কিত নিবন্ধ