SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-21

Nginx-এ Onion-Location হেডার যোগ করার নিয়ম

আপনার Nginx কনফিগারেশনে Onion-Location হেডার যোগ করে Tor Browser-এ সাইটটি প্রচার করুন। রিডাইরেক্ট ও থার্ড-পার্টি অ্যাসেট থেকে তথ্য ফাঁস রোধ করার কার্যকর উপায় এখানে বিস্তারিত দেওয়া হলো।

Onion-Location header যা করে

Onion-Location header হলো আপনার clearnet vhost-এর একটি লাইন, যা Tor Browser-এর কাছে আপনার onion address-এর বিজ্ঞাপন দেয়। যে ভিজিটর Tor ব্যবহার করে https://example.com-এ প্রবেশ করেন, তিনি address bar-এ একটি বেগুনি রঙের পিল দেখতে পান যাতে .onion available লেখা থাকে। একটি ক্লিকেই তারা আপনার onion service-এ চলে যেতে পারেন। এটি কেবল একটি discovery mechanism বা খুঁজে পাওয়ার মাধ্যম। এই header কোনো onion service তৈরি করে না এবং এটি আপনার সম্পর্কে কোনো তথ্য গোপন করে না।

এই নির্দেশিকাটি ধরে নেয় যে উভয় অংশই ইতিমধ্যে বিদ্যমান। আপনার nginx-এর পেছনে একটি VPS-এ একটি সাইট আছে এবং সেটির দিকে নির্দেশ করা একটি কার্যকর v3 onion service রয়েছে। যদি আপনার কাছে দ্বিতীয় অংশটি না থাকে, তবে আগে সেটি তৈরি করুন: hosting an onion site on a VPS নির্দেশিকায় torrc লাইন এবং প্রথম hostname ফাইল সম্পর্কে আলোচনা করা হয়েছে। নিচে যা দেওয়া হলো তা হলো একটির তথ্য অন্যটিতে ফাঁস না করে উভয়কে যুক্ত করার উপায়।

Tor Browser হেডারটি গ্রহণ করার আগে যা যা প্রয়োজন

Tor Project তিনটি শর্তের কথা উল্লেখ করেছে। এই তিনটি শর্তই পূরণ হতে হবে, অন্যথায় পিল (pill) বা নোটিফিকেশনটি প্রদর্শিত হবে না।

  • Onion-Location ভ্যালুটিকে অবশ্যই একটি বৈধ URL হতে হবে, যার একটি http: বা https: স্কিম এবং একটি .onion হোস্টনাম থাকবে।
  • যে ওয়েবপেজটি হেডারটি সংজ্ঞায়িত করছে, সেটি অবশ্যই HTTPS-এর মাধ্যমে পরিবেশন করতে হবে।
  • হেডারটি সংজ্ঞায়িত করা ওয়েবপেজটি নিজে কোনো onion সাইট হতে পারবে না।

দ্বিতীয় শর্তটি ব্যবহারকারীদের জন্য বিভ্রান্তিকর হতে পারে এবং তৃতীয় শর্তটি ব্যাখ্যা করে কেন আপনি onion vhost-এ এই হেডারটি সেট করবেন না। নথিপত্রে উল্লেখ নেই এমন একটি চতুর্থ নিয়মও রয়েছে যা ইমপ্লিমেন্টেশনে বিদ্যমান: Tor Browser শুধুমাত্র টপ-লেভেল ডকুমেন্টের ক্ষেত্রেই এই হেডারের ওপর কাজ করে। কোডটি কোনো কিছু করার আগে লোড টার্গেটটিকে ডকুমেন্টের সাথে তুলনা করে, তাই কোনো স্টাইলশিট, ইমেজ বা API রেসপন্সে এই হেডারটি থাকলে তা উপেক্ষা করা হয়।

ডিফল্টভাবে ব্রাউজার পিলটি দেখায় এবং ক্লিকের জন্য অপেক্ষা করে। কোনো পাঠক যদি স্বয়ংক্রিয়ভাবে রিডাইরেক্ট হতে চান, তবে তাকে Settings, তারপর Privacy and Security, এবং এরপর Onion Services-এ গিয়ে "Prioritize .onion sites when known" অপশনটি "Always"-এ সেট করতে হবে। আপনি সার্ভার সাইড থেকে এটি জোরপূর্বক করতে পারবেন না। হেডারটিকে একটি প্রস্তাব হিসেবে বিবেচনা করুন, রিডাইরেক্ট হিসেবে নয়।

