VPS पर अपनी .onion वेबसाइट कैसे होस्ट करें

आप क्या बना रहे हैं

एक onion site एक सामान्य वेब सर्वर है जो केवल Tor नेटवर्क पर ही प्रतिक्रिया देता है। tor इंस्टॉल करें, /etc/tor/torrc में दो लाइनें जोड़ें, tor द्वारा आपके लिए लिखे गए पते को पढ़ें, और फिर nginx को 127.0.0.1 पर bind करें ताकि public IP पर कोई प्रतिक्रिया न मिले। इंस्टॉलेशन का काम दस मिनट में हो जाता है। इस गाइड का बाकी हिस्सा लीक की सूची है, क्योंकि एक onion site के विफल होने का सामान्य कारण यह है कि उसका अपना कॉन्फ़िगरेशन सीधे ऑपरेटर की ओर इशारा करता है।

Tor की शुरुआत "the onion router" के रूप में हुई थी, और एक onion service वह सेवा है जिसे आप केवल इसके माध्यम से ही एक्सेस कर सकते हैं। एक version 3 पता 56 वर्णों का होता है जिसके बाद .onion आता है, और ये वर्ण सेवा की ed25519 public key, एक चेकसम और एक version byte होते हैं, जिन्हें base32 में एन्कोड किया जाता है। Version 2 पते (16 वर्ण) 2021 में नेटवर्क से हटा दिए गए थे, इसलिए आज आप जो भी जनरेट करेंगे वह v3 होगा। पता ही कुंजी (key) है, जिसके दो परिणाम होते हैं। कनेक्शन end-to-end एन्क्रिप्टेड और प्रमाणित होता है जिसमें किसी certificate authority की आवश्यकता नहीं होती, और key फाइल खोने का मतलब है पता हमेशा के लिए खो देना।

आपका सर्वर कभी भी इनबाउंड कनेक्शन स्वीकार नहीं करता है। Tor कुछ relays को introduction points के रूप में चुनता है, directory servers पर एक हस्ताक्षरित डिस्क्रिप्टर अपलोड करता है, और प्रत्येक आगंतुक से उस rendezvous relay पर मिलता है जिसे आगंतुक ने चुना है। उन सभी कनेक्शनों में से प्रत्येक आपके बॉक्स से आउटबाउंड होता है। इसमें कोई पोर्ट खोलने या DNS रिकॉर्ड प्रकाशित करने की आवश्यकता नहीं है। यदि आप चाहते हैं कि वही VPS नेटवर्क को कुछ वापस दे, तो वह विपरीत प्रकृति का एक अलग कार्य है, क्योंकि an obfs4 bridge सेंसर किए गए क्लाइंट्स से इनबाउंड कनेक्शन लेता है और उसे एक reachable पोर्ट की आवश्यकता होती है।

Tor Project repository से Tor install करना

Ubuntu के universe में tor package उपलब्ध है, लेकिन release freeze होने के समय जो version current था, यह package उसी के आसपास बना रहता है। Tor Project का अपना repository current stable release को track करता है। आपके पते पर आपका नियंत्रण बना रहे या नहीं, यह तय करने वाले software के लिए यही version चाहिए। किसी distribution में package का उपलब्ध होना यह नहीं बताता कि उस पर अभी भी काम हो रहा है। Self-host किए जाने वाले किसी भी software के लिए यह जाँच करना उपयोगी है, क्योंकि Searx पर 2023 के बाद कोई code commit नहीं हुआ है, जबकि SearXNG उस project को आगे बढ़ा रहा है।

sudo apt update
sudo apt install -y apt-transport-https gnupg wget
KEYURL=https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc
wget -qO- "$KEYURL" | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Repository entry deb822 format का उपयोग करती है, और Suites के स्थान पर आपके Ubuntu का codename होना चाहिए। इसे टाइप करने के बजाय /etc/os-release से पढ़ें, क्योंकि गलत codename डालने पर repository resolve तो हो जाएगी, लेकिन आपके release के लिए कोई package नहीं मिलेगा।

