VPS वर स्वतःचा SimpleX chat server कसा होस्ट करावा?

self-hosted SimpleX chat server काय करते

SimpleX chat server स्वतः होस्ट करण्यासाठी तुम्ही VPS वर एक daemon चालवता: smp-server, जो SMP (simplex messaging protocol) साठी relay म्हणून काम करतो. यामध्ये ते मेसेज queues असतात ज्यावर तुमचे संपर्क मेसेज लिहितात आणि वाचतात. xftp-server नावाचा दुसरा, ऐच्छिक daemon फाईल ट्रान्सफरसाठी relay म्हणून काम करतो. हे दोन्ही एकाच प्रोजेक्टचे, simplexmq चे भाग आहेत आणि प्रत्येक एक सिंगल बायनरी, एक config फाईल आणि एक append-only लॉग आहे.

हे मार्गदर्शक ॲप वापरकर्त्यासाठी नसून ऑपरेटरसाठी आहे. Relay कडे कोणतेही अकाउंट्स, कॉन्टॅक्ट लिस्ट किंवा चॅट हिस्ट्री नसते. यामध्ये फक्त queues, काही न पोहोचलेले ciphertext आणि सर्व्हरची ओळख पटवणारे प्रमाणपत्र असते. तुम्हाला फक्त सर्व्हरची uptime, थोडी डिस्क स्पेस आणि तुमच्या सर्व्हरवरून जाणारा मेटाडेटा सांभाळायचा असतो.

खालील प्रत्येक कमांड, पाथ, पोर्ट आणि फ्लॅग प्रोजेक्टच्या अधिकृत डॉक्युमेंटेशनमधून घेतले आहेत: SMP server hosting page, XFTP server page, आणि protocol security document. जिथे आकडा महत्त्वाचा आहे, तिथे तो कोणत्या पेजवरून घेतला आहे हे त्याच्या शेजारी नमूद केले आहे.

युजर आयडेंटिफायर नसलेल्या नेटवर्कला रिलेची गरज का असते

SimpleX मध्ये युजरनेम, फोन नंबर किंवा अकाउंट आयडी नसतात. संपर्क म्हणजे एक युनिडायरेक्शनल (एकतर्फी) रांग असते: रिलेवरील एक पत्ता, ज्यावर एक बाजू संदेश लिहिते आणि दुसरी बाजू तो वाचते. तुमच्या दोन संपर्कांमध्ये असा कोणताही आयडेंटिफायर नसतो, ज्यावरून सर्व्हर त्यांना एकमेकांशी जोडू शकेल.

या रांगा कुठेतरी असणे आवश्यक असते, याचे साधे कारण आहे. दोन फोन एकाच वेळी ऑनलाइन असण्याची शक्यता कमी असते. त्यामुळे, एखादी गोष्ट संदेश स्वीकारून तो दुसऱ्या उपकरणाने मागेपर्यंत साठवून ठेवणे गरजेचे असते. हेच SMP रिलेचे मुख्य काम आहे. याचा अर्थ असा की, दोन उपकरणे कधीही एकमेकांशी थेट जोडली जात नाहीत, त्यामुळे एकाला दुसऱ्याचा IP (internet protocol) पत्ता समजत नाही. त्याऐवजी, रिले हा धोका स्वतःवर घेतो.

रिलेचे hostname हे रांगेच्या पत्त्याचा भाग असते, त्यामुळे तुम्ही दिलेल्या प्रत्येक इनव्हिटेशन लिंकमध्ये ते समाविष्ट असते. शेवटी दिलेल्या थ्रेट मॉडेलबद्दल वाचताना ही गोष्ट लक्षात ठेवा.

रिले काय पाहू शकतो आणि काय पाहू शकत नाही

प्रकल्पाने protocol/security.md मध्ये याला थ्रेट मॉडेल (threat model) म्हणून स्पष्ट केले आहे. काहीही इन्स्टॉल करण्यापूर्वी हे वाचणे आवश्यक आहे, कारण या मार्गदर्शिकेनंतर तो रिले तुमचा असेल. एक रिले, ज्यावर आक्रमणकर्त्याचे पूर्ण नियंत्रण असले तरीही, तो संदेशांचे स्वरूप किंवा त्यातील मजकूर जाणून घेऊ शकत नाही. तो वैयक्तिक संदेशांमध्ये अदृश्यपणे भर घालू शकत नाही, त्यांची प्रत बनवू शकत नाही किंवा ते खराब करू शकत नाही. तसेच, सक्रिय हल्ल्याद्वारे तो एंड-टू-एंड एन्क्रिप्शन (end-to-end encryption) तोडू शकत नाही.

