VPS वर स्वतःचा SimpleX चॅट सर्व्हर कसा होस्ट करावा

SimpleX चॅट सर्व्हर काय करतो

SimpleX चॅट सर्व्हर स्वतः होस्ट करण्यासाठी तुम्ही VPS वर एक डेमन चालवता: smp-server, जो SMP (SimpleX Messaging Protocol) साठी रिले म्हणून काम करतो. यामध्ये ते मेसेज क्यू (queues) असतात, जिथे तुमचे संपर्क मेसेज लिहितात आणि वाचतात. xftp-server नावाचा दुसरा, ऐच्छिक डेमन फाईल ट्रान्सफर रिले करतो. हे दोन्ही एकाच प्रोजेक्टमधून, simplexmq, येतात आणि प्रत्येकामध्ये एक सिंगल बायनरी, एक कॉन्फिगरेशन फाईल आणि एक append-only लॉग असतो.

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

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

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

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

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

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

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

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

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

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

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

• Ubuntu 22.04 किंवा 24.04 वर चालणारा एक VPS. हा प्रकल्प केवळ या दोन आवृत्त्यांसाठी x86-64 आणि aarch64 आर्किटेक्चरवर तयार केलेले release binaries प्रकाशित करतो.
• तुमच्या VPS कडे निर्देश करणारा A record असलेला एक domain name, आणि जर तुमच्याकडे IPv6 असेल तर AAAA record. दस्तऐवजीकरणामध्ये उदाहरणासाठी smp1.example.com चा वापर केला आहे.
• Root किंवा sudo ॲक्सेस, आणि firewall मध्ये बदल करताना उघडे असलेले दुसरे 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) हे क्यूजचा (queues) एक 'append-only' लॉग /var/opt/simplex/smp-server-store.log मध्ये लिहिते, ज्यामुळे रीस्टार्टनंतरही रिले कार्यरत राहतो. याशिवाय, रीस्टार्ट केल्यास सर्व क्यूज नष्ट होतात, ज्याचा अर्थ तुमच्याद्वारे राउट केलेले सर्व संपर्क काम करणे थांबवतात.
• --daily-stats (-s) हे काउंटर CSV फॉरमॅटमध्ये /var/opt/simplex/smp-server-stats.daily.log मध्ये लिहिते.
• --fqdn हे तुमच्या डोमेनला जनरेट केलेल्या प्रमाणपत्रात (certificate) समाविष्ट करते. जर तुमच्याकडे डोमेन नसेल, तर त्याऐवजी --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 वापरून सर्व्हर प्रमाणपत्र रोटेट करण्यासाठीच तुम्हाला याची पुन्हा गरज पडेल.

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

Run it under systemd as an unprivileged user

Write /etc/systemd/system/smp-server.service, exactly as the docs give it:

[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

The upstream unit also carries AmbientCapabilities=CAP_NET_BIND_SERVICE. That line exists because the process runs as smp, and ports below 1024 are closed to a non-root process, so without it the daemon cannot bind 80 or 443. Add it if you serve those ports. LimitNOFILE=65535 matters because every subscribed client holds an open TCP connection, and the default limit is far below what a busy relay needs. ExecStopPost copies the store log to a .bak file on every stop, which gives you one free rollback point.

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

A healthy start logs the server address. Then confirm the sockets are actually open:

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

Both lines should name smp-server. Running the daemon under its own account with no sudo rights is the same habit described in per-service accounts on a VPS, and it is what stops a bug in one network daemon from becoming a root shell.

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

दस्तऐवजात तीन पोर्ट्सची यादी दिली आहे: 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) हटवते, त्यामुळे ते लूपबॅकवरच असणे आवश्यक आहे, जिथे प्रशासक आणि वापरकर्त्याचे पासवर्ड [AUTH] अंतर्गत सेट केलेले असतात. जर तुम्ही या टूलसाठी नवीन असाल, तर VPS वर ufw ची मूलभूत माहिती या लेखात नियमांचा क्रम आणि स्वतःला लॉक-आउट होण्यापासून कसे वाचवावे, याची माहिती दिली आहे.

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

तुमच्या क्लायंटना आवश्यक असलेला सर्व्हर पत्ता

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

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

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

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