. /etc/os-release
sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $VERSION_CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring

deb.torproject.org-keyring package signing key को current रखता है, ताकि key rotation होने पर भविष्य में apt update में कोई समस्या न आए। जाँचें कि tor start हो गया है और network से जुड़ गया है:

tor --version
sudo journalctl -u tor@default -n 20

Journal का अंत Bootstrapped 100% (done): Done के साथ होना चाहिए। यदि tor Bootstrapped 10% पर अटक जाता है, तो इसका मतलब है कि कोई outbound path नहीं है। अपने provider के network firewall और अपने स्वयं के egress rules की जाँच करें: sudo ufw status verbose में default के रूप में allow (outgoing) दिखना चाहिए।

यहाँ से आगे दो नाम महत्वपूर्ण हैं। Package, tor को debian-tor user के रूप में चलाता है, और running unit का नाम tor@default.service है, क्योंकि Debian और Ubuntu पर tor.service, instance के चारों ओर एक wrapper की तरह काम करता है। status और logs के लिए हमेशा instance name का उपयोग करें, इससे आपको वास्तविक process की जानकारी मिलेगी।

torrc में onion service को कॉन्फ़िगर करें

/etc/tor/torrc में निम्नलिखित दो लाइनें जोड़ें:

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

HiddenServiceDir वह स्थान है जहाँ Tor इस सर्विस के लिए keys और address रखता है। इसे स्वयं न बनाएँ। Tor इसे start होने पर आवश्यक owner और mode के साथ बनाता है। यदि आप root के रूप में directory बनाते हैं, तो नीचे दी गई सूची में पहली विफलता (failure) उत्पन्न होगी।

HiddenServicePort के दो भाग होते हैं, और उन्हें आपस में मिला देना सबसे आम पहली गलती है। पहली संख्या वह port है जिससे visitor tunnel के अंदर connect होता है, इसलिए 80 वही है जिसकी लोग अपेक्षा करते हैं और इसे बदलने का कोई कारण नहीं है। दूसरा भाग वह local address है जहाँ Tor उस traffic को forward करता है। एक साधारण HiddenServicePort 80 को 127.0.0.1:80 पर forward किया जाता है, इसलिए address को पूरा लिखना और एक high port का उपयोग करना onion vhost को 80 पर listening किसी भी अन्य चीज़ से अलग रखता है।

sudo systemctl restart tor@default
sudo ls -l /var/lib/tor/onion_site/

इस सूची में hostname, hs_ed25519_public_key, hs_ed25519_secret_key और एक खाली authorized_clients directory होनी चाहिए।

अपना .onion पता पढ़ें

sudo cat /var/lib/tor/onion_site/hostname

एक पंक्ति दिखाई देगी: 56 base32 वर्ण और .onion। यह स्ट्रिंग साइट की पूर्ण पहचान है। कोई भी इसे असाइन नहीं करता, कोई भी इसे स्थानांतरित नहीं कर सकता, और जब तक आपके पास key file है, कोई भी इसे आपसे छीन नहीं सकता। इसे अभी कॉपी करें, क्योंकि नीचे दिए गए प्रत्येक कॉन्फ़िगरेशन के लिए इसकी आवश्यकता होगी। इस गाइड का शेष भाग इसे <your-address>.onion के रूप में लिखता है।

nginx को 127.0.0.1 पर bind करके साइट सर्व करें

sudo apt install -y nginx
sudo install -d -m 755 /srv/onion

/etc/nginx/sites-available/onion लिखें:

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

    root /srv/onion;
    index index.html;

    server_tokens off;
    etag off;
    access_log off;
    error_log /var/log/nginx/onion.error.log error;
}

echo '<h1>hello from the onion</h1>' | sudo tee /srv/onion/index.html
sudo ln -s /etc/nginx/sites-available/onion /etc/nginx/sites-enabled/onion
sudo nginx -t
sudo systemctl reload nginx

