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

کارکرد سرور چت SimpleX در حالت self-hosted

برای میزبانی شخصی (self-hosting) یک سرور چت SimpleX، شما یک دیمون را روی یک VPS اجرا می‌کنید: smp-server، که نقش رله برای SMP (پروتکل پیام‌رسانی SimpleX) را دارد. این دیمون صف‌های پیام را که مخاطبین شما در آن می‌نویسند و از آن می‌خوانند، نگهداری می‌کند. یک دیمون دوم و اختیاری به نام xftp-server وظیفه رله کردن انتقال فایل‌ها را بر عهده دارد. هر دو از یک پروژه واحد به نام simplexmq می‌آیند و هر کدام شامل یک فایل باینری تکی، یک فایل پیکربندی و یک لاگ با قابلیت append-only هستند.

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

تمامی دستورات، مسیرها، پورت‌ها و فلگ‌های زیر از مستندات خود پروژه استخراج شده‌اند: صفحه میزبانی سرور SMP، صفحه سرور XFTP و سند امنیت پروتکل. در مواردی که یک عدد اهمیت دارد، منبع آن در کنارش ذکر شده است.

چرا شبکه‌ای بدون شناسه‌های کاربری همچنان به رله‌ها نیاز دارد

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

این صف‌ها به یک دلیل ساده باید در جایی میزبانی شوند. به ندرت پیش می‌آید که دو گوشی همزمان آنلاین باشند. چیزی باید پیام را در لحظه دریافت کند و نگه دارد تا دستگاه دیگر آن را درخواست کند. این تمام وظیفه یک رله SMP است. این موضوع همچنین به این معناست که دو دستگاه هرگز مستقیماً به یکدیگر متصل نمی‌شوند، بنابراین هیچ‌کدام آدرس IP (پروتکل اینترنت) دیگری را متوجه نمی‌شود. رله این افشای اطلاعات را به جای آن‌ها بر عهده می‌گیرد.

نام میزبان (hostname) رله بخشی از آدرس صف است، بنابراین در هر لینک دعوتی که از طریق آن ارسال می‌کنید وجود دارد. هنگام مطالعه مدل تهدید در انتهای این مستند، این نکته را در نظر داشته باشید.

آنچه یک رله می‌تواند و نمی‌تواند ببیند

پروژه این موضوع را به عنوان یک مدل تهدید در protocol/security.md بیان می‌کند و پیش از نصب هر چیزی، ارزش خواندن دارد؛ چرا که پس از این راهنما، آن رله متعلق به شما خواهد بود. یک رله، حتی اگر کاملاً تحت کنترل یک مهاجم باشد، نمی‌تواند محتوا یا نوع پیام‌ها را بفهمد، نمی‌تواند پیام‌های تکی را به‌طور غیرقابل‌تشخیص اضافه، تکثیر یا مخدوش کند و نمی‌تواند با یک حمله فعال، رمزنگاری سرتاسری (end-to-end) را بشکند.

همان صفحه، کارهایی که یک رله می‌تواند انجام دهد را فهرست کرده است. رله می‌تواند بفهمد گیرندهٔ یک صف چه زمانی آنلاین است. می‌تواند تعداد پیام‌های عبوری از یک صف را بشمارد. می‌تواند آدرس IP گیرنده را یاد بگیرد. همچنین می‌تواند تمام پیام‌های آینده در یک صف را حذف کند یا دربارهٔ وضعیت آن صف دروغ بگوید.

بنابراین مرز کاملاً مشخص است. محرمانگی وظیفهٔ کلاینت است و self-hosting تأثیری بر آن ندارد. متادیتا و در دسترس بودن (availability) وظیفهٔ اپراتور رله است و self-hosting هر دوی این موارد را به شما واگذار می‌کند.

پیش‌نیازهای شروع کار

• یک سرور مجازی (VPS) با سیستم‌عامل Ubuntu 22.04 یا 24.04. این پروژه فایل‌های اجرایی (binaries) خود را دقیقاً برای همین دو نسخه و برای معماری‌های x86-64 و aarch64 منتشر می‌کند.
• یک نام دامنه که رکورد A آن به VPS اشاره داشته باشد؛ اگر از IPv6 استفاده می‌کنید، یک رکورد AAAA نیز اضافه کنید. در این مستندات از smp1.example.com به عنوان نمونه استفاده شده است.
• دسترسی root یا sudo، و یک نشست SSH دوم که هنگام تغییر تنظیمات فایروال باز باشد.
• فضایی خارج از سرور برای ذخیره نسخه پشتیبان، زیرا دایرکتوری پیکربندی، هویت سرور شما محسوب می‌شود.

