VPS پر SimpleX چیٹ سرور کو خود ہوسٹ کرنے کا طریقہ

خود میزبان (self-hosted) SimpleX چیٹ سرور کیا کرتا ہے

SimpleX چیٹ سرور کو خود ہوسٹ کرنے کے لیے آپ ایک VPS پر ایک daemon چلاتے ہیں: smp-server، جو SMP (simplex messaging protocol) کے لیے relay ہے۔ یہ ان پیغام کی قطاروں (message queues) کو محفوظ رکھتا ہے جن پر آپ کے رابطے لکھتے اور پڑھتے ہیں۔ ایک دوسرا، اختیاری daemon جسے xftp-server کہا جاتا ہے، فائل ٹرانسفر کو relay کرتا ہے۔ دونوں ایک ہی پروجیکٹ، simplexmq سے آتے ہیں، اور ہر ایک ایک سنگل بائنری، ایک کنفیگریشن فائل، اور ایک append-only لاگ پر مشتمل ہوتا ہے۔

یہ تحریر آپریٹر کے لیے ہے، نہ کہ ایپ استعمال کرنے والے کے لیے۔ relay کے پاس کوئی اکاؤنٹس، کوئی رابطہ فہرستیں اور کوئی چیٹ ہسٹری نہیں ہوتی۔ یہ صرف قطاریں، کچھ غیر پہنچائے گئے ciphertext، اور ایک سرٹیفکیٹ رکھتا ہے جو اس کی شناخت کرتا ہے۔ آپ جو ذمہ داری لیتے ہیں وہ uptime، تھوڑی سی ڈسک، اور وہ میٹا ڈیٹا ہے جو آپ کے باکس سے گزرتا ہے۔

ذیل میں ہر کمانڈ، پاتھ، پورٹ اور فلیگ پروجیکٹ کی اپنی دستاویزات سے لیا گیا ہے: SMP سرور ہوسٹنگ صفحہ، XFTP سرور صفحہ، اور پروٹوکول سیکیورٹی دستاویز۔ جہاں کسی نمبر کی اہمیت ہے، وہاں اس کا ماخذ اس کے ساتھ درج ہے۔

ایسا نیٹ ورک جس میں صارف کی شناخت نہ ہو، اس کے لیے ریلے کی ضرورت کیوں ہے

SimpleX میں نہ تو usernames ہوتے ہیں، نہ فون نمبرز اور نہ ہی account IDs۔ ایک رابطہ (contact) دراصل ایک یک طرفہ قطار (unidirectional queue) ہے: یہ کسی ریلے پر ایک ایسا پتہ ہے جس پر ایک فریق لکھتا ہے اور دوسرا فریق اسے پڑھتا ہے۔ آپ کے دو رابطوں کے درمیان کوئی ایسی مشترکہ شناخت نہیں ہوتی جسے سرور آپس میں جوڑ سکے۔

ان قطاروں کو کسی نہ کسی جگہ موجود ہونا ضروری ہے، جس کی ایک سادہ وجہ ہے۔ دو فون شاذ و نادر ہی ایک ہی وقت میں آن لائن ہوتے ہیں۔ کوئی ایسی چیز ہونی چاہیے جو پیغام کو ابھی وصول کرے اور اسے تب تک محفوظ رکھے جب تک دوسرا آلہ اسے طلب نہ کرے۔ SMP ریلے کا پورا کام یہی ہے۔ اس کا مطلب یہ بھی ہے کہ دونوں آلات کبھی براہ راست ایک دوسرے سے منسلک نہیں ہوتے، لہذا کوئی بھی فریق دوسرے کا IP (internet protocol) ایڈریس نہیں جان پاتا۔ ریلے اس انکشاف کو خود تک محدود رکھتا ہے۔

ریلے کا hostname قطار کے پتے کا حصہ ہوتا ہے، اس لیے یہ ہر اس invitation link کے اندر موجود ہوتا ہے جو آپ وہاں سے جاری کرتے ہیں۔ جب آپ آخر میں threat model پڑھیں تو اس بات کو ذہن میں رکھیں۔

ایک ریلے کیا دیکھ سکتا ہے اور کیا نہیں

