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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

نصب یک نسخه مشخص (Pinned) به جای نسخه "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 این پروژه، رله‌ها هیچ‌گونه متادیتای فایلی ندارند: آن‌ها تنها تکه‌های مجزای فایل (chunk) را مشاهده می‌کنند که هر کدام 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' تعهدی در مورد فضای دیسک در دسترس شماست. رله فایل بخشی است که بیشترین مصرف دیسک و پهنای باند را دارد. رله پیام (message relay) تقریباً هیچ‌کدام از این دو منبع را به میزان قابل توجهی مصرف نمی‌کند.

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

دو دایرکتوری اهمیت دارند. /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

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

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

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

انتقال SMP از یک مرجع صدور گواهی (CA) عمومی استفاده نمی‌کند. فرآیند Init یک مرجع خصوصی و یک گواهی سرور تولید می‌کند و اثر انگشت (fingerprint) آن مرجع در آدرس سرور قرار می‌گیرد. کلاینت آنچه را که سرور ارائه می‌دهد با آن اثر انگشتِ پین‌شده مطابقت می‌دهد؛ این همان چیزی است که پروژه آن را محافظت از اتصال کلاینت به سرور در برابر حملات machine-in-the-middle می‌نامد. هیچ کلاینت ACME (محیط مدیریت خودکار گواهی) برای اجرا روی آن پورت وجود ندارد و چرخش گواهی (rotation) یک عملیات دستی است که با اجرای 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 نصب می‌کند و یک سرویس مخفی (hidden service) در /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) آن در تمام لینک‌های دعوتی که از طریق آن می‌فرستید وجود دارد. یک رله عمومی شلوغ از این نظر شما را بهتر پنهان می‌کند و این همان معامله واقعی است.
• در دسترس بودن اکنون به عهده شماست. پر شدن دیسک یا خرابی سرور به معنای توقف تحویل پیام‌هاست و مخاطبان شما راهی برای دور زدن شما ندارند.

همین استدلال برای هر سرویس خصوصی که روی سرور شخصی خود قرار می‌دهید صدق می‌کند، خواه این رله باشد یا یک 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] تنظیم کرده‌اید، آدرس نیز باید شامل آن رمز عبور باشد، در غیر این صورت کلاینت اجازه ایجاد صف (queue) را نخواهد داشت.

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

FAQ

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

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

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

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

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

برای یک راه‌اندازی کاربردی به دامنه نیاز دارید، و smp-server init در صورتی که واقعاً دامنه‌ای ندارید، --ip را می‌پذیرد. برای پورت پیام‌رسانی نیازی به گواهی از یک مرجع عمومی ندارید: دستور init مرجع گواهی مخصوص خود را تولید می‌کند و کلاینت، اثر انگشت (fingerprint) ظاهر شده در آدرس smp:// شما را پین می‌کند. گواهی مورد اعتماد عمومی تنها برای صفحه اطلاعات وب اختیاری نیاز است که در بخش [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 دیگر منتقل کنید. همچنین سهمیه ذخیره‌سازی را متناسب با دیسکی که واقعاً در اختیار دارید تعیین کنید، زیرا رله فایل مؤلفه‌ای است که دیسک و پهنای باند مصرف می‌کند.