در نمونه‌های ARM، به جای x86-64 از دارایی aarch64 استفاده کنید. هیچ بخش دیگری از این راهنما تغییر نمی‌کند و انتخاب بین پلن‌های VPS با معماری ARM و x86 تنها به قیمت و سرعت هر هسته مربوط است، نه به قابلیت اجرای این نرم‌افزار.

نصب یک نسخه مشخص (Pinned Release) به جای نسخه "latest"

این پروژه یک اسکریپت نصب ارائه می‌دهد که آخرین نسخه موجود را دریافت کرده و دستور simplex-servers-update را ثبت می‌کند. این روش کار می‌کند، اما با این وجود نسخه را ثابت (Pin) کنید: رله‌ای که فایل اجرایی آن بدون اطلاع شما تغییر کند، رله‌ای است که هنگام بروز مشکل نمی‌توانید رفتار آن را تحلیل کنید.

از اوت 2026، نسخه فعلی simplexmq برابر با v6.5.0 است که در 29 آوریل 2026 منتشر شده است. برای یافتن تگ مورد نظر خود، صفحه نسخه‌ها را بررسی کنید و سپس از آن تگ در تمام مراحل زیر استفاده کنید.

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp هیچ رمز عبوری تنظیم نمی‌کند، بنابراین هیچ‌کس مستقیماً با نام کاربری smp وارد نمی‌شود. پیش از اجرای هر دستور دیگری، این دو دایرکتوری را خودتان ایجاد کنید، زیرا /etc/opt متعلق به root است و با دسترسی 755 تنظیم شده است؛ این یعنی کاربر smp جایی برای نوشتن دایرکتوری پیکربندی خود ندارد.

VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-server

آن هش را با چک‌سام‌های SHA2-256 که در یادداشت‌های انتشار برای همان تگ منتشر شده است، مقایسه کنید. این پروژه همچنین چک‌سام‌های انتشار را با کلید SimpleX Chat به شماره FB44AF81A45BDE327319797C85107E357D4A17FC امضا می‌کند که در صفحه سرور مستند شده است؛ بنابراین می‌توانید به جای اعتماد به صفحه‌ای که هش را از آن خوانده‌اید، امضا را تأیید کنید.

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

آن را عمداً با مالکیت root نصب کنید. این سرویس با کاربر smp اجرا می‌شود، بنابراین در صورت نفوذ به سرویس، مهاجم نمی‌تواند فایل اجرایی که سرویس از آن شروع شده است را بازنویسی کند.

راه‌اندازی اولیه سرور و دو secret تولیدشده

sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"

• --store-log (-l) یک لاگ append-only از صف‌ها را در /var/opt/simplex/smp-server-store.log می‌نویسد تا relay پس از راه‌اندازی مجدد (restart) باقی بماند. بدون این گزینه، هر بار restart باعث حذف تمام صف‌ها می‌شود و در نتیجه، تمام ارتباطاتی که از طریق شما مسیریابی می‌شوند، قطع خواهند شد.
• --daily-stats (-s) شمارنده‌ها را به فرمت CSV در /var/opt/simplex/smp-server-stats.daily.log می‌نویسد.
• --fqdn دامنه شما را در گواهی تولیدشده قرار می‌دهد. اگر دامنه‌ای ندارید، از --ip استفاده کنید.
• --no-password به هر کسی اجازه می‌دهد روی relay شما صف ایجاد کند. برای خصوصی نگه‌داشتن آن، پس از اجرای init، مقدار create_password را در بخش [AUTH] از فایل /etc/opt/simplex/smp-server.ini تنظیم کنید. این کار بهتر از ارسال --password در اینجا است، زیرا دستورات خط فرمان در تاریخچه shell و لیست پردازش‌های در حال اجرا قابل مشاهده هستند.

