Onion সেবা বনাম VPN সেবা: ভিন্ন প্রবেশ মডেল

মানুষ Onion সেবা এবং কেবল VPN দিয়ে পৌঁছানো যায় এমন সেবাকে একই ধারণার দুই রূপ বলে বর্ণনা করে: পোর্ট লুকাও, গোপন ঠিকানা ভাগ করো। ঠিকানাটি কীসের সঙ্গে বাঁধা, কে সেখানে পৌঁছাতে পারে এবং অনুরোধ আসার আগে কী ঘটতে হবে—এসব বিষয়ে তারা আলাদা। একটি Tor-এর ভেতরের মিলনস্থল, অন্যটি ব্যক্তিগত নেটওয়ার্কের ভেতরের পথ। তাদের পরস্পর বিনিময়যোগ্য ভাবলে এমন নকশা তৈরি হয় যা ব্যক্তিগতও নয়, টেকসইইও নয়।

মিথ: দুই নকশাই কেবল একটি লুকানো দরজা

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

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

Onion ঠিকানা আসলে কী নির্দেশ করে

Onion ঠিকানা সংস্করণ v3 সেবার পাবলিক চাবি এনকোড করে, তাই কেউ নিজে নিয়ন্ত্রণ না করা সেবার জন্য ঠিকানা বেছে নিতে পারে না। ক্লায়েন্ট Tor-এর মাধ্যমে মিলনস্থলে সংযোগ করে, আর সেবা তার দিক থেকে সেই বিন্দুতেই পৌঁছায়; কোনো সাধারণ এগজিট নোড সেই সংযোগ সেবা পর্যন্ত বহন করে না। নাম একটি পরিচয়, DNS রেকর্ড নয়।

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

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

যদি onion নকশার একমাত্র কারণ প্রমাণীকরণ চালু করা এড়ানো হয়, তবে থামুন। ওভারলে স্তর তা দেয় না, এবং আপনি এটি পরেও তৈরি করবেন।

VPN পথ আসলে কী দেয়

VPN একটি ডিভাইসকে নেটওয়ার্কে প্রবেশ করায় এবং তাকে গেটওয়ে বা সাবনেট পর্যন্ত পথ দেয়। সেই গেটওয়ের পিছনের সেবা টানেল পুল থেকে ঠিকানা দেখে এবং তার যে অনুমোদন আছে তা প্রয়োগ করে। পথ ব্যবহারকারী কে তা কিছুই বলে না; এটি বলে প্যাকেট কোথায় যেতে পারে।

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

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

দর্শক অজানা হলে বা অবিরাম বদলালে থামুন। একটি পাতা দেখানোর জন্য অপরিচিতদের ব্যক্তিগত নেটওয়ার্কে নিবন্ধন করা সেবা প্রকাশ করার তুলনায় বড় প্রতিশ্রুতি।

দুইয়ের মধ্যে বাছাই, এবং যা একই থাকে

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

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

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