Własny serwer SimpleX na VPS: konfiguracja krok po kroku

Funkcja własnego serwera czatu SimpleX

Aby uruchomić własny serwer czatu SimpleX, należy uruchomić na serwerze VPS jeden demon: smp-server, który pełni rolę przekaźnika dla SMP (simplex messaging protocol). Przechowuje on kolejki wiadomości, do których zapisują i z których odczytują dane kontakty. Drugi, opcjonalny demon o nazwie xftp-server, obsługuje przesyłanie plików. Oba pochodzą z tego samego projektu, simplexmq, a każdy z nich składa się z pojedynczego pliku binarnego, pliku konfiguracyjnego oraz dziennika typu append-only.

Niniejszy tekst jest przeznaczony dla administratora, a nie użytkownika końcowego aplikacji. Przekaźnik nie przechowuje kont, list kontaktów ani historii czatów. Przechowuje jedynie kolejki, pewną ilość niedostarczonych wiadomości w formie szyfrogramów oraz certyfikat identyfikujący serwer. Obowiązkiem administratora jest zapewnienie dostępności usługi, niewielkiej ilości miejsca na dysku oraz zarządzanie metadanymi przepływającymi przez serwer.

Każde polecenie, ścieżka, port i flaga poniżej pochodzą z oficjalnej dokumentacji projektu: strony hostingu serwera SMP, strony serwera XFTP oraz dokumentu dotyczącego bezpieczeństwa protokołu. W miejscach, gdzie istotna jest konkretna wartość liczbowa, obok podano źródło, z którego pochodzi.

Dlaczego sieć bez identyfikatorów użytkowników nadal wymaga przekaźników

SimpleX nie używa nazw użytkowników, numerów telefonów ani identyfikatorów kont. Kontakt jest jednokierunkową kolejką: adresem na wybranym przekaźniku, do którego jedna strona zapisuje dane, a druga je odczytuje. Dwa kontakty użytkownika nie współdzielą żadnego identyfikatora, który serwer mógłby powiązać.

Te kolejki muszą jednak gdzieś istnieć z prostego powodu. Dwa telefony rzadko są online w tym samym momencie. Coś musi przyjąć wiadomość teraz i przechować ją do czasu, aż drugie urządzenie o nią zapyta. To całe zadanie przekaźnika SMP. Oznacza to również, że oba urządzenia nigdy nie łączą się ze sobą bezpośrednio, więc żadne z nich nie poznaje adresu IP (internet protocol) drugiego. Przekaźnik przejmuje na siebie to ryzyko ujawnienia danych.

Nazwa hosta przekaźnika jest częścią adresu kolejki, więc znajduje się w każdym linku zaproszenia udostępnianym z jego poziomu. Należy o tym pamiętać podczas analizy modelu zagrożeń pod koniec dokumentacji.

Co przekaźnik może, a czego nie może zobaczyć

Projekt określa to jako model zagrożeń w protocol/security.md i warto się z nim zapoznać przed instalacją, ponieważ po zakończeniu tego przewodnika przekaźnik będzie należał do użytkownika. Przekaźnik, w tym taki w pełni kontrolowany przez atakującego, nie może poznać zawartości ani typu wiadomości, nie może w sposób niewykrywalny dodawać, duplikować ani uszkadzać poszczególnych wiadomości, a także nie może złamać szyfrowania end-to-end za pomocą aktywnego ataku.

Ta sama strona wymienia, co przekaźnik może zrobić. Może dowiedzieć się, kiedy odbiorca kolejki jest dostępny online. Może zliczyć, ile wiadomości przechodzi przez kolejkę. Może poznać adres IP odbiorcy. Może odrzucić każdą przyszłą wiadomość w kolejce lub skłamać na temat stanu tej kolejki.

