میزبانیِ سایت .onion روی VPS — راه‌اندازی سرویس Onion در Tor

هر وب‌سایتی که تا به حال ساخته‌اید، بر پشته‌ای از اجازه‌های دیگران استوار است. یک ریجیستری نام را به شما اجاره می‌دهد. یک ثبت‌کننده می‌تواند آن را خاموش کند. یک مرجع صدور گواهی برایتان ضمانت می‌کند. یک ریزالور باید صادقانه پاسخ دهد، و یک پورت باید روی آدرسی عمومی باز بماند، جایی که هر کس می‌تواند پیدایش کند، اثرانگشتش را بگیرد و به آن ضربه بزند. هر کدام از این‌ها طرفی است که می‌توان رویش فشار آورد، و سطحی است که می‌توان به آن حمله کرد.

یک سرویس onion همهٔ این‌ها را از میان برمی‌دارد. هیچ ثبت‌کننده‌ای نیست، چون آدرس از کلیدی که خودتان تولید کرده‌اید مشتق می‌شود. هیچ DNS‌ای نیست، چون هیچ‌چیز نام را ریزالو نمی‌کند. هیچ مرجع صدور گواهی‌ای نیست، چون آدرس خودِ کلید عمومی است و اتصال خودش را در برابر آن احراز هویت می‌کند. و اصلاً هیچ پورت ورودی‌ای وجود ندارد — سرور شما برای رسیدن به بازدیدکنندگانش تماس بیرونی می‌گیرد، پس می‌تواند پشت فایروالی بنشیند که همه‌چیز را رها می‌کند و همچنان از هر نقطهٔ زمین در دسترس باشد.

راه‌اندازی حدود ده دقیقه و سه خط پیکربندی طول می‌کشد. آنچه به دقت نیاز دارد، بقیهٔ ماشین است، چون وب‌سروری که پشت Tor نشسته اصلاً نمی‌داند قرار است پنهان باشد و با کمال میل نام میزبان خودش، IP خودش و دوقلوی آشکارِ خودش را به هر کسی که سؤال درست را بپرسد اعلام می‌کند. این راهنما آن ده دقیقه را انجام می‌دهد، سپس بخشی را انجام می‌دهد که واقعاً تعیین می‌کند آیا کار کرده یا نه.

نکات کلیدی

آدرس همان کلید است. یک نام .onion نسخهٔ ۳ یک کدگذاریِ base32 از یک کلید عمومی ed25519 است، پس هیچ‌کس آن را صادر نمی‌کند، هیچ‌کس نمی‌تواند منتقلش کند، و هیچ‌کس نمی‌تواند تعلیقش کند — اما اگر فایل کلید را از دست بدهید، نام برای همیشه از بین می‌رود.
هیچ پورت ورودی‌ای هرگز باز نمی‌شود. سرویس اتصالات خروجی به نقاط معرفی برقرار می‌کند، پس پشت یک فایروالِ رد-پیش‌فرض هم کار می‌کند و چیزی روی یک آدرس عمومی نیست که بتوان اسکن پورتش کرد.
به‌ندرت این خودِ Tor است که نشت می‌کند. وب‌سروری که پشتش نشسته نشت می‌کند — از طریق میزبان مجازیِ پیش‌فرضش، بنرش، صفحات خطایش، URLهای مطلقی که صادر می‌کند، و هر درخواست خروجی‌ای که اپلیکیشن می‌فرستد.
ترافیک onion از قبل سرتاسر تا همان کلیدِ درون آدرس رمزگذاری و احراز هویت شده، و به همین دلیل HTTP سادهٔ روی loopback همان پیکربندی معمول است و یک گواهی TLS چیزی اختیاری است نه چیزی که کم باشد.
پیش از ساختن تصمیم بگیرید که آیا محل سرور یک راز است یا نه. اگر نیست، یک سرویس onion تک‌جهشی تقریباً تأخیر را نصف می‌کند؛ اگر هست، هیچ‌چیز دیگری نباید روی آن ماشین اجرا شود.
مجوزدهی کلاینت آدرس را به یک اعتبارنامه تبدیل می‌کند. بدون کلید، بازدیدکننده حتی نمی‌تواند توصیفگر را هم بگیرد — سرویس به‌جای اینکه فقط فهرست‌نشده باشد، کاملاً نامرئی می‌شود.

یک سرویس onion چه چیزی را از پشته حذف می‌کند

از آنچه واقعاً متفاوت است شروع کنیم، چون این چیزی بیش از یک نام‌میزبانِ عجیب‌به‌نظر است. یک سایت معمولی به زنجیره‌ای از طرف‌های بیرونی وابسته است، و یک سرویس onion به‌سادگی آن زنجیره را ندارد.

بدون ثبت‌کننده و بدون ریجیستری. یک آدرس onion نسخهٔ ۳ همان کدگذاریِ base32 یک کلید عمومیِ ed25519 است، به‌علاوهٔ یک چک‌سام و یک بایت نسخه — پنجاه‌وشش کاراکتر، که روی ماشین خودتان در کسری از ثانیه تولید می‌شود. هیچ‌کس آن را به شما نفروخته، پس هیچ‌کس نمی‌تواند پسش بگیرد، و هیچ تاریخ تمدیدی وجود ندارد. این دقیقاً نقطهٔ مقابل مدل ریسک در راهنمای ما دربارهٔ ثبت خصوصی دامنه است.
بدون DNS. هیچ‌چیز یک نام .onion را ریزالو نمی‌کند. کلاینت از شبکهٔ Tor یک توصیفگرِ امضاشده را که زیر همان کلید منتشر شده درخواست می‌کند، پس هیچ ریزالوری نیست که مسموم شود، هیچ زونی نیست که نشت کند و هیچ نیم‌سروری نیست که از کار بیفتد.
بدون مرجع صدور گواهی. آدرس همان کلید عمومی است، پس کلاینت سرویس را در برابر همان نامی که تایپ کرده تأیید می‌کند. این همان چیزی است که «خوداحرازهویت» به آن معناست: هیچ شخص ثالثی برای هویت ضمانت نمی‌کند، چون هویت و آدرس یک شیء واحدند.
بدون پورت ورودی. سرویس مدارهای خروجی به چند نقطهٔ معرفی باز می‌کند و همان‌جا منتظر می‌ماند. فایروال شما می‌تواند هر بستهٔ ورودی را رها کند و سایت همچنان کار کند. چیزی روی آدرس عمومی گوش نمی‌دهد، پس چیزی برای اسکن‌کردن، چیزی برای اثرانگشت‌گرفتن و چیزی برای سیل مستقیم وجود ندارد.

یک نکتهٔ تاریخی که هنوز باعث سردرگمی می‌شود: آدرس‌های شانزده‌کاراکتریِ قدیمی از بین رفته‌اند. پشتیبانی از سرویس‌های onion نسخهٔ ۲ در اکتبر ۲۰۲۱ از Tor حذف شد، آن آدرس‌ها دیگر هیچ‌جا کار نمی‌کنند، و هر چیزی که دربارهٔ آن‌ها پیدا کنید منسوخ است. هر چیزی که در ادامه می‌آید نسخهٔ ۳ است، که تنها نوع موجود است.

و روشن باشیم دربارهٔ آنچه هیچ‌کدام از این‌ها حذف نمی‌کند. همچنان یک ماشین فیزیکی در یک دیتاسنتر وجود دارد، میزبانی که می‌داند این ماشین وجود دارد، صورت‌حسابی که کسی پرداخته، و اپلیکیشنی که می‌شود به آن نفوذ کرد. سرویس‌های onion لایهٔ آدرس را از دسترس خارج می‌کنند. آن‌ها سرور را جابه‌جا نمی‌کنند.

رله، پل، خروجی، سرویس onion: چهار وظیفهٔ متفاوت

مردم برای انجام یکی از چهار کارِ کاملاً متفاوت سراغ Tor می‌آیند، و نمایه‌های ریسک اصلاً قابل‌مقایسه نیستند. ارزش دارد بدانید دقیقاً برای کدام‌یک ثبت‌نام می‌کنید.

