SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-13

آموزش راه اندازی سایت onion روی VPS

با نصب tor و nginx روی Ubuntu یک سرویس v3 onion بسازید. این راهنما به شما نشان می‌دهد چگونه وب‌سرور را روی loopback تنظیم کنید تا از نشت IP عمومی و شناسایی هویت جلوگیری شود.

آنچه در حال ساخت آن هستید

یک سایت onion یک وب‌سرور معمولی است که فقط از طریق شبکه Tor پاسخ می‌دهد. tor را نصب کنید، دو خط به /etc/tor/torrc اضافه کنید، آدرسی که tor برای شما می‌نویسد را بخوانید، و سپس nginx را روی 127.0.0.1 تنظیم کنید تا هیچ پاسخی روی IP عمومی ارسال نشود. بخش نصب ده دقیقه زمان می‌برد. باقی این راهنما مربوط به لیست نشت اطلاعات است، زیرا روش معمول شکست خوردن یک سایت onion این است که پیکربندی خودِ آن، مستقیماً به سمت اپراتور اشاره می‌کند.

پروژه Tor با نام "the onion router" آغاز شد و یک سرویس onion، سرویسی است که فقط از طریق آن قابل دسترسی است. یک آدرس نسخه 3 شامل 56 کاراکتر و به دنبال آن .onion است؛ این کاراکترها همان کلید عمومی ed25519 سرویس به همراه یک checksum و یک بایت نسخه هستند که با base32 کدگذاری شده‌اند. آدرس‌های نسخه 2 (16 کاراکتری) در سال 2021 از شبکه حذف شدند، بنابراین هر چیزی که امروز تولید می‌کنید نسخه 3 است. آدرس در واقع همان کلید است که دو پیامد دارد: اتصال به‌صورت سرتاسری (end-to-end) رمزنگاری و احراز هویت می‌شود بدون اینکه نیازی به مرجع صدور گواهی (CA) باشد، و از دست دادن فایل کلید به معنای از دست دادن همیشگی آدرس است.

سرور شما هرگز اتصال ورودی نمی‌پذیرد. Tor چند رله را به عنوان نقاط معرفی (introduction points) انتخاب می‌کند، یک توصیف‌گر امضا شده را در سرورهای دایرکتوری بارگذاری می‌کند و در یک رله ملاقات (rendezvous relay) که بازدیدکننده انتخاب کرده است، با او دیدار می‌کند. تمام این اتصالات از سمت سرور شما خروجی (outbound) هستند. هیچ پورتی برای باز کردن و هیچ رکورد DNS برای انتشار وجود ندارد.

نصب tor از مخزن Tor Project

توزیع Ubuntu یک بسته tor در مخزن universe دارد، اما این نسخه معمولاً نزدیک به نسخه‌ای است که در زمان freeze شدن آن release منتشر شده است. مخزن اختصاصی Tor 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

ورودی مخزن از فرمت deb822 استفاده می‌کند و Suites باید نام رمز (codename) توزیع Ubuntu شما باشد. آن را از /etc/os-release بخوانید و از تایپ دستی خودداری کنید، زیرا نام رمز اشتباه باعث می‌شود مخزن به درستی resolve شود اما هیچ بسته‌ای برای نسخه سیستم‌عامل شما پیدا نکند.

. /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 کلید امضا را به‌روز نگه می‌دارد تا چرخش کلید (key rotation) باعث از کار افتادن apt update در سال آینده نشود. بررسی کنید که tor اجرا شده و به شبکه متصل شده باشد:

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

ژورنال باید با Bootstrapped 100% (done): Done پایان یابد. اگر tor روی Bootstrapped 10% متوقف مانده است، یعنی مسیر خروجی ندارد؛ بنابراین فایروال شبکه ارائه‌دهنده و قوانین خروجی (egress) خود را بررسی کنید: sudo ufw status verbose باید allow (outgoing) را به عنوان مسیر پیش‌فرض نشان دهد.

از اینجا به بعد، دو نام اهمیت دارند. این بسته tor را با کاربر debian-tor اجرا می‌کند و واحد در حال اجرا tor@default.service است، زیرا tor.service در Debian و Ubuntu یک wrapper برای این instance محسوب می‌شود. وضعیت و لاگ‌ها را با نام instance درخواست کنید تا همیشه اطلاعات پردازش اصلی را دریافت کنید.