Nginx-এ Onion-Location হেডার যোগ করা

এই হেডারটি সেই server ব্লকে থাকা উচিত যা আপনার clearnet ডোমেইনের জন্য TLS টার্মিনেট করে। এটিকে port 80 ব্লকে রাখলে কোনো কাজ হবে না, কারণ সেই ব্লকটি শুধুমাত্র একটি রিডাইরেক্ট প্রদান করে এবং দ্বিতীয় শর্ত অনুযায়ী plain HTTP পেজে কোনো হেডার সংজ্ঞায়িত করা যায় না।

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    add_header Onion-Location http://<your-onion-address>.onion$request_uri always;

    root /srv/example.com/public;
}

$request_uri পাথ এবং কুয়েরি স্ট্রিং বহন করে, তাই https://example.com/guides/tor-এর একজন পাঠককে onion সাইটেও একই পাথ অফার করা হয়। এটি বাদ দিলে প্রতিটি ভিজিটর তাদের পড়া পেজের পরিবর্তে onion হোম পেজে ল্যান্ড করবে।

always গুরুত্বপূর্ণ কারণ Nginx-এ একটি নথিভুক্ত সীমাবদ্ধতা রয়েছে। add_header শুধুমাত্র তখনই ফিল্ডটি যোগ করে যখন রেসপন্স কোড হয় 200, 201, 204, 206, 301, 302, 303, 304, 307 অথবা 308। আপনার 404 পেজটি সার্চ রেজাল্ট থেকে আসা একটি প্রকৃত এন্ট্রি পয়েন্ট, এবং always ছাড়া এতে কোনো হেডার থাকে না।

Nginx-এর দ্বিতীয় ফাঁদটি হলো ইনহেরিটেন্স (inheritance), যা নীরবে ব্যর্থ হয়। add_header ডিরেক্টিভগুলো শুধুমাত্র তখনই পূর্ববর্তী কনফিগারেশন লেভেল থেকে ইনহেরিট হয় যদি বর্তমান লেভেলে কোনো add_header ডিরেক্টিভ না থাকে। তাই একটি location /assets/ { add_header Cache-Control ...; } ব্লক তার অধীনে থাকা প্রতিটি URL-এর জন্য সার্ভার-লেভেলের Onion-Location বাতিল করে দেয়। আপনি যদি কোথাও per-location হেডার সেট করেন, তবে সেই ব্লকগুলোর প্রতিটির ভেতরে Onion-Location লাইনটি পুনরায় লিখুন। যদি এই আচরণ আপনার কাছে নতুন হয়, তবে Nginx কীভাবে একটি সার্ভার এবং লোকেশন ব্লক নির্বাচন করে বিষয়টি একবার পড়ে নেওয়া ভালো।

রিলোড করুন এবং একটি সাধারণ পেজ ও একটি অনুপস্থিত পেজ উভয়ই চেক করুন:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://example.com/ | grep -i onion-location
curl -sI https://example.com/no-such-page | grep -i onion-location

উভয় কমান্ডেরই একটি onion-location: লাইন প্রিন্ট করা উচিত। দ্বিতীয় কমান্ডটি প্রমাণ করে যে always কাজ করছে। দ্বিতীয় কমান্ড থেকে কোনো আউটপুট না আসার অর্থ হলো ফ্ল্যাগটি অনুপস্থিত অথবা কোনো location ব্লক ডিরেক্টিভটিকে আড়াল (shadowing) করে রেখেছে।

যখন হেডার সেট করা সম্ভব নয় তখন HTML meta tag-এর ব্যবহার

