VPS-এ SimpleX chat server সেটআপ করার নিয়ম

একটি self-hosted SimpleX chat server যা করে

একটি SimpleX chat server self-host করার জন্য আপনি একটি VPS-এ একটি daemon চালান: smp-server, যা SMP (simplex messaging protocol)-এর জন্য relay হিসেবে কাজ করে। এটি সেই message queue-গুলো ধারণ করে যেখানে আপনার পরিচিতরা লেখে এবং যেখান থেকে তারা পড়ে। xftp-server নামে একটি দ্বিতীয়, ঐচ্ছিক daemon ফাইল ট্রান্সফার relay করে। উভয়ই একই প্রজেক্ট, simplexmq থেকে আসে এবং প্রতিটি একটি single binary, একটি config file এবং একটি append-only log নিয়ে গঠিত।

এটি অ্যাপ ব্যবহারকারীর জন্য নয়, বরং অপারেটরের জন্য লেখা হয়েছে। relay-তে কোনো account, contact list বা chat history থাকে না। এটি queue, কিছু undelivered ciphertext এবং একটি certificate ধারণ করে যা এটিকে শনাক্ত করে। আপনি মূলত uptime, সামান্য disk space এবং আপনার সার্ভারের মধ্য দিয়ে যাওয়া metadata-এর দায়িত্ব নিচ্ছেন।

নিচের প্রতিটি command, path, port এবং flag প্রজেক্টের নিজস্ব documentation থেকে নেওয়া হয়েছে: SMP server hosting page, XFTP server page এবং protocol security document। যেখানে কোনো সংখ্যার গুরুত্ব আছে, সেখানে তার পাশের পৃষ্ঠার নাম উল্লেখ করা হয়েছে।

কেন ব্যবহারকারীর পরিচয়হীন নেটওয়ার্কেও রিলে (relay) প্রয়োজন

SimpleX-এ কোনো ইউজারনেম, ফোন নম্বর বা অ্যাকাউন্ট আইডি নেই। একটি কন্টাক্ট হলো একমুখী কিউ (unidirectional queue): এটি কোনো রিলে-তে থাকা একটি ঠিকানা, যেখানে এক পক্ষ মেসেজ লেখে এবং অন্য পক্ষ তা পড়ে। আপনার দুটি কন্টাক্টের মধ্যে এমন কোনো পরিচয়সূচক তথ্য নেই যা দিয়ে সার্ভার তাদের সম্পর্ক স্থাপন করতে পারে।

একটি সাধারণ কারণে এই কিউগুলোকে কোথাও না কোথাও থাকতে হয়। দুটি ফোন খুব কমই একই সময়ে অনলাইনে থাকে। এমন কিছু থাকতে হয় যা এখন মেসেজ গ্রহণ করবে এবং অন্য ডিভাইসটি না চাওয়া পর্যন্ত তা জমা রাখবে। SMP রিলে-র পুরো কাজই এটি। এর মানে হলো, দুটি ডিভাইস কখনোই সরাসরি একে অপরের সাথে সংযুক্ত হয় না, তাই কেউ কারো IP (internet protocol) অ্যাড্রেস জানতে পারে না। রিলে এই ঝুঁকিটি নিজের ওপর নেয়।

রিলে-র হোস্টনেম কিউ অ্যাড্রেসের অংশ, তাই আপনি যে আমন্ত্রণ লিঙ্ক শেয়ার করেন তার ভেতরেই এটি থাকে। শেষের দিকে থাকা থ্রেট মডেল (threat model) পড়ার সময় বিষয়টি মাথায় রাখবেন।

একটি রিলে যা দেখতে পায় এবং যা পায় না