یک رلهٔ میانی ترافیک رمزگذاری‌شده را بین رله‌های دیگر منتقل می‌کند. داده‌های دیگران را حمل می‌کند، اما هرگز از طرف آن‌ها به اینترنت باز دست نمی‌زند، پس هیچ شکایتی جذب نمی‌کند.
یک پل یک نقطهٔ ورودیِ فهرست‌نشده برای کسانی است که دسترسی‌شان به Tor مسدود شده. همان نمایهٔ ترافیکیِ یک رلهٔ میانی را دارد، با این تفاوت که آدرسش از فهرست عمومی بیرون نگه داشته می‌شود.
یک رلهٔ خروجی همان جایی است که ترافیک دیگران Tor را ترک می‌کند و زیر آدرس IP شما به اینترنت معمولی می‌رسد. این همان چیزی است که نامهٔ سوءاستفاده و مکاتبات حقوقی تولید می‌کند، و به مدیریتِ آگاهانه نیاز دارد — راهنمای رلهٔ Tor ما آن را به‌درستی پوشش می‌دهد.
یک سرویس onion منتشر می‌کند. هیچ ترافیکی جز ترافیک خودش حمل نمی‌کند، هرگز از طرف کسی با وب آشکار تماس نمی‌گیرد، و به همین دلیل اصلاً هیچ گزارش سوءاستفاده‌ای علیه IP شما تولید نمی‌کند. هیچ خروجی‌ای وجود ندارد، پس چیزی برای خروج نیست.

ارزش دارد کمی روی آن نکتهٔ آخر مکث کنیم، چون معمولاً بد فهمیده می‌شود. اجرای یک سرویس onion از نظر عملیاتی آرام‌ترین کاری است که می‌توانید روی شبکهٔ Tor انجام دهید. سرور شما اتصالات خروجی‌ای برقرار می‌کند که شبیه ترافیک معمولیِ کلاینت Tor به‌نظر می‌رسند؛ هرگز به‌عنوان منبع یک اتصال به سرور کس دیگری ظاهر نمی‌شود؛ و چیزی که اغلب مردم نگرانش هستند — فرودآمدنِ رفتار کس دیگری روی IP شما — از نظر ساختاری غیرممکن است.

همچنین لازم نیست برای اجرای یک سرویس onion، یک رله هم اجرا کنید، و بهتر است این دو را از هم جدا نگه دارید. یک رله به پهنای باند، یک ORPort عمومی و یک ContactInfo منتشرشده نیاز دارد. یک سرویس به هیچ‌کدام از این‌ها نیاز ندارد. اگر می‌خواهید هر دو را انجام دهید، آن‌ها را روی دو سرور جداگانه انجام دهید.

Tor تقریباً هرگز چیزی نیست که نشت می‌کند

این همان بخشی است که مستندات رسمی دربارهٔ آن کم‌حرف‌اند، و همان بخشی است که واقعاً تعیین می‌کند آیا این کار ارزشش را داشته یا نه. Tor، وقتی مثل زیر پیکربندی شود، به‌شدت بعید است چیزی باشد که سرور شما را لو می‌دهد. نرم‌افزار پشتِ آن این کار را می‌کند، چون آن نرم‌افزار با این فرض نوشته شده که یک وب‌سرور می‌خواهد پیدا شود.

این‌ها همان کانال‌ها هستند، تقریباً به همان ترتیبی که مردم را گیر می‌اندازند:

محتوای یکسان روی IP عمومی. اگر وب‌سرور شما روی 0.0.0.0 هم گوش می‌دهد، هر کسی که اینترنت را اسکن کند، صفحهٔ یکسان را هم روی یک آدرس IP و هم روی یک آدرس onion می‌بیند. اسکنرهای کل‌اینترنت پیوسته هر پورت بازی را نمایه می‌کنند و نتایجشان بر اساس هش بدنه و هش فاویکن قابل‌جست‌وجوست. یک پرس‌وجو این دو را به هم پیوند می‌زند. این رایج‌ترین راهی است که یک سرویس onion افشا می‌شود، و یک اشتباه پیکربندیِ تک‌خطی است.
بنرهای سرور و صفحات پیش‌فرض. یک نصبِ استاندارد nginx یا apache2 به نام‌میزبان‌های ناشناخته با یک صفحهٔ پیش‌فرض پاسخ می‌دهد، نسخه‌اش را در هدر Server چاپ می‌کند، و اغلب نام‌میزبانِ واقعیِ ماشین را در خروجیِ خطا افشا می‌کند. هر کدام از این‌ها یک سرنخ همبستگی است.
URLهای مطلق. ریدایرکت‌ها، تگ‌های canonical، نقشه‌های سایت، فیدهای RSS، تگ‌های Open Graph و ایمیل‌های بازنشانی رمز عبور، همه عاشق صادرکردنِ یک URL آشکارِ کاملاً واجدشرایط هستند. وجود فقط یکی از این‌ها درون نسخهٔ onion یک صفحه کافی است.
درخواست‌های خروجی‌ای که اپلیکیشن می‌فرستد. آنالیتیکس، فونت‌های وب، دارایی‌های CDN، سرویس‌های آواتار، کاشی‌های نقشه، وب‌هوک‌ها و بررسی‌های به‌روزرسانی، همگی از IP واقعیِ سرور سرچشمه می‌گیرند، و چندتاشان به یک شخص ثالث می‌گویند در آن لحظه کدام صفحه رندر می‌شده. یک سایتِ خودمیزبان با فونتی که از دامنهٔ کس دیگری بارگذاری شده، ردپایی دارد که قصدش را نداشته.
ایمیل. هر چیزی که این ماشین بفرستد، IP واقعی‌اش را در هدرهای Received مُهر می‌زند. اگر سرویس نیاز به ارسال ایمیل دارد، این یک مسئلهٔ طراحی است که باید آگاهانه حل شود — از راهنمای سرور ایمیل ما شروع کنید، و به‌طور پیش‌فرض فرض کنید که نباید اصلاً چیزی بفرستد.
کلیدها و اثرانگشت‌های بازاستفاده‌شده. همان کلید میزبانِ SSH که هم روی IP عمومی و هم روی یک آدرس onion پاسخ می‌دهد، آن‌ها را برای همیشه به هم پیوند می‌زند. همین اتفاق برای همان گواهی TLS، همان فاویکن، همان شناسهٔ آنالیتیکس، یا همان صفحهٔ خطای متمایز در دو پروژه هم می‌افتد.
شفافیت گواهی. اگر همان ماشین روزی یک دامنهٔ آشکار را روی HTTPS سرویس‌دهی کند، گواهیِ آن دامنه برای همیشه در لاگ‌های عمومیِ فقط-افزایشی نوشته می‌شود. این ماشین را نام می‌برد، نه onion را، اما ماشین را نام می‌برد.

شکل مشترک همهٔ این‌ها یکسان است: Tor آدرس را پنهان کرد، و چیز دیگری روی سرور آن را منتشر کرد. قدم هشتم در ادامه یک چک‌لیست برای پیداکردنِ آن‌ها پیش از آنکه کس دیگری پیدایشان کند است.

اول تصمیم بگیرید: آیا محل سرور یک راز است؟

پیش از نصب هر چیزی، به یک پرسش پاسخ دهید، چون هر چیزی که بعد از آن می‌آید به همین بستگی دارد: آیا محل فیزیکیِ این سرور رازی است که سعی دارید حفظش کنید؟

سه پاسخ صادقانه وجود دارد و هرکدام به ساختی واقعاً متفاوت می‌رسد.