স্ট্যাটিক হোস্ট এবং কিছু CDN ড্যাশবোর্ড আপনাকে ইচ্ছামতো রেসপন্স হেডার যোগ করতে দেয় না। একই মান ডকুমেন্টের head অংশে meta element হিসেবে কাজ করে, কারণ ব্রাউজার HTTP-এর মাধ্যমে আসুক বা http-equiv ট্যাগ হিসেবে আসুক, উভয় ক্ষেত্রেই এটি একই ডকুমেন্ট হেডার ডেটার মাধ্যমে পড়ে।

<meta http-equiv="onion-location" content="http://<your-onion-address>.onion" />

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

নিজস্ব nginx vhost থেকে onion সাইট পরিবেশন করা

Clearnet সাইট এবং onion সাইট একই server block শেয়ার করতে পারবে না। Tor Browser Host: <your-onion-address>.onion পাঠায়। যদি কোনো server block এই নামটি দাবি না করে, তবে nginx ডিফল্ট server-এ ফিরে যায়, যা আপনার clearnet vhost। ফলে সেই vhost থেকে তৈরি প্রতিটি URL আপনার ডোমেইন নাম প্রদর্শন করে।

Hidden service-টিকে এমন একটি পোর্টে নির্দেশ করুন যা শুধুমাত্র loopback interface-এ সাড়া দেয়:

HiddenServiceDir /var/lib/tor/onion_site/
HiddenServicePort 80 127.0.0.1:8080

এরপর সেই পোর্টের জন্য নিজস্ব একটি vhost তৈরি করুন:

server {
    listen 127.0.0.1:8080;
    server_name <your-onion-address>.onion;

    absolute_redirect off;
    port_in_redirect off;

    root /srv/example.com/public;
}

listen 127.0.0.1:8080 এই vhost-টিকে আপনার পাবলিক IP থেকে দূরে রাখে, যাতে কেউ VPS অ্যাড্রেস স্ক্যান করলে এটি খুঁজে না পায় এবং clearnet কপির সাথে বাইট-বাই-বাইট তুলনা করতে না পারে। absolute_redirect off nginx-কে আপেক্ষিক (relative) Location মান ইস্যু করতে বাধ্য করে, ফলে ডিরেক্টরির শেষে থাকা স্ল্যাশ রিডাইরেক্ট পূর্ণাঙ্গ URL-এর পরিবর্তে Location: /guides/ প্রদান করে। nginx ইতিমধ্যে Host হেডার থেকে পরম (absolute) রিডাইরেক্ট তৈরি করে, server_name থেকে নয়, কারণ server_name_in_redirect ডিফল্টভাবে off থাকে। তবে একটি আপেক্ষিক রিডাইরেক্ট এই বিষয়টি পুরোপুরি সমাধান করে দেয়।

কেন অনিয়ন পেজ এখনও ভিজিটরদের ক্লিয়ারনেট সাইটে পাঠায়?

nginx সাধারণত এই লিকেজের কারণ নয়। আপনার অ্যাপ্লিকেশনই এর জন্য দায়ী। কনফিগার করা সাইটের ঠিকানা থেকে কোনো absolute URL তৈরি করা হলে, সেটি কোন vhost থেকে অনুরোধটি এসেছে তা বিবেচনা না করেই আপনার ডোমেইন নাম ব্যবহার করবে।

  • একটি rel="canonical" লিংক ট্যাগ যা https://example.com/...-এর দিকে নির্দেশ করে। এটি সবচেয়ে সাধারণ কারণ এবং যে কেউ সোর্স কোড দেখলে সরাসরি ক্লিয়ারনেট পেজের নাম দেখতে পাবে।
  • nginx-এর পরিবর্তে ফ্রেমওয়ার্ক দ্বারা তৈরি রিডাইরেক্ট, যেমন Django-এর SECURE_SSL_REDIRECT অথবা WordPress-এর home এবং siteurl অপশন।
  • og:url এবং অন্যান্য সোশ্যাল কার্ড মেটা ট্যাগ।
  • সাইটম্যাপ এবং RSS এন্ট্রি, যা স্পেসিফিকেশন অনুযায়ী absolute হয়।
  • অ্যাপ্লিকেশনের এরর পেজ, যা সাধারণত একই সেটিং থেকে তৈরি "হোম পেজে ফিরে যান" লিংক অন্তর্ভুক্ত করে।