त्याच पानावर रिले काय करू शकतो याची यादी दिली आहे. रिले हे जाणून घेऊ शकतो की रांगेतील (queue) प्राप्तकर्ता कधी ऑनलाइन आहे. तो रांगेतून किती संदेश जातात याची गणना करू शकतो. तो प्राप्तकर्त्याचा IP address जाणून घेऊ शकतो. तो रांगेतील भविष्यातील प्रत्येक संदेश नाकारू शकतो किंवा त्या रांगेच्या स्थितीबद्दल खोटी माहिती देऊ शकतो.

त्यामुळे, जबाबदारीचे विभाजन स्पष्ट आहे. गोपनीयतेची जबाबदारी क्लायंटची आहे आणि सेल्फ-होस्टिंगचा त्यावर कोणताही परिणाम होत नाही. मेटाडेटा आणि उपलब्धता ही रिले ऑपरेटरची जबाबदारी आहे आणि सेल्फ-होस्टिंगमुळे या दोन्ही गोष्टींचे नियंत्रण तुमच्याकडे येते.

सुरुवात करण्यापूर्वी आवश्यक गोष्टी

• Ubuntu 22.04 किंवा 24.04 वर चालणारा VPS. हा प्रकल्प केवळ या दोन आवृत्त्यांसाठी, x86-64 आणि aarch64 आर्किटेक्चरवर तयार केलेले release binaries प्रकाशित करतो.
• VPS कडे निर्देश करणारा A record असलेला डोमेन नेम, आणि जर तुमच्याकडे IPv6 असेल तर AAAA record. दस्तऐवजीकरणामध्ये उदाहरणासाठी smp1.example.com चा वापर केला आहे.
• Root किंवा sudo ॲक्सेस, आणि फायरवॉलमध्ये बदल करताना उघडे असलेले दुसरे SSH सत्र.
• सर्व्हरच्या बाहेर बॅकअप साठवण्यासाठी एखादी जागा, कारण config डिरेक्टरी ही सर्व्हरची ओळख असते.

ARM इन्स्टन्सवर x86-64 ऐवजी aarch64 ॲसेट निवडा. या मार्गदर्शिकेतील इतर कशातही बदल होत नाही, आणि ARM आणि x86 VPS प्लॅन्स मधील निवड ही किंमत आणि प्रति-कोर वेगावर आधारित आहे, हे सॉफ्टवेअर चालण्यावर नाही.

"latest" ऐवजी एका विशिष्ट (pinned) रिलीजची स्थापना करा

हा प्रकल्प एक इन्स्टॉल स्क्रिप्ट प्रदान करतो जी सध्याचे रिलीज खेचते आणि एक simplex-servers-update कमांड नोंदवते. हे काम करते. तरीही, आवृत्ती पिन (pin) करा: ज्या रिलेची बायनरी तुमच्या नकळत बदलते, त्या रिलेच्या बाबतीत काही बिघडल्यास त्याचे विश्लेषण करणे कठीण जाते.

ऑगस्ट 2026 पर्यंत, सध्याचे simplexmq रिलीज v6.5.0 आहे, जे 29 एप्रिल 2026 रोजी प्रकाशित झाले आहे. तुम्हाला हवा असलेला टॅग तपासण्यासाठी releases page पहा आणि त्यानंतर खालील सर्व ठिकाणी तोच टॅग वापरा.

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 ने स्वाक्षरी देखील करतो, ज्याची माहिती server page वर दिली आहे. त्यामुळे तुम्ही हॅश वाचलेल्या पेजवर विश्वास ठेवण्याऐवजी स्वाक्षरीची पडताळणी करू शकता.

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

हे मुद्दाम root-owned म्हणून इन्स्टॉल करा. ही सेवा smp म्हणून चालते, त्यामुळे सेवेमध्ये काही त्रुटी (compromise) निर्माण झाल्यास, ती ज्या बायनरीवरून सुरू होते तिला पुन्हा लिहू शकत नाही.