প্রকল্পটি protocol/security.md-এ এটিকে একটি থ্রেট মডেল হিসেবে উল্লেখ করেছে। কোনো কিছু ইনস্টল করার আগে এটি পড়ে নেওয়া জরুরি, কারণ এই নির্দেশিকা অনুসরণ করার পর সেই রিলেটির নিয়ন্ত্রণ আপনার হাতে থাকবে। একটি রিলে, এমনকি আক্রমণকারীর সম্পূর্ণ নিয়ন্ত্রণে থাকা কোনো রিলেও, বার্তার বিষয়বস্তু বা ধরন জানতে পারে না। এটি কোনো বার্তা শনাক্ত না করে যোগ করতে, নকল করতে বা বিকৃত করতে পারে না এবং সক্রিয় আক্রমণের মাধ্যমে এন্ড-টু-এন্ড এনক্রিপশন ভাঙতে পারে না।

একই পৃষ্ঠায় একটি রিলে যা করতে পারে তার তালিকা দেওয়া হয়েছে। এটি জানতে পারে কখন একজন কিউ (queue) প্রাপক অনলাইনে আছেন। এটি একটি কিউয়ের মধ্য দিয়ে কতগুলো বার্তা যাচ্ছে তা গণনা করতে পারে। এটি প্রাপকের IP address জানতে পারে। এটি কিউয়ের ভবিষ্যতের সব বার্তা মুছে ফেলতে পারে অথবা সেই কিউয়ের অবস্থা সম্পর্কে মিথ্যা তথ্য দিতে পারে।

সুতরাং, এই বিভাজনটি স্পষ্ট। গোপনীয়তা বজায় রাখা ক্লায়েন্টের কাজ এবং সেলফ-হোস্টিং এতে কোনো প্রভাব ফেলে না। মেটাডেটা এবং প্রাপ্যতা রিলে অপারেটরের দায়িত্ব, এবং সেলফ-হোস্টিংয়ের মাধ্যমে এই দুটির নিয়ন্ত্রণই আপনার হাতে চলে আসে।

শুরু করার আগে আপনার যা প্রয়োজন

• Ubuntu 22.04 বা 24.04 চালিত একটি VPS। এই প্রজেক্টটি শুধুমাত্র এই দুটি ভার্সনের জন্যই x86-64 এবং aarch64 আর্কিটেকচারে বিল্ড করা রিলিজ বাইনারি প্রকাশ করে।
• একটি ডোমেইন নাম যার A রেকর্ডটি আপনার VPS-এর দিকে নির্দেশ করা আছে, এবং IPv6 থাকলে একটি AAAA রেকর্ডও থাকতে হবে। ডকুমেন্টেশনে উদাহরণের জন্য smp1.example.com ব্যবহার করা হয়েছে।
• রুট (root) বা sudo অ্যাক্সেস, এবং ফায়ারওয়াল কনফিগার করার সময় খোলা রাখার জন্য একটি দ্বিতীয় SSH সেশন।
• সার্ভারের বাইরে ব্যাকআপ রাখার জন্য কোনো জায়গা, কারণ কনফিগারেশন ডিরেক্টরিটিই সার্ভারের পরিচয় বহন করে।

ARM ইনস্ট্যান্সের ক্ষেত্রে x86-64-এর পরিবর্তে aarch64 অ্যাসেটটি নিন। এই গাইডের অন্য কোনো কিছু পরিবর্তন হবে না, এবং ARM এবং x86 VPS প্ল্যানের মধ্যে পার্থক্য মূলত দাম এবং প্রতি কোরের গতির ওপর নির্ভর করে, এই সফটওয়্যার চলবে কি না তার ওপর নয়।

"latest" নয়, একটি নির্দিষ্ট রিলিজ ভার্সন ইনস্টল করুন

এই প্রজেক্টে একটি ইনস্টল স্ক্রিপ্ট দেওয়া থাকে যা বর্তমান রিলিজটি ডাউনলোড করে এবং একটি 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 কি (key) দিয়ে সাইন করে, যা server page-এ নথিভুক্ত আছে। তাই আপনি হ্যাশটি যে পেজ থেকে পড়েছেন সেটিকে বিশ্বাস না করে বরং সিগনেচারটি যাচাই করতে পারেন।

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