بله، محل همان نکتهٔ اصلی است. در این صورت این ماشین دقیقاً یک کار انجام می‌دهد. بدون سایت آشکار، بدون رکورد DNS عمومی که به IP‌اش اشاره کند، بدون ایمیل، بدون هیچ سرویس دیگری که جایی گوش بدهد. برایش طوری پرداخت می‌کنید که نامتان را به آن نچسباند — راهنمای گام‌به‌گامِ Monero ما جزئیات را پوشش می‌دهد و حساب‌های بدون KYC یعنی چیزی جز یک آدرس تحویل برای دادن وجود ندارد. پیکربندی کاملِ سه‌جهشی را حفظ می‌کنید. هر میان‌بری که در ادامه ناشناسی را با سرعت معامله می‌کند، به رویتان بسته است، و اشکالی ندارد، چون شما سرعت را بهینه نمی‌کنید.
نه، سرور از قبل عمومی است. شما یک سایت معمولی اجرا می‌کنید و می‌خواهید یک آدرس onion هم داشته باشید — برای خواننده‌هایی که پشت سانسورند، برای کسانی که ترجیح می‌دهند دامنه‌تان را ریزالو نکنند، یا چون دوست دارید این گزینه را ارائه دهید. کسی چیزی را پنهان نمی‌کند، پس می‌توانید از یک سرویس onion تک‌جهشی استفاده کنید، مدار را از شش جهش به سه جهش کاهش دهید، و آدرس را از سایت آشکار با یک هدر Onion-Location تبلیغ کنید. این یک ویژگیِ دسترس‌پذیری است، و دلیلی کاملاً مشروع برای اینجا بودن است.
جایی در میانه. بیشتر مردم واقعاً همین‌جا هستند، و همین یکی خطرناک است، چون «تاحدی پنهان» ویژگی‌ای نیست که یک سرور بتواند داشته باشد. یک طرف را انتخاب کنید. اگر محل واقعاً اهمیت دارد، طوری بسازیدش که انگار اهمیت دارد. اگر ندارد، دیگر هزینهٔ تأخیر را برای ویژگیِ ناشناسی‌ای که حفظش نمی‌کنید نپردازید.

پیش از ادامه، پاسخ را یادداشت کنید. تقریباً هر اشتباهی در موضوع این راهنما از اینجا می‌آید که کسی برای حالت اول می‌سازد و طوری کار می‌کند که انگار حالت دوم است.

گام به گام

