Kendi SimpleX sohbet sunucunuzu VPS üzerinde barındırma

Kendi SimpleX sohbet sunucunuzu barındırmanın işlevi

Kendi SimpleX sohbet sunucunuzu barındırmak için bir VPS üzerinde tek bir daemon çalıştırırsınız: SMP (SimpleX messaging protocol) için aktarıcı olan smp-server. Bu daemon, kişilerinizin mesajlarını yazdığı ve okuduğu mesaj kuyruklarını tutar. xftp-server adında ikinci ve isteğe bağlı bir daemon ise dosya transferlerini aktarır. Her ikisi de aynı projeden, simplexmq kaynağından gelir ve her biri tek bir binary dosyası, bir yapılandırma dosyası ve yalnızca ekleme yapılabilen (append-only) bir günlük dosyasından oluşur.

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

Aşağıdaki tüm komutlar, yollar, portlar ve bayraklar projenin kendi belgelerinden 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, taraflardan birinin yazdığı ve diğerinin okuduğu, bir röle üzerindeki adresten ibaret tek yönlü bir kuyruktur. İki kişi arasında, bir sunucunun ilişkilendirebileceği ortak bir tanımlayıcı bulunmaz.

Bu kuyrukların yine de bir yerde barındırılması gerekir; bunun basit bir nedeni vardır. İki telefon nadiren aynı anda çevrimiçi olur. Bir cihazın mesajı kabul edip diğer cihaz talep edene kadar saklaması gerekir. SMP rölesinin tüm işlevi budur. Bu durum, iki cihazın asla doğrudan birbirine bağlanmadığı anlamına gelir; dolayısıyla 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. Tehdit modelini okurken bunu göz önünde bulundurun.

Bir aktarıcının (relay) görebildikleri ve göremedikleri

Proje, bunu protocol/security.md içerisinde bir tehdit modeli olarak tanımlamaktadır. Herhangi bir kurulum yapmadan önce bu kısmı okumanız önerilir; çünkü bu rehberden sonra ilgili aktarıcı artık sizin sorumluluğunuzdadır. Bir saldırgan tarafından tamamen kontrol edilen bir aktarıcı dahil olmak üzere hiçbir aktarıcı, mesajların içeriğini veya türünü öğrenemez, 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 aktarıcının 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. Kuyruktaki gelecekteki tüm mesajları silebilir veya kuyruğun durumu hakkında yalan söyleyebilir.

Bu nedenle ayrım nettir. Gizlilik istemcinin sorumluluğundadır ve self-hosting bu durumu etkilemez. Üstveri (metadata) ve erişilebilirlik ise aktarıcı 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, yalnızca bu iki sürüm için x86-64 ve aarch64 mimarilerinde derlenmiş yazılım sürümlerini yayınlar.
• VPS'in IP adresine yönlendirilmiş bir A kaydı ve IPv6 kullanıyorsanız bir AAAA kaydı içeren bir alan adı. Belgelerde örnek olarak smp1.example.com kullanılmıştır.
• Root veya sudo erişimi ve güvenlik duvarı ayarlarını değiştirirken açık tutulacak ikinci bir SSH oturumu.
• Sunucu dışında bir yedekleme alanı; çünkü yapılandırma dizini, sunucunun kimliğini temsil eder.

ARM tabanlı bir örnekte x86-64 yerine aarch64 varlığını kullanın. Bu kılavuzdaki diğer hiçbir şey değişmez; 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 durumdadı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 tüm işlemlerde 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 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 gerçekleştirin. 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 başlatın ve yazdırdığı iki gizli anahtarı kaydedin

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

• --store-log (-l), kuyrukların sadece ekleme yapılabilen bir günlüğünü /var/opt/simplex/smp-server-store.log dosyasına yazar; böylece röle 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, alan adınızı oluşturulan sertifikaya ekler. Eğer bir alan adınız yoksa bunun yerine --ip kullanın.
• --no-password, herkesin röleniz üzerinde bir kuyruk oluşturmasına izin verir. Röleyi gizli tutmak için, --password bayrağını komut satırında geçirmek yerine, başlatma işleminden sonra /etc/opt/simplex/smp-server.ini dosyası 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 işlem yapmak güvenli değildir.