پروجیکٹ نے protocol/security.md میں اسے ایک threat model کے طور پر بیان کیا ہے۔ کچھ بھی انسٹال کرنے سے پہلے اسے پڑھنا ضروری ہے، کیونکہ اس گائیڈ کے بعد وہ ریلے آپ کا ہوگا۔ ایک ریلے، بشمول وہ جسے مکمل طور پر کوئی حملہ آور کنٹرول کر رہا ہو، پیغامات کے مواد یا ان کی قسم کو نہیں جان سکتا، انفرادی پیغامات کو بغیر پتہ چلے شامل، نقل یا خراب نہیں کر سکتا، اور کسی فعال حملے (active attack) کے ذریعے end-to-end encryption کو توڑ نہیں سکتا۔

اسی صفحے پر ان کاموں کی فہرست دی گئی ہے جو ایک ریلے کر سکتا ہے۔ یہ جان سکتا ہے کہ queue کا وصول کنندہ کب آن لائن ہوتا ہے۔ یہ گن سکتا ہے کہ ایک queue سے کتنے پیغامات گزرتے ہیں۔ یہ وصول کنندہ کا IP address جان سکتا ہے۔ یہ queue میں موجود ہر مستقبل کے پیغام کو ضائع کر سکتا ہے، یا اس queue کی حالت کے بارے میں جھوٹ بول سکتا ہے۔

لہذا، تقسیم واضح ہے۔ رازداری (confidentiality) کلائنٹ کی ذمہ داری ہے اور self-hosting اس پر اثر انداز نہیں ہوتی۔ میٹا ڈیٹا اور دستیابی (availability) ریلے آپریٹر کی ذمہ داری ہے، اور self-hosting ان دونوں کی ذمہ داری آپ کو سونپ دیتی ہے۔

شروع کرنے سے پہلے آپ کو کن چیزوں کی ضرورت ہے

• Ubuntu 22.04 یا 24.04 پر چلنے والا ایک VPS۔ یہ پروجیکٹ خاص طور پر انہی دو ورژنز کے لیے x86-64 اور aarch64 آرکیٹیکچر پر مبنی release binaries فراہم کرتا ہے۔
• ایک ڈومین نام جس کا A record آپ کے VPS کی طرف اشارہ کر رہا ہو، اور اگر آپ کے پاس IPv6 ہے تو ایک AAAA record بھی۔ دستاویزات میں مثال کے طور پر smp1.example.com استعمال کیا گیا ہے۔
• Root یا sudo تک رسائی، اور فائر وال میں تبدیلیوں کے دوران ایک دوسرا SSH سیشن کھلا رکھیں۔
• سرور سے باہر کسی جگہ بیک اپ محفوظ کرنے کی سہولت، کیونکہ config ڈائریکٹری ہی سرور کی شناخت ہے۔

ARM انسٹینس پر x86-64 کے بجائے aarch64 اثاثہ (asset) استعمال کریں۔ اس گائیڈ میں باقی کوئی چیز تبدیل نہیں ہوتی، اور ARM اور x86 VPS پلانز کے درمیان انتخاب کا تعلق قیمت اور فی کور رفتار سے ہے، نہ کہ اس سے کہ یہ سافٹ ویئر چلتا ہے یا نہیں۔

"latest" کے بجائے ایک مخصوص ریلیز انسٹال کریں

یہ پروجیکٹ ایک انسٹال اسکرپٹ فراہم کرتا ہے جو موجودہ ریلیز کو pull کرتا ہے اور ایک simplex-servers-update کمانڈ رجسٹر کرتا ہے۔ یہ کام کرتا ہے، لیکن پھر بھی ورژن کو پن (pin) کریں: اگر آپ کے علم میں لائے بغیر ریلے (relay) کی بائنری تبدیل ہو جائے تو خرابی کی صورت میں آپ اس کا تجزیہ نہیں کر سکیں گے۔

اگست 2026 تک موجودہ simplexmq ریلیز v6.5.0 ہے، جو 29 اپریل 2026 کو جاری کی گئی تھی۔ ریلیز صفحہ پر مطلوبہ ٹیگ چیک کریں، اور پھر نیچے ہر جگہ اسی ٹیگ کا استعمال کریں۔

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 چیک سsums سے کریں۔ پروجیکٹ ریلیز چیک سsums کو SimpleX Chat کی کلید FB44AF81A45BDE327319797C85107E357D4A17FC کے ساتھ سائن بھی کرتا ہے، جس کی تفصیل سرور صفحہ پر موجود ہے، تاکہ آپ ہیش پڑھنے والے صفحے پر بھروسہ کرنے کے بجائے دستخط (signature) کی تصدیق کر سکیں۔

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