सर्व्हर इनिशिअलाईज करा आणि त्याने दर्शवलेले दोन सीक्रेट्स जतन करा

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 मध्ये लिहिते, ज्यामुळे रीस्टार्टनंतरही रिले कार्यरत राहते. याशिवाय, रीस्टार्ट केल्यास सर्व रांगा नष्ट होतात, ज्याचा अर्थ तुमच्याद्वारे राउट केलेले सर्व संपर्क काम करणे थांबवतात.
• --daily-stats (-s) हे काउंटर CSV स्वरूपात /var/opt/simplex/smp-server-stats.daily.log मध्ये लिहिते.
• --fqdn हे तुमच्या डोमेनला जनरेट केलेल्या प्रमाणपत्रात समाविष्ट करते. जर तुमच्याकडे डोमेन नसेल, तर --ip वापरा.
• --no-password मुळे कोणीही तुमच्या रिलेवर रांग तयार करू शकते. हे खाजगी ठेवण्यासाठी, इनिशिअलायझेशननंतर /etc/opt/simplex/smp-server.ini मधील [AUTH] अंतर्गत create_password सेट करा. कमांड लाईनवर --password पास करणे टाळा, कारण कमांड लाईन तुमच्या शेल हिस्ट्रीमध्ये आणि रन होत असताना प्रोसेस लिस्टमध्ये दिसते.

इनिशिअलायझेशन एक प्रमाणपत्र तयार करते आणि तुम्हाला जतन करायची असलेली दोन मूल्ये दर्शवते. पहिले म्हणजे फिंगरप्रिंट, जी एक base64 स्ट्रिंग आहे आणि ती /etc/opt/simplex/fingerprint मध्येही लिहिली जाते. दुसरे म्हणजे पूर्ण सर्व्हर पत्ता, जो फिंगरप्रिंट आणि तुमच्या होस्टनेमचा मिळून बनलेला असतो. दोन्ही आता कॉपी करा.

इनिशिअलायझेशन /etc/opt/simplex/ca.key देखील तयार करते आणि डॉक्युमेंटेशननुसार ही फाईल ऑफलाइन स्टोरेजमध्ये हलवणे आवश्यक आहे. याचे कारण महत्त्वाचे आहे: क्लायंट्स या सर्टिफिकेट अथॉरिटीच्या फिंगरप्रिंटला पिन करतात, त्यामुळे ज्याच्याकडे ca.key असेल तो नवीन सर्व्हर प्रमाणपत्र जारी करू शकतो जे तुमचे क्लायंट तुमचेच असल्याचे मानून स्वीकारतील. भविष्यात smp-server cert वापरून सर्व्हर प्रमाणपत्र रोटेट करण्यासाठीच तुम्हाला याची पुन्हा गरज पडेल.

इनिशिअलायझेशन ही एक एकदाच करण्याची प्रक्रिया आहे असे समजा. तुमच्या पत्त्यातील फिंगरप्रिंट हे त्याने तयार केलेल्या अथॉरिटीवरून येते, त्यामुळे ती अथॉरिटी पुन्हा जनरेट केल्यास तुम्हाला नवीन पत्ता मिळेल आणि तुम्ही आधी दिलेला पत्ता निरुपयोगी ठरेल.

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

अपस्ट्रीम युनिटमध्ये AmbientCapabilities=CAP_NET_BIND_SERVICE देखील असते. ती ओळ तिथे असते कारण प्रक्रिया smp म्हणून चालते आणि 1024 च्या खालील पोर्ट्स नॉन-रूट प्रक्रियेसाठी बंद असतात, त्यामुळे त्याशिवाय डेमन 80 किंवा 443 पोर्टवर बाइंड होऊ शकत नाही. जर तुम्ही ते पोर्ट्स सर्व्ह करत असाल, तर ही ओळ जोडा. LimitNOFILE=65535 महत्त्वाचे आहे कारण प्रत्येक सबस्क्राईब केलेला क्लायंट एक ओपन TCP कनेक्शन धरून ठेवतो आणि डीफॉल्ट मर्यादा एका व्यस्त रिलेसाठी आवश्यक असलेल्या मर्यादेपेक्षा खूप कमी असते. ExecStopPost प्रत्येक स्टॉपवर स्टोअर लॉगची प्रत .bak फाईलमध्ये तयार करते, ज्यामुळे तुम्हाला एक मोफत रोलबॅक पॉइंट मिळतो.

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 चे नाव असावे. डेमनला स्वतःच्या खात्याखाली, कोणत्याही sudo अधिकारांशिवाय चालवणे ही VPS वरील प्रति-सेवा खाती मध्ये वर्णन केलेलीच सवय आहे आणि यामुळेच एका नेटवर्क डेमनमधील त्रुटीचे रूपांतर रूट शेलमध्ये होण्यापासून रोखले जाते.