ইচ্ছাকৃতভাবেই এটিকে root-এর মালিকানায় ইনস্টল করুন। সার্ভিসটি smp হিসেবে চলে, তাই সার্ভিসটি কোনোভাবে আক্রান্ত হলেও এটি যে বাইনারি থেকে শুরু হয়েছে তা পুনরায় লিখতে পারবে না।

সার্ভারটি ইনিশিয়ালাইজ করুন এবং এটি যে দুটি সিক্রেট প্রদর্শন করে তা সংরক্ষণ করুন

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

• --store-log (-l) কিউগুলোর একটি অ্যাপেন্ড-অনলি লগ /var/opt/simplex/smp-server-store.log-এ লিখে রাখে, যাতে রিস্টার্টের পরেও রিলেটি সচল থাকে। এটি ছাড়া রিস্টার্ট দিলে প্রতিটি কিউ মুছে যায়, যার ফলে আপনার মাধ্যমে রাউট হওয়া প্রতিটি যোগাযোগ কাজ করা বন্ধ করে দেয়।
• --daily-stats (-s) কাউন্টারগুলোকে CSV ফরম্যাটে /var/opt/simplex/smp-server-stats.daily.log-এ লিখে রাখে।
• --fqdn আপনার ডোমেইনটিকে জেনারেট করা সার্টিফিকেটের অন্তর্ভুক্ত করে। আপনার কোনো ডোমেইন না থাকলে এর পরিবর্তে --ip ব্যবহার করুন।
• --no-password যে কাউকে আপনার রিলেতে কিউ তৈরি করার অনুমতি দেয়। এটিকে প্রাইভেট রাখতে, ইনিশিয়াল করার পর --password পাস না করে /etc/opt/simplex/smp-server.ini-এর [AUTH] সেকশনের অধীনে create_password সেট করুন। কারণ কমান্ড লাইনটি আপনার শেল হিস্ট্রি এবং প্রসেস লিস্টে দৃশ্যমান থাকে।

ইনিশিয়াল করার সময় একটি সার্টিফিকেট তৈরি হয় এবং দুটি ভ্যালু প্রদর্শিত হয় যা আপনাকে অবশ্যই সংরক্ষণ করতে হবে। প্রথমটি হলো ফিঙ্গারপ্রিন্ট, যা একটি base64 স্ট্রিং এবং এটি /etc/opt/simplex/fingerprint-এও লেখা থাকে। দ্বিতীয়টি হলো সম্পূর্ণ সার্ভার অ্যাড্রেস, যা ফিঙ্গারপ্রিন্ট এবং আপনার হোস্টনামের সমন্বয়ে গঠিত। উভয়ই এখনই কপি করে রাখুন।

ইনিশিয়াল করার সময় /etc/opt/simplex/ca.key ফাইলটিও তৈরি হয় এবং ডকুমেন্টেশনে এই ফাইলটিকে অফলাইন স্টোরেজে সরিয়ে রাখার পরামর্শ দেওয়া হয়েছে। এর কারণটি গুরুত্বপূর্ণ: ক্লায়েন্টরা এই সার্টিফিকেট অথরিটির ফিঙ্গারপ্রিন্ট পিন করে রাখে, তাই যার কাছে ca.key থাকবে সে নতুন সার্ভার সার্টিফিকেট ইস্যু করতে পারবে যা আপনার ক্লায়েন্টরা আপনারই সার্টিফিকেট হিসেবে গ্রহণ করবে। পরবর্তীতে smp-server cert ব্যবহার করে সার্ভার সার্টিফিকেট রোটেশন করার সময় কেবল তখনই আপনার এটি প্রয়োজন হবে।

ইনিশিয়ালকে একবারই করার মতো একটি ধাপ হিসেবে বিবেচনা করুন। আপনার অ্যাড্রেসে থাকা ফিঙ্গারপ্রিন্টটি এর মাধ্যমে তৈরি হওয়া অথরিটি থেকে আসে, তাই সেই অথরিটি পুনরায় তৈরি করলে আপনি একটি ভিন্ন অ্যাড্রেস পাবেন এবং আপনার আগের দেওয়া অ্যাড্রেসটি অকার্যকর হয়ে পড়বে।