دستور init یک گواهی تولید کرده و دو مقداری که باید حفظ کنید را نمایش می‌دهد. مقدار اول، fingerprint است؛ یک رشته base64 که در /etc/opt/simplex/fingerprint نیز نوشته می‌شود. مقدار دوم، آدرس کامل سرور است که از ترکیب fingerprint و نام میزبان (hostname) شما تشکیل شده است. هر دو را اکنون کپی کنید.

دستور init همچنین فایل /etc/opt/simplex/ca.key را ایجاد می‌کند. مستندات توصیه می‌کنند این فایل را به یک فضای ذخیره‌سازی آفلاین منتقل کنید. دلیل این کار مهم است: کلاینت‌ها fingerprint این مرجع صدور گواهی (CA) را pin می‌کنند؛ بنابراین هر کسی که ca.key را در اختیار داشته باشد، می‌تواند گواهی سرور جدیدی صادر کند که کلاینت‌های شما آن را به عنوان گواهی شما بپذیرند. شما تنها زمانی به این فایل نیاز دارید که بخواهید بعداً گواهی سرور را با استفاده از smp-server cert تغییر دهید (rotate).

عملیات init را به عنوان یک مرحله یک‌باره در نظر بگیرید. fingerprint موجود در آدرس شما از مرجع صدور گواهی تولیدشده توسط همین دستور می‌آید؛ بنابراین تولید مجدد آن مرجع، آدرس جدیدی به شما می‌دهد و آدرسی که قبلاً به دیگران داده‌اید، از دسترس خارج می‌شود.

اجرای آن تحت systemd به عنوان یک کاربر بدون دسترسی ویژه

عبارت /etc/systemd/system/smp-server.service را دقیقاً همان‌طور که در مستندات آمده است بنویسید:

[Unit]
Description=SMP server systemd service