कोणते पोर्ट उघडावेत आणि कोणते बंद ठेवावेत

दस्तऐवजात तीन पोर्ट्सची यादी दिली आहे: 5223/tcp, 443/tcp आणि 80/tcp. पोर्ट 5223 हे SMP ट्रान्सपोर्टसाठी आहे. सॉफ्टवेअरसोबत येणारे कॉन्फिगरेशन port: 5223,443 हे [TRANSPORT] अंतर्गत सेट करते, त्यामुळे हाच प्रोटोकॉल 443 वर देखील प्रतिसाद देतो. हे महत्त्वाचे आहे कारण अनेक प्रतिबंधित नेटवर्क्समध्ये फक्त 443 पोर्टवरून आउटबाउंड ट्रॅफिकला परवानगी असते. पोर्ट 80 ची गरज फक्त पर्यायी माहिती पृष्ठ आणि त्याचे 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 वापरून या पोर्टशी संपर्क साधतो. हे पोर्ट सर्व्हरची स्थिती दर्शवते आणि रांगा (queues) हटवू शकते, त्यामुळे ते लूपबॅक (loopback) वरच असणे आवश्यक आहे, जिथे [AUTH] अंतर्गत ॲडमिन आणि युजर पासवर्ड सेट केलेले असतात. जर तुम्ही या टूलसाठी नवीन असाल, तर VPS वर ufw ची मूलभूत माहिती या लेखात नियमांचा क्रम आणि स्वतःला लॉक-आउट होण्यापासून कसे वाचवावे, याची माहिती दिली आहे.

आणखी एक नियंत्रण बाब अनेकदा लोकांच्या लक्षात येत नाही. बहुतेक प्रोव्हाइडर्स सर्व्हरवरील ufw पेक्षा वेगळा, त्यांच्या पॅनेलमध्ये एक नेटवर्क फायरवॉल चालवतात. एखादे पोर्ट ufw मध्ये उघडे असूनही, तुमच्यापर्यंत पोहोचण्यापूर्वीच ते नेटवर्क फायरवॉलद्वारे ड्रॉप केले जाऊ शकते.

क्लायंटसाठी आवश्यक सर्व्हर पत्ता

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

ही स्ट्रिंग म्हणजे संपूर्ण क्लायंट-साइड कॉन्फिगरेशन आहे. ती ॲपच्या सर्व्हर सेटिंग्जमध्ये पेस्ट करा किंवा ॲपमध्ये दिसणारा QR कोड स्कॅन करायला सांगा. दस्तऐवजीकरणानुसार, QR कोडमध्ये पासवर्डचा समावेश असतो, त्यामुळे तो स्कॅन करणारी व्यक्ती तुमच्या सर्व्हरद्वारे संदेश प्राप्त करू शकते.

एका दस्तऐवजीकरण केलेल्या वर्तनामुळे सर्वांनाच आश्चर्य वाटते. ॲपमध्ये तुमचा सर्व्हर जोडल्याचा परिणाम फक्त त्यानंतर तुम्ही जोडलेल्या संपर्कांवरच होतो. अस्तित्वात असलेले संपर्क ज्या रिलेवर त्यांच्या रांगा (queues) तयार झाल्या होत्या, तिथेच राहतात आणि ते स्थलांतरित होत नाहीत. म्हणूनच तुम्ही रिले बदलल्यानंतर दुसऱ्याच दिवशी तो बंद करू शकत नाही.

XFTP फाइल रिले जोडणे

XFTP (SimpleX file transfer protocol) हा नेटवर्कचा फाइल हस्तांतरण करणारा भाग आहे. हा एक स्वतंत्र daemon असून त्याचे स्वतःचे वेगळे पत्ता (address) असते. प्रकल्पाच्या XFTP घोषणेनुसार, रिलेकडे फाइलचे कोणतेही मेटाडेटा नसतात. त्यांना फक्त 256kb, 1mb किंवा 4mb चे स्वतंत्र तुकडे दिसतात आणि त्यांचा प्रवेश anonymous credentials द्वारे अधिकृत केला जातो. पाठवणारा (sender) एका फाइलचे तुकडे अनेक रिलेवर विभागू शकतो, त्यामुळे तुमच्या सर्व्हरवर पूर्ण फाइल्स नसून फक्त त्यांचे तुकडे साठवले जातात.

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/ मध्ये असते, तर स्थिती (state) /var/opt/simplex-xftp/ मध्ये असते. फाइलचे तुकडे -p मध्ये नमूद केलेल्या ठिकाणी साठवले जातात. systemd युनिटचे स्वरूप User=xftp आणि ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS प्रमाणेच असते. Init प्रक्रिया SMP प्रमाणेच फॉरमॅटमध्ये xftp:// पत्ता प्रिंट करते आणि त्याचे स्वतःचे फिंगरप्रिंट /etc/opt/simplex-xftp/fingerprint मध्ये असते.