Başlatma işlemi (init) 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 ile ana makine adınızdan (hostname) oluşan tam sunucu adresidir. Her ikisini de hemen 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 sizinki olarak kabul edeceği yeni bir sunucu sertifikası oluşturabilir. Bu dosyaya yalnızca daha sonra smp-server cert ile sunucu sertifikasını yenilemek (rotate) 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 ifadesini, dokümantasyonda verildiği şekliyle 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 kullanıcısı 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 ayarı önemlidir çünkü abone olan her istemci açık bir TCP bağlantısı tutar ve varsayılan sınır, yoğun bir relay'in ihtiyaç duyduğunun çok altındadır. 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şlatma işlemi, 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 yetkisi olmayan kendi hesabı altında çalıştırmak, VPS üzerinde servis bazlı hesaplar bölümünde açıklanan alışkanlıkla aynıdır ve bir ağ daemon'ındaki hatanın root shell'e dönüşmesini engelleyen yöntem budur.

Hangi portların açılması, hangisinin kapalı tutulması gerektiği

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 ayarını yapar; bu sayede aynı protokol 443 portunda da yanıt verir. Bu durum, kısıtlayıcı ağların çoğunun yalnızca 443 portundan dışa doğru 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, bir VPS üzerinde ufw'nin temelleri rehberi, kural sıralamasını ve sistemden dışarıda kalmamak için yapılması gerekenleri kapsar.

Kullanıcıların gözünden kaçan bir diğer kontrol noktası daha vardır. Çoğu sağlayıcı, sunucu üzerindeki ufw'den bağımsız olarak panel üzerinden bir ağ güvenlik duvarı çalıştırır. Bir port ufw üzerinde açık olsa bile, size ulaşmadan önce ağ seviyesinde düşürülüyor olabilir.

İstemcilerinizin ihtiyaç duyduğu sunucu adresi

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

Bu karakter dizisi, istemci tarafındaki yapılandırmanın tamamıdır. Diziyi uygulamanın sunucu ayarları kısmına yapıştırın veya uygulamanın bunun için oluşturduğu QR kodunu taratın. Belgelerde, QR kodunun parolayı da içerdiği belirtilmiştir; bu nedenle kodu taratan bir kişi, sunucunuz üzerinden mesaj 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.

XFTP dosya aktarım rölesi ekleme

XFTP (SimpleX file transfer protocol), ağın dosya aktarım tarafıdır ve kendi adresine sahip ayrı bir daemon olarak çalışır. Projenin XFTP duyurusunda belirtildiği üzere, röleler hiçbir dosya meta verisine sahip değildir: röleler, her biri 256kb, 1mb veya 4mb boyutunda olan ve anonim kimlik bilgileriyle erişim yetkisi verilen 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ı tutar.

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 bulunur. systemd birimi, User=xftp ve ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS ile aynı yapıdadır. Başlatma işlemi, SMP ile aynı formatta bir xftp:// adresi yazdırır ve kendi parmak izini /etc/opt/simplex-xftp/fingerprint içerisinde tutar.

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; bu durum, kısıtlayıcı ağlardaki istemciler için 443 portu üzerinden yedekleme (fallback) özelliğinin kaybedilmesine neden olur. 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 neredeyse hiç kullanmaz.

Disk üzerinde neler bulunur ve bir yedekleme neleri geri yükler

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

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. Dosyayı şifreleyin ve sunucunun 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 edecektir. Bu dizini kaybederseniz kurtarma şansı yoktur: yeni bir kurulum yeni bir parmak izi, yeni bir parmak izi ise yeni bir adres demektir; bu da 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 aktarımı, genel 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 veriyi bu sabitlenmiş parmak iziyle karşılaştırır; proje, istemci ile sunucu arasındaki bağlantının ortadaki adam (MITM) saldırılarına karşı bu şekilde korunduğunu belirtir. Bu port üzerinde çalışacak bir ACME (otomatik sertifika yönetim ortamı) istemcisi bulunmamaktadır ve sertifika rotasyonu, SMP_SERVER_CFG_PATH ayarı ile birlikte smp-server cert komutunun çalıştırılmasıyla manuel olarak yapılır.

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

Tor üzerinden röleye erişim