اسے جان بوجھ کر root کی ملکیت میں انسٹال کریں۔ سروس 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 میں لکھتا ہے، تاکہ ریلے (relay) ری اسٹارٹ ہونے کے بعد بھی برقرار رہے۔ اس کے بغیر، ری اسٹارٹ ہونے پر ہر قطار ضائع ہو جاتی ہے، جس کا مطلب ہے کہ آپ کے ذریعے روٹ ہونے والا ہر رابطہ کام کرنا بند کر دے گا۔
• --daily-stats (-s) کاؤنٹرز کو CSV فارمیٹ میں /var/opt/simplex/smp-server-stats.daily.log میں لکھتا ہے۔
• --fqdn آپ کے ڈومین کو تیار کردہ سرٹیفکیٹ میں شامل کرتا ہے۔ اگر آپ کے پاس ڈومین نہیں ہے تو --ip استعمال کریں۔
• --no-password کسی کو بھی آپ کے ریلے پر قطار بنانے کی اجازت دیتا ہے۔ اسے نجی رکھنے کے لیے، init کے بعد /etc/opt/simplex/smp-server.ini میں [AUTH] کے تحت create_password سیٹ کریں، بجائے اس کے کہ یہاں --password پاس کریں۔ اس کی وجہ یہ ہے کہ کمانڈ لائن آپ کی شیل ہسٹری اور چلتے ہوئے پروسیس لسٹ میں نظر آتی ہے۔

Init ایک سرٹیفکیٹ تیار کرتا ہے اور وہ دو ویلیوز پرنٹ کرتا ہے جنہیں آپ کو محفوظ رکھنا ہوگا۔ پہلی ویلیو فنگر پرنٹ ہے، جو ایک base64 سٹرنگ ہے اور اسے /etc/opt/simplex/fingerprint میں بھی لکھا جاتا ہے۔ دوسری ویلیو مکمل سرور ایڈریس ہے، جو فنگر پرنٹ اور آپ کے ہوسٹ نیم کا مجموعہ ہے۔ دونوں کو ابھی کاپی کر لیں۔

Init /etc/opt/simplex/ca.key بھی بناتا ہے، اور دستاویزات آپ کو مشورہ دیتی ہیں کہ اس فائل کو آف لائن اسٹوریج میں منتقل کر دیں۔ اس کی وجہ یہ ہے: کلائنٹس اس سرٹیفکیٹ اتھارٹی کے فنگر پرنٹ کو پن (pin) کر لیتے ہیں، لہذا جس کے پاس بھی ca.key ہوگا، وہ ایک نیا سرور سرٹیفکیٹ جاری کر سکتا ہے جسے آپ کے کلائنٹس آپ کا سرٹیفکیٹ سمجھ کر قبول کر لیں گے۔ آپ کو اسے صرف بعد میں smp-server cert کے ساتھ سرور سرٹیفکیٹ کو تبدیل (rotate) کرنے کے لیے واپس لانے کی ضرورت ہوگی۔

Init کو ایک بار کیا جانے والا عمل سمجھیں۔ آپ کے ایڈریس میں موجود فنگر پرنٹ اس اتھارٹی سے آتا ہے جسے یہ تیار کرتا ہے، لہذا اسے دوبارہ بنانے سے آپ کو ایک مختلف ایڈریس ملے گا اور آپ کا پرانا ایڈریس بے کار ہو جائے گا۔

اسے 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

اوپر والی unit میں AmbientCapabilities=CAP_NET_BIND_SERVICE بھی شامل ہے۔ یہ لائن اس لیے موجود ہے کیونکہ عمل smp کے طور پر چلتا ہے، اور 1024 سے نیچے کے ports ایک غیر روٹ عمل کے لیے بند ہوتے ہیں، لہذا اس کے بغیر daemon 80 یا 443 پر bind نہیں ہو سکتا۔ اگر آپ ان ports کو serve کرتے ہیں تو اسے شامل کریں۔ LimitNOFILE=65535 اس لیے اہم ہے کیونکہ ہر سبسکرائب شدہ کلائنٹ ایک کھلا TCP کنکشن رکھتا ہے، اور ڈیفالٹ حد اس سے کہیں کم ہے جس کی ایک مصروف relay کو ضرورت ہوتی ہے۔ 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 کا نام ہونا چاہیے۔ daemon کو اس کے اپنے اکاؤنٹ کے تحت بغیر کسی sudo حقوق کے چلانا وہی عادت ہے جس کا ذکر VPS پر فی سروس اکاؤنٹس میں کیا گیا ہے، اور یہی وہ چیز ہے جو ایک نیٹ ورک daemon میں موجود بگ کو روٹ شیل بننے سے روکتی ہے۔