येथे पोर्टच्या वापराबाबत संघर्ष (collision) होऊ शकतो, ज्याचे नियोजन करणे आवश्यक आहे. XFTP सर्व्हरचा अधिकृत पोर्ट 443 आहे आणि SMP कॉन्फिगरेशनमध्येही 443 पोर्टचा उल्लेख आहे. दोन प्रक्रिया एकाच पत्त्यावर एकाच पोर्टला बाइंड होऊ शकत नाहीत, त्यामुळे एका VPS वर तुम्हाला तडजोड करावी लागेल. सर्वात सोपा उपाय म्हणजे SMP च्या [TRANSPORT] सेक्शनमध्ये port: 5223 सेट करणे आणि 443 पोर्ट फाइल रिलेसाठी मोकळा ठेवणे. मात्र, यामुळे प्रतिबंधित नेटवर्क वापरणाऱ्या क्लायंटसाठी 443 पोर्टचा fallback उपलब्ध राहणार नाही. इतर पर्यायांमध्ये त्याच VPS वर दुसरा IP पत्ता वापरणे किंवा दुसरा VPS घेणे यांचा समावेश होतो.

डिस्क कोटा प्रामाणिकपणे ठरवा. -q '20gb' हे तुम्ही उपलब्ध करून दिलेल्या डिस्क स्पेसचे आश्वासन आहे. फाइल रिले हा असा भाग आहे जो सर्वाधिक डिस्क आणि बँडविड्थ वापरतो. मेसेज रिलेचा वापर या दोन्ही गोष्टींसाठी नगण्य असतो.

डिस्कवर काय साठवले जाते आणि बॅकअप कशाची पुनर्प्राप्ती करतो

दोन डिरेक्टरीज महत्त्वाच्या आहेत. /etc/opt/simplex/ ही ओळख दर्शवते: smp-server.ini, सर्व्हर प्रमाणपत्र आणि की, ca.key, आणि fingerprint. /var/opt/simplex/ मध्ये स्थिती (state) असते: smp-server-store.log मध्ये रांगा (queues) असतात आणि, जेव्हा restore_messages: on असते, तेव्हा न पोहोचलेले संदेश, तसेच दैनंदिन सांख्यिकी फाईल (stats file) असते.

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

ती अर्काईव्ह नक्की काय आहे हे स्पष्ट असावे. हे संदेशांचे अर्काईव्ह नाही: रांगेत असलेले आयटम हे अशा की (keys) साठीचे सायफरटेक्स्ट आहेत ज्या रिलेकडे कधीच नव्हत्या, आणि पुरवलेली [STORE_LOG] कॉन्फिगरेशन 21 दिवसांनंतर संदेश आपोआप काढून टाकते. ही सर्व्हरच्या ओळखीची प्रत आहे, ज्यात ca.key समाविष्ट आहे, त्यामुळे ही फाईल ज्याच्या हाती लागेल तो तुमच्या संपर्कांसाठी स्वतःला तुमचा रिले म्हणून सादर करू शकतो. या फाईलला एनक्रिप्ट करा आणि ती सर्व्हरपासून दूर सुरक्षित ठेवा.

याचा फायदा पुनर्प्राप्तीमध्ये (restore) होतो. /etc/opt/simplex ला नवीन VPS वर पुन्हा ठेवा, त्याच DNS नावाचा पॉइंटर तिथे वळवा, आणि फिंगरप्रिंट बदलणार नाही, त्यामुळे तुम्ही दिलेले प्रत्येक ॲड्रेस पूर्वीप्रमाणेच काम करेल. जर ती डिरेक्टरी गमावली तर कोणतीही रिकव्हरी शक्य नाही: नवीन इन्स्टॉलेशन म्हणजे नवीन फिंगरप्रिंट, ज्याचा अर्थ नवीन ॲड्रेस, आणि याचा अर्थ तुमच्या रिलेद्वारे जोडलेला प्रत्येक संपर्क कायमचा नष्ट होईल.

TLS: दोन प्रमाणपत्रे आणि त्यांची वेगवेगळी कार्ये