এর সমাধান আপনার স্ট্যাকের ওপর নির্ভর করে এবং এর কোনো সাধারণ সমাধান নেই। তবে পরীক্ষা করার পদ্ধতিটি সাধারণ। Tor-এর মাধ্যমে অনিয়ন পেজটি ফেচ করুন এবং রেসপন্সের মধ্যে আপনার ডোমেইনটি খুঁজুন।

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -i 'example\.com'

--socks5-hostname নামটিকে রেজোলিউশনের জন্য Tor-এর SOCKS পোর্টে পাঠায়, যা প্রয়োজনীয় কারণ আপনার মেশিনের কোনো কিছুই স্থানীয়ভাবে .onion নাম রেজলভ করতে পারে না। পোর্ট 9050 হলো প্যাকেজড tor ডেমনের ডিফল্ট পোর্ট। ফলাফল খালি আসা মানে আপনি সফল। কোনো ফলাফল পাওয়া গেলে বুঝতে হবে সেই পেজটি প্রতিটি অনিয়ন ভিজিটরকে আপনার ক্লিয়ারনেট ডোমেইনটি দেখাচ্ছে। এটি হোম পেজে এবং 404 এরর তৈরি করে এমন একটি URL-এ চালিয়ে দেখুন।

রিডাইরেক্ট চেইনটি আলাদাভাবে পরীক্ষা করুন, কারণ রিডাইরেক্ট বডি সাধারণত খালি থাকে:

curl -sI --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/guides \
  | grep -i '^location'

example.com নামযুক্ত একটি Location ভ্যালুর অর্থ হলো, একটি রিডাইরেক্ট আপনার অনিয়ন ভিজিটরকে ক্লিয়ারনেটে ফিরিয়ে দিচ্ছে। ভিজিটর মনে করছেন তিনি Tor-এর ভেতরেই আছেন, কিন্তু রিডাইরেক্টটি একটি এক্সিট নোডের মাধ্যমে কাজ করছে।

আপনার clearnet certificate onion সার্ভিসে ব্যবহার করবেন না

একটি v3 onion address সরাসরি সার্ভিসটির নিজস্ব public key থেকে তৈরি হয়। তাই কোনো HTTP request পাঠানোর আগেই Tor সেই নির্দিষ্ট সার্ভিসের সাথে সার্কিটটিকে প্রমাণীকরণ (authenticate) এবং এনক্রিপ্ট (encrypt) করে নেয়। onion সার্ভিসের ভেতরে plain HTTP ব্যবহার করা একটি স্বাভাবিক কনফিগারেশন এবং এটি ইন্টারনেটের সাধারণ plain HTTP-এর মতো নয়।

আপনি যদি clearnet-এর কনফিগারেশন কপি করে onion vhost তৈরি করেন, তবে আপনি এর সাথে ssl_certificate-ও কপি করে ফেলবেন। এর ফলে onion সার্ভিসটি এমন একটি সার্টিফিকেট প্রদর্শন করবে যার subject alternative names তালিকায় example.com থাকে। এতে দুটি সমস্যা হয়। প্রথমত, ব্রাউজার একটি name mismatch ত্রুটি দেখাবে, কারণ URL-টি হলো onion address এবং সার্টিফিকেটটি সেই ঠিকানাকে কভার করে না। দ্বিতীয়ত, যে ভিজিটরই এই সতর্কতা এড়িয়ে সাইটে প্রবেশ করবে, সে একটি স্বাক্ষরিত বিবৃতি পাবে যে এই দুটি সাইট একই মেশিনে হোস্ট করা। তাই onion vhost-কে আলাদা ফাইলে রাখুন এবং এর জন্য নিজস্ব server_name ব্যবহার করুন। এটি করলে তা Certbot nginx plugin থেকেও মুক্ত থাকবে, কারণ এই প্লাগইনটি সেই server block-টিকে এডিট করে যা আপনার অনুরোধ করা ডোমেইনের সাথে মিলে যায়।

কোন tor প্যাকেজ ব্যবহার করবেন এবং সার্ভিস কি (service key) সুরক্ষিত রাখা