سرور را انتخاب کنید، و تصمیم بگیرید چه چیز دیگری رویش زندگی می‌کند
اجرای یک سرویس onion ارزان است. خودِ Tor وقتی رله نمی‌کند CPU بسیار کمی مصرف می‌کند، و بار کاری همان چیزی است که سایتتان در هر صورت هزینه داشت، پس اندازه را برای اپلیکیشن انتخاب کنید نه برای Tor. یک سایت استاتیک یا یک اپِ کوچکِ خودمیزبان روی ۱ vCPU و ۲ گیگابایت راحت است؛ اگر پای یک دیتابیس یا یک ران‌تایمِ زبان برنامه‌نویسی در میان باشد، ۲ vCPU و ۴ گیگابایت به آن بدهید. روی نردبان قیمتیِ ما این یعنی Cub (1 vCPU، 2 GB RAM، 40 GB) به قیمت ۵ دلار در ماه یا Scout (2 vCPU، 4 GB RAM، 70 GB) به قیمت ۹ دلار در ماه، هر دو تمام‌NVMe با ترافیک نامحدود روی ۱ گیگابیت بر ثانیه.
تصمیمی که واقعاً اهمیت دارد، پلن نیست. همان چیزی است که در بخش بالا آمد: اگر قرار است محلِ این ماشین خصوصی بماند، این ماشین یک کار انجام می‌دهد و فقط یک کار. بدون سایت دیگری رویش، بدون رکورد DNS در هیچ‌کجا که به آدرسش اشاره کند، بدون ایمیل، بدون هیچ‌چیز دیگری که گوش بدهد. وسوسهٔ گذاشتنِ «فقط یک چیزِ دیگر» روی ماشینی که از قبل بابتش پول می‌دهید، دقیقاً همان‌طوری است که همبستگی اتفاق می‌افتد.
متناسب با آن پرداخت کنید. حساب‌ها اینجا فقط به یک آدرس ایمیل برای تحویل نیاز دارند و نه چیز دیگری، و تسویه‌حساب on-chain انجام می‌شود — راهنمای گام‌به‌گامِ Monero و خرید بدون کارت آن را از صفر پوشش می‌دهند. از یک ایمیجِ مینیمالِ Debian یا Ubuntu شروع کنید؛ هر دستوری که در ادامه می‌آید فرض می‌کند Debian 12 یا جدیدتر را به‌عنوان root دارید.
Tor را از مخزن Tor Project نصب کنید
به‌جای پکیج توزیع، از مخزن خودِ Tor Project استفاده کنید. نسخهٔ توزیع عقب می‌ماند، و دو تا از تنظیمات این راهنما — محدودکنندهٔ نرخ در نقاط معرفی و دفاع اثبات‌کار — فقط در نسخه‌های اخیر وجود دارند.
```
apt update && apt install -y apt-transport-https curl gpg lsb-release

curl -s https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor | tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

echo "deb [signed-by=/usr/share/keyrings/deb.torproject.org-keyring.gpg] \
https://deb.torproject.org/torproject.org $(lsb_release -cs) main" \
  > /etc/apt/sources.list.d/tor.list

apt update && apt install -y tor deb.torproject.org-keyring
tor --version
```
پکیج deb.torproject.org-keyring کلید امضا را به‌روز نگه می‌دارد، پس این یک کارِ یک‌باره است نه چیزی که یک سال دیگر خراب شود. هر نسخه از 0.4.8 به بالا همهٔ گزینه‌هایی که در ادامه استفاده می‌شوند را دارد.
هنوز چیزی را پیکربندی نکنید. Tor در این مرحله به‌عنوان یک کلاینت در حال اجراست، که برای مرحلهٔ تأییدِ بعدی همین کافی است.
وب‌سرور را روی loopback بگذارید و هیچ‌جای دیگر
این همان قدمی است که بیشترین احتمال را دارد نادیده گرفته شود و بیشترین احتمال را دارد کل کار را خراب کند. وب‌سرور باید فقط از خودِ ماشین قابل‌دسترس باشد و از هیچ‌جای دیگر. nginx را نصب کنید، سپس یک میزبان مجازی بنویسید که فقط به loopback بایند شود:
```
# /etc/nginx/sites-available/onion
server {
    listen 127.0.0.1:8080;
    server_name _;
    server_tokens off;
    root /var/www/onion;
    index index.html;
    access_log off;
}
```
server_tokens off نسخه را از هدر Server و از صفحات خطا حذف می‌کند. خاموش‌کردنِ لاگِ دسترسی یک انتخاب آگاهانه است نه تنبلی: هر درخواستی که از مسیر Tor می‌آید از 127.0.0.1 می‌رسد، پس لاگ هیچ‌چیز مفیدی دربارهٔ بازدیدکننده‌ها ثبت نمی‌کند و چیزهای زیادی ثبت می‌کند که بهتر است نگه‌داشته نشوند.
سپس یک catch-all اضافه کنید که روی آدرس عمومی پاسخ می‌دهد و از گفتنِ هر چیزی امتناع می‌کند. 444 در nginx اتصال را بدون پاسخ می‌بندد، که آرام‌ترین پاسخ ممکن به یک اسکنر است:
```
# /etc/nginx/sites-available/deny-direct
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    return 444;
}
```
هر دو را فعال کنید، سایتِ پیش‌فرضِ استاندارد را حذف کنید، و تأیید کنید واقعاً چه چیزی گوش می‌دهد:
```
rm -f /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/onion /etc/nginx/sites-enabled/
ln -s /etc/nginx/sites-available/deny-direct /etc/nginx/sites-enabled/
mkdir -p /var/www/onion && echo 'it works' > /var/www/onion/index.html
nginx -t && systemctl reload nginx
ss -ltnp
```
خروجیِ ss را با دقت بخوانید. تنها ورودی‌ای که به 0.0.0.0 یا :: بایند شده باید همانی باشد که قصد داشتید نگهش دارید — SSH، و catch-all با 444 اگر تصمیم گرفتید اجرایش کنید. هر چیز دیگری باید روی 127.0.0.1 باشد. اگر اپلیکیشنی که میزبانی می‌کنید listener خودش را دارد، آن را هم بررسی کنید؛ خیلی از فریم‌ورک‌ها به‌طور پیش‌فرض روی همهٔ اینترفیس‌ها گوش می‌دهند و چیزی دربارهٔ آن نمی‌گویند.
سرویس onion را در torrc اعلام کنید
سه خط سرویس را می‌سازند. آن‌ها را به /etc/tor/torrc اضافه کنید، همراه با دو دفاعی که همین حالا فعال‌کردنشان خیلی راحت‌تر از وسط یک حادثه است:
```
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/onion-site/
HiddenServicePort 80 127.0.0.1:8080

# rate-limit floods at the introduction points
HiddenServiceEnableIntroDoSDefense 1

# make each connection attempt cost the client a little work
HiddenServicePoWDefensesEnabled 1
```
خط پورت را با دقت بخوانید، چون این دو عدد کارهای متفاوتی انجام می‌دهند. اولی همان پورتی است که بازدیدکننده‌ها در URL onion استفاده می‌کنند — آن را روی 80 نگه دارید تا کسی مجبور نباشد پورتی تایپ کند. دومی همان جایی است که Tor درخواست را محلی فوروارد می‌کند، که همان listenerِ loopback از قدم قبل است. لازم نیست یکسان باشند و اغلب وقتی یکسان نباشند شفاف‌تر است.
اگر می‌خواهید حتی سوکت TCP روی loopback را هم حذف کنید، Tor می‌تواند به‌جایش با یک سوکت یونیکس صحبت کند، که یعنی اصلاً هیچ‌چیزی روی یک پورت گوش نمی‌دهد. سرویس را به یک سوکت اشاره دهید و nginx را طوری تنظیم کنید که رویش گوش بدهد:
```
HiddenServicePort 80 unix:/run/onion-site.sock
```
پوشه را خودتان نسازید و فایل‌های کلید را هم خودتان نسازید. Tor آن‌ها را در اولین اجرا با مالکیت و مجوزهایی که انتظار دارد می‌سازد، و پوشه‌ای که خودتان دستی با مُد اشتباه ساخته باشید، دلیل رایجی است برای اینکه سرویس بی‌سروصدا بالا نیاید.
Tor را راه‌اندازی کنید و آدرستان را بخوانید
Tor را ری‌استارت کنید، بالاآمدنش را تماشا کنید، و آدرستان را جمع کنید:
```
systemctl restart tor@default
journalctl -u tor@default -n 20 --no-pager
cat /var/lib/tor/onion-site/hostname
```
آن فایل پنجاه‌وشش کاراکترِ base32 دارد که با .onion تمام می‌شود، و همین آدرس شماست — از همان لحظه‌ای که Tor در لاگ می‌گوید توصیفگرش را منتشر کرده زنده است، معمولاً ظرف یک دقیقه. چیزی برای ثبت‌کردن، چیزی برای انتشاردادن و چیزی برای منتظرماندن وجود ندارد.
نگاهی به بقیهٔ چیزهایی که Tor ساخته بیندازید، چون دوتا از این فایل‌ها بیشتر از هر چیز دیگری روی این ماشین اهمیت دارند:
```
ls -l /var/lib/tor/onion-site/
```
باید hostname، hs_ed25519_public_key و hs_ed25519_secret_key را ببینید، در پوشه‌ای که مالکش debian-tor است با مُد 0700. کلید محرمانه یک اعتبارنامه برای آدرس نیست؛ خودِ آدرس است. آن را روی ماشین دیگری کپی کنید و همان ماشین سرویس شما می‌شود. آن را بدون پشتیبان حذف کنید و آدرس دیگر هرگز توسط هیچ‌کس، حتی خودتان، قابل بازسازی نیست. قدم نه به‌درستی به این می‌پردازد — آن را رد نکنید.
اگر فایل hostname ظاهر نشد، پاسخ تقریباً همیشه در لاگ است: پوشه‌ای که Tor نمی‌تواند مالکش شود، یک مُدِ مجوز که از پذیرفتنش امتناع می‌کند، یا یک غلط تایپیِ در خط پورت.
به آن برسید، و ثابت کنید ماشین خودتان است
تست بدیهی این است که آدرس را در Tor Browser باز کنید، و باید همین کار را هم بکنید. تست مفید از خط فرمان است، جایی که می‌توانید هدرها را ببینید:
```
apt install -y torsocks
torsocks curl -sI http://<your-address>.onion/
torsocks curl -s  http://<your-address>.onion/ | head
```
ثابت کنید واقعاً سرور خودتان است. آدرسی که دستی تایپ کرده‌اید پنجاه‌وشش کاراکتر base32 است، و جابه‌جاشدنِ یک کاراکتر می‌تواند شما را به سرویس کس دیگری برساند. یک token تصادفی روی سرور بنویسید، بعد همان مسیر دقیق را از میان Tor بگیرید و مقایسه کنید:
```
head -c 16 /dev/urandom | base32 | tr -d '=' > /var/www/onion/token.txt
cat /var/www/onion/token.txt
torsocks curl -s http://<your-address>.onion/token.txt
```
دو رشتهٔ یکسان یعنی به ماشین خودتان رسیده‌اید. بعدش فایل را حذف کنید.
بدانید این تست چه چیزی را نشان می‌دهد و چه چیزی را نه. اجرایش از خودِ سرور ثابت می‌کند سرویس منتشر شده و قابل‌دسترس است، که دقیقاً همان چیزی است که می‌خواستید بدانید. دربارهٔ ناشناسی هیچ‌چیز ثابت نمی‌کند، چون هر دو سر همان یک ماشین‌اند. برای آن، از یک شبکهٔ کاملاً متفاوت تست کنید — و اگر خودِ Tor در جایی که هستید مسدود است، یک پل همان پاسخ است، که راهنمای ما دربارهٔ دور زدن مسدودسازی DPI آن را پوشش می‌دهد.
پورت‌هایی را که سرویس نیازی به آن‌ها ندارد ببندید
حالا وقت جمع‌کردنِ پاداش است. یک سرویس onion به صفر پورت ورودی نیاز دارد، پس فایروال می‌تواند تا جایی که ممکن است بی‌پرده باشد: هر چیز ورودی را رها کنید، اتصالات established و هر چیزی که برای ادارهٔ ماشین لازم دارید را اجازه دهید. راهنمای سخت‌سازیِ Debian ما یک مجموعه‌قاعدهٔ کاملِ nftables دارد؛ آن را اعمال کنید، بعد تأیید کنید تنها استثنای ورودیِ باقی‌مانده SSH است.
بعد به حذف‌کردنِ همان استثنا هم فکر کنید. SSH آخرین پورت عمومی روی ماشینی است که در غیر این صورت نامرئی است، و لازم نیست همین‌طور بماند. یک آدرس onion مخصوص خودش به آن بدهید:
```
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/onion-ssh/
HiddenServicePort 22 127.0.0.1:22
```
Tor را ری‌استارت کنید، hostname جدید را بخوانید، و از طریق پورت SOCKS محلیِ Tor وصل شوید. این در ~/.ssh/config روی لپ‌تاپتان می‌رود:
```
Host onionbox
    HostName <ssh-address>.onion
    User root
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p
```
وقتی این کار کرد، ListenAddress 127.0.0.1 را در sshd_config تنظیم کنید و قاعدهٔ ورودی را رها کنید. حالا این ماشین اصلاً هیچ‌چیزی ندارد که روی یک آدرس عمومی گوش بدهد.
دو نکتهٔ احتیاطی. پیش از آنکه در را پشت سرتان ببندید، مسیر onion را کامل تست کنید، و دسترسیِ کنسولِ ارائه‌دهندهٔ خود را در دسترس نگه دارید تا یک اشتباه فقط هزینهٔ یک ری‌بوت داشته باشد نه هزینهٔ خودِ سرور — مالِ ما در پنل کنترل است. و هرگز نگذارید همان کلید میزبانِ SSH هم روی IP عمومی و هم روی آدرس onion پاسخ دهد، چون اثرانگشت در هر دو جا یکسان است و این دقیقاً همان پیوندی است که سعی دارید نسازیدش.
پیش از انتشار آدرس، نشتی‌ها را شکار کنید
پیش از آنکه آدرس را به کسی بگویید، این مراحل را طی کنید. پنج دقیقه طول می‌کشد و همان تفاوت بین یک سرویسِ واقعاً مخفی و سرویسی است که فقط پیداکردنش کمی دردسر دارد.
هیچ چیز غیرمنتظره‌ای گوش نمی‌دهد. هر خط باید loopback باشد، یا پورتی که آگاهانه تصمیم گرفتید باز بگذارید:
```
ss -ltnp
```
IP عمومی چیزی سرویس‌دهی نمی‌کند. از جای دیگری، هر دو طرف را مستقیماً بپرسید. پاسخ‌های خالی یا امتناع از اتصال همان چیزی است که می‌خواهید؛ محتوای خودتان همان چیزی است که نمی‌خواهید:
```
curl -sI --max-time 5 http://203.0.113.10/
curl -skI --max-time 5 https://203.0.113.10/
```
هیچ URL آشکاری درون چیزی که سرویس‌دهی می‌کنید نیست. صفحه را از میان Tor بگیرید و هر لینک مطلق درونش را فهرست کنید. هر چیزی که به دامنه‌ای که کنترلش می‌کنید، یک CDN، یک میزبانِ فونت یا یک نقطهٔ پایانیِ آنالیتیکس اشاره کند، یک نشتی یا یک سرنخ همبستگی است:
```
torsocks curl -s http://<your-address>.onion/ \
  | grep -Eo 'https?://[^ "]+' | sort -u
```
هدرها و صفحات خطا چیزی نمی‌گویند. یک صفحهٔ واقعی و یک صفحهٔ عمداً موجودنبوده را بررسی کنید، و دنبال رشته‌های نسخه، نام‌میزبان‌ها، مسیرهای فایل و stack trace بگردید:
```
torsocks curl -sI http://<your-address>.onion/
torsocks curl -s  http://<your-address>.onion/nothing-here | head -20
```
اپلیکیشن به خانه زنگ نمی‌زند. این یکی دستور نیست، یک مرورِ دقیق است. آنالیتیکس را غیرفعال کنید. فونت‌ها، آیکون‌ها و اسکریپت‌ها را خودمیزبان کنید. گرفتنِ آواتار و پیش‌نمایش را خاموش کنید. بررسی‌های به‌روزرسانی‌ای که طبق یک زمان‌بندی بیرون تماس می‌گیرند را حذف کنید. هر تنظیمِ URL مطلق — URL سایت، میزبان canonical، دامنهٔ فرستندهٔ ایمیل — را به آدرس onion اشاره دهید نه یک آدرس آشکار.
نظافتِ عمومی. ماشین را با timedatectl set-timezone UTC روی UTC تنظیم کنید تا timestampها چیزی دربارهٔ اینکه خودش یا شما کجا ممکن است باشید افشا نکنند. مطمئن شوید /server-status، /.git، فایل‌های پشتیبان و فایل‌های swap ادیتور در دسترس نیستند. و اگر این ماشین یک سایت آشکار هم سرویس‌دهی می‌کند، برگردید و بخش سوم را دوباره بخوانید، چون چک‌لیستِ بالا نمی‌تواند ساختی را نجات دهد که موضعش هرگز تصمیم‌گیری نشده.
کلید را پشتیبان بگیرید، چون کلید همان آدرس است
بار دیگر بگوییم، چون این همان شکستی است که مردم از آن بازنمی‌گردند: کلید محرمانه، خودِ آدرس است. ثبت‌کننده‌ای برای درخواست تجدیدنظر نیست، ایمیل بازیابی‌ای نیست، تیکت پشتیبانی‌ای نیست. آن بایت‌ها را از دست بدهید و نام برای همیشه از اینترنت می‌رود.
Tor را متوقف کنید تا فایل‌ها سازگار بمانند، کل پوشهٔ سرویس را آرشیو کنید، و پیش از آنکه از ماشین خارج شود رمزگذاری‌اش کنید:
```
systemctl stop tor@default
tar -C /var/lib/tor -czf - onion-site \
  | gpg -c --cipher-algo AES256 -o onion-site-$(date +%F).tar.gz.gpg
systemctl start tor@default
```
آرشیو رمزگذاری‌شده را به جایی ببرید که این سرور نیست — کل نکته همین است که از خودِ ماشین جان سالم به‌در ببرد. راهنمای پشتیبان‌گیری رمزگذاری‌شده ما نشان می‌دهد چطور این کار را طبق یک زمان‌بندی به یک مقصدِ فقط-افزایشی در کشوری دیگر انجام دهید، که خانهٔ درستش همان‌جاست.
بازیابی همان کار برعکس است، و مجوزها اختیاری نیستند: اگر مُد اشتباه باشد Tor از شروع‌شدن سر باز می‌زند، که در همان لحظه آزاردهنده است و دقیقاً همان رفتاری است که می‌خواهید.
```
gpg -d onion-site-2026-09-14.tar.gz.gpg | tar -C /var/lib/tor -xzf -
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
chmod 700 /var/lib/tor/onion-site
chmod 600 /var/lib/tor/onion-site/hs_ed25519_secret_key
systemctl restart tor@default
cat /var/lib/tor/onion-site/hostname
```
آن خط آخر همان تست است. آدرس یکسان روی ماشینی دیگر یعنی پشتیبان واقعی است. همین حالا، یک‌بار تمرینش کنید، روی یک سرور یک‌بارمصرف — یک پشتیبانِ تست‌نشده از یک کلیدِ جایگزین‌ناپذیر، فقط داستانِ کلیدی است که قبلاً داشتید. همان نظمی که در راهنمای مهاجرت ما هست، اینجا هم صدق می‌کند: بازیابی همان چیزی است که واقعاً دارید برایش پول می‌دهید.
آدرس را طوری منتشر کنید که مردم بتوانند به آن اعتماد کنند
حالا پنجاه‌وشش کاراکتر دارید که هیچ‌کس نمی‌تواند بخواندشان، به‌خاطر بسپاردشان، یا با چشم تأییدشان کند. این یک مشکل واقعیِ کاربردپذیری است و یک مشکل امنیتی هم هست، چون بازدیدکننده نمی‌تواند آدرس شما را از یک تقلبیِ تقریباً یکسان تشخیص دهد. توزیع بخشی از ساخت است، نه یک فکرِ بعدی.
آن را جایی منتشر کنید که خواننده از قبل به شما اعتماد دارد. اگر یک سایت آشکار دارید، آدرس را در فوتر بگذارید و هدر Onion-Location را از بخش زیر سرویس‌دهی کنید. در غیر این صورت از هر کانالی که مخاطبانتان از قبل با شما در ذهنشان تداعی می‌کنند استفاده کنید — یک حساب موجود، یک پیامِ امضاشده، یک کارتِ چاپی. آدرس دقیقاً به همان اندازهٔ جایی که منتشرش کرده‌اید اعتبار به ارث می‌برد.
اگر ریسک توجیهش می‌کند، امضایش کنید. یک امضا روی آدرس، که در برابر کلیدی که مردم از قبل دارند قابل‌تأیید باشد، تنها راهی است که کسی می‌تواند بدون اعتماد به کانالی که آن را حمل کرده، تأیید کند آدرس درست را دارد.
به فهرست‌ها یا موتورهای جست‌وجو تکیه نکنید. ایندکس‌های onion وجود دارند، ناقص‌اند، و چندتاشان سابقهٔ فهرست‌کردنِ نسخه‌های فیشینگِ آدرس‌های محبوب را در کنار نسخه‌های واقعی دارند. آنجا پیداشدنی‌بودن یک امتیاز است؛ یک برنامهٔ توزیع نیست.
یک پیشوند vanity کمی کمک می‌کند. ابزار mkp224o آن‌قدر کلید می‌سازد تا یکی از آن‌ها آدرسی تولید کند که با رشته‌ای که خودتان انتخاب کرده‌اید شروع شود، که آن را در یک نگاه قابل‌تشخیص می‌کند:
```
apt install -y gcc libc6-dev libsodium-dev make autoconf
git clone https://github.com/cathugger/mkp224o && cd mkp224o
./autogen.sh && ./configure && make
./mkp224o -d ./keys -n 1 wolf
```
هزینه‌اش با طول به‌صورت نمایی رشد می‌کند: چند کاراکتر چند ثانیه طول می‌کشد، هفت یا هشتا روی سخت‌افزار واقعی زمانِ واقعی می‌برد، و هر چیزی فراتر از آن عملاً اتفاق نمی‌افتد. دربارهٔ اینکه چه چیزی می‌خرید صادق باشید — یک مهاجم هم می‌تواند همان پیشوند را بسازد، و اعتمادکردن به چند کاراکترِ اولِ منطبق دقیقاً همان عادتی است که باعث می‌شود مردم روی لینک اشتباه کلیک کنند. با آن مثل برندینگ رفتار کنید، نه احراز هویت. پوشهٔ تولیدشده مستقیم به‌عنوان یک HiddenServiceDir جا می‌افتد: مالکیت و مُدها را مثل قدم قبل درست کنید، و آن را جایی بسازید که به آن اعتماد دارید، چون هر کس ابزار را اجرا کند، کلید را در دست دارد.