SMP ट्रान्सपोर्ट सार्वजनिक certificate authority चा वापर करत नाही. Init एक खाजगी authority आणि सर्व्हर प्रमाणपत्र तयार करते. या authority चा फिंगरप्रिंट सर्व्हरच्या पत्त्यामध्ये समाविष्ट असतो. क्लायंट सर्व्हरने सादर केलेले प्रमाणपत्र या पिन केलेल्या फिंगरप्रिंटशी जुळवून पाहतो. प्रकल्प याला क्लायंट-टू-सर्व्हर कनेक्शनला machine-in-the-middle हल्ल्यांपासून संरक्षण देणारी पद्धत म्हणून संबोधतो. या पोर्टवर चालण्यासाठी कोणतेही ACME (automatic certificate management environment) क्लायंट उपलब्ध नाही आणि रोटेशन ही एक मॅन्युअल प्रक्रिया आहे, जी smp-server cert चालवून आणि SMP_SERVER_CFG_PATH सेट करून पूर्ण केली जाते.

पर्यायी माहिती पृष्ठ (information page) हे दुसरे प्रमाणपत्र वापरते. त्याच्या [WEB] विभागात static_path, https: 443, cert: /etc/opt/simplex/web.crt आणि key: /etc/opt/simplex/web.key यांची नावे दिलेली असतात. ब्राउझरला तुमच्या खाजगी authority बद्दल माहिती नसते, त्यामुळे सार्वजनिकरित्या विश्वसनीय (publicly trusted) प्रमाणपत्र वापरण्यासाठी हे एकमेव योग्य ठिकाण आहे. दस्तऐवजीकरणातील Docker quick start मध्ये याच कारणासाठी Caddy ला सर्व्हरच्या समोर ठेवले जाते, जे आपोआप प्रमाणपत्र जारी करते.

Tor द्वारे रिलेपर्यंत पोहोचणे

दस्तऐवजात Tor चा एक विभाग समाविष्ट आहे, जो Tor Project रिपॉझिटरीमधून Tor इंस्टॉल करतो आणि /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 वर शोधण्यायोग्य राहतो. /var/lib/tor/simplex-smp/hostname मधील onion होस्टनेम सर्व्हर ॲड्रेसच्या शेवटी स्वल्पविरामानंतर (comma) लावले जाते. जर तुम्हाला सर्व्हरचे लोकेशन देखील लपवायचे असेल, तर त्यासाठी वेगळे कॉन्फिगरेशन आवश्यक आहे आणि VPS वर प्रत्यक्ष onion सर्व्हिस चालवणे या विषयामध्ये त्याचे फायदे-तोटे स्पष्ट केले आहेत. प्रत्येक साधन नक्की काय लपवते यातील फरक हा Tor आणि VPN ची तुलना या विषयाचा भाग आहे आणि तो येथे थेट लागू होतो.

थ्रेट मॉडेल: सेल्फ-होस्टिंगमुळे काय बदलते

यामुळे तुम्हाला काय मिळते. मेटाडेटा (कोणते queues अस्तित्वात आहेत, ते कधी वाचले जातात, कोणती पत्ते कनेक्ट होतात) तुमच्या नियंत्रणाखालील मशीनवर राहतो आणि तो किती काळ साठवून ठेवायचा हे तुम्ही ठरवता. तसेच, तुम्ही अशा मोठ्या समूहाचा भाग राहत नाही ज्याची माहिती एकाच वेळी मागवली जाऊ शकते.

यामुळे तुम्हाला काय मिळत नाही, हे स्पष्टपणे खालीलप्रमाणे आहे:

• एन्क्रिप्शनमध्ये कोणताही बदल होत नाही. तुम्ही हे सेटअप करण्यापूर्वी संदेश end to end encrypted होते आणि सेटअप केल्यानंतरही ते end to end encrypted राहतात. सेल्फ-होस्टिंग हा मेटाडेटाचा निर्णय आहे, क्रिप्टोग्राफीचा नाही.
• तुमचा VPS प्रोव्हायडर तुमच्या IP पत्त्यावरील ट्रॅफिक पाहू शकतो आणि त्याच्याकडे तुमची बिलिंग माहिती असते. तुम्ही मेसेजिंग ऑपरेटरकडून विश्वास होस्टिंग ऑपरेटरकडे हलवला आहे. तुम्ही तो पूर्णपणे काढून टाकलेला नाही.
• तुमचा रिले हा एक छोटा समूह असतो. जर तो एका घरासाठी सेवा देत असेल, तर त्याला कनेक्ट होणे म्हणजे त्या घराची ओळख पटणे होय आणि तुम्ही पाठवलेल्या प्रत्येक आमंत्रण लिंकमध्ये त्याचा hostname असतो. या एका बाबतीत, एक व्यस्त सार्वजनिक रिले तुम्हाला अधिक चांगल्या प्रकारे लपवू शकतो आणि हाच खरा व्यवहार (trade-off) आहे.
• उपलब्धतेची जबाबदारी आता तुमची आहे. डिस्क पूर्ण भरल्यास किंवा सर्व्हर बंद पडल्यास संदेश पोहोचणे थांबते आणि तुमच्या संपर्कांकडे तुम्हाला वगळून मार्ग काढण्याचा कोणताही पर्याय नसतो.