Ubuntu আর্কাইভের tor প্যাকেজটি এই কাজের জন্য উপযুক্ত এবং এতে বাড়তি কোনো সেটআপের প্রয়োজন হয় না। এটি বর্তমান স্টেবল সিরিজের চেয়ে কিছুটা পিছিয়ে থাকে, তাই আপনি যদি দীর্ঘমেয়াদে কোনো সার্ভিস চালাতে চান, তবে Tor Project-এর নিজস্ব Debian রিপোজিটরি ব্যবহার করুন এবং apt-এর মাধ্যমে অন্যান্য সবকিছুর সাথে এটিকে আপডেট হতে দিন। আগস্ট 2026 অনুযায়ী, নির্দেশিত ধাপগুলো নিচে দেওয়া হলো:

sudo apt install apt-transport-https
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

/etc/apt/sources.list.d/tor.sources লিখুন এবং lsb_release -c থেকে আপনার রিলিজ কোডনেম দিয়ে suite প্রতিস্থাপন করুন:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
sudo apt update
sudo apt install tor deb.torproject.org-keyring

deb.torproject.org-keyring প্যাকেজটি সাইনিং কি (signing key) আপডেট রাখে, যাতে এক বছর পর রিপোজিটরি ভেরিফিকেশন বন্ধ না হয়ে যায়। যেকোনো একটি সোর্স বেছে নিন এবং সেটিই ব্যবহার করুন। আর্কাইভ প্যাকেজ এবং রিপোজিটরি প্যাকেজের ভার্সন আলাদা হয়, তাই উভয়টি সক্রিয় থাকলে আপগ্রেডের সময় apt আপনাকে একটি থেকে অন্যটিতে সরিয়ে নিতে পারে।

HiddenServiceDir ডিরেক্টরিটি আপনার সার্ভিসের পরিচয় বহন করে। ওই ডিরেক্টরির hs_ed25519_secret_key ফাইলটিই আপনার onion অ্যাড্রেস, কারণ এই অ্যাড্রেসটি কি-পেয়ারের পাবলিক অংশ। ফাইলটি হারিয়ে ফেললে অ্যাড্রেসটি চিরতরে হারিয়ে যাবে, কারণ এটি পুনরায় ইস্যু করার মতো কোনো কর্তৃপক্ষ নেই। ফাইলটি অসতর্কভাবে কোথাও কপি করে রাখলে যে কেউ সেই কপি ব্যবহার করে আপনার onion সার্ভিস চালাতে পারবে।

অন্য কোনো ব্যবহারকারী পড়তে পারে এমন ডিরেক্টরি tor ব্যবহার করতে অস্বীকার করে। অন্য কিছু পরীক্ষা করার আগে এর মোড এবং মালিকানা যাচাই করুন:

sudo ls -ld /var/lib/tor/onion_site
sudo -u debian-tor cat /var/lib/tor/onion_site/hostname

লিস্টিংয়ে drwx------ দেখা উচিত এবং Debian ও Ubuntu-তে এর মালিক ও গ্রুপ হতে হবে debian-tor। এর চেয়ে বেশি পারমিশন থাকলে, tor Permissions on directory /var/lib/tor/onion_site/ are too permissive.-এর মতো একটি লগ দেখাবে এবং সার্ভিসটি চালু হবে না। sudo chown -R debian-tor:debian-tor /var/lib/tor/onion_site এবং এরপর sudo chmod 700 /var/lib/tor/onion_site চালিয়ে এটি ঠিক করুন, sudo systemctl restart tor দিয়ে রিস্টার্ট করুন এবং sudo journalctl -u tor@default -n 30 দিয়ে ফলাফল দেখুন।

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

অ্যানালিটিক্স এবং থার্ড-পার্টি অ্যাসেট হেডার থেকে বেশি তথ্য ফাঁস করে

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

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

