VPS üzerinde SimpleX sohbet sunucusu kurulumu

Kendi kendine barındırılan bir SimpleX sohbet sunucusu ne işe yarar

Bir SimpleX sohbet sunucusunu kendi altyapınızda barındırmak için bir VPS üzerinde tek bir daemon çalıştırırsınız: SMP (SimpleX Messaging Protocol) için röle görevi gören smp-server. Bu servis, kişilerinizin mesaj yazıp okuduğu mesaj kuyruklarını tutar. xftp-server adlı ikinci ve isteğe bağlı bir daemon ise dosya transferlerini aktarır. Her ikisi de aynı projeden, simplexmq, gelir ve her biri tek bir binary dosyası, bir yapılandırma dosyası ve yalnızca ekleme yapılabilen (append-only) bir log dosyasından oluşur.

Bu metin, uygulama kullanıcısı için değil, operatör için hazırlanmıştır. Röle; hesap, kişi listesi veya sohbet geçmişi tutmaz. Yalnızca kuyrukları, henüz teslim edilmemiş bazı şifreli metinleri ve kendisini tanımlayan bir sertifikayı barındırır. Üstlendiğiniz sorumluluk; çalışma süresi (uptime), küçük bir disk alanı ve sunucunuz üzerinden geçen meta verilerdir.

Aşağıdaki tüm komutlar, yollar, portlar ve bayraklar projenin kendi dokümantasyonundan alınmıştır: SMP sunucu barındırma sayfası, XFTP sunucu sayfası ve protokol güvenliği belgesi. Bir sayının önemli olduğu durumlarda, kaynağı olan sayfa hemen yanında belirtilmiştir.

Kullanıcı tanımlayıcısı olmayan bir ağın neden rölelere ihtiyaç duyduğu

SimpleX; kullanıcı adı, telefon numarası veya hesap kimliği içermez. Bir kişi, bir tarafın yazdığı ve diğer tarafın okuduğu, bir röle üzerindeki adres olan tek yönlü bir kuyruktur. İki kişiniz, bir sunucunun ilişkilendirebileceği hiçbir ortak tanımlayıcıyı paylaşmaz.

Bu kuyrukların basit bir nedenden dolayı bir yerde barındırılması gerekir. İki telefon nadiren aynı anda çevrimiçidir. Bir cihazın mesajı kabul edip, diğeri talep edene kadar saklaması gerekir. SMP rölesinin tüm işlevi budur. Bu durum, iki cihazın asla birbirine doğrudan bağlanmadığı anlamına gelir; böylece taraflardan hiçbiri diğerinin IP (internet protokolü) adresini öğrenemez. Röle, bu maruziyeti kendi üzerine alır.

Rölenin ana bilgisayar adı (hostname), kuyruk adresinin bir parçasıdır; bu nedenle, paylaştığınız her davet bağlantısının içinde yer alır. Belgenin sonuna doğru yer alan tehdit modelini okurken bunu göz önünde bulundurun.

Bir relay'in görebildikleri ve göremedikleri

Proje, bunu protocol/security.md içerisinde bir tehdit modeli olarak belirtmektedir. Herhangi bir kurulum yapmadan önce bu kısmı okumanız faydalıdır; çünkü bu rehberden sonra ilgili relay artık size aittir. Bir saldırgan tarafından tamamen kontrol edilen bir relay dahil olmak üzere hiçbir relay, mesajların içeriğini veya türünü öğrenemez, tekil mesajları tespit edilemeyecek şekilde ekleyemez, çoğaltamaz veya bozamaz; ayrıca aktif bir saldırı ile uçtan uca şifrelemeyi kıramaz.

Aynı sayfada bir relay'in neler yapabileceği de listelenmiştir. Bir kuyruk alıcısının ne zaman çevrimiçi olduğunu öğrenebilir. Bir kuyruktan kaç mesajın geçtiğini sayabilir. Bir alıcının IP adresini öğrenebilir. Bir kuyruktaki tüm gelecek mesajları düşürebilir veya o kuyruğun durumu hakkında yalan söyleyebilir.