پیکربندی سرویس onion در torrc

دو خط زیر را به /etc/tor/torrc اضافه کنید:

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

HiddenServiceDir مسیری است که Tor کلیدها و آدرس این سرویس را در آن نگهداری می‌کند. خودتان آن را ایجاد نکنید. Tor هنگام شروع به کار، این دایرکتوری را با مالکیت و دسترسی‌های لازم می‌سازد؛ ایجاد دایرکتوری توسط شما با دسترسی root، اولین مورد از لیست خطاهای زیر را ایجاد می‌کند.

HiddenServicePort از دو بخش تشکیل شده است و جابه‌جا کردن آن‌ها اولین اشتباه رایج است. عدد اول پورتی است که بازدیدکننده در داخل تونل به آن متصل می‌شود، بنابراین 80 همان چیزی است که کاربران انتظار دارند و دلیلی برای تغییر آن وجود ندارد. بخش دوم، آدرس محلی است که Tor ترافیک را به آن هدایت می‌کند. یک HiddenServicePort 80 ساده، ترافیک را به 127.0.0.1:80 می‌فرستد، بنابراین نوشتن کامل آدرس و استفاده از یک پورت بالا باعث می‌شود vhost سرویس onion با هر سرویس دیگری که روی پورت 80 گوش می‌دهد، تداخل نداشته باشد.

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

این لیست باید شامل hostname، hs_ed25519_public_key، hs_ed25519_secret_key و یک دایرکتوری خالی authorized_clients باشد.

خواندن آدرس .onion

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

یک خط خروجی دریافت می‌کنید: 56 کاراکتر base32 و .onion. آن رشته، تمام هویت سایت شماست. هیچ‌کس آن را تخصیص نمی‌دهد، هیچ‌کس نمی‌تواند آن را منتقل کند و تا زمانی که فایل کلید را در اختیار دارید، هیچ‌کس نمی‌تواند آن را از شما بگیرد. اکنون آن را کپی کنید، زیرا تمام تنظیمات زیر به آن نیاز دارند. در ادامهٔ این راهنما، از آن با عنوان <your-address>.onion یاد می‌شود.

سرویس‌دهی سایت از طریق nginx متصل به 127.0.0.1

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 شما روی اینترنت عمومی نیز در دسترس است که اولین مورد در لیست نشت اطلاعات (leak list) محسوب می‌شود. یک خط listen 8080; بدون آدرس، سرویس را به تمام رابط‌های شبکه متصل می‌کند که حالت پیش‌فرض است.

آدرس را در Tor Browser باز کنید. بارگذاری اولیه چند ثانیه طول می‌کشد تا کلاینت descriptor شما را دریافت کرده و یک rendezvous circuit ایجاد کند.

مستندات رسمی Tor Project استفاده از unix socket را به پورت loopback ترجیح می‌دهد: HiddenServicePort 80 unix:/var/run/tor/onion_site.sock، که در آن nginx روی آن مسیر گوش می‌دهد. یک socket به هیچ وجه از میزبان دیگر قابل دسترسی نیست، حتی اگر سرور بعداً دارای رابط شبکه دومی شود. هزینه این کار مدیریت مجوزهای فایل است، زیرا nginx سوکت را ایجاد می‌کند و tor به عنوان کاربر debian-tor به آن متصل می‌شود، بنابراین این دو کاربر باید در مورد دایرکتوری توافق داشته باشند. استفاده از loopback با خروجی تأییدشده ss ساده‌تر است و این همان چیزی است که در ادامه این راهنما فرض شده است.

با قرار گرفتن سایت روی loopback، سرور به هیچ قانون ورودی (inbound rule) برای آن نیاز ندارد. پورت 22 را برای خود باز نگه دارید و بقیه را مسدود کنید (تنظیمات پیش‌فرض ufw که باید روی VPS اعمال شوند). به یاد داشته باشید که فایروال، سرویسی را که به 0.0.0.0 متصل شده است غیرفعال نمی‌کند، بلکه فقط بسته‌هایی را که به فایروال می‌رسند فیلتر می‌کند. کانتینرها این موضوع را حساس‌تر می‌کنند، زیرا انتشار پورت Docker قوانین iptables را پیش از ufw می‌نویسد، بنابراین -p 8080:80 باعث می‌شود backend onion شما روی IP عمومی قرار بگیرد در حالی که ufw همچنان پورت را مسدود گزارش می‌دهد. پورت‌های کانتینر را به صورت -p 127.0.0.1:8080:80 منتشر کنید.