अब सर्वर से दो चीजें सिद्ध करें। पहली यह कि nginx onion नाम के लिए उत्तर देता है, जो कि सटीक Host हेडर है जिसे tor भेजेगा:

curl -s -H 'Host: <your-address>.onion' http://127.0.0.1:8080/

दूसरी यह कि यह केवल वहीं उत्तर देता है और कहीं और नहीं:

sudo ss -tlnp | grep 8080

एड्रेस कॉलम में 127.0.0.1:8080 लिखा होना चाहिए। यदि इसमें 0.0.0.0:8080 या *:8080 लिखा है, तो आपकी onion साइट पब्लिक इंटरनेट पर भी उपलब्ध है, जो लीक सूची में पहला आइटम है। बिना एड्रेस वाली listen 8080; लाइन हर इंटरफेस को bind करती है, और यही डिफ़ॉल्ट है।

Tor Browser में एड्रेस खोलें। पहली बार लोड होने में कुछ सेकंड लगते हैं क्योंकि क्लाइंट आपका डिस्क्रिप्टर फेच करता है और एक रेंडेज़वस सर्किट बनाता है।

Tor Project का अपना डॉक्यूमेंटेशन लूपबैक पोर्ट के बजाय unix socket को प्राथमिकता देता है: HiddenServicePort 80 unix:/var/run/tor/onion_site.sock, जिसमें nginx उस पाथ पर लिसन करता है। एक सॉकेट तक किसी अन्य होस्ट से बिल्कुल भी नहीं पहुँचा जा सकता, भले ही बाद में बॉक्स में दूसरा इंटरफेस जुड़ जाए। इसकी कीमत फाइल अनुमतियाँ (permissions) हैं, क्योंकि nginx सॉकेट बनाता है और tor इससे debian-tor के रूप में जुड़ता है, इसलिए दोनों उपयोगकर्ताओं को डायरेक्टरी पर सहमत होना पड़ता है। सत्यापित ss आउटपुट के साथ लूपबैक को सही ढंग से सेट करना आसान है, और यह गाइड का शेष भाग इसी पर आधारित है।

साइट के लूपबैक पर होने के कारण, बॉक्स को इसके लिए किसी इनबाउंड नियम की आवश्यकता नहीं है। अपने लिए 22 को खुला रखें और बाकी को अस्वीकार करें (VPS पर सेट करने योग्य ufw डिफ़ॉल्ट्स)। याद रखें कि फ़ायरवॉल उस सर्विस को पूर्ववत नहीं करता जो 0.0.0.0 पर bind होती है, यह केवल उन पैकेटों को फ़िल्टर करता है जो फ़ायरवॉल तक पहुँचते हैं। कंटेनर इसे और अधिक गंभीर बना देते हैं, क्योंकि Docker पोर्ट पब्लिश करना ufw से पहले iptables नियम लिखता है, इसलिए -p 8080:80 आपके onion बैकएंड को पब्लिक IP पर डाल देता है जबकि ufw अभी भी पोर्ट को अस्वीकृत दिखाता है। कंटेनर पोर्ट्स को -p 127.0.0.1:8080:80 के रूप में पब्लिश करें।

वे लीक्स जो एक onion site की पहचान उजागर कर देते हैं

Tor यह छिपाता है कि सर्वर कहाँ है। Tor में ऐसा कुछ नहीं है जो यह छिपा सके कि सर्वर क्या कह रहा है। नीचे दी गई हर चीज़ वह है जिसे आपका अपना stack प्रकाशित करता है। किसी भी privacy tool की प्रतिष्ठा के बजाय उसकी वास्तविक सीमाओं को समझना वही आदत है जो आपको यह बताती है कि एक self-hosted SearXNG क्या छिपाता है, जो कि search engines से आपका IP छिपाने के अलावा और कुछ नहीं है।

वही साइट जो आपके public IP पर जवाब देती है