XFTP (SimpleX file transfer protocol) हा नेटवर्कचा फाइल हस्तांतरण करणारा भाग आहे. हा एक स्वतंत्र डेमन (daemon) असून त्याचा स्वतःचा पत्ता असतो. प्रकल्पाच्या XFTP घोषणेनुसार, रिलेकडे फाइलचे कोणतेही मेटाडेटा नसतात. ते फक्त स्वतंत्र चंक्स (chunks) पाहतात, जे प्रत्येकी 256kb, 1mb किंवा 4mb आकाराचे असतात. या चंक्सचा ॲक्सेस अनामिक क्रेडेन्शियल्सद्वारे अधिकृत केला जातो. पाठवणारा (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/ मध्ये, स्टेट /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 पोर्टचा उल्लेख आहे. दोन प्रक्रिया एकाच पत्त्यावर एकाच पोर्टला बाइंड (bind) होऊ शकत नाहीत, त्यामुळे एका VPS वर तुम्हाला काहीतरी बदल करावे लागतील. सर्वात सोपा उपाय म्हणजे SMP च्या [TRANSPORT] सेक्शनमध्ये port: 5223 सेट करणे आणि 443 पोर्ट फाइल रिलेसाठी मोकळा ठेवणे. मात्र, यामुळे प्रतिबंधित नेटवर्कवर असलेल्या क्लायंटसाठी 443 पोर्टचा फॉलबॅक उपलब्ध राहणार नाही. इतर पर्यायांमध्ये त्याच VPS वर दुसरा IP पत्ता वापरणे किंवा दुसरा VPS घेणे यांचा समावेश होतो.

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

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

दोन डिरेक्टरीज महत्त्वाच्या आहेत. /etc/opt/simplex/ ही सर्व्हरची ओळख आहे: यामध्ये smp-server.ini, सर्व्हरचे प्रमाणपत्र (certificate) आणि की (key), ca.key, आणि fingerprint यांचा समावेश होतो. /var/opt/simplex/ मध्ये सर्व्हरची स्थिती (state) असते: smp-server-store.log मध्ये रांगा (queues) असतात आणि जेव्हा restore_messages: on सक्रिय असते, तेव्हा न पाठवलेले संदेश (undelivered messages) तसेच दैनंदिन सांख्यिकी फाईल (daily 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) साठीचे सायफरटेक्स्ट (ciphertext) आहेत ज्या रिलेकडे कधीच नव्हत्या, आणि पुरवलेली [STORE_LOG] कॉन्फिगरेशन फाईल 21 दिवसांनंतर संदेश आपोआप काढून टाकते. ही फाईल सर्व्हरच्या ओळखीची प्रत आहे, ज्यामध्ये ca.key चा समावेश आहे. त्यामुळे, ज्याच्याकडे ही फाईल जाईल, तो तुमच्या संपर्कांसमोर स्वतःला तुमचा रिले म्हणून सादर करू शकतो. या फाईलला एनक्रिप्ट करा आणि ती सर्व्हरपासून दूर सुरक्षित ठेवा.

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

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

SMP ट्रान्सपोर्ट सार्वजनिक प्रमाणपत्र प्राधिकरणाचा (public certificate authority) वापर करत नाही. Init एक खाजगी प्राधिकरण आणि सर्व्हर प्रमाणपत्र तयार करते. या प्राधिकरणाचा फिंगरप्रिंट सर्व्हरच्या पत्त्यामध्ये समाविष्ट असतो. क्लायंट सर्व्हरने सादर केलेले प्रमाणपत्र या पिन केलेल्या फिंगरप्रिंटशी जुळवून पाहतो. प्रकल्प यालाच क्लायंट-टू-सर्व्हर कनेक्शनचे 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 यांची नावे असतात. ब्राउझरला तुमच्या खाजगी प्राधिकरणाची माहिती नसते, म्हणून सार्वजनिकरित्या विश्वासार्ह प्रमाणपत्र वापरण्यासाठी हे एकमेव योग्य ठिकाण आहे. दस्तऐवजातील 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 असते. एक व्यस्त सार्वजनिक रिले तुम्हाला या एका बाबतीत अधिक चांगल्या प्रकारे लपवते, आणि हाच खरा व्यवहार आहे. खाजगी सर्च सर्व्हरचे स्वरूपही असेच असते, म्हणूनच तुमच्या स्वतःच्या VPS वर SearXNG नक्की काय लपवते हे तुमच्यासोबत किती लोक ती इन्स्टन्स वापरतात यावर अवलंबून असते.
• उपलब्धता आता तुमची जबाबदारी आहे. डिस्क पूर्ण भरली किंवा सर्व्हर बंद पडला, तर संदेश पोहोचणे थांबते आणि तुमच्या संपर्कांकडे तुम्हाला वगळून मार्ग काढण्याचा कोणताही पर्याय नसतो.

हीच तर्कपद्धती तुम्ही स्वतःच्या सर्व्हरवर ठेवलेल्या कोणत्याही खाजगी सेवेला लागू होते, मग तो हा रिले असो किंवा तुमच्या स्वतःच्या 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 वापरून नाव योग्य पत्त्यावर रिझॉल्व्ह (resolve) होत आहे का ते तपासा. त्यानंतर, सर्व्हरवरून नव्हे तर तुमच्या लॅपटॉपवरून पोर्टची चाचणी घ्या: nc -vz smp1.example.com 5223. जर ss सर्व्हरवर सॉकेट उघडे असल्याचे दर्शवत असेल, परंतु बाहेरून कनेक्शन अयशस्वी होत असेल, तर याचा अर्थ प्रोव्हायडरच्या नेटवर्क फायरवॉलमध्ये समस्या आहे, जी ufw पेक्षा वेगळी असते.

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

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

FAQ

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

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

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

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

मला डोमेन नेम आणि TLS प्रमाणपत्राची गरज आहे का?

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

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

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

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

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