نشت‌هایی که یک سایت Onion را از حالت ناشناس خارج می‌کنند

Tor مکان سرور را مخفی می‌کند، اما هیچ‌چیز در Tor محتوای ارسالی سرور را مخفی نمی‌کند. هر مورد زیر، اطلاعاتی است که پشتهٔ نرم‌افزاری شما منتشر می‌کند.

پاسخ‌دهی همان سایت روی IP عمومی شما

این موردی است که بسیاری را گرفتار می‌کند. اسکنرها به‌طور مداوم پاسخ‌های HTTP تمام آدرس‌های قابل‌مسیریابی را ایندکس می‌کنند و این نتایج عمومی و قابل‌جستجو هستند. اگر همان صفحه را هم روی IP عمومی و هم روی آدرس Onion خود ارائه دهید، اتصال آن‌ها تنها با یک پرس‌وجو ممکن می‌شود: عنوان یکسان، هش Favicon یکسان، ETag یکسان و ترتیب هدرهای یکسان. خط listen 127.0.0.1:8080; در بالا راهکار این مشکل است. آن را از یک ماشین دیگر (نه خود سرور) بررسی کنید:

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

نتیجهٔ صحیح، Connection refused یا یک timeout است. هرگونه محتوای HTML به این معنی است که سایت عمومی است. اگر سرور شما یک سایت Clearnet هم میزبانی می‌کند، برای آن vhost یک root مجزا تعریف کنید و یک بلوک default_server صریح در listener عمومی قرار دهید تا یک هدر Host که با هیچ‌چیز مطابقت ندارد، هرگز به سمت vhost مربوط به Onion هدایت نشود.

بنرهای نسخه (Version banners)

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

یک nginx پیش‌فرض، مقدار Server: nginx/1.24.0 را برمی‌گرداند. آن رشتهٔ نسخه، همراه با ترتیب دقیق سایر هدرها، یک اثر انگشت (fingerprint) است که Onion شما را به میزبان Clearnet شما متصل می‌کند. server_tokens off; آن را به Server: nginx کاهش می‌دهد. این کار هدر را حذف نمی‌کند و nginx دستور داخلی برای حذف کامل آن ندارد، بنابراین ماژول headers-more معمول‌ترین راهکار برای حذف آن است. PHP تا زمانی که expose_php = Off را تنظیم نکنید، مقدار X-Powered-By را اضافه می‌کند. etag off; نیز در همین لیست قرار می‌گیرد، زیرا nginx مقدار ETag را بر اساس زمان اصلاح و اندازهٔ فایل می‌سازد؛ بنابراین فایل‌های یکسانی که در دو سرور کپی شده‌اند، ETag یکسانی در هر دو ارائه می‌دهند.

آدرس‌های مطلق (Absolute URLs) که به دامنه Clearnet شما اشاره دارند

یک تگ rel="canonical"، یک Open Graph og:url، یک فید RSS، یک نقشهٔ سایت (sitemap)، ایمیل بازنشانی رمز عبور یا URL سخت‌کد شدهٔ لوگو؛ هر کدام از این‌ها دامنهٔ Clearnet را در صفحه‌ای که از طریق Onion ارائه می‌شود، فاش می‌کنند. از مسیرهای نسبی به ریشه (root-relative) مانند /static/logo.svg استفاده کنید و اجازه دهید برنامه، URL پایهٔ خود را از host درخواست بخواند، نه از یک مقدار ثابت. ریدایرکت‌ها نیز همان باگ در جای دیگر هستند: return 301 https://example.com$request_uri; در یک بلوک catch-all، بازدیدکنندهٔ Onion را به دامنهٔ واقعی شما می‌فرستد و هدر Location مستقیماً پاسخ را به آن‌ها تحویل می‌دهد.

گواهی TLS مشترک با سایت Clearnet