यह वह गलती है जो लोगों को फँसाती है। Scanners लगातार हर routable address के HTTP response को index करते हैं, और वे परिणाम सार्वजनिक और खोजने योग्य होते हैं। यदि आप एक ही पेज को अपने public IP और onion address दोनों पर serve करते हैं, तो उन्हें जोड़ना केवल एक query का काम है: समान title, समान favicon hash, समान ETag, समान header order। ऊपर दी गई listen 127.0.0.1:8080; लाइन इसका समाधान है। इसे सर्वर से नहीं, बल्कि किसी अन्य मशीन से verify करें:

curl -sv --max-time 5 http://<your-public-ip>:8080/

Connection refused या timeout ही सही परिणाम है। किसी भी HTML का मतलब है कि साइट सार्वजनिक है। यदि बॉक्स पर clearnet साइट भी चल रही है, तो उस vhost को अपना root दें और public listener पर एक स्पष्ट default_server block रखें, ताकि कोई भी बेमेल Host header कभी भी onion vhost तक न पहुँच सके।

Version banners

curl -sI http://127.0.0.1:8080/ | grep -i '^server'

एक default nginx Server: nginx/1.24.0 के साथ जवाब देता है। वह version string, अन्य headers के सटीक क्रम के साथ मिलकर, एक ऐसा fingerprint है जो आपके onion को आपके clearnet host से मिला देता है। server_tokens off; इसे घटाकर Server: nginx कर देता है। यह header को हटाता नहीं है, और nginx में इसे हटाने के लिए कोई built-in directive नहीं है, इसलिए यदि आप इसे हटाना चाहते हैं तो headers-more module ही सामान्य समाधान है। PHP तब तक X-Powered-By जोड़ता है जब तक आप expose_php = Off सेट नहीं करते। etag off; भी इसी सूची में आता है, क्योंकि nginx फाइल के modification time और size से ETag बनाता है, इसलिए दो सर्वरों पर कॉपी की गई समान फाइलें दोनों पर एक ही ETag देती हैं।

आपके clearnet domain की ओर इशारा करते हुए Absolute URLs

एक rel="canonical" tag, एक Open Graph og:url, एक RSS feed, एक sitemap, एक password reset email, या hardcoded logo URL। इनमें से कोई भी onion पर serve किए गए पेज के अंदर clearnet साइट का नाम ले सकता है। /static/logo.svg जैसे root-relative paths का उपयोग करें, और application को constant के बजाय request host से अपना base URL पढ़ने दें। Redirects भी दूसरी जगह पर वही bug हैं: catch-all block में return 301 https://example.com$request_uri; onion visitor को आपके असली domain पर भेज देता है, और Location header उन्हें सीधे जवाब दे देता है।

Clearnet साइट के साथ साझा किया गया TLS certificate

एक onion address खुद को प्रमाणित करता है, क्योंकि address ही public key है, इसलिए onion connection पर http:// पहले से ही end-to-end encrypted होता है और Tor Browser इसे एक secure context मानता है। Onion vhost पर अपना मौजूदा certificate install करना दोनों के बीच संबंध को प्रकाशित करता है, क्योंकि हर publicly trusted certificate Certificate Transparency logs में दर्ज होता है, और वे logs सार्वजनिक, स्थायी और नाम से खोजने योग्य होते हैं। Let's Encrypt certificates को clearnet vhost पर रखें और onion vhost को plain HTTP पर छोड़ दें।

Third-party fonts और analytics

CDN (content delivery network) से कोई font, या कोई analytics script। Visitor का browser हर एक को सीधे fetch करता है, इसलिए third party को पता चल जाता है कि किसी ने आपका पेज लोड किया है और आमतौर पर यह भी कि कौन सा पेज, और Tor Browser के सख्त security levels वैसे भी request को block कर देते हैं, जिससे layout बिगड़ जाता है। पेज को जिन assets की आवश्यकता है, उन सभी को self-host करें।

Host header mismatch