unprivileged user হিসেবে 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-এর নিচের পোর্টগুলো non-root প্রসেসের জন্য বন্ধ থাকে, তাই এটি ছাড়া daemon 80 বা 443 পোর্টে bind হতে পারে না। আপনি যদি এই পোর্টগুলো ব্যবহার করেন, তবে এটি যোগ করুন। 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 নাম থাকা উচিত। কোনো sudo অধিকার ছাড়া নিজস্ব অ্যাকাউন্টের অধীনে daemon চালানো হলো VPS-এ প্রতি-সার্ভিস অ্যাকাউন্ট-এ বর্ণিত অভ্যাসের মতোই, এবং এটিই একটি নেটওয়ার্ক daemon-এর বাগ-কে 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 ব্যবহার করে অ্যাক্সেস করা হয়। এটি সার্ভারের অবস্থা প্রদর্শন করে এবং কিউ (queue) মুছে ফেলতে পারে, তাই এটি লুপব্যাক ইন্টারফেসে রাখা উচিত এবং [AUTH]-এর অধীনে অ্যাডমিন ও ব্যবহারকারীর পাসওয়ার্ড সেট করা থাকা জরুরি। আপনি যদি এই টুলটি ব্যবহারে নতুন হন, তবে VPS-এ ufw-এর মৌলিক বিষয়সমূহ নিবন্ধটি পড়ুন; সেখানে রুল অর্ডারিং এবং নিজেকে লক-আউট হওয়া থেকে বাঁচার উপায় আলোচনা করা হয়েছে।

আরও একটি নিয়ন্ত্রণ ব্যবস্থা ব্যবহারকারীদের বিভ্রান্ত করতে পারে। বেশিরভাগ প্রোভাইডার সার্ভারের ভেতরে থাকা ufw থেকে আলাদা একটি নেটওয়ার্ক ফায়ারওয়াল তাদের কন্ট্রোল প্যানেলে পরিচালনা করে। এমন হতে পারে যে, ufw-তে একটি পোর্ট খোলা আছে কিন্তু সেটি আপনার সার্ভারে পৌঁছানোর আগেই নেটওয়ার্ক ফায়ারওয়াল দ্বারা ড্রপ করা হচ্ছে।

আপনার ক্লায়েন্টদের জন্য প্রয়োজনীয় সার্ভার অ্যাড্রেস

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

এই স্ট্রিংটিই হলো সম্পূর্ণ ক্লায়েন্ট-সাইড কনফিগারেশন। এটি অ্যাপের সার্ভার সেটিংসে পেস্ট করুন, অথবা অ্যাপে প্রদর্শিত QR কোডটি স্ক্যান করতে দিন। ডকুমেন্টেশনে উল্লেখ আছে যে, QR কোডের মধ্যে পাসওয়ার্ডটিও অন্তর্ভুক্ত থাকে, তাই যে কেউ এটি স্ক্যান করলে আপনার সার্ভারের মাধ্যমে মেসেজ গ্রহণ করতে পারবে।

ডকুমেন্টেশনে বর্ণিত একটি আচরণ সবাইকে অবাক করে। অ্যাপে আপনার সার্ভার যোগ করলে তা শুধুমাত্র সেই মুহূর্ত থেকে তৈরি করা পরিচিতিগুলোর (contacts) ওপর প্রভাব ফেলে। বিদ্যমান পরিচিতিগুলো সেই রিলেতেই (relay) থেকে যায় যেখানে তাদের কিউ (queue) তৈরি করা হয়েছিল এবং সেগুলো স্বয়ংক্রিয়ভাবে স্থানান্তরিত হয় না। এই কারণেই একটি রিলে প্রতিস্থাপনের পরের দিনই আপনি সেটি বন্ধ করতে পারবেন না।

একটি XFTP ফাইল রিলে যোগ করা

