SSD Nodes Learn Hosting plans →
تعلیمی Matt Connorتحریر: Matt Connor · اپ ڈیٹ شدہ 2026-08-29

VPS پر SimpleX چیٹ سرور کو خود میزبان کیسے کریں

اپنے VPS پر SimpleX SMP relay چلانے کا مکمل طریقہ۔ اس گائیڈ میں unprivileged service user، TLS کنفیگریشن، ضروری ports، اور سرور بیک اپ کے لیے درست کمانڈز شامل ہیں۔

خود میزبان (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 سرور صفحہ، اور پروٹوکول سیکیورٹی دستاویز۔ جہاں کسی نمبر کی اہمیت ہے، وہاں اس صفحے کا نام اس کے ساتھ درج کیا گیا ہے جہاں سے وہ لیا گیا ہے۔

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

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

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

relay کا 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 ان دونوں کی ذمہ داری آپ کو سونپ دیتی ہے۔

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

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

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

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

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

اگست 2026 تک simplexmq کا موجودہ release ورژن 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

اس ہیش کا موازنہ اسی ٹیگ کے لیے release نوٹس میں شائع کردہ SHA2-256 چیکسمز سے کریں۔ پروجیکٹ release چیکسمز کو SimpleX Chat کی کلید FB44AF81A45BDE327319797C85107E357D4A17FC سے سائن بھی کرتا ہے، جس کی تفصیل server page پر موجود ہے، تاکہ آپ ہیش والی ویب سائٹ پر بھروسہ کرنے کے بجائے دستخط (signature) کی تصدیق کر سکیں۔

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

اسے جان بوجھ کر root کی ملکیت میں انسٹال کریں۔ سروس smp کے طور پر چلتی ہے، لہذا اگر سروس compromised ہو جائے تو وہ اس binary کو دوبارہ نہیں لکھ سکتی جہاں سے وہ شروع ہوتی ہے۔

سرور کو انیشلائز کریں، اور ان دو خفیہ کوڈز کو محفوظ کریں جو یہ پرنٹ کرتا ہے

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 کسی کو بھی آپ کے ریلے پر قطار بنانے کی اجازت دیتا ہے۔ اسے نجی رکھنے کے لیے، انیشلائزیشن کے بعد /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 پر سروس فراہم کرتے ہیں تو اسے شامل کریں۔ 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

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 announcement کے مطابق، ریلے کے پاس فائل کا کوئی metadata نہیں ہوتا: وہ صرف انفرادی chunks دیکھ سکتے ہیں، جن میں سے ہر ایک 256kb، 1mb یا 4mb کا ہوتا ہے، اور ان تک رسائی گمنام 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 والے فارمیٹ جیسا ہی ہوتا ہے، اور اس کا اپنا فنگر پرنٹ /etc/opt/simplex-xftp/fingerprint میں ہوتا ہے۔

ایک تصادم (collision) ہے جس کے لیے منصوبہ بندی ضروری ہے۔ XFTP سرور کا دستاویزی پورٹ 443 ہے، اور SMP کنفیگریشن میں بھی 443 درج ہے۔ دو عمل (processes) ایک ہی ایڈریس پر ایک ہی پورٹ کو bind نہیں کر سکتے، لہذا ایک VPS پر کسی ایک کو راستہ دینا ہوگا۔ سب سے آسان حل یہ ہے کہ SMP کے [TRANSPORT] سیکشن میں port: 5223 کو سیٹ کر دیا جائے اور 443 کو فائل ریلے کے لیے چھوڑ دیا جائے، جس کی قیمت محدود نیٹ ورکس پر موجود کلائنٹس کے لیے 443 فال بیک کا نہ ہونا ہے۔ متبادل حل یہ ہیں کہ اسی 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 ہو، تو غیر پہنچائے گئے پیغامات، روزانہ کے اعدادوشمار کی فائل کے ساتھ موجود ہوتے ہیں۔

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 ٹرانسپورٹ عوامی سرٹیفکیٹ اتھارٹی (public certificate authority) کا استعمال نہیں کرتی ہے۔ Init ایک پرائیویٹ اتھارٹی اور سرور سرٹیفکیٹ تیار کرتا ہے، اور اس اتھارٹی کا فنگر پرنٹ سرور ایڈریس کے اندر منتقل ہوتا ہے۔ کلائنٹ اس بات کی جانچ کرتا ہے کہ سرور جو پیش کر رہا ہے وہ اس پن شدہ (pinned) فنگر پرنٹ سے مطابقت رکھتا ہے یا نہیں، جسے پروجیکٹ کلائنٹ سے سرور کے کنکشن کو 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 کے نام بتاتا ہے۔ براؤزر آپ کی پرائیویٹ اتھارٹی کے بارے میں نہیں جانتا، لہذا یہ وہ واحد جگہ ہے جہاں عوامی طور پر قابل اعتماد (publicly trusted) سرٹیفکیٹ کا استعمال ہونا چاہیے۔ دستاویزات کا Docker quick start اسی مقصد کے لیے Caddy کو سرور کے سامنے رکھتا ہے، اور سرٹیفکیٹ خودکار طور پر جاری کرتا ہے۔

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

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

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

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

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

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

یہی استدلال ہر اس پرائیویٹ سروس پر لاگو ہوتا ہے جسے آپ اپنی مشین پر رکھتے ہیں، چاہے وہ یہ ریلے ہو یا آپ کے اپنے 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) کی خرابی پیدا ہوتی ہے، کیونکہ /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 سرور کو self-host کرنے سے میرے پیغامات زیادہ محفوظ ہو جاتے ہیں؟