کون سے ports کھولیں، اور کون سا بند رکھیں

دستاویزات میں تین ports درج ہیں: 5223/tcp، 443/tcp اور 80/tcp۔ Port 5223 دراصل SMP ٹرانسپورٹ ہے۔ فراہم کردہ کنفیگریشن port: 5223,443 کو [TRANSPORT] کے تحت سیٹ کرتی ہے، لہذا یہی پروٹوکول 443 پر بھی جواب دیتا ہے، جو کہ اہم ہے کیونکہ بہت سے محدود نیٹ ورکس صرف آؤٹ باؤنڈ 443 کی اجازت دیتے ہیں اور کچھ نہیں۔ Port 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

Port 5224 کو ہرگز نہ کھولیں۔ یہ کنٹرول پورٹ ہے، اور دستاویزات کے مطابق اس تک رسائی خود سرور سے nc 127.0.0.1 5224 کے ذریعے کی جاتی ہے۔ یہ سرور کی حالت کو پرنٹ کرتا ہے اور قطاروں (queues) کو ڈیلیٹ کرتا ہے، اس لیے اسے لوپ بیک (loopback) پر رہنا چاہیے جہاں ایڈمن اور صارف کے پاس ورڈز [AUTH] کے تحت سیٹ ہوں۔ اگر آپ اس ٹول کے لیے نئے ہیں، تو VPS پر ufw کی بنیادی باتیں میں رولز کی ترتیب اور خود کو لاک آؤٹ ہونے سے بچانے کا طریقہ بیان کیا گیا ہے۔

ایک اور کنٹرول اکثر لوگوں کے لیے مسئلہ بنتا ہے۔ زیادہ تر پرووائیڈرز پینل میں ایک نیٹ ورک فائر وال چلاتے ہیں، جو سرور پر موجود ufw سے الگ ہوتی ہے۔ ایک پورٹ ufw میں کھلی ہو سکتی ہے لیکن آپ تک پہنچنے سے پہلے ہی اسے ڈراپ کیا جا سکتا ہے۔

وہ سرور ایڈریس جس کی آپ کے کلائنٹس کو ضرورت ہے

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

یہ سٹرنگ کلائنٹ سائیڈ کی مکمل کنفیگریشن ہے۔ اسے ایپ کی سرور سیٹنگز میں پیسٹ کریں، یا ایپ میں موجود QR کوڈ کو اسکین کرنے کی سہولت دیں۔ دستاویزات میں یہ ذکر ہے کہ QR کوڈ میں پاس ورڈ بھی شامل ہوتا ہے، لہذا جو شخص اسے اسکین کرے گا وہ آپ کے سرور کے ذریعے پیغامات وصول کر سکے گا۔

ایک دستاویزی رویہ سب کو حیران کر دیتا ہے۔ ایپ میں اپنا سرور شامل کرنے کا اثر صرف ان رابطوں پر ہوتا ہے جو آپ اس کے بعد بناتے ہیں۔ موجودہ رابطے ان ریلے (relays) پر ہی رہتے ہیں جہاں ان کی قطاریں (queues) بنائی گئی تھیں، اور وہ منتقل نہیں ہوتے۔ یہی وجہ ہے کہ آپ کسی ریلے کو تبدیل کرنے کے اگلے ہی دن اسے بند نہیں کر سکتے۔

XFTP فائل ریلے کا اضافہ