اجرای همان سایت هم روی وب آشکار و هم به‌عنوان یک onion

اگر محل سرور راز نیست، اجرای هر دو ساده و واقعاً مفید است — همین کاری است که سازمان‌های خبریِ بزرگ، Debian و چند موتور جست‌وجو برای ارائهٔ سایت‌هایشان انجام می‌دهند. دو سازوکار و یک معامله وجود دارد که باید درکشان کنید.

آن را با Onion-Location تبلیغ کنید. یک هدر تکی روی سایت آشکار باعث می‌شود Tor Browser یک دکمهٔ «.onion موجود است» در نوار آدرس نشان دهد و پیشنهاد بدهد سوییچ کنید. این هدر فقط روی صفحاتی که روی HTTPS سرویس‌دهی می‌شوند رعایت می‌شود، و مقدارش باید یک URL معتبرِ onion باشد:

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

برای میزبان‌هایی که نمی‌توانید هدر تنظیم کنید، یک معادل HTML هم وجود دارد، که همان الزام HTTPS را دارد:

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

همچنین آدرس را جایی بگذارید که یک انسان بتواند بخواندش، در فوتر یا در یک صفحهٔ دربارهٔ‌ما. آن هدر فقط به کسانی می‌رسد که از قبل از Tor Browser استفاده می‌کنند؛ فوتر به همهٔ بقیه می‌رسد.