সবকিছু একই অরিজিন থেকে সার্ভ করুন। আপনার ফন্টগুলো নিজে হোস্ট করুন। হোস্ট করা অ্যানালিটিক্স ট্যাগ বাদ দিন অথবা সেগুলোকে আপনার নিজের সার্ভারে সরিয়ে নিন, যেখানে VPS-এ সেলফ-হোস্টেড অ্যানালিটিক্স অনুরোধটিকে অনিয়নের ভেতরেই রাখে। Tor Browser-এর ডিফল্ট সেটিংস যেকোনো অ্যানালিটিক্স টুলের সংগৃহীত তথ্যের অনেক কিছুই ব্লক বা অকার্যকর করে দেবে বলে ধরে নিন, এবং এটিই সঠিক ফলাফল। যদি কোনো পেজ থার্ড-পার্টি স্ক্রিপ্ট ছাড়া কাজ করতে না পারে, তবে সেই পেজটি অনিয়নে প্রকাশ করবেন না।

একটি পেজ প্রকৃতপক্ষে কী কী পুল করে তার তালিকা করুন:

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -oE '(src|href)="https?://[^"]+"' | sort -u

এটি যে প্রতিটি লাইন প্রিন্ট করে তা হলো একটি অ্যাবসোলিউট URL, যা আপনার পেজ ব্রাউজারকে ফেচ করতে বলে। আপনার নিজের অনিয়ন অ্যাড্রেস ছাড়া অন্য যেকোনো কিছুই হলো একটি আউটবাউন্ড ক্লিয়ারনেট অনুরোধ, যা আপনি আপনার পাঠকদের আপনার পক্ষ থেকে করতে বলছেন।

হুমকির মডেল, সহজ ভাষায়

Onion-Location একটি onion service খুঁজে পাওয়া সহজ করে দেয়, এটি কেবল এটুকুই করে। এটি অপারেটর হিসেবে আপনাকে বেনামী করে না, কারণ আপনার clearnet ডোমেইনে এখনও রেজিস্ট্রার রেকর্ড, DNS রেকর্ড, Certificate Transparency লগে প্রকাশিত সার্টিফিকেট এবং আপনার বিলিংয়ের বিবরণসহ একটি VPS অ্যাকাউন্ট থাকে। এটি onion-কেও বেনামী করে না, কারণ আপনি সেই clearnet ডোমেইন থেকে একটি স্থায়ী পাবলিক ঘোষণা দিয়েছেন যে এই দুটি ঠিকানাই একই সাইট। এর সুবিধা পায় পাঠক: যে কেউ Tor ব্যবহার করে এলে সে Tor-এর ভেতরেই থাকতে পারে, যেখানে পথে কোনো exit node থাকে না এবং আপনার ডোমেইনের জন্য কোনো DNS লুকআপের প্রয়োজন হয় না। যদি আপনার লক্ষ্য এমন একটি onion service হয় যেখানে কেউ আপনার সাথে সংযোগ করতে পারবে না, তবে এই হেডার প্রকাশ করবেন না এবং একই মেশিনে দুটি কপি চালাবেন না।

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

পুরো সেটআপটি একবার যাচাই করুন

নিচের কমান্ডগুলো ক্রমানুসারে চালান। প্রতিটির একটি ফলাফল আপনি দেখতে পাবেন।

  1. curl -sI https://example.com/ | grep -i onion-location হেডারটি প্রিন্ট করে।
  2. একই কমান্ড একটি URL-এর বিপরীতে চালালে যা 404 এরর দেয়, সেটিও একই হেডার প্রিন্ট করে।
  3. curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ আপনার পেজটি রিটার্ন করে।
  4. সেই আউটপুট থেকে আপনার clearnet ডোমেইনটি grep করলে কোনো ফলাফল পাওয়া যায় না।
  5. https://example.com-এ Tor Browser ব্যবহার করলে .onion available পিলটি দেখা যায়।

যদি 1 থেকে 4 পর্যন্ত ধাপগুলো সফল হয় কিন্তু 5 নম্বর ধাপটি না হয়, তবে এর কারণ সাধারণত হেডারটি যেখান থেকে সার্ভ করা হচ্ছে সেখানে থাকে, হেডারের নিজের মধ্যে নয়। ব্রাউজারটি সত্যিই HTTPS পেজ লোড করেছে কি না এবং কোনো ক্যাশড রিডাইরেক্ট (cached redirect) লোড করেনি তা নিশ্চিত করুন। এরপর আপনি যে নির্দিষ্ট URL-টি খুলেছেন তার বিপরীতে curl -sI চালান, কারণ সেই নির্দিষ্ট পাথে থাকা কোনো location ব্লক সার্ভার-লেভেলের নির্দেশনাকে বাতিল করে দিতে পারে।