Dolayısıyla ayrım nettir. Gizlilik istemcinin sorumluluğundadır ve self-hosting bu durumu etkilemez. Üstveri (metadata) ve erişilebilirlik ise relay operatörünün sorumluluğundadır; self-hosting ile her ikisinin kontrolü de size geçer.

Başlamadan önce gerekenler

• Ubuntu 22.04 veya 24.04 çalıştıran bir VPS. Proje, x86-64 ve aarch64 mimarileri için tam olarak bu iki sürümle derlenmiş yazılım sürümlerini yayınlar.
• VPS'e işaret eden bir A kaydına ve IPv6 kullanıyorsanız bir AAAA kaydına sahip bir alan adı. Belgelerde örnek olarak smp1.example.com kullanılmaktadır.
• Root veya sudo erişimi ve güvenlik duvarı ayarlarını değiştirirken açık tutulacak ikinci bir SSH oturumu.
• Yedekleri saklamak için sunucu dışında bir konum; çünkü yapılandırma dizini sunucunun kimliğidir.

ARM tabanlı bir örnekte x86-64 yerine aarch64 varlığını kullanın. Bu kılavuzdaki diğer hiçbir şey değişmez ve ARM ve x86 VPS planları arasındaki seçim, yazılımın çalışıp çalışmayacağıyla değil, fiyat ve çekirdek başına hız ile ilgilidir.

"latest" yerine sabitlenmiş bir sürüm kurun

Proje, güncel sürümü çeken ve bir simplex-servers-update komutu kaydeden bir kurulum betiği sunar. Bu betik çalışır. Yine de sürümü sabitleyin: ikili dosyası sizden habersiz değişen bir relay, bir sorun çıktığında üzerinde mantık yürütemeyeceğiniz bir relaydir.

Ağustos 2026 itibarıyla güncel simplexmq sürümü v6.5.0 olup 29 Nisan 2026 tarihinde yayınlanmıştır. İstediğiniz etiket için sürümler sayfasına göz atın ve aşağıdaki her yerde bu etiketi kullanın.

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

useradd -m smp parola belirlemez, bu nedenle hiç kimse doğrudan smp olarak giriş yapamaz. Başka herhangi bir işlem yapmadan önce iki dizini kendiniz oluşturun; çünkü /etc/opt dizini root kullanıcısına aittir ve 755 modundadır, bu da smp kullanıcısının kendi yapılandırma dizinini yazabileceği bir alan bırakmaz.

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

Bu hash değerini, aynı etiket için sürüm notlarında yayınlanan SHA2-256 sağlama toplamları ile karşılaştırın. Proje ayrıca sürüm sağlama toplamlarını, sunucu sayfasında belgelenen SimpleX Chat anahtarı FB44AF81A45BDE327319797C85107E357D4A17FC ile imzalar; böylece hash değerini okuduğunuz sayfaya güvenmek yerine imzayı doğrulayabilirsiniz.

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

Kurulumu bilerek root sahipliğinde yapın. Servis smp kullanıcısı olarak çalışır, bu sayede servisin ele geçirilmesi durumunda, servisin başlatıldığı ikili dosya yeniden yazılamaz.

Sunucuyu ve yazdırdığı iki gizli anahtarı başlatın

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

• --store-log (-l), kuyrukların salt-okunur bir günlüğünü /var/opt/simplex/smp-server-store.log dosyasına yazar; böylece relay bir yeniden başlatma sonrasında çalışmaya devam eder. Bu özellik olmadan yeniden başlatma işlemi tüm kuyrukları siler; bu da üzerinizden yönlendirilen her bağlantının kesilmesi anlamına gelir.
• --daily-stats (-s), sayaçları CSV formatında /var/opt/simplex/smp-server-stats.daily.log dosyasına yazar.
• --fqdn, oluşturulan sertifikaya alan adınızı ekler. Eğer bir alan adınız yoksa bunun yerine --ip kullanın.
• --no-password, herkesin relay üzerinde bir kuyruk oluşturmasına izin verir. Erişimi kısıtlamak için, --password bayrağını burada kullanmak yerine, başlatma işleminden sonra /etc/opt/simplex/smp-server.ini içindeki [AUTH] altında create_password ayarını yapılandırın. Komut satırı geçmişinizde ve çalışan süreç listesinde görüneceği için komut satırı üzerinden parametre geçmek güvenli değildir.