Podział jest zatem wyraźny. Poufność jest zadaniem klienta, a self-hosting nie ma na nią wpływu. Metadane i dostępność są zadaniem operatora przekaźnika, a self-hosting przekazuje oba te aspekty w ręce użytkownika.

Wymagania wstępne

• Serwer VPS z systemem Ubuntu 22.04 lub 24.04. Projekt udostępnia pliki binarne wydań zbudowane dokładnie dla tych dwóch wersji, w architekturach x86-64 oraz aarch64.
• Nazwa domenowa z rekordem A wskazującym na VPS oraz rekordem AAAA, jeśli dostępna jest obsługa IPv6. W dokumentacji jako przykładu użyto smp1.example.com.
• Dostęp root lub sudo oraz otwarta druga sesja SSH na czas modyfikacji ustawień firewalla.
• Zewnętrzna lokalizacja do przechowywania kopii zapasowych, ponieważ katalog konfiguracyjny stanowi o tożsamości serwera.

W przypadku instancji ARM należy pobrać zasób aarch64 zamiast x86-64. Żadne inne elementy tego przewodnika nie ulegają zmianie, a wybór między planami VPS ARM i x86 dotyczy wyłącznie ceny oraz wydajności pojedynczego rdzenia, a nie możliwości uruchomienia tego oprogramowania.

Instalacja przypiętej wersji zamiast "latest"

Projekt udostępnia skrypt instalacyjny, który pobiera bieżące wydanie i rejestruje polecenie simplex-servers-update. Rozwiązanie to działa. Należy jednak przypiąć wersję: przekaźnik, którego plik binarny zmienia się bez wiedzy administratora, jest niemożliwy do zdiagnozowania w przypadku awarii.

Na dzień 11 października 2026 najnowsze wydanie simplexmq, które nie jest oznaczone w serwisie GitHub jako wersja przedpremierowa, to v6.5.0, opublikowane 29 kwietnia 2026. Tagi v7.0.0 oraz v7.0.1 z końca lipca 2026, a także wersje beta v7.1.0, są oznaczone jako wydania przedpremierowe. Należy sprawdzić stronę wydań w celu wybrania odpowiedniego tagu, a następnie używać go w dalszej części konfiguracji.

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

useradd -m smp nie ustawia hasła, więc nikt nie loguje się bezpośrednio jako smp. Przed uruchomieniem jakichkolwiek procesów należy samodzielnie utworzyć dwa katalogi, ponieważ /etc/opt należy do użytkownika root i posiada uprawnienia 755, co uniemożliwia użytkownikowi smp zapisanie własnego katalogu konfiguracyjnego.

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

Należy porównać ten skrót z sumami kontrolnymi SHA2-256 opublikowanymi w informacjach o wydaniu dla tego samego tagu. Strona serwera opisuje również podpisany plik sumy kontrolnej _sha256sums wraz z jego podpisem _sha256sums.asc, weryfikowanym kluczem FB44AF81A45BDE327319797C85107E357D4A17FC. Strona powtarzalnych kompilacji projektu wskazuje inny klucz podpisujący, build@simplex.chat, o odcisku BBDF 7BDA D154 8B16 836A F5B9 D53B DFD1 53C3 66BA. Na dzień 11 października 2026 żaden z plików podpisu nie jest dołączony do wydań serwera v6.5.0 lub v7.0.1 w serwisie GitHub, zatem skrót z informacji o wydaniu jest jedyną dostępną metodą weryfikacji dla tych tagów. Jeśli przypisane wydanie zawiera pliki podpisu, przed zaufaniem wynikowi należy potwierdzić, który klucz został użyty do podpisu, korzystając ze strony powtarzalnych kompilacji.

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

Instalację należy przeprowadzić z uprawnieniami użytkownika root. Usługa działa jako smp, więc naruszenie bezpieczeństwa usługi nie pozwoli na nadpisanie pliku binarnego, z którego jest uruchamiana.

Inicjalizacja serwera oraz dwóch wygenerowanych sekretów

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