XFTP (SimpleX file transfer protocol) হলো নেটওয়ার্কের ফাইল আদান-প্রদানের অংশ, এবং এটি একটি আলাদা ডেমোন যার নিজস্ব ঠিকানা রয়েছে। প্রজেক্টের XFTP ঘোষণা অনুযায়ী, রিলেগুলোর কাছে ফাইলের কোনো মেটাডেটা থাকে না: তারা কেবল 256kb, 1mb বা 4mb আকারের আলাদা আলাদা অংশ দেখতে পায়, যেগুলোর অ্যাক্সেস বেনামী ক্রেডেনশিয়াল দ্বারা অনুমোদিত। একজন প্রেরক একটি ফাইলের অংশগুলোকে একাধিক রিলের মধ্যে ছড়িয়ে দিতে পারেন, তাই আপনার সার্ভারে পুরো ফাইল নয়, বরং ফাইলের টুকরোগুলো জমা থাকে।

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-এ থাকে।

এখানে একটি পোর্ট কনফ্লিক্ট বা সংঘর্ষের বিষয়টি মাথায় রাখতে হবে। XFTP সার্ভারের নির্ধারিত পোর্ট হলো 443, এবং SMP কনফিগারেশনেও 443 পোর্টটি উল্লেখ থাকে। দুটি প্রসেস একই ঠিকানায় একই পোর্ট ব্যবহার করতে পারে না, তাই একটি VPS-এ যেকোনো একটিকে পরিবর্তন করতে হবে। সবচেয়ে সহজ সমাধান হলো SMP-এর [TRANSPORT] সেকশনে port: 5223 সেট করা এবং 443 পোর্টটি ফাইল রিলের জন্য ছেড়ে দেওয়া। তবে এর ফলে সীমাবদ্ধ নেটওয়ার্ক ব্যবহারকারী ক্লায়েন্টদের জন্য 443 পোর্ট ফলব্যাক সুবিধাটি আর থাকবে না। এর বিকল্প উপায় হলো একই VPS-এ দ্বিতীয় একটি IP ঠিকানা ব্যবহার করা অথবা অন্য একটি VPS নেওয়া।

কোটা বা ধারণক্ষমতা সঠিকভাবে নির্ধারণ করুন। -q '20gb' হলো আপনার ডিস্কের প্রাপ্যতার একটি প্রতিশ্রুতি। ফাইল রিলে অংশটিই মূলত ডিস্ক এবং ব্যান্ডউইথ বেশি ব্যবহার করে। মেসেজ রিলে খুব সামান্যই ডিস্ক বা ব্যান্ডউইথ খরচ করে।

ডিস্কে কী থাকে এবং ব্যাকআপ কী পুনরুদ্ধার করে

দুটি ডিরেক্টরি গুরুত্বপূর্ণ। /etc/opt/simplex/ হলো সার্ভারের পরিচয়: smp-server.ini, সার্ভার সার্টিফিকেট এবং কি (key), ca.key, এবং fingerprint। /var/opt/simplex/ হলো সার্ভারের স্টেট: 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

এই আর্কাইভটি কী তা পরিষ্কারভাবে বুঝে নিন। এটি কোনো মেসেজ আর্কাইভ নয়: কিউতে থাকা আইটেমগুলো এমন কি (key) দিয়ে এনক্রিপ্ট করা সাইফারটেক্সট, যা রিলে কখনোই ধারণ করেনি, এবং সরবরাহকৃত [STORE_LOG] কনফিগারেশন অনুযায়ী 21 দিন পর মেসেজগুলো এমনিতেই মুছে যায়। এটি সার্ভারের পরিচয়ের একটি কপি, যার মধ্যে ca.key অন্তর্ভুক্ত থাকে, তাই যে কেউ এই ফাইলটি পেলে আপনার পরিচিতদের কাছে নিজেকে আপনার রিলে হিসেবে উপস্থাপন করতে পারবে। ফাইলটি এনক্রিপ্ট করে সার্ভারের বাইরে সংরক্ষণ করুন।