XFTP (SimpleX file transfer protocol) نیٹ ورک کا فائل والا حصہ ہے، اور یہ اپنے الگ ایڈریس کے ساتھ ایک علیحدہ daemon ہے۔ پروجیکٹ کے XFTP اعلان کے مطابق، ریلے کے پاس فائل کا کوئی metadata نہیں ہوتا: وہ صرف انفرادی chunks دیکھ سکتے ہیں، جن میں سے ہر ایک 256kb، 1mb یا 4mb کا ہوتا ہے، اور ان تک رسائی anonymous credentials کے ذریعے مجاز ہوتی ہے۔ ایک بھیجنے والا ایک فائل کے chunks کو کئی ریلے پر پھیلا سکتا ہے، لہذا آپ کا سرور فائلیں نہیں بلکہ ان کے ٹکڑے رکھتا ہے۔

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/ میں، اور فائل کے chunks اس جگہ ہوتے ہیں جس کا نام -p میں درج ہے۔ systemd یونٹ کی ساخت User=xftp اور ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS کے ساتھ ویسی ہی ہے۔ Init ایک xftp:// ایڈریس پرنٹ کرتا ہے جو SMP والے فارمیٹ جیسا ہی ہوتا ہے، اور اس کا اپنا fingerprint /etc/opt/simplex-xftp/fingerprint میں ہوتا ہے۔

ایک تصادم (collision) ہے جس کے لیے منصوبہ بندی ضروری ہے۔ XFTP سرور کا دستاویزی پورٹ 443 ہے، اور SMP کنفیگریشن میں بھی 443 درج ہے۔ دو پروسیس ایک ہی ایڈریس پر ایک ہی پورٹ کو bind نہیں کر سکتے، اس لیے ایک VPS پر کسی ایک کو راستہ دینا ہوگا۔ سب سے آسان حل یہ ہے کہ SMP کے [TRANSPORT] سیکشن میں port: 5223 کو سیٹ کر دیا جائے اور 443 کو فائل ریلے کے لیے چھوڑ دیا جائے، جس کی قیمت یہ ہوگی کہ محدود نیٹ ورکس پر موجود کلائنٹس کے لیے 443 کا fallback دستیاب نہیں ہوگا۔ متبادل حل یہ ہیں کہ اسی VPS پر دوسرا IP ایڈریس استعمال کیا جائے، یا دوسرا VPS لیا جائے۔

کوٹہ (quota) کا تعین ایمانداری سے کریں۔ -q '20gb' اس ڈسک کے بارے میں ایک وعدہ ہے جو آپ کے پاس موجود ہے۔ فائل ریلے وہ حصہ ہے جو ڈسک اور بینڈوڈتھ استعمال کرتا ہے۔ میسج ریلے ان دونوں میں سے کسی کو بھی بمشکل ہی استعمال کرتا ہے۔

ڈسک پر کیا محفوظ رہتا ہے، اور بیک اپ کیا بحال کرتا ہے

دو ڈائریکٹریز اہم ہیں۔ /etc/opt/simplex/ شناخت ہے: smp-server.ini، سرور سرٹیفکیٹ اور کی، ca.key، اور fingerprint۔ /var/opt/simplex/ حالت (state) ہے: smp-server-store.log میں قطاریں (queues) ہوتی ہیں اور، جب restore_messages: on ہو، تو غیر پہنچائے گئے پیغامات، روزانہ کے اعدادوشمار کی فائل کے ساتھ۔

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

واضح رہیں کہ وہ آرکائیو کیا ہے۔ یہ پیغامات کا آرکائیو نہیں ہے: قطار میں موجود آئٹمز ان کیز کے لیے سائفر ٹیکسٹ ہیں جو ریلے کے پاس کبھی نہیں تھیں، اور فراہم کردہ [STORE_LOG] کنفیگریشن ویسے بھی 21 دنوں کے بعد پیغامات کو ختم کر دیتی ہے۔ یہ سرور کی شناخت کی ایک کاپی ہے، جس میں ca.key شامل ہے، لہذا جو بھی اس فائل کو حاصل کر لے وہ آپ کے رابطوں کے سامنے خود کو آپ کا ریلے ظاہر کر سکتا ہے۔ اسے انکرپٹ کریں اور سرور سے باہر محفوظ رکھیں۔

اس کا فائدہ بحالی (restore) ہے۔ /etc/opt/simplex کو ایک نئے VPS پر واپس رکھیں، اسی DNS نام کو اس کی طرف پوائنٹ کریں، اور فنگر پرنٹ تبدیل نہیں ہوگا، لہذا ہر وہ ایڈریس جو آپ نے دیا تھا وہ اب بھی کام کرے گا۔ اس ڈائریکٹری کو کھونے کا مطلب ہے کوئی ریکوری ممکن نہیں: ایک نئی انسٹالیشن کا مطلب ایک نیا فنگر پرنٹ ہے، جس کا مطلب ایک نیا ایڈریس ہے، جس کا مطلب یہ ہے کہ آپ کے ریلے کے ذریعے روٹ ہونے والا ہر رابطہ ختم ہو چکا ہے۔