• --store-log (-l) zapisuje dziennik kolejek w trybie append-only do /var/opt/simplex/smp-server-store.log, dzięki czemu przekaźnik zachowuje stan po restarcie. Bez tego restart powoduje utratę wszystkich kolejek, co oznacza, że każdy kontakt obsługiwany przez dany węzeł przestaje działać.
• --daily-stats (-s) zapisuje liczniki w formacie CSV do /var/opt/simplex/smp-server-stats.daily.log.
• --fqdn umieszcza domenę w wygenerowanym certyfikacie. W przypadku braku domeny należy użyć --ip.
• --no-password pozwala każdemu na tworzenie kolejki na przekaźniku. Aby zachować prywatność, po inicjalizacji należy ustawić create_password w sekcji [AUTH] pliku /etc/opt/simplex/smp-server.ini, zamiast przekazywać --password w tym miejscu. Polecenie wpisane w wierszu poleceń jest widoczne w historii powłoki oraz na liście procesów podczas jego wykonywania.

Proces inicjalizacji generuje certyfikat i wyświetla dwie wartości, które należy zachować. Pierwszą jest odcisk (fingerprint), ciąg znaków base64 zapisany również w /etc/opt/simplex/fingerprint. Drugą jest pełny adres serwera, składający się z odcisku oraz nazwy hosta. Należy skopiować obie wartości.

Inicjalizacja tworzy również /etc/opt/simplex/ca.key. Dokumentacja zaleca przeniesienie tego pliku do pamięci offline. Powód jest istotny: klienci przypinają (pin) odcisk tego urzędu certyfikacji, więc każdy posiadacz ca.key może wystawić nowy certyfikat serwera, który klienci zaakceptują jako autentyczny. Plik ten jest potrzebny wyłącznie do późniejszej rotacji certyfikatu serwera za pomocą smp-server cert.

Inicjalizację należy traktować jako czynność jednorazową. Odcisk w adresie pochodzi z wygenerowanego urzędu, więc ponowne wygenerowanie urzędu spowoduje zmianę adresu i unieważnienie wcześniej udostępnionego.

Uruchamianie w systemd jako użytkownik bez uprawnień administratora

Należy wpisać /etc/systemd/system/smp-server.service, dokładnie tak, jak podaje dokumentacja:

[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

Dostarczona jednostka zawiera również AmbientCapabilities=CAP_NET_BIND_SERVICE. Linia ta istnieje, ponieważ proces działa jako smp, a porty poniżej 1024 są niedostępne dla procesów niebędących rootem, więc bez tego wpisu daemon nie może powiązać się z portami 80 lub 443. Należy dodać ten wpis w przypadku obsługi tych portów. LimitNOFILE=65535 jest istotne, ponieważ każdy subskrybowany klient utrzymuje otwarte połączenie TCP, a domyślny limit jest znacznie niższy niż wymagany dla obciążonego przekaźnika. ExecStopPost kopiuje dziennik magazynu do pliku .bak przy każdym zatrzymaniu, co zapewnia jeden punkt przywracania.

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

Poprawny start loguje adres serwera. Następnie należy potwierdzić, czy gniazda są faktycznie otwarte:

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

Obie linie powinny wskazywać smp-server. Uruchamianie daemona na własnym koncie bez uprawnień sudo to ten sam nawyk, który opisano w kontach dla poszczególnych usług na VPS, i jest to zabezpieczenie, które zapobiega przekształceniu błędu w jednym daemonie sieciowym w powłokę root.

Które porty otworzyć, a który pozostawić zamknięty

Dokumentacja wymienia trzy porty: 5223/tcp, 443/tcp oraz 80/tcp. Port 5223 obsługuje transport SMP. Dostarczona konfiguracja ustawia port: 5223,443 w sekcji [TRANSPORT], dzięki czemu ten sam protokół odpowiada również na porcie 443. Jest to istotne, ponieważ wiele restrykcyjnych sieci zezwala na ruch wychodzący wyłącznie przez port 443. Port 80 jest wymagany jedynie dla opcjonalnej strony informacyjnej oraz przekierowania na HTTPS.

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

Nie należy otwierać portu 5224. Jest to port sterujący, do którego dokumentacja odwołuje się z poziomu samego serwera za pomocą nc 127.0.0.1 5224. Wyświetla on stan serwera i usuwa kolejki, dlatego powinien być dostępny wyłącznie przez interfejs loopback, przy skonfigurowanych hasłach administratora i użytkownika w sekcji [AUTH]. W przypadku braku doświadczenia z tym narzędziem, podstawy ufw na VPS wyjaśniają kolejność reguł oraz sposób uniknięcia zablokowania dostępu do serwera.

Dodatkowym elementem kontrolnym, który często sprawia trudności, jest zewnętrzny firewall sieciowy. Większość dostawców udostępnia zaporę w panelu zarządzania, niezależną od ufw działającego wewnątrz systemu. Port może być otwarty w ufw, a mimo to ruch może zostać odrzucony przed dotarciem do serwera.

Adres serwera wymagany przez klientów

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

Ten ciąg znaków stanowi pełną konfigurację po stronie klienta. Należy wkleić go w ustawieniach serwera aplikacji lub pozwolić na zeskanowanie kodu QR wyświetlanego przez aplikację. Dokumentacja wskazuje, że kod QR zawiera hasło, więc osoba, która go zeskanuje, może również odbierać wiadomości za pośrednictwem serwera.

Jedno z udokumentowanych zachowań jest często zaskakujące. Dodanie serwera w aplikacji wpływa tylko na kontakty nawiązane od tego momentu. Istniejące kontakty pozostają na przekaźnikach, na których utworzono ich kolejki, i nie są przenoszone automatycznie. Jest to również powód, dla którego nie można wyłączyć przekaźnika dzień po jego wymianie.

Dodawanie przekaźnika plików XFTP

XFTP (SimpleX file transfer protocol) stanowi sieciową warstwę przesyłu plików i działa jako osobny demon z własnym adresem. Zgodnie z ogłoszeniem XFTP projektu, przekaźniki nie przechowują żadnych metadanych plików: widzą jedynie pojedyncze fragmenty o rozmiarze 256kb, 1mb lub 4mb, do których dostęp autoryzowany jest anonimowymi poświadczeniami. Nadawca może rozproszyć fragmenty jednego pliku pomiędzy kilka przekaźników, dlatego serwer przechowuje części danych, a nie kompletne pliki.

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/"

Konfiguracja znajduje się w /etc/opt/simplex-xftp/, stan w /var/opt/simplex-xftp/, a fragmenty plików w lokalizacji wskazanej przez -p. Jednostka systemd ma taką samą strukturę jak User=xftp oraz ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS. Proces inicjalizacji wyświetla adres xftp:// w formacie identycznym jak w przypadku SMP, wraz z własnym odciskiem palca w /etc/opt/simplex-xftp/fingerprint.

Należy zaplanować rozwiązanie konfliktu portów. Dokumentacja serwera XFTP wskazuje port 443, który jest również wymieniony w konfiguracji SMP. Dwa procesy nie mogą nasłuchiwać na tym samym porcie pod tym samym adresem, więc na jednym VPS należy dokonać zmian. Najprostszym rozwiązaniem jest ustawienie port: 5223 w sekcji [TRANSPORT] konfiguracji SMP i pozostawienie portu 443 dla przekaźnika plików, kosztem utraty mechanizmu fallback na port 443 dla klientów w restrykcyjnych sieciach. Alternatywą jest przypisanie drugiego adresu IP do tego samego VPS lub użycie drugiego serwera VPS.

Należy rzetelnie określić limit przydziału. Wartość -q '20gb' stanowi deklarację dostępnej przestrzeni dyskowej. Przekaźnik plików jest komponentem, który zużywa dysk oraz pasmo. Przekaźnik wiadomości nie obciąża znacząco żadnego z tych zasobów.

Co znajduje się na dysku i co przywraca kopia zapasowa

Istotne są dwa katalogi. /etc/opt/simplex/ to tożsamość: smp-server.ini, certyfikat serwera oraz klucz, ca.key, a także fingerprint. /var/opt/simplex/ to stan: smp-server-store.log przechowuje kolejki oraz, gdy restore_messages: on, niedostarczone wiadomości, wraz z plikiem codziennych statystyk.

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

Należy jasno określić, czym jest to archiwum. Nie jest to archiwum wiadomości: elementy w kolejce to szyfrogramy dla kluczy, których przekaźnik nigdy nie posiadał, a dostarczona konfiguracja [STORE_LOG] i tak usuwa wiadomości po 21 dniach. Jest to kopia tożsamości serwera, w tym ca.key, więc każdy, kto przejmie ten plik, może podszyć się pod Twój przekaźnik w kontaktach z innymi. Należy go zaszyfrować i przechowywać poza serwerem.

Korzyścią jest możliwość przywrócenia. Umieść /etc/opt/simplex na nowym VPS, skieruj na niego tę samą nazwę DNS, a odcisk klucza pozostanie niezmieniony, dzięki czemu każdy adres, który udostępniłeś, nadal działa. Utrata tego katalogu oznacza brak możliwości odzyskania danych: nowa instalacja oznacza nowy odcisk klucza, co oznacza nowy adres, a to z kolei oznacza, że każdy kontakt kierowany przez Twój przekaźnik zostaje utracony.

TLS: dwa certyfikaty do różnych zadań

Transport SMP nie korzysta z publicznego urzędu certyfikacji (CA). Proces inicjalizacji generuje prywatny urząd oraz certyfikat serwera, a odcisk palca (fingerprint) tego urzędu jest zawarty w adresie serwera. Klient weryfikuje certyfikat przedstawiony przez serwer w oparciu o ten przypięty odcisk, co w dokumentacji projektu opisano jako ochronę połączenia klient-serwer przed atakami typu machine-in-the-middle. Na tym porcie nie działa klient ACME (automatic certificate management environment), a rotacja certyfikatów jest procesem ręcznym, wykonywanym przez smp-server cert z ustawioną flagą SMP_SERVER_CFG_PATH.

Opcjonalna strona informacyjna korzysta z drugiego certyfikatu. Jej sekcja [WEB] definiuje static_path, https: 443, cert: /etc/opt/simplex/web.crt oraz key: /etc/opt/simplex/web.key. Przeglądarka nie rozpoznaje prywatnego urzędu certyfikacji, dlatego w tym miejscu należy użyć certyfikatu zaufanego publicznie. Dokumentacja w sekcji Docker quick start zaleca umieszczenie Caddy przed serwerem właśnie w tym celu, co pozwala na automatyczne wystawienie certyfikatu.

Dostęp do przekaźnika przez Tor

Dokumentacja zawiera sekcję dotyczącą sieci Tor, która opisuje instalację oprogramowania z repozytorium Tor Project oraz dodanie usługi ukrytej w /etc/tor/torrc:

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

Należy uważnie przeczytać dwie linie trybu. Tryby single hop oraz non-anonymous oznaczają, że lokalizacja przekaźnika nie jest ukryta. Adres onion zapewnia szybkie połączenie i umożliwia klientom dostęp bez ujawniania ich adresu IP, jednak sam serwer pozostaje wykrywalny pod swoim publicznym adresem IP. Nazwę hosta onion z /var/lib/tor/simplex-smp/hostname należy umieścić na końcu adresu serwera po przecinku. Jeśli celem jest również ukrycie lokalizacji serwera, wymaga to innej konfiguracji, a kwestię tę opisuje uruchamianie pełnej usługi onion na VPS. Różnice w zakresie ochrony prywatności oferowanej przez poszczególne narzędzia są przedmiotem porównania sieci Tor z VPN, co ma bezpośrednie zastosowanie w tym przypadku.

Model zagrożeń: co zmienia self-hosting

Co zyskujesz. Metadane (jakie kolejki istnieją, kiedy są odczytywane, które adresy nawiązują połączenie) znajdują się na maszynie, którą kontrolujesz, a Ty decydujesz, jak długo są przechowywane. Nie jesteś również częścią dużej puli użytkowników, o których dane można wystąpić w ramach jednego zapytania.

Czego nie zyskujesz, mówiąc wprost:

• Szyfrowanie pozostaje bez zmian. Wiadomości były szyfrowane end-to-end przed wdrożeniem tego rozwiązania i pozostają tak szyfrowane po jego wdrożeniu. Self-hosting to decyzja dotycząca metadanych, a nie kryptografii.
• Twój dostawca VPS widzi ruch do Twojego adresu IP i posiada Twoje dane rozliczeniowe. Przeniosłeś zaufanie z operatora komunikatora na operatora hostingu. Nie wyeliminowałeś go.
• Twój przekaźnik (relay) to niewielka grupa. Jeśli obsługuje jedno gospodarstwo domowe, połączenie z nim identyfikuje to gospodarstwo, a jego nazwa hosta znajduje się w każdym linku z zaproszeniem, który z niego wysyłasz. Obciążony publiczny przekaźnik zapewnia w tym jednym aspekcie lepszą anonimowość i jest to realny kompromis. Prywatny serwer wyszukiwarki ma tę samą charakterystykę, dlatego co SearXNG faktycznie ukrywa na Twoim własnym VPS sprowadza się do tego, ile osób korzysta z instancji razem z Tobą.
• Dostępność zależy teraz od Ciebie. Pełny dysk lub awaria serwera oznaczają wstrzymanie dostarczania wiadomości, a Twoje kontakty nie mają możliwości obejścia Twojego węzła.

To samo rozumowanie dotyczy każdej prywatnej usługi umieszczonej na własnym serwerze, niezależnie od tego, czy jest to ten przekaźnik, czy WireGuard VPN na własnym VPS. Wybierasz, która strona widzi metadane. Nie sprawiasz, że one znikają.

Gdy to nie działa

Usługa uruchamia się i natychmiast zatrzymuje. Przeczytaj sudo journalctl -u smp-server -n 50. Błąd powiązania (bind failure) wskazuje port, którego nie udało się zająć. Następnie uruchom sudo ss -tlnp | grep :443, aby sprawdzić, który proces już go zajmuje; na świeżym serwerze jest to zazwyczaj nginx, Caddy lub serwer XFTP zainstalowany godzinę wcześniej.

Init nie może zapisać konfiguracji. Uruchomienie smp-server init jako użytkownik smp przed utworzeniem /etc/opt/simplex powoduje błąd uprawnień, ponieważ właścicielem /etc/opt jest root. Najpierw utwórz katalog z odpowiednim właścicielem, a następnie ponownie uruchom init.

Klienci nie mogą połączyć się z przekaźnikiem. Sprawdź, czy nazwa rozwiązuje się na właściwy adres za pomocą dig +short smp1.example.com. Następnie przetestuj port ze swojego laptopa, a nie z serwera: nc -vz smp1.example.com 5223. Jeśli połączenie z zewnątrz nie udaje się, podczas gdy ss pokazuje otwarte gniazdo na serwerze, może to wskazywać na blokadę przez firewall sieciowy dostawcy, który jest niezależny od ufw.

Kontakt nie może połączyć się przez Twój przekaźnik. Odcisk palca (fingerprint) w adresie, który udostępniłeś, musi być zgodny z aktualną zawartością /etc/opt/simplex/fingerprint. Jeśli ustawiłeś create_password w sekcji [AUTH], adres musi również zawierać to hasło, w przeciwnym razie klient nie będzie mógł utworzyć kolejki.

Nic się nie zmieniło po dodaniu serwera w aplikacji. Tak ma być. Tylko nowe kontakty korzystają z nowo dodanego przekaźnika. Istniejące kontakty zachowują kolejki, które już posiadają.

FAQ

Czy samodzielne hostowanie serwera SimpleX zwiększa bezpieczeństwo moich wiadomości?

Nie, i jest to zamierzone. SimpleX szyfruje wiadomości metodą end-to-end między urządzeniami, więc przekaźnik nigdy nie posiada kluczy, niezależnie od tego, kto go obsługuje. Samodzielne hostowanie zmienia jedynie podmiot obserwujący metadane powiązane z tymi wiadomościami: które kolejki istnieją, kiedy są odczytywane oraz jakie adresy IP nawiązują połączenie. Jest to decyzja dotycząca metadanych. Jeśli powodem samodzielnego hostowania jest silniejsze szyfrowanie, to szyfrowanie było obecne od samego początku.

Co faktycznie widzi operator przekaźnika SimpleX?

Projekt protocol/security.md określa to jasno. Przekaźnik nie może odczytać treści ani typów wiadomości, nie może w sposób niewykrywalny zmieniać poszczególnych wiadomości ani złamać szyfrowania end-to-end za pomocą aktywnego ataku. Może natomiast zobaczyć, kiedy odbiorca kolejki jest online, zliczyć wiadomości przechodzące przez kolejkę, poznać adres IP odbiorcy, odrzucić przyszłe wiadomości w kolejce lub skłamać na temat stanu tej kolejki. Są to uprawnienia, które zyskujesz, gdy przekaźnik należy do Ciebie.

Czy potrzebuję nazwy domeny i certyfikatu TLS?

Do poprawnego działania potrzebujesz domeny, a smp-server init akceptuje --ip, jeśli faktycznie jej nie posiadasz. Nie potrzebujesz certyfikatu od publicznego urzędu certyfikacji dla portu przesyłania wiadomości: init generuje własny urząd, a klient przypina (pinning) odcisk palca, który pojawia się w Twoim adresie smp://. Publicznie zaufany certyfikat jest potrzebny tylko dla opcjonalnej strony informacyjnej, skonfigurowanej jako cert i key w sekcji [WEB] pliku smp-server.ini.

Co się stanie, jeśli utracę /etc/opt/simplex?

Każdy adres, który udostępniłeś, przestanie działać. Ten katalog przechowuje urząd certyfikacji, którego odcisk palca jest osadzony w adresie Twojego serwera, więc ponowna budowa wygeneruje inny odcisk palca, a tym samym inny serwer. Kontaktów, których kolejki znajdują się na tym przekaźniku, nie da się naprawić po stronie klienta. Wykonaj zaszyfrowaną kopię zapasową katalogu poza serwerem i przechowuj ca.key w trybie offline zgodnie z instrukcją, ponieważ każdy, kto go posiada, może podszyć się pod Twój przekaźnik.

Czy mogę uruchomić przekaźnik SMP i przekaźnik plików XFTP na tym samym VPS?

Tak, z jednym konfliktem do rozwiązania. Udokumentowany port serwera XFTP to 443, a domyślna konfiguracja SMP wymienia port: 5223,443, więc oba chcą korzystać z tego samego gniazda. Przypisz port 443 do jednego z nich: ustaw port: 5223 dla serwera SMP lub przenieś przekaźnik plików na drugi adres IP albo drugi serwer VPS. Dostosuj również limit miejsca na dysku do faktycznie dostępnej przestrzeni, ponieważ to przekaźnik plików jest komponentem zużywającym dysk i przepustowość łącza.