यदि server_name उस Host header से मेल नहीं खाता है जिसे tor भेजता है, तो nginx उस listen address के लिए default server पर वापस चला जाता है। एक vhost वाले बॉक्स पर यह अदृश्य होता है, क्योंकि एकमात्र server block ही default होता है। बाद में एक clearnet vhost जोड़ें और onion requests उस पर लैंड करना शुरू कर सकती हैं, जो अपने canonical tags और redirects के साथ आती हैं। हर nginx बदलाव के बाद curl -H 'Host: ...' जांच को फिर से चलाएं, और परिणाम में अपने असली domain के लिए grep करें:

curl -s -H 'Host: <your-address>.onion' http://127.0.0.1:8080/ | grep -o 'https\?://[^"]*' | sort -u

यह जानना कि कौन सी process किस socket की मालिक है, इस काम का अधिकांश हिस्सा है (Linux पर ports और listening sockets कैसे काम करते हैं)।

Logs में क्या बचता है

हर request 127.0.0.1 से आती है, इसलिए nginx के पास रिकॉर्ड करने के लिए कोई visitor address नहीं होता और access_log off; पर आपका कोई खर्च नहीं होता। इसके ऊपर का application एक अलग मामला है, क्योंकि एक order, email address या uploaded फाइल का metadata संभालना आपकी जिम्मेदारी है। आपकी अपनी आदतें भी मायने रखती हैं: बिना hardened login के बॉक्स को administer करना Tor द्वारा सुरक्षित किसी भी चीज़ के दायरे से बाहर है, इसलिए उसी VPS पर SSH hardening को इस build का हिस्सा मानें।

Private key का बैकअप लें, क्योंकि यही आपका पता है

/var/lib/tor/onion_site/hs_ed25519_secret_key वह service है। इसके लिए कोई registrar या recovery की सुविधा नहीं है। यदि आप इसे खो देते हैं, तो आपका पता हमेशा के लिए समाप्त हो जाएगा। यदि आप इसकी प्रतिलिपि बनाते हैं, तो जिसके पास भी वह प्रतिलिपि होगी, वह आपके पते पर अपनी सामग्री होस्ट कर सकेगा, और आपके पास उसे रद्द करने का कोई तरीका नहीं होगा।

sudo systemctl stop tor@default
sudo tar -C /var/lib/tor -czf onion-keys.tgz onion_site
sudo chmod 600 onion-keys.tgz
sudo systemctl start tor@default

उस archive (gpg -c onion-keys.tgz) को encrypt करें और उसे सर्वर से बाहर किसी सुरक्षित स्थान पर ले जाएँ। एक नए VPS पर restore करने के लिए उस archive की आवश्यकता होती है और साथ ही उस ownership की जो tor अपेक्षा करता है:

sudo systemctl stop tor@default
sudo tar -C /var/lib/tor -xzf onion-keys.tgz
sudo chown -R debian-tor:debian-tor /var/lib/tor/onion_site
sudo chmod 700 /var/lib/tor/onion_site
sudo systemctl start tor@default
sudo cat /var/lib/tor/onion_site/hostname

नया hardware चालू होने के एक या दो मिनट बाद, जब tor descriptor को फिर से publish कर देता है, तो वही पुराना पता वापस आ जाता है। पूरी migration प्रक्रिया बस इतनी ही है: इसमें न तो कोई DNS बदलाव करना पड़ता है और न ही किसी certificate को फिर से जारी करने की आवश्यकता होती है।

Onion-Location, जब साइट clearnet पर भी उपलब्ध हो

यदि onion एड्रेस गोपनीयता के बजाय सुविधा के लिए है, तो इसे clearnet vhost से advertise करें:

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

Tor Browser इसके बाद एड्रेस बार में एक .onion available बटन दिखाता है और स्विच करने का विकल्प देता है। यह हेडर केवल तभी मान्य होता है जब clearnet पेज HTTPS पर सर्व किया जा रहा हो और मान एक वैध onion URL हो।