TLS: دو سرٹیفکیٹس جو مختلف کام انجام دیتے ہیں

SMP ٹرانسپورٹ پبلک سرٹیفکیٹ اتھارٹی کا استعمال نہیں کرتی ہے۔ Init ایک پرائیویٹ اتھارٹی اور سرور سرٹیفکیٹ تیار کرتا ہے، اور اس اتھارٹی کا فنگر پرنٹ سرور ایڈریس کے اندر سفر کرتا ہے۔ کلائنٹ اس بات کی تصدیق کرتا ہے کہ سرور جو پیش کر رہا ہے وہ اس پن شدہ فنگر پرنٹ سے مطابقت رکھتا ہے، جسے پروجیکٹ کلائنٹ سے سرور کنکشن کو machine-in-the-middle حملوں سے بچانے کے طور پر بیان کرتا ہے۔ اس پورٹ پر چلانے کے لیے کوئی ACME (automatic certificate management environment) کلائنٹ موجود نہیں ہے، اور روٹیشن ایک دستی smp-server cert عمل ہے جس میں SMP_SERVER_CFG_PATH سیٹ کیا جاتا ہے۔

اختیاری انفارمیشن پیج دوسرا سرٹیفکیٹ ہے۔ اس کا [WEB] سیکشن static_path، https: 443، cert: /etc/opt/simplex/web.crt اور key: /etc/opt/simplex/web.key کے نام بتاتا ہے۔ براؤزر نے آپ کی پرائیویٹ اتھارٹی کے بارے میں کبھی نہیں سنا ہوتا، لہذا یہ وہ واحد جگہ ہے جہاں عوامی طور پر قابل اعتماد سرٹیفکیٹ کا استعمال ہونا چاہیے۔ دستاویزات کا Docker کوئیک اسٹارٹ بالکل اسی مقصد کے لیے Caddy کو سرور کے سامنے رکھتا ہے، اور سرٹیفکیٹ خود بخود جاری کر دیتا ہے۔

Tor کے ذریعے ریلے تک رسائی

دستاویزات میں Tor کا ایک سیکشن شامل ہے جو Tor Project کی ریپوزٹری سے Tor انسٹال کرتا ہے اور /etc/tor/torrc میں ایک hidden service کا اضافہ کرتا ہے:

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 ایڈریس آپ پر ظاہر نہیں کرتا، لیکن سرور خود اپنے public IP پر تلاش کیا جا سکتا ہے۔ /var/lib/tor/simplex-smp/hostname سے حاصل کردہ onion ہوسٹ نیم کو سرور ایڈریس کے آخر میں کوما کے بعد درج کیا جاتا ہے۔ اگر آپ سرور کا مقام بھی پوشیدہ رکھنا چاہتے ہیں، تو اس کی کنفیگریشن مختلف ہے، اور VPS پر حقیقی onion سروس چلانا اس کے متبادل کا احاطہ کرتا ہے۔ ہر ٹول کیا کچھ چھپاتا ہے، اس کا فرق Tor بمقابلہ VPN کا موضوع ہے، اور یہ یہاں براہ راست لاگو ہوتا ہے۔

تھریٹ ماڈل: سیلف ہوسٹنگ کیا تبدیل کرتی ہے

یہ آپ کو کیا فائدہ دیتی ہے۔ میٹا ڈیٹا (کون سی قطاریں موجود ہیں، کب پڑھی جاتی ہیں، کون سے پتے جڑتے ہیں) ایک ایسی مشین پر ہوتا ہے جسے آپ کنٹرول کرتے ہیں، اور آپ طے کرتے ہیں کہ اس میں سے کتنا ڈیٹا کتنی دیر تک محفوظ رکھا جائے۔ آپ کسی ایسے بڑے گروپ کا حصہ بھی نہیں ہوتے جس کا ڈیٹا ایک ہی بار میں مانگا جا سکے۔