یک آدرس Onion خودش را احراز هویت می‌کند، زیرا آدرس همان کلید عمومی است؛ بنابراین http:// روی یک اتصال Onion از قبل به‌صورت سرتاسری رمزنگاری شده است و Tor Browser آن را یک بستر امن در نظر می‌گیرد. نصب گواهی فعلی خود روی vhost مربوط به Onion، پیوند بین این دو را منتشر می‌کند، زیرا هر گواهی مورد اعتماد عمومی در لاگ‌های Certificate Transparency ثبت می‌شود و آن لاگ‌ها عمومی، دائمی و بر اساس نام قابل‌جستجو هستند. گواهی‌های Let's Encrypt روی vhost Clearnet را نگه دارید و vhost مربوط به Onion را روی HTTP ساده باقی بگذارید.

فونت‌ها و ابزارهای تحلیل شخص ثالث

یک فونت از یک CDN یا یک اسکریپت تحلیل (analytics). مرورگر بازدیدکننده هر کدام را مستقیماً دریافت می‌کند، بنابراین شخص ثالث متوجه می‌شود که کسی صفحهٔ شما را بارگذاری کرده است (و معمولاً کدام صفحه). سطوح امنیتی سخت‌گیرانه‌تر Tor Browser به‌هرحال این درخواست‌ها را مسدود می‌کند و باعث به‌هم‌ریختگی ظاهر سایت می‌شود. تمام دارایی‌های مورد نیاز صفحه را خودتان میزبانی کنید.

عدم تطابق هدر Host

اگر server_name با هدر Host که Tor ارسال می‌کند مطابقت نداشته باشد، nginx به سرور پیش‌فرض برای آن آدرس listen بازمی‌گردد. در سیستمی با یک vhost، این موضوع نامرئی است زیرا تنها بلوک سرور، همان پیش‌فرض است. اگر بعداً یک vhost برای Clearnet اضافه کنید، درخواست‌های Onion ممکن است به آن هدایت شوند و همراه با تگ‌های canonical و ریدایرکت‌های آن ظاهر شوند. پس از هر تغییر در nginx، بررسی curl -H 'Host: ...' را دوباره اجرا کنید و نتیجه را برای دامنهٔ واقعی خود grep کنید:

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

دانستن اینکه کدام پردازش مالک کدام سوکت است، بخش بزرگی از این کار است (نحوه عملکرد پورت‌ها و سوکت‌های listening در لینوکس).

چه چیزی در لاگ‌ها باقی می‌ماند

هر درخواست از 127.0.0.1 می‌رسد، بنابراین nginx هیچ آدرس بازدیدکننده‌ای برای ثبت ندارد و access_log off; هزینه‌ای برای شما ندارد. برنامهٔ لایهٔ بالاتر موضوع متفاوتی است، زیرا یک سفارش، آدرس ایمیل یا متادیتای یک فایل آپلود شده، مواردی هستند که باید مدیریت کنید. عادات شخصی شما نیز مهم هستند: مدیریت سرور از طریق یک لاگین ناامن، خارج از محدودهٔ حفاظتی Tor است، بنابراین ایمن‌سازی SSH روی همان VPS را بخشی از این فرآیند ساخت در نظر بگیرید.

از کلید خصوصی نسخه پشتیبان تهیه کنید، زیرا این کلید همان آدرس شماست

/var/lib/tor/onion_site/hs_ed25519_secret_key سرویس مورد نظر است. هیچ مرجع ثبت‌کننده یا راهی برای بازیابی وجود ندارد. اگر آن را از دست بدهید، آدرس برای همیشه از بین می‌رود. اگر از آن کپی تهیه کنید، هر کسی که کپی را در اختیار داشته باشد می‌تواند محتوای خود را در آدرس شما ارائه دهد و شما هیچ راهی برای ابطال آن نخواهید داشت.

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

آن آرشیو را رمزنگاری کنید (gpg -c onion-keys.tgz) و آن را از سرور خارج کنید. بازیابی روی یک VPS جدید شامل همان آرشیو و مالکیت مورد انتظار 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

آدرس یکسان، یک یا دو دقیقه پس از اینکه tor توصیف‌گر (descriptor) را دوباره منتشر کند، روی سخت‌افزار جدید بازمی‌گردد. کل فرآیند مهاجرت همین است: بدون تغییر DNS و بدون نیاز به صدور مجدد گواهی.

قابلیت Onion-Location، زمانی که سایت روی clearnet نیز در دسترس است

اگر سرویس onion صرفاً برای راحتی کاربران است و نه برای مخفی ماندن، آن را از طریق vhost مربوط به clearnet معرفی کنید:

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