यहाँ nginx का एक नियम ध्यान देने योग्य है। add_header डायरेक्टिव्स को एक location ब्लॉक में तभी इनहेरिट किया जाता है जब उस ब्लॉक में अपना कोई डायरेक्टिव न हो। इसलिए, यदि किसी location में अपना स्वयं का add_header है, तो वह Onion-Location को चुपचाप हटा देता है। इसे वहाँ दोहराएँ, या सभी रिस्पॉन्स हेडर्स को एक ही स्थान पर रखें। इस हेडर को पब्लिश करने से दोनों साइटें जानबूझकर आपस में जुड़ जाती हैं, जो कि मिरर के लिए सही है, लेकिन किसी ऐसी चीज़ के लिए गलत है जिसे अलग रखना है।

Vanity addresses

mkp224o तब तक key pairs generate करता है जब तक कि कोई ऐसा address न मिल जाए जो आपके द्वारा मांगे गए prefix से शुरू होता हो। यह एक brute force search है, इसलिए prefix और आपके प्रतीक्षा करने के समय के अलावा इसमें कॉन्फ़िगर करने के लिए कुछ भी नहीं है।

sudo apt install -y git gcc libc6-dev libsodium-dev make autoconf
git clone https://github.com/cathugger/mkp224o
cd mkp224o
./autogen.sh
./configure --enable-amd64-51-30k
make
./mkp224o -d onionkeys blog

प्रत्येक hit onionkeys/<address>.onion/ में जाकर जमा होती है, जिसमें hostname और hs_ed25519_secret_key होते हैं। इसे install करने के लिए tor को stop करें, उस directory को अपने HiddenServiceDir पर copy करें, और फिर ऊपर बताए गए restore की तरह ही वही chown और chmod 700 लागू करें।

Prefix की लंबाई ही इसकी पूरी लागत है। Address base32 में होता है, इसलिए आपके द्वारा मांगे गए प्रत्येक अतिरिक्त character के साथ keys की अपेक्षित संख्या 32 गुना बढ़ जाती है। एक छोटा prefix laptop पर जल्दी पूरा हो जाता है। एक लंबा prefix आपके पास मौजूद किसी भी उपकरण पर पूरा नहीं होगा। एक vanity prefix पाठकों को पूरे address के बजाय केवल शुरुआती कुछ characters को पहचानने के लिए भी प्रेरित करता है, और इसी आदत का फायदा उठाकर onion sites की phishing प्रतियां बनाई जाती हैं।

विफलता के प्रकार और दिखाई देने वाले संदेश

रीस्टार्ट के बाद hostname फाइल नहीं मिलती। Tor शुरू नहीं हुआ, या उसने डायरेक्टरी को स्वीकार करने से मना कर दिया। sudo journalctl -u tor@default -n 50 इसका कारण बताता है:

/var/lib/tor/onion_site/ is not owned by this user (debian-tor, 108) but by root (0). Perhaps you are running Tor as the wrong user?

हाथ से बनाई गई डायरेक्टरी ऐसी ही दिखती है। इसके ओनरशिप और मोड को ठीक करें, या डायरेक्टरी को डिलीट कर दें ताकि Tor इसे खुद बना सके।

Tor Browser में Onionsite Not Found (0xF0) दिखाई देता है। क्लाइंट डिस्क्रिप्टर प्राप्त नहीं कर सका, इसलिए नेटवर्क के अनुसार उस पते पर कुछ भी प्रकाशित नहीं है। पुष्टि करें कि Tor चल रहा है और बूटस्ट्रैप हो चुका है, टाइप किए गए पते की तुलना sudo cat /var/lib/tor/onion_site/hostname से अक्षर-दर-अक्षर करें, और फिर घड़ी की जाँच करें। डिस्क्रिप्टर को प्रकाशित और मान्य करने के लिए Tor को सटीक समय की आवश्यकता होती है, और timedatectl को System clock synchronized: yes रिपोर्ट करना चाहिए।

पता रिज़ॉल्व हो जाता है लेकिन पेज लोड नहीं होता। Tor ने रेंडेज़वस (rendezvous) पूरा कर लिया लेकिन अंतिम हॉप पर विफल हो गया, जो Tor से Nginx तक का है। यह हॉप लोकल है इसलिए Tor लॉग शांत रहता है। सर्वर पर curl -sI http://127.0.0.1:8080/ चलाएं। Connection refused का मतलब है कि Nginx बंद है या किसी ऐसे पते पर लिसन कर रहा है जो HiddenServicePort द्वारा इंगित पते से अलग है।