یہ آپ کو کیا فائدہ نہیں دیتی، واضح الفاظ میں:

• انکرپشن میں کوئی تبدیلی نہیں آتی۔ آپ کے اس سسٹم کو بنانے سے پہلے پیغامات اینڈ ٹو اینڈ انکرپٹڈ تھے اور اسے بنانے کے بعد بھی وہ اینڈ ٹو اینڈ انکرپٹڈ ہی رہتے ہیں۔ سیلف ہوسٹنگ میٹا ڈیٹا کا فیصلہ ہے، کرپٹوگرافی کا نہیں۔
• آپ کا VPS فراہم کنندہ آپ کے IP ایڈریس پر آنے والی ٹریفک کو دیکھتا ہے اور آپ کی بلنگ کی تفصیلات رکھتا ہے۔ آپ نے اعتماد کو ایک میسجنگ آپریٹر سے ہوسٹنگ آپریٹر پر منتقل کیا ہے۔ آپ نے اسے ختم نہیں کیا۔
• آپ کا ریلے ایک چھوٹا سا ہجوم ہے۔ اگر یہ صرف ایک گھر کو سروس دیتا ہے، تو اس سے جڑنا اس گھر کی شناخت ظاہر کرتا ہے، اور اس کا ہوسٹ نیم ہر اس انویٹیشن لنک کے اندر موجود ہوتا ہے جو آپ وہاں سے بھیجتے ہیں۔ ایک مصروف عوامی ریلے اس ایک پہلو سے آپ کو بہتر چھپاتا ہے، اور یہی اصل سودا ہے۔
• دستیابی اب آپ کی ذمہ داری ہے۔ ڈسک کا بھر جانا یا سرور کا بند ہونا مطلب پیغامات کی ترسیل کا رک جانا ہے، اور آپ کے رابطوں کے پاس آپ کے گرد راستہ بنانے کا کوئی طریقہ نہیں ہوتا۔

یہی استدلال کسی بھی ایسی نجی سروس پر لاگو ہوتا ہے جسے آپ اپنے باکس پر رکھتے ہیں، چاہے وہ یہ ریلے ہو یا آپ کے اپنے VPS پر ایک WireGuard VPN۔ آپ انتخاب کر رہے ہیں کہ کون سا فریق میٹا ڈیٹا دیکھے گا۔ آپ اسے غائب نہیں کر رہے ہیں۔

جب یہ کام نہ کرے

سروس شروع ہو کر فوراً بند ہو جاتی ہے۔ sudo journalctl -u smp-server -n 50 پڑھیں۔ Bind میں ناکامی اس پورٹ کا نام بتاتی ہے جسے وہ حاصل نہیں کر سکی۔ پھر sudo ss -tlnp | grep :443 چلائیں تاکہ معلوم ہو سکے کہ کون سا عمل (process) پہلے ہی اسے استعمال کر رہا ہے، جو کہ ایک نئے سرور پر عام طور پر 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) بنانے کی اجازت نہیں ہوگی۔

ایپ میں سرور شامل کرنے کے بعد کچھ بھی منتقل نہیں ہوا۔ یہ جان بوجھ کر ہے۔ صرف نئے رابطے ہی نئے شامل کردہ ریلے کا استعمال کرتے ہیں۔ موجودہ رابطے اپنی پرانی قطاریں ہی برقرار رکھتے ہیں۔

FAQ

کیا SimpleX سرور کو خود ہوسٹ کرنے سے میرے پیغامات زیادہ محفوظ ہو جاتے ہیں؟

نہیں، اور یہ ڈیزائن کے لحاظ سے ایسا ہی ہے۔ SimpleX آلات کے درمیان پیغامات کو اینڈ ٹو اینڈ انکرپٹ کرتا ہے، لہذا اسے چلانے والا کوئی بھی شخص، relay کے پاس کبھی بھی keys نہیں ہوتی۔ خود ہوسٹ کرنے سے صرف یہ بدلتا ہے کہ ان پیغامات کے گرد موجود میٹا ڈیٹا (metadata) کو کون دیکھ رہا ہے: کون سی قطاریں (queues) موجود ہیں، انہیں کب پڑھا جاتا ہے، اور کون سے IP ایڈریسز منسلک ہوتے ہیں۔ یہ میٹا ڈیٹا سے متعلق فیصلہ ہے۔ اگر آپ کی خود ہوسٹ کرنے کی وجہ مضبوط انکرپشن ہے، تو انکرپشن پہلے سے ہی موجود تھی۔