Belgeler, Tor'un Tor Project deposundan kurulmasını ve /etc/tor/torrc içerisinde bir gizli servis eklenmesini içeren bir Tor bölümü barındırır:

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 inceleyin. Single hop ve non-anonymous ifadeleri, rölenin kendi konumunun gizlenmediği anlamına gelir. Onion adresi hızlıdır ve istemcilere, IP adreslerini size asla ifşa etmeden sisteme giriş yolu sağlar; ancak sunucunun kendisi genel IP adresi üzerinden bulunabilir durumda kalır. /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. Her bir aracın neleri gizlediği arasındaki fark, Tor ile VPN karşılaştırması konusunun temelidir 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 talep edilebilecek büyük bir havuzun parçası olmazsınız.

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

• Şifreleme değişmez. Mesajlar bu yapıyı kurmadan önce de uçtan uca şifreliydi, kurduktan sonra da uçtan uca şifrelidir. 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 taşıdınız. Güven ihtiyacını ortadan kaldırmadınız.
• Relay sunucunuz küçük bir gruptur. Eğer tek bir haneye hizmet veriyorsa, ona bağlanmak o haneyi tanımlar ve sunucu ana bilgisayar adı, gönderdiğiniz her davet bağlantısının içinde yer alır. Yoğun bir genel relay, bu açıdan sizi daha iyi gizler; gerçek takas budur. Özel bir arama sunucusu da aynı yapıdadır, bu yüzden SearXNG'nin kendi VPS'nizde aslında neleri gizlediği, örneği sizinle kaç kişinin paylaştığına bağlıdır.
• Erişilebilirlik artık sizin sorumluluğunuzdadır. Dolu bir disk veya çökmüş bir sunucu, mesajların iletilmesinin durması anlamına gelir ve kişilerinizin sizi devre dışı bırakma şansı yoktur.

Aynı mantık, bu relay veya kendi VPS'nizdeki bir WireGuard VPN olsun, sahip olduğunuz bir sunucuya koyduğ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 kısmını okuyun. Bir bind hatası, alınamayan portun adını belirtir. Ardından, hangi sürecin portu halihazırda kullandığını 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 sunucunun kendisinden değil, 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.

Uygulamaya sunucuyu ekledikten sonra hiçbir şey değişmedi. 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

Bir SimpleX sunucusunu kendi sunucumda 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 röleyi kim çalıştırırsa çalıştırsın, anahtarlar rölenin elinde olmaz. Kendi sunucunuzda barındırmak, bu 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ü bir şifreleme ise, şifreleme zaten halihazırda mevcuttu.

Bir SimpleX röle operatörü gerçekte neleri görebilir?

Projenin protocol/security.md belgesi bunu açıklar. Bir röle, mesaj içeriklerini veya türlerini okuyamaz, bireysel mesajları fark edilmeden değiştiremez ve aktif bir saldırı ile uçtan uca şifrelemeyi kıramaz. Röle; 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 o kuyruğun durumu hakkında yalan söyleyebilir. Röle size ait 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 ve 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 (pinler). Halka açık güvenilir bir sertifika, yalnızca smp-server.ini dosyasının [WEB] bölümünde cert ve key olarak yapılandırılan isteğe bağlı web bilgi sayfası için gereklidir.

/etc/opt/simplex dosyasını kaybedersem ne olur?

Dağıttığınız tüm adresler çalışmayı durdurur. Bu dizin, sunucu adresinize gömülü parmak izine sahip sertifika otoritesini barındırır; bu nedenle yeniden oluşturma işlemi farklı bir parmak izi ve dolayısıyla farklı bir sunucu üretir. Kuyrukları o rölede bulunan kişilerin bağlantıları, istemci tarafından onarılamaz. Dizin yedeğini şifreli bir şekilde sunucu dışında saklayın ve belgelendirmede belirtildiği gibi ca.key dosyasını çevrimdışı tutun; çünkü bu dosyaya sahip olan kişi rölenizi taklit edebilir.

SMP rölesini ve XFTP dosya rölesini 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 verin: SMP sunucusu için port: 5223 değerini ayarlayın veya dosya rölesini ikinci bir IP adresine ya da ikinci bir VPS'e taşıyın. Ayrıca depolama kotasını sahip olduğunuz gerçek disk alanına göre belirleyin, çünkü disk ve bant genişliğini tüketen bileşen dosya rölesidir.