به یک سرویس onion تک‌جهشی فکر کنید. یک اتصال معمولیِ onion شش جهش دارد — سه‌تا از سمت کلاینت، سه‌تا از سمت سرویس — و آن سه‌تای سرویس فقط برای این وجود دارند که محلش را پنهان کنند. اگر آن یک راز نیست، می‌توانید آن‌ها را کنار بگذارید. بهبود تأخیر بزرگ و فوراً محسوس است. پیکربندی عمداً بی‌پرده است:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

هر دو گزینه باید با هم تنظیم شوند، پورت SOCKS باید غیرفعال شود، و روی هر سرویس onion در آن نمونهٔ Tor اعمال می‌شوند — هیچ راه خروجِ به‌ازای هر سرویس وجود ندارد. اگر یکی را بدون بقیه تنظیم کنید Tor از شروع‌شدن سر باز می‌زند، که همان لطفی است که نرم‌افزار در حق شما می‌کند. اگر یک نمونهٔ تکی هم میزبان سرویسی است که محلش عمومی است و هم سرویسی که محلش عمومی نیست، دو نمونه اجرا کنید، یا بهتر، دو سرور.

و معامله را بپذیرید. منتشرکردنِ هر دو آدرس اعلام می‌کند که یک اپراتور واحد هر دو را اجرا می‌کند، و سرویس‌دهیِ محتوای یکسان از هر دو، در هر صورت آن‌ها را به‌سادگی قابل‌پیونددادن می‌کند. این همان معامله است، و برای یک سایت عمومی هیچ هزینه‌ای ندارد. بااین‌حال بهداشت را رعایت کنید: بدون URLهای آشکارِ مطلق درون نسخهٔ onion، کوکی‌هایی که به‌ازای هر میزبان محدود شده‌اند تا یک نشست بین آن‌ها سفر نکند، و یک سیاست امنیت محتوا که دارایی‌ها را از آن‌سو نمی‌کشد.

مجوزدهی کلاینت: وقتی آدرس همان اعتبارنامه است

به‌طور پیش‌فرض، هر کسی که آدرس شما را بداند می‌تواند به سرویس برسد. مجوزدهی کلاینت این را در لایهٔ شبکه تغییر می‌دهد نه در لایهٔ اپلیکیشن، و این تفاوت بیشتر از آنچه به‌نظر می‌رسد اهمیت دارد.

وقتی مجوزدهی فعال باشد، توصیفگری که سرویس شما منتشر می‌کند برای مجموعه‌ای از کلیدهای کلاینت رمزگذاری می‌شود. بازدیدکننده‌ای که یکی از آن کلیدها را نداشته باشد نمی‌تواند رمزش را باز کند، نمی‌تواند نقاط معرفی را بشناسد، و درنتیجه اصلاً نمی‌تواند وصل شود — به صفحهٔ ورود نمی‌رسد، ردی هم دریافت نمی‌کند، هیچ‌چیز دریافت نمی‌کند. سرویس فهرست‌نشده نیست؛ نامرئی است.

برای هر کلاینت یک جفت‌کلید x25519 تولید کنید. هر ابزاری که اینجا لازم است از قبل روی یک ماشین Debian هست:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

روی سرور، کلید عمومی را داخل یک پوشهٔ authorized_clients درون پوشهٔ سرویس بیندازید. نام فایل دلخواه است، تا وقتی به .auth ختم شود، که ابطال را به حذفِ یک فایل ساده تبدیل می‌کند:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

روی کلاینت، کلید محرمانه در پوشه‌ای می‌رود که با ClientOnionAuthDir نام‌گذاری شده، در فایلی که به .auth_private ختم می‌شود، با آدرسی که داخلش تکرار شده. Tor Browser پوشهٔ خودش را برای این‌ها زیر پوشهٔ داده‌اش دارد، و اگر به سرویسی برسد که به یکی نیاز دارد، از شما کلید می‌خواهد:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

این همان ابزار درست برای یک سایت staging، یک پنل ادمین، یک محل بارگذاریِ خصوصیِ فایل، یا یک Nextcloud خودمیزبان است که فقط خودتان از آن استفاده می‌کنید — هر جایی که پاسخ صادقانه به «چه کسی باید بتواند ببیند این وجود دارد؟» این باشد: «هیچ‌کس جز خودمان». هزینه‌اش واقعی و اداری است: باید کلیدها را از کانالی که به آن اعتماد دارید به دست افراد برسانید، و باید یادتان باشد بعداً حذفشان کنید.

زنده نگه‌داشتنش: DoS، ساعت‌ها و آپ‌تایم

سرویس‌های onion به شیوه‌های خاص خودشان از کار می‌افتند، و هیچ‌کدامشان شبیه یک قطعیِ معمولی نیستند. چهار چیز ارزش دارد پیش از آنکه بهشان نیاز پیدا کنید راه‌اندازی شوند.

حملهٔ منع سرویس همان مشکل واقعیِ عملیاتی است. چون هیچ آدرس IP‌ای برای فیلترکردن وجود ندارد، دفاع‌های معمول کاربردی ندارند، و یک سیل مصمم از درخواست‌های معرفی، فرستادنش ارزان است. Tor دو پاسخ دارد، هر دو به‌ازای هر سرویس در torrc تنظیم می‌شوند: HiddenServiceEnableIntroDoSDefense 1 درخواست‌ها را در نقاط معرفی محدود می‌کند، و HiddenServicePoWDefensesEnabled 1 کلاینت‌ها را وادار می‌کند یک پازل کوچکِ اثبات‌کار حل کنند که زیر بار سنگین‌تر می‌شود، پس بازدیدکننده‌های واقعی کمی صبر می‌کنند درحالی‌که یک سیل گران می‌شود. هر دو را از همان ابتدا روشن کنید؛ هزینه‌اش وقتی چیزی به شما حمله نمی‌کند ناچیز است.