ایک SimpleX relay آپریٹر اصل میں کیا دیکھ سکتا ہے؟

پروجیکٹ کا protocol/security.md اس کی وضاحت کرتا ہے۔ ایک relay پیغامات کے مواد یا اقسام کو نہیں پڑھ سکتا، انفرادی پیغامات کو خفیہ طور پر تبدیل نہیں کر سکتا، اور ایکٹو حملے کے ذریعے اینڈ ٹو اینڈ انکرپشن کو توڑ نہیں سکتا۔ یہ دیکھ سکتا ہے کہ قطار کا وصول کنندہ کب آن لائن ہے، قطار سے گزرنے والے پیغامات کی گنتی کر سکتا ہے، وصول کنندہ کا IP ایڈریس جان سکتا ہے، قطار میں مستقبل کے پیغامات کو ضائع کر سکتا ہے، یا اس قطار کی حالت کے بارے میں جھوٹ بول سکتا ہے۔ جب relay آپ کا ہوتا ہے تو یہ اختیارات آپ کے پاس ہوتے ہیں۔

کیا مجھے ڈومین نام اور TLS سرٹیفکیٹ کی ضرورت ہے؟

قابل استعمال سیٹ اپ کے لیے آپ کو ایک ڈومین کی ضرورت ہے، اور اگر آپ کے پاس واقعی کوئی ڈومین نہیں ہے تو smp-server init، --ip کو قبول کرتا ہے۔ میسجنگ پورٹ کے لیے آپ کو کسی پبلک اتھارٹی سے سرٹیفکیٹ کی ضرورت نہیں ہے: init اپنی اتھارٹی خود تیار کرتا ہے، اور کلائنٹ اس فنگر پرنٹ کو پن (pin) کرتا ہے جو آپ کے smp:// ایڈریس میں ظاہر ہوتا ہے۔ عوامی طور پر قابل اعتماد سرٹیفکیٹ کی ضرورت صرف اختیاری ویب انفارمیشن پیج کے لیے ہوتی ہے، جسے smp-server.ini کے [WEB] سیکشن میں cert اور key کے طور پر کنفیگر کیا جاتا ہے۔

اگر میں /etc/opt/simplex کھو دوں تو کیا ہوگا؟

آپ کا دیا ہوا ہر ایڈریس کام کرنا بند کر دے گا۔ اس ڈائریکٹری میں وہ سرٹیفکیٹ اتھارٹی موجود ہوتی ہے جس کا فنگر پرنٹ آپ کے سرور ایڈریس میں ایمبیڈڈ ہوتا ہے، لہذا دوبارہ تعمیر کرنے سے ایک مختلف فنگر پرنٹ اور نتیجتاً ایک مختلف سرور بنتا ہے۔ جن رابطوں کی قطاریں اس relay پر موجود ہیں، انہیں کلائنٹ کی طرف سے ٹھیک نہیں کیا جا سکتا۔ ڈائریکٹری کا انکرپٹڈ بیک اپ لیں اور اسے سرور سے باہر رکھیں، اور ca.key کو دستاویزات کی ہدایت کے مطابق آف لائن اسٹور کریں، کیونکہ جو بھی اسے حاصل کر لے گا وہ آپ کے relay کا روپ دھار سکتا ہے۔

کیا میں SMP relay اور XFTP فائل relay کو ایک ہی VPS پر چلا سکتا ہوں؟

جی ہاں، لیکن ایک تنازعہ حل کرنا ہوگا۔ XFTP سرور کی دستاویزی پورٹ 443 ہے اور ڈیفالٹ SMP کنفیگریشن میں port: 5223,443 درج ہے، لہذا دونوں ایک ہی ساکٹ چاہتے ہیں۔ ان میں سے ایک کو 443 پورٹ دیں: SMP سرور کے لیے port: 5223 سیٹ کریں، یا فائل relay کو دوسرے IP ایڈریس یا دوسرے VPS پر منتقل کریں۔ اس کے علاوہ اسٹوریج کوٹہ کو اپنی اصل ڈسک کے مطابق رکھیں، کیونکہ فائل relay ہی وہ جزو ہے جو ڈسک اور بینڈوتھ استعمال کرتا ہے۔