हेच तर्क तुम्ही स्वतःच्या सर्व्हरवर ठेवलेल्या कोणत्याही खाजगी सेवेला लागू होतात, मग तो हा रिले असो किंवा तुमच्या स्वतःच्या VPS वरील WireGuard VPN. तुम्ही फक्त हे निवडत आहात की कोणता घटक मेटाडेटा पाहू शकेल. तुम्ही तो पूर्णपणे नष्ट करत नाही आहात.

जेव्हा ते काम करत नाही

सर्व्हिस सुरू होते आणि लगेच थांबते. sudo journalctl -u smp-server -n 50 वाचा. बाइंड (bind) अयशस्वी झाल्यास, ज्या पोर्टवर ते घेता आले नाही त्याचे नाव समोर येते. त्यानंतर, कोणता प्रोसेस आधीच तो पोर्ट वापरत आहे हे पाहण्यासाठी sudo ss -tlnp | grep :443 चालवा. नवीन सर्व्हरवर सहसा nginx, Caddy किंवा तुम्ही एक तासापूर्वी इन्स्टॉल केलेला XFTP सर्व्हर हे पोर्ट वापरत असतात.

Init ला त्याचे कॉन्फिगरेशन लिहिता येत नाही. /etc/opt/simplex अस्तित्वात येण्यापूर्वी smp युजर म्हणून smp-server init चालवल्यास परवानगी त्रुटी (permission error) येते, कारण /etc/opt ची मालकी root कडे असते. प्रथम योग्य मालकासह डिरेक्टरी तयार करा आणि त्यानंतर init पुन्हा चालवा.

क्लायंट्सना रिलेपर्यंत पोहोचता येत नाही. dig +short smp1.example.com वापरून नाव योग्य पत्त्यावर रिझॉल्व्ह होत आहे का ते तपासा. त्यानंतर, सर्व्हरवरून नाही तर तुमच्या लॅपटॉपवरून पोर्ट तपासा: nc -vz smp1.example.com 5223. जर बाहेरून कनेक्शन अयशस्वी होत असेल आणि ss सर्व्हरवर सॉकेट उघडे असल्याचे दर्शवत असेल, तर याचा अर्थ प्रोव्हायडरच्या नेटवर्क फायरवॉलमध्ये समस्या आहे, जे ufw पेक्षा वेगळे नियंत्रण आहे.

एखादा संपर्क तुमच्या रिलेद्वारे कनेक्ट होऊ शकत नाही. तुम्ही शेअर केलेल्या पत्त्यातील फिंगरप्रिंट /etc/opt/simplex/fingerprint मधील सध्याच्या मजकुराशी जुळले पाहिजे. जर तुम्ही [AUTH] अंतर्गत create_password सेट केले असेल, तर पत्त्यामध्ये तो पासवर्ड असणे आवश्यक आहे, अन्यथा क्लायंटला रांग (queue) तयार करण्याची परवानगी मिळणार नाही.

अॅपमध्ये सर्व्हर जोडल्यानंतर काहीही हलले नाही. हे अपेक्षितच आहे. फक्त नवीन संपर्कच नव्याने जोडलेल्या रिलेचा वापर करतात. अस्तित्वात असलेले संपर्क त्यांच्याकडे आधीपासून असलेल्या रांगा (queues) वापरत राहतात.

FAQ

SimpleX सर्व्हर स्वतः होस्ट केल्याने माझे संदेश अधिक सुरक्षित होतात का?