در این حالت، Tor Browser یک دکمه .onion available در نوار آدرس نمایش می‌دهد و پیشنهاد تغییر مسیر به نسخه onion را ارائه می‌کند. این هدر تنها زمانی معتبر است که صفحه clearnet از طریق HTTPS سرو شود و مقدار آن یک URL معتبر onion باشد.

یک نکته در مورد پیکربندی nginx وجود دارد. دستورات add_header تنها زمانی توسط یک بلاک location به ارث می‌رسند که آن بلاک هیچ دستور مشابهی نداشته باشد؛ بنابراین، یک بلاک location که خود دارای add_header است، هدر Onion-Location را بدون هیچ هشداری نادیده می‌گیرد. در چنین شرایطی، باید هدر را در آن بلاک تکرار کنید یا تمام هدرهای پاسخ را در یک مکان متمرکز نگه دارید. انتشار این هدر عملاً دو سایت را به هم پیوند می‌دهد؛ این کار برای یک mirror صحیح است، اما برای هر سرویسی که قرار است بدون پیوند باقی بماند، اشتباه است.

آدرس‌های Vanity

mkp224o جفت‌کلیدها را تا زمانی که یکی از آن‌ها آدرسی با پیشوند درخواستی شما تولید کند، ایجاد می‌کند. این یک جستجوی brute force است، بنابراین فراتر از تعیین پیشوند و مدت زمانی که مایل به انتظار هستید، تنظیمات دیگری وجود ندارد.

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

هر نتیجه موفق در onionkeys/<address>.onion/ ذخیره می‌شود که شامل hostname و hs_ed25519_secret_key است. برای نصب، ابتدا tor را متوقف کنید، آن دایرکتوری را روی HiddenServiceDir خود کپی کنید و سپس همان chown و chmod 700 را مشابه عملیات بازیابی بالا اعمال نمایید.

طول پیشوند، هزینه اصلی را تعیین می‌کند. آدرس بر مبنای base32 است، بنابراین هر کاراکتر اضافی که درخواست کنید، تعداد کلیدهای مورد انتظار را در 32 ضرب می‌کند. یک پیشوند کوتاه روی لپ‌تاپ به سرعت تمام می‌شود. یک پیشوند طولانی روی هیچ سخت‌افزاری که در اختیار دارید به پایان نمی‌رسد. همچنین، یک پیشوند vanity به کاربران می‌آموزد که به جای کل آدرس، فقط چند کاراکتر اول را تشخیص دهند؛ این همان عادتی است که سایت‌های onion فیشینگ بر پایه آن ساخته می‌شوند.

حالت‌های شکست و پیام‌های مربوط به آن‌ها

عدم وجود فایل 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?

این وضعیت یک دایرکتوری است که به‌صورت دستی ایجاد شده است. مالکیت (ownership) و سطح دسترسی (mode) آن را اصلاح کنید، یا دایرکتوری را حذف کنید تا Tor خودش آن را بسازد.

مرورگر Tor خطای Onionsite Not Found (0xF0) را نشان می‌دهد. کلاینت نتوانسته است descriptor را دریافت کند، بنابراین از دید شبکه، هیچ‌چیزی در آن آدرس منتشر نشده است. مطمئن شوید Tor در حال اجراست و فرآیند bootstrap را تکمیل کرده است؛ آدرسی که وارد کرده‌اید را کاراکتر به کاراکتر با sudo cat /var/lib/tor/onion_site/hostname مقایسه کنید و سپس ساعت سیستم را چک کنید. Tor برای انتشار و اعتبارسنجی descriptorها به زمان دقیق نیاز دارد و timedatectl باید وضعیت System clock synchronized: yes را گزارش دهد.

آدرس resolve می‌شود اما صفحه بارگذاری نمی‌شود. Tor فرآیند rendezvous را تکمیل کرده اما در آخرین گام، یعنی اتصال از Tor به Nginx، شکست خورده است. از آنجا که این گام محلی است، لاگ Tor چیزی ثبت نمی‌کند. دستور curl -sI http://127.0.0.1:8080/ را روی سرور اجرا کنید. خطای Connection refused به این معناست که Nginx متوقف شده یا روی آدرسی غیر از آنچه در HiddenServicePort تنظیم شده، گوش می‌دهد.