এর মূল সুবিধা হলো পুনরুদ্ধার। একটি নতুন VPS-এ /etc/opt/simplex ডিরেক্টরি ফিরিয়ে আনুন এবং একই DNS নাম সেটির দিকে নির্দেশ করুন। এতে ফিঙ্গারপ্রিন্ট অপরিবর্তিত থাকে, ফলে আপনার দেওয়া প্রতিটি ঠিকানা আগের মতোই কাজ করবে। এই ডিরেক্টরি হারিয়ে ফেললে কোনো পুনরুদ্ধার সম্ভব নয়: নতুন ইন্সটলেশন মানে নতুন ফিঙ্গারপ্রিন্ট, যার অর্থ নতুন ঠিকানা, এবং এর ফলে আপনার রিলের মাধ্যমে যুক্ত থাকা প্রতিটি পরিচিতি সংযোগ বিচ্ছিন্ন হয়ে যাবে।

TLS: দুটি ভিন্ন কাজের জন্য দুটি সার্টিফিকেট

SMP transport কোনো পাবলিক certificate authority ব্যবহার করে না। 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-এ একটি হিডেন সার্ভিস যোগ করে:

SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443

মোড লাইন দুটি মনোযোগ দিয়ে পড়ুন। Single hop এবং non-anonymous হওয়ার অর্থ হলো রিলের নিজস্ব অবস্থান গোপন থাকে না। Onion অ্যাড্রেসটি দ্রুত কাজ করে এবং এটি ক্লায়েন্টদের এমন একটি পথ দেয় যা আপনার কাছে তাদের IP অ্যাড্রেস প্রকাশ করে না, কিন্তু সার্ভারটি তার পাবলিক IP-তেই খুঁজে পাওয়া যায়। /var/lib/tor/simplex-smp/hostname থেকে পাওয়া onion হোস্টনামটি সার্ভার অ্যাড্রেসের শেষে একটি কমার পরে বসাতে হয়। আপনি যদি সার্ভারের অবস্থানও গোপন রাখতে চান, তবে সেটি একটি ভিন্ন কনফিগারেশন, এবং VPS-এ একটি প্রকৃত onion সার্ভিস চালানো বিষয়টি সেই পার্থক্য নিয়ে আলোচনা করে। প্রতিটি টুল কী গোপন করে তার পার্থক্য হলো VPN-এর সাথে Tor-এর তুলনা বিষয়ের মূল আলোচ্য, যা এখানে সরাসরি প্রযোজ্য।

থ্রেট মডেল: সেলফ-হোস্টিং যা পরিবর্তন করে

এটি আপনাকে যা দেয়। মেটাডেটা (কোন কিউগুলো বিদ্যমান, কখন সেগুলো পড়া হয়, কোন ঠিকানাগুলো সংযুক্ত হয়) আপনার নিয়ন্ত্রণে থাকা একটি মেশিনে থাকে এবং আপনি নির্ধারণ করেন এগুলো কতদিন সংরক্ষণ করা হবে। এছাড়া আপনি এমন কোনো বড় পুলের অংশ নন, যেখান থেকে একসাথে অনেক তথ্য চেয়ে নেওয়া সম্ভব।

এটি আপনাকে যা দেয় না, তা স্পষ্টভাবে নিচে দেওয়া হলো:

• এনক্রিপশন অপরিবর্তিত থাকে। আপনি এটি তৈরি করার আগেও মেসেজগুলো এন্ড-টু-এন্ড এনক্রিপ্টেড ছিল এবং পরেও তাই থাকবে। সেলফ-হোস্টিং একটি মেটাডেটা সংক্রান্ত সিদ্ধান্ত, ক্রিপ্টোগ্রাফি সংক্রান্ত নয়।
• আপনার VPS প্রোভাইডার আপনার IP ঠিকানায় আসা ট্রাফিক দেখতে পায় এবং আপনার বিলিংয়ের তথ্য তাদের কাছে থাকে। আপনি মেসেজিং অপারেটরের ওপর থেকে আস্থা সরিয়ে হোস্টিং অপারেটরের ওপর স্থাপন করেছেন। আপনি আস্থা বা বিশ্বাসের প্রয়োজনীয়তা দূর করেননি।
• আপনার রিলে একটি ছোট দল। যদি এটি একটি পরিবারের জন্য সেবা দেয়, তবে এর সাথে সংযুক্ত হওয়া মানেই সেই পরিবারকে শনাক্ত করা, এবং আপনি যে ইনভাইটেশন লিঙ্ক পাঠান তার ভেতরেই এর হোস্টনাম থাকে। একটি ব্যস্ত পাবলিক রিলে এই একটি ক্ষেত্রে আপনাকে আরও ভালোভাবে আড়াল করে, এবং এটিই আসল বিনিময়।
• সার্ভিসের প্রাপ্যতা এখন আপনার দায়িত্ব। ডিস্ক পূর্ণ হয়ে গেলে বা সার্ভার বন্ধ হয়ে গেলে মেসেজ আসা বন্ধ হয়ে যাবে এবং আপনার পরিচিতদের কাছে আপনাকে এড়িয়ে যাওয়ার কোনো উপায় থাকবে না।