पेज लोड होता है और हर लिंक आपके वास्तविक डोमेन पर जाता है। टेम्पलेट्स में एब्सोल्यूट URL मौजूद हैं। ऊपर दिया गया grep -o 'https\?://[^"]*' चेक चलाएं और पता साझा करने से पहले जो भी आउटपुट मिले उसे ठीक करें।

यह काम करता है, फिर रीबूट के बाद बंद हो जाता है। साइट पर निर्भर होने से पहले एक बार जानबूझकर बॉक्स को रीबूट करें, फिर sudo systemctl status tor@default और sudo systemctl status nginx चलाएं। किसी के द्वारा हाथ से शुरू की गई सर्विस और इनेबल की गई सर्विस रीस्टार्ट होने तक एक जैसी ही दिखती हैं।

FAQ

क्या मुझे Tor onion service के लिए अपने firewall में कोई port खोलने की आवश्यकता है?

नहीं। tor daemon केवल outbound connections बनाता है, जैसे directory servers, introduction points और प्रत्येक rendezvous relay के लिए, इसलिए किसी inbound rule की आवश्यकता नहीं होती है और web server स्वयं 127.0.0.1 पर listen करता है। incoming traffic के लिए ufw को default deny पर रखें और केवल SSH को अनुमति दें। इसी विशेषता के कारण, एक onion service NAT (network address translation) के पीछे वाली मशीन से भी काम करती है, भले ही उसका कोई public IP न हो।

मैं Tor Browser में अपने .onion address तक क्यों नहीं पहुँच पा रहा हूँ?

सर्वर से बाहर की ओर जाँच करें। sudo journalctl -u tor@default -n 50 को Bootstrapped 100% (done): Done दिखाना चाहिए, फिर सर्वर पर curl -sI http://127.0.0.1:8080/ को एक status line दिखानी चाहिए, और अंत में आपके द्वारा टाइप किए गए address की तुलना hostname फ़ाइल से करें, क्योंकि एक गलत character का मतलब पूरी तरह से एक अलग service होता है। Onionsite Not Found (0xF0) का अर्थ है कि address के लिए कोई descriptor नहीं मिला, जिसका सामान्यतः मतलब है कि tor चल नहीं रहा है या system clock गलत है।

क्या मैं अपनी onion site को एक नए सर्वर पर ले जा सकता हूँ और वही address बनाए रख सकता हूँ?

हाँ। address hs_ed25519_secret_key से प्राप्त होता है, इसलिए पूरी HiddenServiceDir को नई मशीन पर कॉपी करें, इसे debian-tor ownership और 700 mode पर सेट करें, और tor को start करें। descriptor के पुनः प्रकाशित होते ही address फिर से live हो जाता है, और इसमें update करने के लिए कोई DNS record नहीं होता है। यदि वह फ़ाइल खो गई तो address को पुनः प्राप्त नहीं किया जा सकता है, इसलिए इसे बनाने के दिन ही इसे encrypt करके सर्वर से बाहर backup ले लें।

क्या एक onion site को HTTPS certificate की आवश्यकता होती है?

नहीं। 56-character वाला address service की public key होता है, इसलिए connection पहले से ही end-to-end encrypted और authenticated होता है, और Tor Browser .onion नाम पर http:// को एक secure context मानता है। अपने clearnet certificate को onion vhost पर फिर से उपयोग करना कुछ न करने से भी बदतर है, क्योंकि Certificate Transparency logs सार्वजनिक होते हैं और स्थायी रूप से रिकॉर्ड करते हैं कि कौन से नाम एक ही certificate साझा करते हैं। .onion नाम के लिए certificate खरीदने का एकमात्र कारण CA से मिलने वाला brand assurance है, और वह लिंक डिज़ाइन के अनुसार सार्वजनिक होता है।