صفحه بارگذاری می‌شود اما تمام لینک‌ها به دامنه اصلی شما اشاره دارند. این مشکل به دلیل وجود URLهای مطلق (Absolute URLs) در قالب‌هاست. دستور grep -o 'https\?://[^"]*' که در بالا ذکر شد را اجرا کنید و پیش از اشتراک‌گذاری آدرس، مواردی که در خروجی چاپ می‌شود را اصلاح کنید.

سرویس کار می‌کند اما پس از reboot متوقف می‌شود. پیش از آنکه به سایت خود تکیه کنید، یک بار سیستم را عمداً reboot کنید و سپس دستورات sudo systemctl status tor@default و sudo systemctl status nginx را اجرا کنید. سرویسی که به‌صورت دستی توسط کاربر اجرا شده، تا پیش از راه‌اندازی مجدد سیستم، مشابه سرویسی به نظر می‌رسد که برای شروع خودکار فعال (enabled) شده است.

FAQ

آیا برای سرویس Tor onion نیاز به باز کردن پورت در فایروال دارم؟

خیر. دیمون tor فقط اتصالات خروجی به سرورهای دایرکتوری، نقاط معرفی (introduction points) و هر رلهٔ ملاقات (rendezvous relay) برقرار می‌کند، بنابراین نیازی به قانون ورودی نیست و وب‌سرور در داخل سیستم روی 127.0.0.1 گوش می‌دهد. فایروال ufw را برای ترافیک ورودی روی حالت پیش‌فرض deny نگه دارید و فقط SSH را مجاز کنید. همین ویژگی باعث می‌شود سرویس onion از پشت NAT (ترجمه آدرس شبکه) و بدون داشتن IP عمومی نیز کار کند.

چرا نمی‌توانم آدرس .onion خود را در Tor Browser باز کنم؟

از سمت سرور شروع به عیب‌یابی کنید. دستور sudo journalctl -u tor@default -n 50 باید Bootstrapped 100% (done): Done را نشان دهد، سپس curl -sI http://127.0.0.1:8080/ روی سرور باید یک خط وضعیت برگرداند. در نهایت آدرسی که وارد کرده‌اید را با محتویات فایل hostname مقایسه کنید، زیرا حتی یک کاراکتر اشتباه به معنای سرویسی متفاوت است. خطای Onionsite Not Found (0xF0) به این معنی است که هیچ توصیف‌گری (descriptor) برای آن آدرس یافت نشده است که معمولاً نشان‌دهندهٔ در حال اجرا نبودن tor یا تنظیم نبودن ساعت سیستم است.

آیا می‌توانم سایت onion خود را به سرور جدید منتقل کنم و همان آدرس را حفظ کنم؟

بله. آدرس از روی hs_ed25519_secret_key مشتق می‌شود، بنابراین کل پوشه HiddenServiceDir را به سرور جدید کپی کنید، مالکیت آن را به debian-tor تغییر دهید، دسترسی آن را روی 700 تنظیم کنید و tor را اجرا کنید. به محض اینکه توصیف‌گر دوباره منتشر شود، آدرس فعال می‌شود و نیازی به به‌روزرسانی هیچ رکورد DNS نیست. اگر این فایل را گم کنید، آدرس غیرقابل بازیابی خواهد بود؛ بنابراین همان روزی که آن را ایجاد می‌کنید، یک نسخهٔ پشتیبان رمزنگاری‌شده در خارج از سرور تهیه کنید.

آیا سایت onion به گواهی HTTPS نیاز دارد؟

خیر. آدرس 56 کاراکتری در واقع کلید عمومی سرویس است، بنابراین اتصال از ابتدا تا انتها رمزنگاری و احراز هویت شده است و Tor Browser آدرس http:// روی یک نام .onion را به عنوان یک بستر امن در نظر می‌گیرد. استفادهٔ مجدد از گواهی وب‌سایت معمولی (clearnet) روی vhost سرویس onion، از انجام ندادن آن بدتر است، زیرا لاگ‌های Certificate Transparency عمومی هستند و برای همیشه ثبت می‌کنند که کدام نام‌ها از یک گواهی مشترک استفاده کرده‌اند. تنها دلیل خرید گواهی برای یک نام .onion، اطمینان‌بخشی برند توسط یک CA است که آن‌ها را صادر می‌کند، و این پیوند طبق طراحی، عمومی است.