ساعت را درست نگه دارید. توصیفگرها بر اساس بازه‌های زمانیِ مشتق‌شده از یک مقدار مشترکِ شبکه منتشر و جست‌وجو می‌شوند. سروری که ساعتش بد رانده شده، در جای اشتباه منتشر می‌کند و غیرقابل‌دسترس می‌شود درحالی‌که در لاگ‌های خودش کاملاً سالم به‌نظر می‌رسد. مطمئن شوید یک کلاینت NTP در حال اجراست، ماشین را روی UTC نگه دارید، و وقتی سرویسی به‌طرز مرموزی از ریزالوشدن می‌ایستد، همین را بررسی کنید.

مانیتورینگ باید از مسیر Tor عبور کند. هیچ سرویس آپ‌تایمِ تجاری‌ای نمی‌تواند یک آدرس .onion را پروب کند، یعنی پاسخ معمول برایتان در دسترس نیست. خودتان این بررسی را از یک ماشین دوم که میزبانِ خودِ سرویس نیست اجرا کنید — یک وظیفهٔ cron که torsocks curl -s --max-time 60 را روی یک URL شناخته‌شده اجرا کند و خروجی را با یک رشتهٔ شناخته‌شده مقایسه کند، کافی است و هیچ هزینه‌ای ندارد.

اگر آپ‌تایم اهمیت دارد، برای بیش از یک نمونه برنامه‌ریزی کنید. OnionBalance به چند سرور بک‌اند اجازه می‌دهد یک آدرس onion واحد را به اشتراک بگذارند: یک نمونهٔ front-end همان کلیدی را نگه می‌دارد که آدرس را در مالکیت دارد و توصیفگری منتشر می‌کند که به نقاط معرفیِ بک‌اندها اشاره می‌کند، پس توزیع بار و failover را بدون تغییرِ آدرس به دست می‌آورید. این بخش‌های متحرکِ بیشتری از آنچه اکثر سایت‌ها لازم دارند دارد، اما همان پاسخِ پشتیبانی‌شده است، و ارزش دارد پیش از آنکه خودتان را در یک ماشینِ تکی گیر بیندازید، بدانید که وجود دارد.

یک عادت عملیاتیِ آخر: ری‌استارت‌کردنِ Tor سرویس را برای چند ثانیه، تا زمانی که دوباره منتشر کند، آفلاین می‌کند، و یک نصبِ دوباره که /var/lib/tor را پاک کند، آن را برای همیشه آفلاین می‌کند. با آن پوشه طوری رفتار کنید که با یک کلید خصوصی رفتار می‌کنید، چون خودش یکی از آن‌هاست.

محدودیت‌های صادقانه

یک آدرس onion ثبت‌کننده، ریزالور، مرجع صدور گواهی و پورت باز را حذف می‌کند. چیز دیگری را حذف نمی‌کند، و دقیق‌بودن دربارهٔ باقیِ ماجرا همان چیزی است که یک ابزار مفید را از یک حسِ کاذبِ امنیت جدا می‌کند.

اپلیکیشن را درست نمی‌کند. یک اپ وب آسیب‌پذیر پشتِ یک سرویس onion، همچنان یک اپ وب آسیب‌پذیر است؛ اولین کاری که خیلی از مهاجم‌ها بعد از دست‌یابی به اجرای کد انجام می‌دهند، فرستادنِ یک درخواست خروجی است که آدرس واقعیِ سرور را افشا می‌کند. آن گذرِ ده‌دقیقه‌ای را در راهنمای سخت‌سازیِ Debian ما به این ماشین بدهید، آپدیتش کنید، و طوری با آن رفتار کنید که انگار در معرض دید است، حتی اگر چیزی روی آن گوش نمی‌دهد.

سرور را از کسانی که اجرایش می‌کنند پنهان نمی‌کند. ما می‌دانیم یک سرور وجود دارد، کِی مستقر شده، و آدرس IP‌اش چیست، چون ما همان کسی هستیم که آن را تخصیص داده‌ایم. این دربارهٔ هر میزبانی، همه‌جا، درست است، و هر کسی که خلاف این را بگوید دارد چیزی می‌فروشد. آنچه می‌توانیم دقیقاً بگوییم این است که با آن چه می‌کنیم، که در تحلیل صادقانهٔ ما از آنچه یک VPS پرداخت‌شده با رمزارز پنهان می‌کند آمده است.

به‌تنهایی یک خصمِ صبور و باامکانات را شکست نمی‌دهد. حجم و زمان‌بندیِ ترافیک در لبه‌های شبکه دیده می‌شود، و سرویسی که هر وقت فرد خاصی خواب است ساکت می‌شود، دارد چیزی را لو می‌دهد. اگر محتوا شما را شناسایی کند هم کمکی نمی‌کند: همان سبک نوشتار، همان کلید PGP، همان آواتار یا همان نام کاربریِ فوروم که یک هویت عمومی دارد، حلقه را می‌بندد، مهم نیست انتقال چقدر خوب باشد.

از سمتِ خودمان، تا بتوانید بسنجید: سرویس‌های onion در هر پلنی خوش‌آمدند و هیچ چیز خاصی از ما نمی‌خواهند، چون هیچ پورتی باز نمی‌کنند و هیچ ترافیک سوءاستفاده‌ای تولید نمی‌کنند. ما حساب‌های بدون KYC اجرا می‌کنیم که فقط به یک آدرس برای تحویلِ اطلاعات ورود نیاز دارند. مکاتبات معمولِ کپی‌رایت را به‌عنوان یک مسئلهٔ عملیاتی می‌بینیم نه یک حذفِ خودکار، به احکام معتبر دادگاه در حوزهٔ قضایی‌ای که سرور در آن قرار دارد عمل می‌کنیم، و کفِ سخت‌گیرانه مطلق است و دقیقاً همان‌طور که همه‌جای دیگر اعمال می‌شود اینجا هم اعمال می‌شود: بدون CSAM، بدون محتوای تروریستی، بدون استثنا. پیش از آنکه چیزی بسازید که از جابه‌جاکردنش ناراضی باشید، سیاست استفاده قابل قبول و اینکه چطور گزارش‌های سوءاستفاده را مدیریت می‌کنیم را بخوانید. صفحهٔ VPS دوستدار Tor ما راهنمای پلن‌ها را دارد.

پرسش‌های متداول

آیا برای اجرای یک سایت .onion به یک نام دامنه نیاز دارم؟

نه، و همین بیشترِ نکته است. آدرس از یک کلید روی سرور خودتان در کسری از ثانیه تولید می‌شود، پس ثبت‌کننده‌ای برای خریدنش نیست، تمدیدی برای ازدست‌دادنش نیست، رکورد WHOIS‌ای نیست و کسی با قدرتِ تعلیق‌کردنش نیست. چیزی که از دست می‌دهید خوانایی است: یک آدرس .onion پنجاه‌وشش کاراکتر است که هیچ‌کس نمی‌تواند حفظش کند یا تایپش کند، فقط در Tor Browser یا یک کلاینتِ آگاه از Tor باز می‌شود، و موتورهای جست‌وجو اغلب ایندکسش نمی‌کنند. خیلی‌ها به همین دلیل هر دو را اجرا می‌کنند — یک دامنه برای دسترس‌پذیریِ گسترده و یک آدرس onion برای تداوم. راهنمای ما دربارهٔ ثبت خصوصی دامنه نیمهٔ دیگرِ این جفت را پوشش می‌دهد.

آیا باید یک پورت باز کنم یا port forwarding تنظیم کنم؟

هیچ‌کدام. این همان تفاوت ساختاری بین یک سرویس onion و هاستینگِ معمولی است: سرویس اتصالات خروجی به نقاط معرفی درون شبکهٔ Tor برقرار می‌کند و همان‌جا منتظر کلاینت‌ها می‌ماند، پس هیچ اتصال ورودی‌ای هرگز به سرور شما نمی‌رسد. فایروالی که هر بستهٔ ورودی را رها می‌کند، هیچ اثری رویش ندارد. در عمل این یعنی می‌توانید به ماشینی برسید که اصلاً هیچ‌چیزی روی یک آدرس عمومی گوش نمی‌دهد — از جمله SSH، اگر مثل قدم هفت آدرس onion مخصوص خودش را به آن بدهید — که سطح حملهٔ بسیار کوچک‌تری است از آنچه هر سایتِ به‌شکل معمول میزبانی‌شده می‌تواند به آن برسد.