[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity

[Install]
WantedBy=multi-user.target

فایل unit بالادستی شامل AmbientCapabilities=CAP_NET_BIND_SERVICE نیز هست. این خط به این دلیل وجود دارد که پردازش به عنوان smp اجرا می‌شود و پورت‌های زیر 1024 برای یک پردازش غیر-root بسته هستند؛ بنابراین بدون آن، daemon نمی‌تواند روی پورت‌های 80 یا 443 گوش دهد. اگر قصد دارید از این پورت‌ها استفاده کنید، آن را اضافه کنید. LimitNOFILE=65535 اهمیت دارد زیرا هر کلاینت مشترک، یک اتصال TCP باز نگه می‌دارد و حد پیش‌فرض بسیار کمتر از مقداری است که یک relay پرمشغله نیاز دارد. ExecStopPost لاگ ذخیره‌شده را در هر بار توقف به یک فایل .bak کپی می‌کند که یک نقطه بازگشت (rollback) رایگان در اختیار شما قرار می‌دهد.

sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-server

یک شروع موفق، آدرس سرور را در لاگ ثبت می‌کند. سپس تأیید کنید که سوکت‌ها واقعاً باز هستند:

sudo ss -tlnp | grep -E ':(443|5223)'

هر دو خط باید smp-server را نشان دهند. اجرای daemon تحت حساب کاربری اختصاصی خود و بدون دسترسی sudo، همان عادتی است که در حساب‌های کاربری اختصاصی برای هر سرویس در VPS توضیح داده شد و این همان چیزی است که مانع از تبدیل شدن یک باگ در یک شبکه daemon به یک root shell می‌شود.

کدام پورت‌ها را باز کنیم و کدام را بسته نگه داریم

مستندات سه پورت را فهرست کرده‌اند: 5223/tcp، 443/tcp و 80/tcp. پورت 5223 برای انتقال SMP است. پیکربندی پیش‌فرض، port: 5223,443 را تحت [TRANSPORT] تنظیم می‌کند، بنابراین همین پروتکل روی 443 نیز پاسخگو است؛ این موضوع اهمیت دارد زیرا بسیاری از شبکه‌های محدودکننده، ترافیک خروجی روی پورت 443 را مجاز می‌دانند و هیچ پورت دیگری را باز نمی‌گذارند. پورت 80 تنها برای صفحه اطلاعات اختیاری و هدایت (redirect) آن به HTTPS مورد نیاز است.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

پورت 5224 را باز نکنید. این پورت کنترل است و مستندات توصیه می‌کنند از داخل خود سرور با استفاده از nc 127.0.0.1 5224 به آن دسترسی پیدا کنید. این پورت وضعیت سرور را چاپ کرده و صف‌ها را حذف می‌کند، بنابراین باید روی loopback باقی بماند و رمزهای عبور مدیر و کاربر نیز تحت [AUTH] تنظیم شده باشند. اگر با این ابزار تازه‌کار هستید، اصول اولیه ufw روی VPS ترتیب قوانین و نحوه جلوگیری از مسدود کردن دسترسی خودتان را پوشش می‌دهد.

یک مورد کنترلی دیگر وجود دارد که اغلب کاربران را غافلگیر می‌کند. اکثر ارائه‌دهندگان خدمات، یک فایروال شبکه در پنل مدیریتی خود دارند که از ufw روی سرور مجزا است. ممکن است پورتی در ufw باز باشد، اما پیش از رسیدن به سرور شما توسط فایروال شبکه مسدود شود.

آدرس سروری که کلاینت‌های شما به آن نیاز دارند

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

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

یک رفتار مستندشده وجود دارد که همه را غافلگیر می‌کند. افزودن سرور در برنامه، فقط بر مخاطبانی تأثیر می‌گذارد که از آن لحظه به بعد ایجاد می‌کنید. مخاطبان موجود در همان رله‌هایی (relays) باقی می‌مانند که صف‌های آن‌ها روی آن ایجاد شده است و مهاجرت نمی‌کنند. به همین دلیل است که نمی‌توانید یک رله را درست یک روز پس از جایگزینی آن خاموش کنید.

افزودن یک رله فایل XFTP

پروتکل XFTP (پروتکل انتقال فایل SimpleX) بخش فایل‌محور شبکه است و به عنوان یک دیمون (daemon) مجزا با آدرس اختصاصی خود عمل می‌کند. طبق اطلاعیه XFTP این پروژه، رله‌ها هیچ‌گونه متادیتای فایلی ندارند: آن‌ها تنها تکه‌های مجزای فایل را مشاهده می‌کنند که هر کدام 256kb، 1mb یا 4mb هستند و دسترسی به آن‌ها با اعتبارنامه‌های ناشناس مجاز می‌شود. فرستنده می‌تواند تکه‌های یک فایل را بین چندین رله پخش کند، بنابراین سرور شما فقط قطعاتی از فایل را نگهداری می‌کند، نه کل فایل را.

sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"

فایل پیکربندی آن در /etc/opt/simplex-xftp/، وضعیت آن در /var/opt/simplex-xftp/ و تکه‌های فایل در مسیری که -p تعیین می‌کند قرار دارند. یونیت systemd آن با User=xftp و ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS ساختار مشابهی دارد. فرآیند Init یک آدرس xftp:// را با همان فرمت آدرس SMP چاپ می‌کند که اثر انگشت (fingerprint) اختصاصی خود را در /etc/opt/simplex-xftp/fingerprint دارد.

باید برای یک تداخل احتمالی برنامه‌ریزی کنید. پورت مستندشده برای سرور XFTP برابر با 443 است و پیکربندی SMP نیز پورت 443 را لیست می‌کند. دو فرآیند نمی‌توانند همزمان یک پورت را روی یک آدرس واحد bind کنند، بنابراین در یک VPS باید یکی از آن‌ها تغییر کند. ساده‌ترین راه حل، تنظیم port: 5223 در بخش [TRANSPORT] مربوط به SMP و اختصاص پورت 443 به رله فایل است؛ این کار باعث می‌شود کلاینت‌هایی که در شبکه‌های محدود هستند، قابلیت fallback روی پورت 443 را از دست بدهند. گزینه‌های جایگزین، استفاده از یک آدرس IP دوم روی همان VPS یا تهیه یک VPS دوم است.

سهمیه (quota) را صادقانه تعیین کنید. -q '20gb' تعهدی در مورد فضای دیسک در دسترس شماست. رله فایل بخشی است که بیشترین مصرف دیسک و پهنای باند را دارد، در حالی که رله پیام تأثیر ناچیزی بر هر دو دارد.

چه چیزی روی دیسک ذخیره می‌شود و یک نسخه پشتیبان چه چیزی را بازیابی می‌کند

دو دایرکتوری اهمیت دارند. /etc/opt/simplex/ هویت سرور است: smp-server.ini، گواهی و کلید سرور، ca.key، و fingerprint. /var/opt/simplex/ وضعیت سرور است: smp-server-store.log صف‌ها و در صورت restore_messages: on، پیام‌های تحویل‌نشده را به همراه فایل آمار روزانه نگهداری می‌کند.

sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-server

دقیق باشید که این آرشیو چیست. این یک آرشیو پیام نیست: موارد موجود در صف، متن‌های رمزنگاری‌شده‌ای هستند که کلیدهای آن هرگز در اختیار relay نبوده است و فایل پیکربندی [STORE_LOG] که همراه نرم‌افزار ارائه می‌شود، به‌هرحال پیام‌ها را پس از 21 روز منقضی می‌کند. این آرشیو، کپی هویت سرور است که ca.key نیز در آن گنجانده شده؛ بنابراین هر کسی که این فایل را در اختیار داشته باشد، می‌تواند خود را به عنوان relay شما به مخاطبانتان معرفی کند. آن را رمزنگاری کنید و خارج از سرور نگهداری نمایید.

مزیت این کار در بازیابی است. کافی است /etc/opt/simplex را روی یک VPS جدید قرار دهید و همان نام DNS را به آن اشاره دهید؛ اثر انگشت (fingerprint) بدون تغییر باقی می‌ماند و در نتیجه، تمام آدرس‌هایی که توزیع کرده‌اید همچنان کار می‌کنند. اگر این دایرکتوری را از دست بدهید، هیچ راه بازیابی وجود ندارد: نصب جدید به معنای اثر انگشت جدید است، که یعنی آدرس جدید، و این یعنی تمام مخاطبانی که از طریق relay شما مسیریابی می‌شدند، از دست رفته‌اند.

TLS: دو گواهی با وظایف متفاوت

انتقال SMP از یک مرجع صدور گواهی (CA) عمومی استفاده نمی‌کند. فرآیند Init یک مرجع خصوصی و یک گواهی سرور تولید می‌کند و اثر انگشت (fingerprint) آن مرجع در آدرس سرور گنجانده می‌شود. کلاینت آنچه را که سرور ارائه می‌دهد با آن اثر انگشتِ پین‌شده تطبیق می‌دهد؛ این همان چیزی است که پروژه آن را محافظت از اتصال کلاینت به سرور در برابر حملات machine-in-the-middle می‌نامد. هیچ کلاینت ACME (محیط مدیریت خودکار گواهی) برای اجرا روی آن پورت وجود ندارد و چرخش گواهی یک عملیات دستی است که با اجرای smp-server cert و تنظیم SMP_SERVER_CFG_PATH انجام می‌شود.

صفحه اطلاعات اختیاری، گواهی دوم را به کار می‌گیرد. بخش [WEB] در آن، static_path، https: 443، cert: /etc/opt/simplex/web.crt و key: /etc/opt/simplex/web.key را نام‌گذاری می‌کند. مرورگرها مرجع خصوصی شما را نمی‌شناسند، بنابراین این تنها جایی است که یک گواهی با اعتبار عمومی در آن کاربرد دارد. راهنمای سریع Docker در مستندات، Caddy را دقیقاً برای همین منظور در مقابل سرور قرار می‌دهد تا گواهی را به‌صورت خودکار صادر کند.

دسترسی به رله از طریق Tor

مستندات شامل بخشی درباره Tor است که Tor را از مخزن Tor Project نصب کرده و یک سرویس مخفی را در /etc/tor/torrc اضافه می‌کند:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

دو خط mode را با دقت مطالعه کنید. Single hop و non-anonymous به این معنی است که موقعیت مکانی خودِ رله مخفی نمی‌ماند. آدرس onion سریع است و به کلاینت‌ها راهی برای ورود می‌دهد که هرگز IP آن‌ها را برای شما فاش نمی‌کند، اما خودِ سرور همچنان از طریق IP عمومی‌اش قابل‌ردیابی است. نام میزبان onion از /var/lib/tor/simplex-smp/hostname در انتهای آدرس سرور و پس از یک کاما قرار می‌گیرد. اگر می‌خواهید موقعیت مکانی سرور نیز مخفی بماند، پیکربندی متفاوتی نیاز است و اجرای یک سرویس onion واقعی روی VPS این موضوع را پوشش می‌دهد. تفاوت در آنچه هر ابزار مخفی می‌کند، موضوع مقایسه Tor با VPN است و مستقیماً در اینجا کاربرد دارد.

مدل تهدید: خود-میزبانی چه چیزی را تغییر می‌دهد

آنچه به دست می‌آورید. متادیتا (اینکه چه صف‌هایی وجود دارند، چه زمانی خوانده می‌شوند، کدام آدرس‌ها متصل می‌شوند) روی ماشینی قرار می‌گیرد که کنترل آن با شماست و شما تعیین می‌کنید هر کدام از این داده‌ها تا چه مدت نگهداری شوند. همچنین شما دیگر بخشی از یک مجموعه بزرگ نیستید که بتوان اطلاعات کل آن را یک‌جا درخواست کرد.

آنچه به دست نمی‌آورید، به زبان ساده:

• رمزنگاری تغییری نمی‌کند. پیام‌ها پیش از آنکه این سیستم را بسازید رمزنگاری سرتاسری (end-to-end) بودند و پس از آن نیز هستند. خود-میزبانی تصمیمی در حوزه متادیتا است، نه تصمیمی در حوزه رمزنگاری.
• ارائه‌دهنده VPS شما، ترافیک ورودی به آدرس IP شما را می‌بیند و جزئیات پرداخت شما را در اختیار دارد. شما اعتماد را از یک اپراتور پیام‌رسان به یک اپراتور میزبانی منتقل کرده‌اید. شما آن را حذف نکرده‌اید.
• رله (relay) شما یک گروه کوچک است. اگر این رله تنها به یک خانوار خدمات‌رسانی کند، اتصال به آن باعث شناسایی آن خانوار می‌شود و نام میزبان (hostname) آن در تمام لینک‌های دعوتی که از آن ارسال می‌کنید، وجود دارد. یک رله عمومی شلوغ، از این نظر شما را بهتر پنهان می‌کند و این همان بده‌بستان واقعی است. یک سرور جستجوی خصوصی نیز همین وضعیت را دارد، به همین دلیل است که آنچه SearXNG واقعاً روی VPS شخصی شما پنهان می‌کند به تعداد افرادی بستگی دارد که نمونه (instance) را با شما به اشتراک می‌گذارند.
• پایداری اکنون بر عهده شماست. پر شدن دیسک یا از کار افتادن سرور به معنای توقف تحویل پیام‌هاست و مخاطبان شما راهی برای دور زدن شما ندارند.

همین استدلال برای هر سرویس خصوصی که روی سرور شخصی خود قرار می‌دهید صادق است، خواه این رله باشد یا یک WireGuard VPN روی VPS شخصی شما. شما در حال انتخاب این هستید که کدام طرف متادیتا را ببیند. شما باعث ناپدید شدن آن نمی‌شوید.

هنگامی که کار نمی‌کند

سرویس شروع می‌شود و بلافاصله متوقف می‌گردد. sudo journalctl -u smp-server -n 50 را بخوانید. خطای bind نام پورتی را که نتوانسته اشغال کند، اعلام می‌کند. سپس sudo ss -tlnp | grep :443 را اجرا کنید تا ببینید کدام پردازش در حال حاضر آن پورت را در اختیار دارد؛ در یک سرور تازه، این معمولاً nginx، Caddy یا سرور XFTP است که یک ساعت پیش نصب کرده‌اید.

Init نمی‌تواند فایل پیکربندی خود را بنویسد. اجرای smp-server init با کاربر smp پیش از آنکه /etc/opt/simplex وجود داشته باشد، منجر به خطای مجوز می‌شود، زیرا مالکیت /etc/opt متعلق به root است. ابتدا دایرکتوری را با مالک صحیح ایجاد کنید و سپس init را دوباره اجرا کنید.

کلاینت‌ها نمی‌توانند به relay دسترسی پیدا کنند. با استفاده از dig +short smp1.example.com بررسی کنید که نام دامنه به آدرس صحیح ترجمه می‌شود. سپس پورت را از لپ‌تاپ خود تست کنید، نه از داخل سرور: nc -vz smp1.example.com 5223. اتصالی که از خارج ناموفق است، در حالی که ss نشان می‌دهد سوکت روی سرور باز است، به فایروال شبکه ارائه‌دهنده اشاره دارد که کنترلی جدا از ufw است.

یک مخاطب نمی‌تواند از طریق relay شما متصل شود. اثر انگشت (fingerprint) در آدرسی که به اشتراک گذاشته‌اید باید با محتوای فعلی /etc/opt/simplex/fingerprint مطابقت داشته باشد. اگر create_password را در بخش [AUTH] تنظیم کرده‌اید، آدرس نیز باید شامل آن رمز عبور باشد، در غیر این صورت کلاینت اجازه ایجاد صف را نخواهد داشت.

پس از افزودن سرور در اپلیکیشن، هیچ اتفاقی نیفتاد. این رفتار مورد انتظار است. فقط مخاطبین جدید از relay تازه اضافه‌شده استفاده می‌کنند. مخاطبین موجود، صف‌هایی را که از قبل دارند حفظ می‌کنند.

FAQ

آیا میزبانی شخصی (self-hosting) سرور SimpleX امنیت پیام‌های من را افزایش می‌دهد؟

خیر، و این موضوع بخشی از طراحی سیستم است. SimpleX پیام‌ها را به‌صورت سرتاسری (end-to-end) بین دستگاه‌ها رمزنگاری می‌کند، بنابراین رله (relay) هرگز به کلیدها دسترسی ندارد، فارغ از اینکه چه کسی آن را اجرا می‌کند. میزبانی شخصی تنها مشخص می‌کند چه کسی متادیتای پیرامون پیام‌ها را مشاهده می‌کند: اینکه چه صف‌هایی وجود دارند، چه زمانی خوانده می‌شوند و کدام آدرس‌های IP متصل هستند. این یک تصمیم در سطح متادیتا است. اگر دلیل شما برای میزبانی شخصی، رمزنگاری قوی‌تر است، باید بدانید که آن رمزنگاری از قبل وجود داشته است.

یک اپراتور رله SimpleX واقعاً چه چیزی را می‌تواند ببیند؟

پروژه در protocol/security.md این موضوع را مشخص کرده است. یک رله نمی‌تواند محتوا یا نوع پیام‌ها را بخواند، نمی‌تواند پیام‌های تکی را به‌طور نامحسوس تغییر دهد و نمی‌تواند با یک حمله فعال، رمزنگاری سرتاسری را بشکند. رله می‌تواند ببیند چه زمانی گیرندهٔ یک صف آنلاین است، تعداد پیام‌های عبوری از یک صف را بشمارد، آدرس IP گیرنده را یاد بگیرد، پیام‌های بعدی در یک صف را حذف کند یا درباره وضعیت آن صف دروغ بگوید. این‌ها قدرت‌هایی هستند که پس از در اختیار گرفتن رله، به دست می‌آورید.

آیا به نام دامنه و گواهی TLS نیاز دارم؟

برای یک راه‌اندازی کاربردی به دامنه نیاز دارید، و smp-server init در صورتی که واقعاً دامنه‌ای ندارید، --ip را می‌پذیرد. برای پورت پیام‌رسانی نیازی به گواهی از یک مرجع عمومی ندارید: init مرجع خودش را تولید می‌کند و کلاینت، اثر انگشتی (fingerprint) که در آدرس smp:// شما ظاهر می‌شود را پین (pin) می‌کند. گواهی مورد اعتماد عمومی تنها برای صفحه اطلاعات وب اختیاری نیاز است که در بخش [WEB] از smp-server.ini به‌عنوان cert و key پیکربندی می‌شود.

اگر /etc/opt/simplex را گم کنم چه اتفاقی می‌افتد؟

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

آیا می‌توانم رله SMP و رله فایل XFTP را روی یک VPS اجرا کنم؟

بله، با یک تداخل که باید حل شود. پورت مستندشده برای سرور XFTP برابر با 443 است و پیکربندی پیش‌فرض SMP نیز port: 5223,443 را لیست می‌کند، بنابراین هر دو به یک سوکت نیاز دارند. پورت 443 را به یکی از آن‌ها اختصاص دهید: برای سرور SMP مقدار port: 5223 را تنظیم کنید، یا رله فایل را به یک آدرس IP دوم یا یک VPS دوم منتقل کنید. همچنین سهمیه ذخیره‌سازی را متناسب با دیسکی که واقعاً در اختیار دارید تنظیم کنید، زیرا رله فایل مؤلفه‌ای است که دیسک و پهنای باند مصرف می‌کند.