नाही, आणि ते डिझाइननुसारच आहे. SimpleX उपकरणांमधील संदेशांचे end-to-end एन्क्रिप्शन करते, त्यामुळे relay चालवणारी व्यक्ती कोणीही असली तरी त्यांच्याकडे की (keys) नसतात. स्वतः होस्ट केल्याने त्या संदेशांच्या मेटाडेटावर कोणाचे लक्ष आहे हे बदलते: कोणते queues अस्तित्वात आहेत, ते कधी वाचले जातात आणि कोणते IP addresses कनेक्ट होतात. हा मेटाडेटाचा निर्णय आहे. जर तुमचे स्वतः होस्ट करण्याचे कारण अधिक मजबूत एन्क्रिप्शन असेल, तर एन्क्रिप्शन आधीच तिथे अस्तित्वात होते.

SimpleX relay ऑपरेटर प्रत्यक्षात काय पाहू शकतो?

प्रकल्पाचे protocol/security.md हे स्पष्ट करते. Relay संदेशांची सामग्री किंवा प्रकार वाचू शकत नाही, वैयक्तिक संदेशांमध्ये अदृश्यपणे बदल करू शकत नाही आणि सक्रिय हल्ल्याद्वारे end-to-end एन्क्रिप्शन तोडू शकत नाही. तो हे पाहू शकतो की रांगेचा (queue) प्राप्तकर्ता कधी ऑनलाइन आहे, रांगेतून जाणारे संदेश मोजू शकतो, प्राप्तकर्त्याचा IP address जाणून घेऊ शकतो, रांगेतील भविष्यातील संदेश ड्रॉप करू शकतो किंवा त्या रांगेच्या स्थितीबद्दल खोटे सांगू शकतो. एकदा का relay तुमच्या ताब्यात आला की, ही शक्ती तुमच्याकडे येते.

मला domain name आणि TLS certificate ची गरज आहे का?

वापरण्यायोग्य सेटअपसाठी तुम्हाला domain ची गरज आहे आणि जर तुमच्याकडे खरोखर काही नसेल तर smp-server init हे --ip स्वीकारते. मेसेजिंग पोर्टसाठी तुम्हाला सार्वजनिक प्राधिकरणाकडून (public authority) प्रमाणपत्राची गरज नाही: init स्वतःचे प्राधिकरण तयार करते आणि क्लायंट तुमच्या smp:// पत्त्यामध्ये दिसणारा फिंगरप्रिंट पिन करतो. सार्वजनिकरित्या विश्वासार्ह प्रमाणपत्राची गरज फक्त पर्यायी वेब माहिती पृष्ठासाठी असते, जे smp-server.ini च्या [WEB] विभागात cert आणि key म्हणून कॉन्फिगर केलेले असते.

जर मी /etc/opt/simplex गमावले तर काय होईल?

तुम्ही दिलेले प्रत्येक पत्ते काम करणे थांबवतील. त्या डिरेक्टरीमध्ये प्रमाणपत्र प्राधिकरण (certificate authority) असते ज्याचा फिंगरप्रिंट तुमच्या सर्व्हर पत्त्यामध्ये एम्बेड केलेला असतो, त्यामुळे पुन्हा तयार केल्यास (rebuild) वेगळा फिंगरप्रिंट तयार होतो आणि परिणामी वेगळा सर्व्हर तयार होतो. ज्या संपर्कांचे queues त्या relay वर आहेत, ते क्लायंटच्या बाजूने दुरुस्त केले जाऊ शकत नाहीत. डिरेक्टरीचे एन्क्रिप्टेड बॅकअप सर्व्हरच्या बाहेर ठेवा आणि दस्तऐवजात सांगितल्याप्रमाणे ca.key ऑफलाइन साठवा, कारण ज्याच्याकडे ते असेल तो तुमच्या relay चे रूप धारण करू शकतो.

मी SMP relay आणि XFTP file relay एकाच VPS वर चालवू शकतो का?

हो, पण एक संघर्ष सोडवावा लागेल. XFTP सर्व्हरचा दस्तऐवजीकरण केलेला पोर्ट 443 आहे आणि डीफॉल्ट SMP कॉन्फिगरेशनमध्ये port: 5223,443 दिलेले आहे, त्यामुळे दोघांनाही एकाच सॉकेटची गरज असते. त्यापैकी एकाला 443 पोर्ट द्या: SMP सर्व्हरसाठी port: 5223 सेट करा किंवा file relay दुसऱ्या IP address वर किंवा दुसऱ्या VPS वर हलवा. तसेच तुमच्याकडे असलेल्या डिस्कच्या क्षमतेनुसार स्टोरेज कोटा ठरवा, कारण file relay हा घटक डिस्क आणि बँडविड्थचा वापर करतो.