نہیں، اور یہ ڈیزائن کے مطابق ہے۔ SimpleX پیغامات کو ڈیوائسز کے درمیان end-to-end encrypt کرتا ہے، لہذا relay کے پاس کبھی بھی keys نہیں ہوتیں، چاہے اسے کوئی بھی چلا رہا ہو۔ Self-hosting صرف اس بات کو تبدیل کرتی ہے کہ ان پیغامات کے گرد موجود metadata کو کون دیکھ سکتا ہے: جیسے کہ کون سی queues موجود ہیں، انہیں کب پڑھا جاتا ہے، اور کون سے IP addresses منسلک ہوتے ہیں۔ یہ metadata سے متعلق فیصلہ ہے۔ اگر آپ کی self-hosting کی وجہ مضبوط encryption ہے، تو encryption پہلے سے ہی موجود تھی۔

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

پروجیکٹ کی protocol/security.md اس کی وضاحت کرتی ہے۔ ایک relay پیغامات کے مواد یا اقسام کو نہیں پڑھ سکتا، انفرادی پیغامات کو بغیر پتہ چلے تبدیل نہیں کر سکتا، اور active attack کے ذریعے end-to-end encryption کو توڑ نہیں سکتا۔ یہ دیکھ سکتا ہے کہ queue کا وصول کنندہ کب آن لائن ہے، queue سے گزرنے والے پیغامات کی گنتی کر سکتا ہے، وصول کنندہ کا IP address جان سکتا ہے، queue میں مستقبل کے پیغامات کو روک سکتا ہے، یا اس queue کی حالت کے بارے میں جھوٹ بول سکتا ہے۔ جب relay آپ کا ہوتا ہے تو یہ اختیارات آپ کے پاس ہوتے ہیں۔

کیا مجھے domain name اور TLS certificate کی ضرورت ہے؟

قابل استعمال سیٹ اپ کے لیے آپ کو ایک domain کی ضرورت ہے، اور smp-server init تب --ip کو قبول کرتا ہے اگر آپ کے پاس واقعی کوئی domain نہ ہو۔ آپ کو messaging port کے لیے کسی public authority سے certificate کی ضرورت نہیں ہے: init اپنی authority خود بناتا ہے، اور client اس fingerprint کو pin کرتا ہے جو آپ کے smp:// ایڈریس میں ظاہر ہوتا ہے۔ عوامی طور پر قابل اعتماد certificate صرف اختیاری web information page کے لیے درکار ہوتا ہے، جسے smp-server.ini کے [WEB] سیکشن میں cert اور key کے طور پر configure کیا جاتا ہے۔

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

آپ کا دیا ہوا ہر ایڈریس کام کرنا چھوڑ دے گا۔ اس ڈائریکٹری میں وہ certificate authority موجود ہوتی ہے جس کا fingerprint آپ کے سرور ایڈریس میں شامل ہوتا ہے، لہذا دوبارہ تعمیر (rebuild) کرنے سے ایک مختلف fingerprint اور نتیجتاً ایک مختلف سرور بنتا ہے۔ جن رابطوں (contacts) کی queues اس relay پر موجود ہوں، انہیں client کی طرف سے ٹھیک نہیں کیا جا سکتا۔ ڈائریکٹری کا encrypted بیک اپ سرور سے باہر رکھیں، اور ca.key کو ہدایات کے مطابق آف لائن محفوظ کریں، کیونکہ جو بھی اسے حاصل کر لے وہ آپ کے relay کا روپ دھار سکتا ہے۔

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

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

#simplex#privacy#messaging#self-hosting#vps