একই যুক্তি আপনার নিজের কোনো সার্ভারে রাখা যেকোনো প্রাইভেট সার্ভিসের ক্ষেত্রে প্রযোজ্য, তা এই রিলে হোক কিংবা আপনার নিজস্ব VPS-এ থাকা একটি WireGuard VPN। আপনি কেবল বেছে নিচ্ছেন কোন পক্ষ আপনার মেটাডেটা দেখবে। আপনি মেটাডেটাকে অদৃশ্য করে দিচ্ছেন না।

যখন এটি কাজ করে না

সার্ভিসটি চালু হয়েই সাথে সাথে বন্ধ হয়ে যায়। sudo journalctl -u smp-server -n 50 পড়ুন। একটি bind failure সেই পোর্টটির নাম উল্লেখ করে যা এটি নিতে পারেনি। এরপর 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) তৈরি করার অনুমতি দেওয়া হবে না।

অ্যাপে সার্ভার যোগ করার পর কিছুই পরিবর্তন হয়নি। এটি ইচ্ছাকৃত। শুধুমাত্র নতুন কন্টাক্টগুলো নতুন যোগ করা রিলে ব্যবহার করে। বিদ্যমান কন্টাক্টগুলো তাদের আগের কিউগুলোই ব্যবহার করতে থাকে।

FAQ

SimpleX সার্ভার নিজে হোস্ট করলে কি আমার মেসেজ আরও নিরাপদ হয়?

না, এবং এটি ইচ্ছাকৃতভাবেই করা হয়েছে। SimpleX ডিভাইসগুলোর মধ্যে এন্ড-টু-এন্ড এনক্রিপশন ব্যবহার করে, তাই সার্ভার যে-ই পরিচালনা করুক না কেন, রিলে কখনোই এনক্রিপশন কি (key) পায় না। নিজে সার্ভার হোস্ট করার ফলে মেসেজের মেটাডেটা কারা পর্যবেক্ষণ করছে তা পরিবর্তিত হয়: যেমন কোন কিউ (queue) বিদ্যমান, কখন সেগুলো পড়া হচ্ছে এবং কোন IP অ্যাড্রেস থেকে সংযোগ করা হচ্ছে। এটি মূলত মেটাডেটার সিদ্ধান্ত। যদি আপনার নিজে হোস্ট করার কারণ হয় আরও শক্তিশালী এনক্রিপশন, তবে জেনে রাখুন সেই এনক্রিপশন আগেই সেখানে ছিল।

একজন SimpleX রিলে অপারেটর আসলে কী দেখতে পায়?

প্রকল্পের protocol/security.md-এ এটি স্পষ্টভাবে উল্লেখ করা হয়েছে। একটি রিলে মেসেজের বিষয়বস্তু বা ধরন পড়তে পারে না, কোনো মেসেজ শনাক্ত না করে পরিবর্তন করতে পারে না এবং সক্রিয় আক্রমণের মাধ্যমে এন্ড-টু-এন্ড এনক্রিপশন ভাঙতে পারে না। তবে এটি দেখতে পায় কখন কিউ-এর প্রাপক অনলাইনে আছেন, কিউ দিয়ে কতগুলো মেসেজ যাচ্ছে, প্রাপকের IP অ্যাড্রেস কী, কিউ-এর ভবিষ্যৎ মেসেজগুলো মুছে ফেলতে পারে অথবা কিউ-এর অবস্থা সম্পর্কে ভুল তথ্য দিতে পারে। রিলে আপনার নিয়ন্ত্রণে থাকলে এই ক্ষমতাগুলো আপনার হাতে থাকে।