Başlatma işlemi bir sertifika oluşturur ve saklamanız gereken iki değeri yazdırır. İlki, /etc/opt/simplex/fingerprint dosyasına da yazılan base64 formatındaki parmak izidir (fingerprint). İkincisi ise parmak izi ve ana makine adınızdan oluşan tam sunucu adresidir. Her ikisini de şimdi kopyalayın.

Başlatma işlemi ayrıca /etc/opt/simplex/ca.key dosyasını oluşturur; belgeler bu dosyayı çevrimdışı bir depolama alanına taşımanızı önerir. Bunun nedeni önemlidir: istemciler bu sertifika yetkilisinin parmak izini sabitler (pin), dolayısıyla ca.key dosyasına sahip olan herkes, istemcilerinizin sizin sertifikanız olarak kabul edeceği yeni bir sunucu sertifikası oluşturabilir. Bu dosyaya yalnızca daha sonra smp-server cert ile sunucu sertifikasını yenilemek istediğinizde ihtiyaç duyarsınız.

Başlatma işlemini tek seferlik bir adım olarak değerlendirin. Adresinizdeki parmak izi, oluşturulan yetkiliden gelir; bu nedenle yetkiliyi yeniden oluşturmak farklı bir adres almanıza ve dağıttığınız adresin geçersiz kalmasına neden olur.

Servisi systemd altında yetkisiz bir kullanıcı olarak çalıştırma

/etc/systemd/system/smp-server.service dosyasını, belgelerde belirtildiği şekilde yazın:

[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

Yukarı akış birimi (upstream unit) ayrıca AmbientCapabilities=CAP_NET_BIND_SERVICE satırını da içerir. Bu satır, süreç smp olarak çalıştığı ve 1024'ün altındaki portlar root olmayan bir sürece kapalı olduğu için mevcuttur; bu satır olmadan daemon 80 veya 443 portlarına bağlanamaz. Bu portlar üzerinden hizmet veriyorsanız bu satırı ekleyin. LimitNOFILE=65535, her abone olan istemci açık bir TCP bağlantısı tuttuğu ve varsayılan sınır yoğun bir relay'in ihtiyaç duyduğundan çok daha düşük olduğu için önemlidir. ExecStopPost, her durdurma işleminde depo günlüğünü bir .bak dosyasına kopyalar; bu da size ücretsiz bir geri alma noktası sağlar.

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

Sağlıklı bir başlangıç, sunucu adresini günlüğe kaydeder. Ardından soketlerin gerçekten açık olduğunu doğrulayın:

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

Her iki satır da smp-server değerini belirtmelidir. Daemon'ı sudo hakları olmayan kendi hesabı altında çalıştırmak, VPS üzerinde servis bazlı hesaplar bölümünde açıklanan alışkanlığın aynısıdır ve bir ağ daemon'ındaki hatanın root shell'e dönüşmesini engelleyen yöntemdir.

Hangi portlar açılmalı, hangisi kapalı tutulmalı

Dokümantasyon üç port listeler: 5223/tcp, 443/tcp ve 80/tcp. Port 5223, SMP taşıma protokolüdür. Yazılımla birlikte gelen yapılandırma, [TRANSPORT] altında port: 5223,443 değerini ayarlar; bu sayede aynı protokol 443 portunda da yanıt verir. Bu durum, kısıtlayıcı ağların çoğunun yalnızca 443 portuna giden trafiğe izin vermesi nedeniyle önemlidir. Port 80, yalnızca isteğe bağlı bilgi sayfası ve bu sayfanın HTTPS'e yönlendirilmesi için gereklidir.

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

5224 portunu açmayın. Bu port kontrol portudur ve dokümantasyon bu porta sunucunun kendisinden nc 127.0.0.1 5224 ile erişilmesini önerir. Bu port sunucu durumunu yazdırır ve kuyrukları siler; bu nedenle, [AUTH] altında yönetici ve kullanıcı parolaları ayarlanmış şekilde yalnızca loopback üzerinde çalışmalıdır. Araca yeni başlıyorsanız, VPS üzerinde ufw temelleri rehberi, kural sırasını ve kendinizi dışarıda bırakmaktan nasıl kaçınacağınızı açıklar.

Bir diğer kontrol noktası ise kullanıcıları sıkça yanıltır. Çoğu sağlayıcı, sunucu üzerindeki ufw'den bağımsız olarak panelde bir ağ güvenlik duvarı çalıştırır. Bir port ufw üzerinde açık olsa bile, size ulaşmadan önce ağ düzeyinde engellenebilir.

İstemcilerinizin ihtiyaç duyduğu sunucu adresi

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

Bu dizge, istemci tarafındaki yapılandırmanın tamamıdır. Dizgeyi uygulamanın sunucu ayarlarına yapıştırın veya uygulamanın bunun için gösterdiği QR kodunu taratın. Belgeler, QR kodunun parolayı da içerdiğini belirtir; bu nedenle kodu taratan bir kişi, sunucunuz üzerinden mesaj da alabilir.

Belgelenmiş bir davranış herkesi şaşırtır. Sunucunuzu uygulamaya eklemek, yalnızca o andan itibaren kurduğunuz bağlantıları etkiler. Mevcut bağlantılar, kuyruklarının oluşturulduğu relay üzerinde kalır ve başka bir yere taşınmazlar. Bir relay'i değiştirdikten hemen sonraki gün kapatamamanızın nedeni de budur.

Bir XFTP dosya aktarım rölesi ekleme

XFTP (SimpleX file transfer protocol), ağın dosya aktarım tarafını oluşturur ve kendi adresine sahip ayrı bir daemon olarak çalışır. Projenin XFTP duyurusunda belirtildiği üzere, röleler herhangi bir dosya meta verisine sahip değildir: röleler, anonim kimlik bilgileriyle erişim yetkisi verilen 256kb, 1mb veya 4mb boyutundaki parçaları görürler. Bir gönderici, tek bir dosyanın parçalarını birden fazla röleye dağıtabilir; bu nedenle sunucunuz dosyaları değil, sadece parçaları barındırır.

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

Yapılandırma dosyası /etc/opt/simplex-xftp/ dizininde, durum bilgisi /var/opt/simplex-xftp/ dizininde ve dosya parçaları ise -p içerisinde belirtilen konumda tutulur. systemd birimi, User=xftp ve ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS ile aynı yapıya sahiptir. Başlatma işlemi, SMP adresiyle aynı formatta bir xftp:// adresi yazdırır ve kendi parmak izini /etc/opt/simplex-xftp/fingerprint içerisinde sunar.

Planlanması gereken bir çakışma durumu mevcuttur. XFTP sunucusunun dokümante edilen portu 443'tür ve SMP yapılandırması da 443 portunu listeler. İki süreç, aynı adres üzerinde aynı porta bağlanamaz; bu nedenle tek bir VPS üzerinde birinden feragat edilmesi gerekir. En basit çözüm, SMP [TRANSPORT] bölümünde port: 5223 ayarını değiştirmek ve 443 portunu dosya rölesine bırakmaktır; ancak bu durum, kısıtlayıcı ağlardaki istemciler için 443 portu üzerinden sağlanan yedekleme imkanından feragat edilmesi anlamına gelir. Diğer alternatifler ise aynı VPS üzerinde ikinci bir IP adresi kullanmak veya ikinci bir VPS temin etmektir.

Kota boyutunu gerçekçi bir şekilde belirleyin. -q '20gb', sahip olduğunuz disk alanı hakkında bir taahhüttür. Dosya rölesi, disk ve bant genişliğini tüketen kısımdır. Mesaj rölesi ise her ikisini de çok az kullanır.

Disk üzerinde neler tutulur ve yedekleme neleri geri yükler

İki dizin önemlidir. /etc/opt/simplex/ kimliği barındırır: smp-server.ini, sunucu sertifikası ve anahtarı, ca.key ve fingerprint. /var/opt/simplex/ ise durumu tutar: smp-server-store.log kuyrukları ve restore_messages: on etkinleştirildiğinde teslim edilmemiş iletileri, günlük istatistik dosyasıyla birlikte saklar.

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

Arşivin ne olduğu konusunda net olun. Bu bir ileti arşivi değildir: kuyruktaki öğeler, rölenin hiçbir zaman sahip olmadığı anahtarlar için şifreli metinlerdir ve gönderilen [STORE_LOG] yapılandırması iletileri zaten 21 gün sonra siler. Bu, ca.key dahil olmak üzere sunucunun kimliğinin bir kopyasıdır; dolayısıyla dosyayı ele geçiren herkes, kişilerinize karşı kendisini sizin röleniz olarak tanıtabilir. Arşivi şifreleyin ve sunucu dışında saklayın.

Bunun getirisi geri yüklemedir. /etc/opt/simplex dizinini yeni bir VPS üzerine geri koyun, aynı DNS adını bu sunucuya yönlendirin; parmak izi değişmeyeceği için dağıttığınız tüm adresler çalışmaya devam eder. Bu dizini kaybederseniz kurtarma şansı yoktur: yeni bir kurulum yeni bir parmak izi, yeni bir adres ve röleniz üzerinden yönlendirilen tüm kişilerin bağlantısının kopması anlamına gelir.

TLS: farklı görevler üstlenen iki sertifika

SMP taşıma katmanı, halka açık bir sertifika yetkilisi (CA) kullanmaz. Init süreci, özel bir yetkili ve bir sunucu sertifikası oluşturur; bu yetkilinin parmak izi, sunucu adresi içerisinde taşınır. İstemci, sunucunun sunduğu sertifikayı bu sabitlenmiş parmak izi ile karşılaştırır; proje, istemci-sunucu bağlantısını ortadaki adam (machine-in-the-middle) saldırılarına karşı koruma yöntemi olarak bunu tanımlar. Bu port üzerinde çalışacak bir ACME (otomatik sertifika yönetim ortamı) istemcisi bulunmaz ve sertifika rotasyonu, SMP_SERVER_CFG_PATH ayarı ile birlikte smp-server cert çalıştırılarak manuel olarak yapılır.

İsteğe bağlı bilgi sayfası ise diğer sertifikayı kullanır. Bu sayfanın [WEB] bölümü; static_path, https: 443, cert: /etc/opt/simplex/web.crt ve key: /etc/opt/simplex/web.key öğelerini tanımlar. Bir tarayıcı, özel yetkilinizi tanımayacağı için halka açık güvenilir bir sertifikanın kullanılması gereken tek yer burasıdır. Dokümantasyondaki Docker hızlı başlangıç rehberi, tam olarak bu amaçla Caddy'yi sunucunun önüne yerleştirir ve sertifikayı otomatik olarak düzenler.

Tor üzerinden röleye erişim

Dokümantasyon, Tor'u Tor Project deposundan kuran ve /etc/tor/torrc içerisinde bir gizli servis ekleyen bir Tor bölümü içerir:

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

İki mod satırını dikkatlice okuyun. "Single hop" (tek sekme) ve "non-anonymous" (anonim olmayan) ifadeleri, rölenin kendi konumunun gizlenmediği anlamına gelir. Onion adresi hızlıdır ve istemcilere, IP adresinizi asla açığa çıkarmadan sisteme giriş yolu sağlar; ancak sunucunun kendisi genel IP adresi üzerinden bulunabilir olmaya devam eder. /var/lib/tor/simplex-smp/hostname içerisindeki onion ana makine adı, sunucu adresinin sonuna virgül ile eklenir. Eğer sunucunun konumunun da gizli kalmasını istiyorsanız, bu farklı bir yapılandırmadır ve bir VPS üzerinde gerçek bir onion servisi çalıştırmak bu konudaki takasları ele alır. Hangi aracın neyi gizlediği arasındaki fark, Tor ile VPN karşılaştırması konusunun içeriğidir ve burada doğrudan geçerlidir.

Tehdit modeli: self-hosting neleri değiştirir

Size sağladığı avantajlar. Meta veriler (hangi kuyrukların var olduğu, ne zaman okundukları, hangi adreslerin bağlandığı) kontrolünüz altındaki bir makinede tutulur ve bunların ne kadar süre saklanacağına siz karar verirsiniz. Ayrıca, tek seferde toplu veri talebinde bulunulabilecek büyük bir havuzun parçası olmazsınız.

Açıkça belirtmek gerekirse, size sağlamadığı şeyler şunlardır:

• Şifreleme değişmez. Mesajlar bu yapıyı kurmadan önce de uçtan uca şifreliydi, kurduktan sonra da uçtan uca şifreli kalmaya devam eder. Self-hosting bir meta veri kararıdır, kriptografi kararı değildir.
• VPS sağlayıcınız IP adresinize gelen trafiği görür ve fatura bilgilerinizi tutar. Güveni bir mesajlaşma operatöründen bir barındırma operatörüne devretmiş olursunuz. Güven ihtiyacını ortadan kaldırmazsınız.
• Relay sunucunuz küçük bir topluluktur. Eğer sadece tek bir haneye hizmet veriyorsa, ona bağlanmak o haneyi tanımlar ve sunucu ana makine adı, gönderdiğiniz her davet bağlantısının içinde yer alır. Yoğun bir genel relay sunucusu sizi bu açıdan daha iyi gizler; gerçek takas budur.
• Erişilebilirlik artık sizin sorumluluğunuzdadır. Dolu bir disk veya çalışmayan bir sunucu, mesajların iletilmesinin durması anlamına gelir ve kişilerinizin sizin üzerinizden başka bir yol izleme şansı kalmaz.

Aynı mantık, bu relay sunucusu olsun ya da kendi VPS'iniz üzerinde bir WireGuard VPN olsun, sahip olduğunuz bir makineye kurduğunuz her özel servis için geçerlidir. Meta verileri hangi tarafın göreceğini seçiyorsunuz. Onları yok etmiyorsunuz.

Çalışmadığı durumlar

Servis başlıyor ve hemen duruyor. sudo journalctl -u smp-server -n 50 dosyasını okuyun. Bir bind hatası, alınamayan portu belirtir. Ardından, o portu halihazırda hangi sürecin tuttuğunu görmek için sudo ss -tlnp | grep :443 komutunu çalıştırın; yeni kurulmuş bir sunucuda bu genellikle nginx, Caddy veya bir saat önce kurduğunuz XFTP sunucusudur.

Init yapılandırmasını yazamıyor. /etc/opt/simplex mevcut değilken smp kullanıcısı olarak smp-server init komutunu çalıştırmak bir izin hatasına yol açar, çünkü /etc/opt dizininin sahibi root kullanıcısıdır. Önce dizini doğru sahiplik bilgileriyle oluşturun, ardından init işlemini tekrar çalıştırın.

İstemciler röleye erişemiyor. dig +short smp1.example.com ile ismin doğru adrese çözümlendiğini kontrol edin. Ardından portu sunucudan değil, kendi dizüstü bilgisayarınızdan test edin: nc -vz smp1.example.com 5223. ss komutu soketin sunucuda açık olduğunu gösterdiği halde dışarıdan bağlantı başarısız oluyorsa, sorun ufw'den bağımsız bir kontrol mekanizması olan sağlayıcının ağ güvenlik duvarından kaynaklanıyordur.

Bir kişi röleniz üzerinden bağlanamıyor. Paylaştığınız adresteki parmak izi, /etc/opt/simplex/fingerprint dosyasının mevcut içeriğiyle eşleşmelidir. Eğer [AUTH] altında create_password ayarını yaptıysanız, adresin de bu parolayı içermesi gerekir; aksi takdirde istemcinin kuyruk oluşturmasına izin verilmez.

Sunucuyu uygulamaya ekledikten sonra hiçbir şey taşınmadı. Bu beklenen bir durumdur. Yalnızca yeni kişiler yeni eklenen röleyi kullanır. Mevcut kişiler halihazırda sahip oldukları kuyrukları kullanmaya devam eder.

FAQ

SimpleX sunucusunu kendi bünyemde barındırmak mesajlarımı daha güvenli hale getirir mi?

Hayır, bu durum tasarım gereği böyledir. SimpleX, mesajları cihazlar arasında uçtan uca şifreler; dolayısıyla sunucuyu kim çalıştırırsa çalıştırsın, aktarıcı (relay) anahtarlara hiçbir zaman sahip olmaz. Kendi sunucunuzu barındırmak, mesajların etrafındaki meta verileri kimin gözlemlediğini değiştirir: hangi kuyrukların var olduğu, ne zaman okundukları ve hangi IP adreslerinin bağlandığı gibi. Bu bir meta veri tercihidir. Kendi sunucunuzu barındırma nedeniniz daha güçlü şifreleme ise, şifreleme zaten halihazırda mevcuttu.

Bir SimpleX aktarıcı operatörü gerçekte neleri görebilir?

Projenin protocol/security.md belgesi bunu açıklar. Bir aktarıcı, mesaj içeriklerini veya türlerini okuyamaz, mesajları tespit edilemeyecek şekilde değiştiremez ve aktif bir saldırı ile uçtan uca şifrelemeyi kıramaz. Aktarıcı; bir kuyruğun alıcısının ne zaman çevrimiçi olduğunu görebilir, kuyruktan geçen mesajları sayabilir, alıcının IP adresini öğrenebilir, kuyruktaki gelecekteki mesajları silebilir veya kuyruğun durumu hakkında yanlış bilgi verebilir. Aktarıcı sizin kontrolünüzde olduğunda sahip olduğunuz yetkiler bunlardır.

Bir alan adına ve TLS sertifikasına ihtiyacım var mı?

Kullanılabilir bir kurulum için bir alan adına ihtiyacınız vardır; eğer gerçekten hiçbir alan adınız yoksa smp-server init, --ip kullanımına izin verir. Mesajlaşma portu için halka açık bir otoriteden alınmış bir sertifikaya ihtiyacınız yoktur: init süreci kendi otoritesini oluşturur ve istemci, smp:// adresinizde görünen parmak izini sabitler (pin). Halka açık güvenilir bir sertifika, yalnızca [WEB] bölümündeki smp-server.ini dosyasında cert ve key olarak yapılandırılan isteğe bağlı web bilgi sayfası için gereklidir.

/etc/opt/simplex dizinini kaybedersem ne olur?

Dağıttığınız tüm adresler çalışmayı durdurur. Bu dizin, parmak izi sunucu adresinize gömülü olan sertifika otoritesini tutar; bu nedenle yeniden oluşturma işlemi farklı bir parmak izi ve dolayısıyla farklı bir sunucu üretir. Kuyrukları o aktarıcıda bulunan kişilerin bağlantıları, istemci tarafında onarılamaz. Dizini şifreli bir şekilde sunucu dışında yedekleyin ve belgelerde belirtildiği gibi ca.key dosyasını çevrimdışı saklayın; çünkü bu dosyaya sahip olan kişi aktarıcınızı taklit edebilir.

SMP aktarıcısını ve XFTP dosya aktarıcısını aynı VPS üzerinde çalıştırabilir miyim?

Evet, ancak çözülmesi gereken bir çakışma vardır. XFTP sunucusunun belgelenen portu 443'tür ve varsayılan SMP yapılandırması port: 5223,443 değerini listeler; bu nedenle her ikisi de aynı soketi kullanmak ister. 443 numaralı portu bunlardan birine atayın: SMP sunucusu için port: 5223 değerini ayarlayın veya dosya aktarıcısını ikinci bir IP adresine ya da ikinci bir VPS'e taşıyın. Ayrıca depolama kotasını sahip olduğunuz gerçek disk kapasitesine göre belirleyin, çünkü disk ve bant genişliğini tüketen bileşen dosya aktarıcısıdır.