آیا برای یک آدرس .onion به گواهی HTTPS نیاز دارم؟

تقریباً قطعاً نه. آدرس onion خودش کلید عمومیِ سرویس است، پس اتصال از قبل سرتاسر تا همان نامی که بازدیدکننده تایپ کرده رمزگذاری و احراز هویت شده — چیزی نیست که یک مرجع صدور گواهی بتواند به آن اضافه کند، و Tor Browser مبدأهای .onion را همچون بسترهای امن در نظر می‌گیرد، پس ویژگی‌هایی که به HTTPS نیاز دارند بدون آن هم کار می‌کنند. تعداد کمی از CAها برای یک نام .onion گواهی صادر می‌کنند، که گاهی وقتی نیاز دارید نام یک سازمان در نوار آدرس نشان داده شود یا دارید دارایی‌های onion و آشکار را با هم مخلوط می‌کنید، مفید است. برای یک سایت معمولی، HTTPِ سادهٔ روی یک listenerِ loopback همان پیکربندی درست و معمول است.

چرا سرویس onion من کند است، و می‌توانم سریع‌ترش کنم؟

یک اتصال معمولیِ onion از میان شش رله عبور می‌کند، سه‌تا انتخابِ کلاینت و سه‌تا انتخابِ سرویس شما، و همان رفت‌وبرگشت بیشترِ چیزی است که حس می‌کنید. سه چیز کمک می‌کند. اگر محل سرورتان راز نیست، یک سرویس onion تک‌جهشی سه جهشِ خودتان را به صفر می‌رساند و تأخیر را تقریباً نصف می‌کند — به بخش اجرای هر دو در بالا نگاه کنید، و توجه داشته باشید این تنظیم در سطح کل نمونه است و به‌صراحت حریم خصوصیِ محل سرور را کنار می‌گذارد. دوم، خودِ سایت را سبک کنید: بدون دارایی‌های بیرونی، بدون فونت یا اسکریپتی که از میزبان‌های دیگر گرفته شود، کشِ تهاجمی، چون هر درخواست اضافه دوباره کل هزینهٔ مدار را می‌پردازد. سوم، بررسی کنید سیل‌زده نشده باشید؛ فعال‌کردنِ HiddenServicePoWDefensesEnabled یک سرویس را زیر سوءاستفادهٔ نقطهٔ معرفی قابل‌استفاده نگه می‌دارد، وگرنه دقیقاً شبیه کارایی ضعیف به‌نظر می‌رسید.

می‌توانم همان سایت را هم روی وب آشکار و هم به‌عنوان یک سرویس onion اجرا کنم؟

بله، و برای یک پروژهٔ عمومی ایدهٔ خوبی است — به خواننده‌های پشت سانسور یک مسیرِ ورود می‌دهد و مجبورشان نمی‌کند دامنهٔ شما را ریزالو کنند. اما روشن باشید این دقیقاً چیست: سرویس‌دهیِ محتوای یکسان از هر دو، آن‌ها را به‌سادگی قابل‌پیونددادن می‌کند، پس این یک ویژگیِ دسترس‌پذیری است نه یک ویژگیِ پنهان‌کاری. آدرس را با یک هدر Onion-Location روی سایتِ HTTPS تبلیغ کنید و برای بقیه در فوتر بگذاریدش. اگر محل سرور واقعاً قرار است خصوصی بماند، اصلاً این کار را نکنید؛ سرویس onion را روی ماشینی اجرا کنید که هیچ کار دیگری نمی‌کند، هیچ رکورد DNS‌ای به آن اشاره نمی‌کند و هیچ ایمیلی نمی‌فرستد.

اگر کلید onion را از دست بدهم چه اتفاقی می‌افتد؟

آدرس برای همیشه، برای همه، از بین می‌رود. هیچ فرایند بازیابی‌ای وجود ندارد چون هیچ مرجعی وجود ندارد — نام به‌طور ریاضی از کلیدِ درون /var/lib/tor/<service>/hs_ed25519_secret_key مشتق شده، و بدون آن بایت‌ها هیچ‌کس هرگز نمی‌تواند دوباره زیرش منتشر کند. این همان معاملهٔ نداشتنِ ثبت‌کننده‌ای است که بتواند آن را از شما بگیرد. آن پوشه را رمزگذاری‌شده و بیرون از سرور پشتیبان بگیرید، یک‌بار روی یک ماشینِ یک‌بارمصرف بازیابی‌اش کنید تا مطمئن شوید آدرس برمی‌گردد، و به‌خاطر داشته باشید هر کس آن فایل را به دست بیاورد، خودِ سرویس شما می‌شود، پس همان رفتاری را می‌طلبد که هر کلید خصوصیِ دیگری می‌طلبد.

می‌توانم یک سرویس onion را روی VPSCrypto میزبانی کنم؟

بله، روی هر پلنی، و هیچ چیز خاصی از ما نمی‌خواهد: یک سرویس onion هیچ پورت ورودی‌ای باز نمی‌کند و هیچ ترافیک سوءاستفاده‌ای علیه IP شما تولید نمی‌کند، که آن را یکی از آرام‌ترین چیزهایی می‌کند که می‌توانید اجرا کنید. حساب‌ها بدون KYC هستند و فقط به یک آدرس برای تحویلِ اطلاعات ورود نیاز دارند، تسویه‌حساب on-chain با Monero به‌عنوان گزینهٔ درجه‌یک انجام می‌شود، و سروری حدود یک دقیقه‌ای زنده می‌شود. کفِ سوءاستفاده دقیقاً همان‌طور که همه‌جای دیگر اعمال می‌شود اینجا هم اعمال می‌شود — بدون CSAM، بدون محتوای تروریستی، بدون استثنا — و ما به احکام معتبر دادگاه در حوزهٔ قضاییِ سرور عمل می‌کنیم. برای راهنمای پلن‌ها به صفحهٔ VPS دوستدار Tor ما و برای بقیه به سیاست استفاده قابل قبول مراجعه کنید.

میزبانی یک سایت .onion روی یک VPS بدون لو دادن سرور

یک سرویس onion چه چیزی را از پشته حذف می‌کند

رله، پل، خروجی، سرویس onion: چهار وظیفهٔ متفاوت

Tor تقریباً هرگز چیزی نیست که نشت می‌کند

اول تصمیم بگیرید: آیا محل سرور یک راز است؟

گام به گام

اجرای همان سایت هم روی وب آشکار و هم به‌عنوان یک onion

مجوزدهی کلاینت: وقتی آدرس همان اعتبارنامه است

زنده نگه‌داشتنش: DoS، ساعت‌ها و آپ‌تایم

محدودیت‌های صادقانه

پرسش‌های متداول

کاوش بیشتر.

در حدود یک دقیقه یک VPS آفشور راه‌اندازی کنید

پنل کاربری

یک سرویس onion چه چیزی را از پشته حذف می‌کند#

رله، پل، خروجی، سرویس onion: چهار وظیفهٔ متفاوت#

Tor تقریباً هرگز چیزی نیست که نشت می‌کند#

اول تصمیم بگیرید: آیا محل سرور یک راز است؟#

گام به گام#

اجرای همان سایت هم روی وب آشکار و هم به‌عنوان یک onion#

مجوزدهی کلاینت: وقتی آدرس همان اعتبارنامه است#

زنده نگه‌داشتنش: DoS، ساعت‌ها و آپ‌تایم#

محدودیت‌های صادقانه#

پرسش‌های متداول#

کاوش بیشتر.

در حدود یک دقیقه یک VPS آفشور راه‌اندازی کنید

یک سرویس onion چه چیزی را از پشته حذف می‌کند

رله، پل، خروجی، سرویس onion: چهار وظیفهٔ متفاوت

Tor تقریباً هرگز چیزی نیست که نشت می‌کند

اول تصمیم بگیرید: آیا محل سرور یک راز است؟

گام به گام

اجرای همان سایت هم روی وب آشکار و هم به‌عنوان یک onion

مجوزدهی کلاینت: وقتی آدرس همان اعتبارنامه است

زنده نگه‌داشتنش: DoS، ساعت‌ها و آپ‌تایم

محدودیت‌های صادقانه

پرسش‌های متداول