আমার কি একটি ডোমেইন নাম এবং TLS সার্টিফিকেট প্রয়োজন?

একটি ব্যবহারযোগ্য সেটআপের জন্য আপনার একটি ডোমেইন প্রয়োজন, তবে আপনার যদি সত্যিই কোনো ডোমেইন না থাকে তবে smp-server init-এ --ip ব্যবহার করা যায়। মেসেজিং পোর্টের জন্য আপনার কোনো পাবলিক কর্তৃপক্ষের কাছ থেকে সার্টিফিকেট নেওয়ার প্রয়োজন নেই: init নিজেই নিজস্ব অথরিটি তৈরি করে এবং ক্লায়েন্ট আপনার smp:// অ্যাড্রেসে থাকা ফিঙ্গারপ্রিন্টটি পিন (pin) করে নেয়। পাবলিকলি ট্রাস্টেড সার্টিফিকেট শুধুমাত্র ঐচ্ছিক ওয়েব ইনফরমেশন পেজের জন্য প্রয়োজন, যা smp-server.ini-এর [WEB] সেকশনে cert এবং key হিসেবে কনফিগার করা হয়।

আমি যদি /etc/opt/simplex হারিয়ে ফেলি তবে কী হবে?

আপনার দেওয়া প্রতিটি অ্যাড্রেস কাজ করা বন্ধ করে দেবে। ওই ডিরেক্টরিতে সার্টিফিকেট অথরিটি থাকে যার ফিঙ্গারপ্রিন্ট আপনার সার্ভার অ্যাড্রেসে এমবেড করা থাকে, তাই সার্ভার পুনরায় তৈরি করলে ভিন্ন ফিঙ্গারপ্রিন্ট তৈরি হবে এবং ফলে সেটি একটি ভিন্ন সার্ভার হিসেবে গণ্য হবে। যেসব পরিচিত ব্যক্তির কিউ ওই রিলেতে রয়েছে, তাদের ক্লায়েন্ট সাইড থেকে আর ঠিক করা সম্ভব হবে না। ডিরেক্টরিটি এনক্রিপ্ট করে সার্ভারের বাইরে ব্যাকআপ রাখুন এবং ডকুমেন্টেশনের নির্দেশনা অনুযায়ী ca.key অফলাইনে সংরক্ষণ করুন, কারণ যার কাছে এটি থাকবে সে আপনার রিলের ছদ্মবেশ ধারণ করতে পারবে।

আমি কি একই VPS-এ SMP রিলে এবং XFTP ফাইল রিলে চালাতে পারি?

হ্যাঁ, তবে একটি কনফ্লিক্ট সমাধান করতে হবে। XFTP সার্ভারের নির্ধারিত পোর্ট হলো 443 এবং ডিফল্ট SMP কনফিগারেশনে port: 5223,443 তালিকাভুক্ত থাকে, তাই উভয়ই একই সকেট ব্যবহার করতে চায়। এদের যেকোনো একটিকে 443 পোর্ট দিন: SMP সার্ভারের জন্য port: 5223 সেট করুন, অথবা ফাইল রিলেটিকে দ্বিতীয় কোনো IP অ্যাড্রেস বা দ্বিতীয় কোনো VPS-এ সরিয়ে নিন। এছাড়া আপনার ডিস্কের প্রকৃত ধারণক্ষমতা অনুযায়ী স্টোরেজ কোটা নির্ধারণ করুন, কারণ ফাইল রিলে হলো সেই উপাদান যা সবচেয়ে বেশি ডিস্ক এবং ব্যান্ডউইথ ব্যবহার করে।