FAQ

Tor Browser কেন ".onion available" পিলটি দেখায় না?

প্রথমে তিনটি নথিভুক্ত প্রয়োজনীয়তা পরীক্ষা করুন। মানটি অবশ্যই একটি পূর্ণ URL হতে হবে যার সাথে http: বা https: স্কিম এবং একটি .onion হোস্ট থাকবে, তাই স্কিমবিহীন সাধারণ ঠিকানা কাজ করবে না এবং কোনো এররও দেখাবে না। পেজটি অবশ্যই HTTPS-এর মাধ্যমে পরিবেশন করতে হবে, তাই আপনার port 80 রিডাইরেক্ট ব্লকে সেট করা হেডার কখনোই পড়া হবে না। এছাড়া পেজটি নিজে কোনো অনিয়ন সাইট হতে পারবে না। এরপর nginx পরীক্ষা করুন: ম্যাচিং location ব্লকের ভেতরে যেকোনো add_header সার্ভার লেভেলের প্রতিটি add_header-কে বাতিল করে দেয়, এবং always ফ্ল্যাগ ছাড়া 404 এবং 500 রেসপন্সে হেডারটি অনুপস্থিত থাকে। ব্রাউজারে লোড করা সঠিক URL-এর বিপরীতে curl -sI চালান এবং নিশ্চিত করুন যে হেডারটি আসলেই নেটওয়ার্কে পাঠানো হচ্ছে।

আমার অনিয়ন সাইটের জন্য কি TLS সার্টিফিকেট প্রয়োজন?

না। একটি v3 অনিয়ন ঠিকানা সার্ভিসটির পাবলিক কি (public key) থেকে তৈরি হয়, তাই কোনো HTTP অনুরোধ পাঠানোর আগেই সার্কিটটি সেই নির্দিষ্ট সার্ভিসের সাথে অথেন্টিকেট হয় এবং এন্ড-টু-এন্ড এনক্রিপ্ট করা থাকে। অনিয়ন সার্ভিসের ভেতরে সাধারণ HTTP ব্যবহার করাই স্বাভাবিক কনফিগারেশন। যা আপনাকে অবশ্যই এড়াতে হবে তা হলো অনিয়ন সাইটে আপনার ক্লিয়ারনেট (clearnet) সার্টিফিকেট প্রদর্শন করা। এর সাবজেক্ট অল্টারনেটিভ নেম (subject alternative names)-এ আপনার ডোমেইন তালিকাভুক্ত থাকে, যা ব্রাউজারে নাম অমিলের সতর্কতা (name mismatch warning) তৈরি করে এবং প্রতিটি ভিজিটরকে নিশ্চিত করে যে সাইট দুটি একই মেশিনে চলছে।

Onion-Location প্রকাশ করা কি আমার সাইটকে বেনামী (anonymous) করে?

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

আমি কি HTTP হেডারের পরিবর্তে মেটা ট্যাগ ব্যবহার করতে পারি?

হ্যাঁ, যখন আপনি রেসপন্স হেডার সেট করতে পারেন না, যা স্ট্যাটিক হোস্টের ক্ষেত্রে সাধারণ পরিস্থিতি। ডকুমেন্টের হেডের ভেতরে <meta http-equiv="onion-location" content="http://youraddress.onion" /> বসান। একই তিনটি প্রয়োজনীয়তা এখানেও প্রযোজ্য, তাই পেজটি অবশ্যই HTTPS হতে হবে এবং অনিয়ন সাইট হওয়া যাবে না। একমাত্র আসল পার্থক্য হলো, ট্যাগটিতে কোনো পাথ ছাড়া একটি নির্দিষ্ট ঠিকানা থাকে, যেখানে nginx হেডার $request_uri যুক্ত করতে পারে এবং ভিজিটরকে হোম পেজের পরিবর্তে অনিয়ন সাইটে সেই একই পেজটি অফার করতে পারে।

#tor#onion-service#nginx#privacy#headers