วิธีติดตั้ง SimpleX SMP relay บน VPS ด้วยตนเอง

สิ่งที่เซิร์ฟเวอร์แชต SimpleX แบบ self-hosted ทำ

การ self-host เซิร์ฟเวอร์แชต SimpleX ต้องรัน daemon 1 ตัวบน VPS: smp-server ซึ่งเป็น relay สำหรับ SMP (simplex messaging protocol) daemon นี้เก็บคิวข้อความที่ contact ของคุณเขียนและอ่าน อีก daemon ที่เป็นตัวเลือกชื่อ xftp-server ใช้ relay การถ่ายโอนไฟล์ ทั้งสองตัวมาจากโปรเจกต์เดียวกันคือ simplexmq และแต่ละตัวประกอบด้วย binary เดียว ไฟล์ config 1 ไฟล์ และ log แบบ append-only

เนื้อหานี้เขียนสำหรับผู้ดูแลระบบ ไม่ใช่ผู้ใช้แอป relay ไม่เก็บบัญชี รายชื่อ contact หรือประวัติการแชต แต่เก็บคิว ciphertext บางส่วนที่ยังส่งไม่ถึงปลายทาง และ certificate ที่ใช้ระบุเซิร์ฟเวอร์ สิ่งที่คุณต้องรับผิดชอบคือ uptime พื้นที่ดิสก์จำนวนเล็กน้อย และ metadata ที่ผ่านเซิร์ฟเวอร์ของคุณ

คำสั่ง path port และ flag ทุกอย่างด้านล่างมาจากเอกสารของโปรเจกต์เอง ได้แก่ หน้า SMP server hosting, หน้า XFTP server และ เอกสารความปลอดภัยของ protocol หากตัวเลขใดมีความสำคัญ จะระบุชื่อหน้าที่เป็นแหล่งข้อมูลไว้ถัดจากตัวเลขนั้น

เหตุใดเครือข่ายที่ไม่มีตัวระบุผู้ใช้ยังต้องใช้ relay

SimpleX ไม่มี username, หมายเลขโทรศัพท์ หรือ account ID รายชื่อติดต่อคือคิวแบบทิศทางเดียว ซึ่งประกอบด้วย address บน relay ที่ฝ่ายหนึ่งเขียนข้อมูลลงไป และอีกฝ่ายอ่านข้อมูลจากคิวนั้น ไม่มีตัวระบุใดที่ใช้เชื่อมโยงรายชื่อติดต่อ 2 รายการของคุณเข้าด้วยกันได้

คิวเหล่านี้ยังต้องอยู่บนระบบใดระบบหนึ่งด้วยเหตุผลตรงไปตรงมา โทรศัพท์ 2 เครื่องแทบจะไม่ออนไลน์ในเวลาเดียวกัน ต้องมีระบบที่รับข้อความไว้ตอนนี้และเก็บข้อความจนกว่าอุปกรณ์อีกเครื่องจะร้องขอ นั่นคือหน้าที่ทั้งหมดของ SMP relay การทำงานนี้ยังหมายความว่าอุปกรณ์ทั้ง 2 เครื่องจะไม่เชื่อมต่อกันโดยตรง ดังนั้นแต่ละเครื่องจึงไม่ทราบ IP (internet protocol) address ของอีกเครื่อง relay จะรับความเสี่ยงจากการเปิดเผยข้อมูลนี้แทน

hostname ของ relay เป็นส่วนหนึ่งของ queue address ดังนั้น hostname นี้จะอยู่ใน invitation link ทุกลิงก์ที่คุณสร้างและส่งจาก relay ดังกล่าว โปรดคำนึงถึงเรื่องนี้เมื่ออ่าน threat model ในช่วงท้าย

สิ่งที่ relay มองเห็นและทำไม่ได้

โครงการระบุเรื่องนี้ไว้เป็น threat model ใน protocol/security.md และควรอ่านก่อนติดตั้งสิ่งใด เพราะหลังจากทำตามคู่มือนี้ relay นั้นจะอยู่ภายใต้การดูแลของคุณ แม้แต่ relay ที่ผู้โจมตีควบคุมทั้งหมดก็ไม่สามารถเรียนรู้เนื้อหาหรือประเภทของข้อความ ไม่สามารถเพิ่ม ทำซ้ำ หรือทำให้ข้อความแต่ละรายการเสียหายโดยตรวจไม่พบ และไม่สามารถทำลายการเข้ารหัสแบบ end-to-end ด้วยการโจมตีเชิงรุกได้

หน้าเดียวกันระบุสิ่งที่ relay ทำได้ ไว้ด้วย relay สามารถทราบได้ว่า recipient ของ queue ออนไลน์เมื่อใด สามารถนับจำนวนข้อความที่ส่งผ่าน queue และสามารถทราบ IP address ของ recipient ได้ นอกจากนี้ยังสามารถทิ้งข้อความใหม่ทั้งหมดที่จะส่งไปยัง queue หรือรายงานสถานะของ queue เป็นเท็จได้

ดังนั้นขอบเขตจึงชัดเจน การรักษาความลับเป็นหน้าที่ของ client และการ self-hosting ไม่กระทบส่วนนี้ ส่วน metadata และความพร้อมใช้งานเป็นหน้าที่ของผู้ดูแล relay และการ self-hosting จะทำให้ทั้งสองเรื่องอยู่ภายใต้การดูแลของคุณ

สิ่งที่ต้องเตรียมก่อนเริ่ม

• VPS ที่ใช้ Ubuntu 22.04 หรือ 24.04 โปรเจกต์นี้เผยแพร่ release binary ที่สร้างมาสำหรับระบบทั้ง 2 รุ่นนี้โดยเฉพาะ รองรับ x86-64 และ aarch64
• ชื่อโดเมนที่มีระเบียน A ชี้ไปยัง VPS และมีระเบียน AAAA หากคุณใช้ IPv6 เอกสารนี้ใช้ smp1.example.com เป็นตัวอย่าง
• สิทธิ์ root หรือสิทธิ์เข้าถึง sudo และเปิด SSH session ที่สองค้างไว้ขณะปรับ firewall
• พื้นที่จัดเก็บ backup นอกเซิร์ฟเวอร์ เพราะไดเรกทอรี config เป็นข้อมูลระบุตัวตนของเซิร์ฟเวอร์

บน instance ที่ใช้ ARM ให้ใช้ asset aarch64 แทน x86-64 ส่วนอื่นในคู่มือนี้ไม่ต้องเปลี่ยน และ การเลือกระหว่างแผน ARM กับ x86 VPS ขึ้นอยู่กับราคาและความเร็วต่อ core ไม่ได้ขึ้นอยู่กับว่าซอฟต์แวร์นี้ทำงานได้หรือไม่

ติดตั้ง release ที่ระบุเวอร์ชัน ไม่ใช่ "latest"

โปรเจกต์มี install script ที่ดึง release ปัจจุบันและลงทะเบียนคำสั่ง simplex-servers-update ใช้งานได้ แต่ควร pin เวอร์ชันไว้เสมอ เพราะ relay ที่ binary เปลี่ยนโดยที่คุณไม่ทราบ จะวิเคราะห์สาเหตุได้ยากเมื่อเกิดปัญหา

ณ เดือน August 2026 release ปัจจุบันของ simplexmq คือ v6.5.0 ซึ่งเผยแพร่เมื่อ 29 April 2026 ตรวจสอบ หน้า releases เพื่อดู tag ที่ต้องการ แล้วใช้ tag นั้นในทุกตำแหน่งด้านล่าง

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp ไม่กำหนดรหัสผ่าน ดังนั้นจึงไม่มีใคร login โดยตรงในชื่อ smp สร้างไดเรกทอรี 2 รายการด้วยตนเองก่อนรันคำสั่งอื่น เนื่องจาก /etc/opt เป็นของ root และมี mode 755 ทำให้ผู้ใช้ smp ไม่มีตำแหน่งสำหรับเขียนไดเรกทอรี config ของตนเอง

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

เปรียบเทียบ hash ดังกล่าวกับ checksum แบบ SHA2-256 ที่เผยแพร่ใน release notes ของ tag เดียวกัน โปรเจกต์ยังเซ็น release checksum ด้วยคีย์ SimpleX Chat FB44AF81A45BDE327319797C85107E357D4A17FC ซึ่งมีเอกสารอยู่ใน หน้า server คุณจึงตรวจสอบลายเซ็นได้ แทนที่จะเชื่อถือหน้าเว็บที่ใช้ดู hash

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

ติดตั้งโดยให้ root เป็นเจ้าของโดยตั้งใจ service ทำงานในชื่อ smp ดังนั้นหาก service ถูก breach จะไม่สามารถเขียนทับ binary ที่ใช้เริ่มทำงานได้

เริ่มต้นเซิร์ฟเวอร์และเก็บ secret 2 รายการที่ระบบแสดง

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

• --store-log (-l) เขียน log ของคิวแบบ append-only ลงใน /var/opt/simplex/smp-server-store.log เพื่อให้ relay ทำงานต่อได้หลัง restart หากไม่มีตัวเลือกนี้ restart จะลบคิวทั้งหมด ทำให้ทุก contact ที่ route ผ่านคุณหยุดทำงาน
• --daily-stats (-s) เขียนตัวนับในรูปแบบ CSV ลงใน /var/opt/simplex/smp-server-stats.daily.log
• --fqdn ใส่โดเมนของคุณลงใน certificate ที่สร้างขึ้น ใช้ --ip แทนหากคุณไม่มีโดเมน
• --no-password อนุญาตให้ทุกคนสร้างคิวบน relay ของคุณ หากต้องการให้ใช้งานแบบ private ให้ตั้งค่า create_password ใต้ [AUTH] ใน /etc/opt/simplex/smp-server.ini หลัง init แทนการส่ง --password ที่นี่ เนื่องจาก command line จะปรากฏใน shell history และใน process list ระหว่างที่คำสั่งทำงาน

Init จะสร้าง certificate และแสดงค่าที่ต้องเก็บไว้ 2 รายการ รายการแรกคือ fingerprint ซึ่งเป็นสตริง base64 และถูกเขียนลงใน /etc/opt/simplex/fingerprint ด้วย รายการที่สองคือ server address แบบเต็ม ซึ่งประกอบด้วย fingerprint และ hostname ของคุณ ให้คัดลอกทั้งสองรายการไว้ทันที

Init จะสร้าง /etc/opt/simplex/ca.key ด้วย และเอกสารแนะนำให้ย้ายไฟล์นี้ไปเก็บใน offline storage เหตุผลสำคัญคือ client จะ pin fingerprint ของ certificate authority ดังนั้นผู้ที่มี ca.key สามารถออก server certificate ใหม่ที่ client ยอมรับว่าเป็น certificate ของคุณได้ คุณจำเป็นต้องนำไฟล์นี้กลับมาใช้เฉพาะเมื่อต้องการ rotate server certificate ภายหลังด้วย smp-server cert

ให้ถือว่า init เป็นขั้นตอนที่ทำเพียงครั้งเดียว fingerprint ใน address ของคุณมาจาก authority ที่ init สร้างขึ้น ดังนั้นการสร้าง authority ใหม่จะทำให้ได้ address ใหม่ และ address เดิมที่คุณแจกจ่ายไว้จะไม่สามารถใช้งานได้

เรียกใช้งานภายใต้ 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 จาก upstream ยังมี AmbientCapabilities=CAP_NET_BIND_SERVICE ด้วย บรรทัดนี้มีไว้เนื่องจากกระบวนการทำงานในฐานะ smp และพอร์ตที่ต่ำกว่า 1024 ไม่เปิดให้กระบวนการที่ไม่ใช่ root ใช้งาน ดังนั้นหากไม่มีบรรทัดนี้ daemon จะ bind พอร์ต 80 หรือ 443 ไม่ได้ ให้เพิ่มบรรทัดนี้หากคุณให้บริการผ่านพอร์ตดังกล่าว LimitNOFILE=65535 มีความสำคัญเนื่องจาก client ที่ subscribe ทุกตัวจะถือการเชื่อมต่อ TCP ที่เปิดอยู่ และค่าจำกัดเริ่มต้นต่ำกว่าจำนวนที่ relay ที่มีการใช้งานสูงต้องการมาก ExecStopPost จะคัดลอก log ของ store ไปเป็นไฟล์ .bak ทุกครั้งที่หยุดบริการ ทำให้มีจุด rollback สำรองไว้โดยไม่ต้องตั้งค่าเพิ่มเติม

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

การเริ่มทำงานที่ปกติจะแสดง address ของ server ใน log จากนั้นยืนยันว่า socket เปิดใช้งานอยู่จริง:

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

ทั้งสองบรรทัดควรระบุ smp-server การเรียกใช้ daemon ด้วย account ของตนเองโดยไม่มีสิทธิ์ sudo เป็นแนวทางเดียวกับที่อธิบายไว้ใน account แยกตาม service บน VPS และช่วยป้องกันไม่ให้ bug ใน network daemon ตัวหนึ่งพัฒนาไปเป็น root shell

พอร์ตที่ควรเปิด และพอร์ตที่ควรปิดไว้

เอกสารระบุไว้ 3 รายการ ได้แก่ 5223/tcp, 443/tcp และ 80/tcp พอร์ต 5223 คือ SMP transport config ที่มากับระบบกำหนด port: 5223,443 ไว้ภายใต้ [TRANSPORT] ดังนั้น protocol เดียวกันจึงตอบสนองบน 443 ได้ด้วย ซึ่งมีความสำคัญเพราะเครือข่ายที่มีข้อจำกัดจำนวนมากอนุญาต outbound 443 และไม่อนุญาตพอร์ตอื่น พอร์ต 80 จำเป็นเฉพาะสำหรับ information page ที่เป็นตัวเลือก และการ redirect ไปยัง 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 พอร์ตนี้คือ control port และเอกสารสั่งเข้าถึงจากเครื่องเดียวกันด้วย nc 127.0.0.1 5224 พอร์ตนี้แสดงสถานะเซิร์ฟเวอร์และลบคิว จึงควรให้รับการเชื่อมต่อเฉพาะบน loopback และกำหนดรหัสผ่าน admin กับ user ไว้ภายใต้ [AUTH] หากยังไม่คุ้นเคยกับเครื่องมือนี้ พื้นฐานของ ufw บน VPS อธิบายลำดับของกฎและวิธีป้องกันไม่ให้ตนเองถูกตัดการเข้าถึง

ยังมีการควบคุมอีกชั้นหนึ่งที่มักทำให้เกิดความสับสน ผู้ให้บริการส่วนใหญ่มี network firewall ในแผงควบคุม ซึ่งแยกจาก ufw บนเครื่อง พอร์ตอาจเปิดอยู่ใน ufw แต่ยังถูก drop ก่อนที่การเชื่อมต่อจะมาถึงเครื่องของคุณ

ที่อยู่เซิร์ฟเวอร์ที่ไคลเอนต์ของคุณต้องใช้

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

สตริงนี้คือการกำหนดค่าฝั่งไคลเอนต์ทั้งหมด ให้วางลงในการตั้งค่าเซิร์ฟเวอร์ของแอป หรือให้ผู้ใช้อื่นสแกน QR code ที่แอปแสดงสำหรับค่านี้ เอกสารระบุว่า QR code มี password รวมอยู่ด้วย ดังนั้นผู้ที่สแกนจึงสามารถรับข้อความผ่านเซิร์ฟเวอร์ของคุณได้เช่นกัน

มีพฤติกรรมหนึ่งที่ระบุไว้ในเอกสารและทำให้ผู้ใช้ส่วนใหญ่ประหลาดใจ การเพิ่มเซิร์ฟเวอร์ของคุณในแอปจะมีผลเฉพาะกับ contact ที่คุณสร้างตั้งแต่เวลานั้นเป็นต้นไปเท่านั้น contact ที่มีอยู่เดิมจะยังคงใช้ relay ที่สร้าง queue ของตนเองไว้ และจะไม่ migrate ไปยัง relay ใหม่ ด้วยเหตุนี้ คุณจึงไม่สามารถปิด relay เดิมในวันถัดจากวันที่เปลี่ยน relay ได้

การเพิ่ม file relay ของ XFTP

XFTP (SimpleX file transfer protocol) เป็นส่วนรับส่งไฟล์ของเครือข่าย และทำงานเป็น daemon แยกต่างหากที่มี address ของตนเอง ตาม ประกาศ XFTP ของโครงการ relay ไม่มี metadata ของไฟล์เลย โดยจะเห็นเพียง chunk แต่ละชิ้นที่มีขนาด 256kb, 1mb หรือ 4mb และมีการอนุญาตให้เข้าถึงด้วยข้อมูลรับรองแบบไม่ระบุตัวตน ผู้ส่งสามารถกระจาย chunk ของไฟล์เดียวกันไปยัง relay หลายตัวได้ ดังนั้นเครื่องของคุณจึงเก็บเพียงชิ้นส่วน ไม่ใช่ไฟล์ทั้งไฟล์

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/"

config ของบริการอยู่ใน /etc/opt/simplex-xftp/, state อยู่ใน /var/opt/simplex-xftp/ และ chunk ของไฟล์อยู่ในตำแหน่งที่ -p ระบุ unit ของ systemd มีรูปแบบเดียวกัน โดยใช้ User=xftp และ ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS ตอนเริ่มต้นระบบจะแสดง address ของ xftp:// ในรูปแบบเดียวกับ SMP พร้อม fingerprint ของบริการใน /etc/opt/simplex-xftp/fingerprint

ต้องวางแผนเรื่องพอร์ตชนกัน พอร์ตที่ระบุไว้สำหรับ XFTP server คือ 443 และ SMP config ก็ระบุ 443 เช่นกัน กระบวนการ 2 รายการไม่สามารถ bind พอร์ตเดียวกันบน address เดียวกันได้ ดังนั้นเมื่อใช้ VPS เดียวจะต้องเลือกแก้ไขอย่างใดอย่างหนึ่ง วิธีที่ง่ายที่สุดคือกำหนด port: 5223 ในส่วน [TRANSPORT] ของ SMP แล้วสงวนพอร์ต 443 ให้ file relay โดยต้องแลกกับการไม่มี 443 fallback สำหรับ client บนเครือข่ายที่มีข้อจำกัด ทางเลือกอื่นคือเพิ่ม IP address ที่ 2 ให้กับ VPS เดิม หรือใช้ VPS ที่ 2

กำหนด quota ตามพื้นที่ดิสก์ที่มีอยู่จริง -q '20gb' เป็นการรับรองว่าคุณมีพื้นที่ดิสก์เพียงพอ file relay เป็นส่วนที่ใช้พื้นที่ดิสก์และ bandwidth มากที่สุด ส่วน message relay แทบไม่ใช้ทรัพยากรทั้ง 2 รายการนี้

สิ่งที่อยู่บนดิสก์ และสิ่งที่การสำรองข้อมูลกู้คืนได้

มี 2 ไดเรกทอรีที่สำคัญ /etc/opt/simplex/ คือข้อมูลระบุตัวตน ซึ่งประกอบด้วย smp-server.ini, certificate และ key ของเซิร์ฟเวอร์, ca.key และ fingerprint ส่วน /var/opt/simplex/ คือสถานะของระบบ โดย smp-server-store.log เก็บคิว และเมื่อเป็น 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

ควรทำความเข้าใจให้ชัดว่า archive นี้คืออะไร archive นี้ไม่ใช่คลังข้อความ รายการที่อยู่ในคิวเป็น ciphertext สำหรับ key ที่ relay ไม่เคยถือครอง และ config [STORE_LOG] ที่มากับซอฟต์แวร์จะทำให้ข้อความหมดอายุหลัง 21 วันอยู่แล้ว archive นี้เป็นสำเนาข้อมูลระบุตัวตนของเซิร์ฟเวอร์ รวม ca.key ไว้ด้วย ดังนั้นผู้ใดก็ตามที่ได้ไฟล์นี้ไปสามารถแอบอ้างเป็น relay ของคุณกับ contact ของคุณได้ ให้เข้ารหัสไฟล์และเก็บไว้นอกเครื่องเซิร์ฟเวอร์

ประโยชน์สำคัญคือการกู้คืนระบบ ให้นำ /etc/opt/simplex กลับไปไว้บน VPS เครื่องใหม่ แล้วชี้ DNS name เดิมมายังเครื่องนั้น fingerprint จะยังคงเดิม ดังนั้น address ที่แจกไปก่อนหน้านี้ทั้งหมดจะยังใช้งานได้ หากไดเรกทอรีนี้สูญหาย จะไม่สามารถกู้คืนได้ การติดตั้งใหม่จะสร้าง fingerprint ใหม่ ซึ่งหมายถึง address ใหม่ และทำให้ contact ทุกแห่งที่ส่งผ่าน relay ของคุณหายไป

TLS: certificate 2 ใบที่ทำหน้าที่ต่างกัน

SMP transport ไม่ได้ใช้ public certificate authority โดย Init จะสร้าง private authority และ server certificate แล้วส่ง fingerprint ของ authority นั้นไปภายใน server address ไคลเอนต์จะตรวจสอบสิ่งที่เซิร์ฟเวอร์นำเสนอเทียบกับ fingerprint ที่กำหนดตายตัวไว้ ซึ่งเป็นกลไกที่โครงการระบุว่าใช้ป้องกันการเชื่อมต่อระหว่างไคลเอนต์กับเซิร์ฟเวอร์จากการโจมตีแบบ machine-in-the-middle ไม่จำเป็นต้องเรียกใช้ไคลเอนต์ ACME (automatic certificate management environment) บนพอร์ตนั้น และการหมุนเวียน certificate ต้องดำเนินการด้วยตนเองโดยใช้ smp-server cert พร้อมกำหนด SMP_SERVER_CFG_PATH

หน้าข้อมูลแบบเลือกใช้ได้ใช้ certificate อีกใบหนึ่ง ส่วน [WEB] ของหน้านี้ระบุ static_path, https: 443, cert: /etc/opt/simplex/web.crt และ key: /etc/opt/simplex/web.key เบราว์เซอร์ไม่รู้จัก private authority ของคุณ ดังนั้น certificate ที่ได้รับความเชื่อถือจากสาธารณะจึงควรใช้ในจุดนี้ เอกสาร quick start สำหรับ Docker ตั้งค่า Caddy ไว้หน้าเซิร์ฟเวอร์เพื่อทำหน้าที่ดังกล่าวโดยเฉพาะ และออก certificate ให้อัตโนมัติ

การเชื่อมต่อไปยัง relay ผ่าน Tor

เอกสารมีส่วน Tor ที่ติดตั้ง Tor จาก repository ของ Tor Project และเพิ่ม hidden service ใน /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 หมายความว่า location ของ relay เองจะไม่ถูกซ่อน onion address ทำงานได้รวดเร็ว และเปิดช่องทางให้ client เชื่อมต่อโดยที่คุณไม่เห็น IP ของ client แต่ตัวเซิร์ฟเวอร์ยังคงค้นหาได้จาก public IP ของตนเอง ให้นำ onion hostname จาก /var/lib/tor/simplex-smp/hostname ไปต่อท้าย server address หลังเครื่องหมาย comma หากต้องการซ่อน location ของเซิร์ฟเวอร์ด้วย จะต้องใช้การตั้งค่าอีกแบบ และ การรัน onion service จริงบน VPS จะอธิบายข้อแลกเปลี่ยนดังกล่าว ความแตกต่างของสิ่งที่เครื่องมือแต่ละชนิดซ่อนเป็นหัวข้อของ Tor เปรียบเทียบกับ VPN และเกี่ยวข้องกับกรณีนี้โดยตรง

Threat model: การ self-hosting เปลี่ยนแปลงอะไรบ้าง

สิ่งที่คุณได้รับ Metadata เช่น queue ที่มีอยู่, เวลาที่มีการอ่านข้อมูล และ address ที่เชื่อมต่อ จะอยู่บนเครื่องที่คุณควบคุม และคุณเป็นผู้กำหนดว่าจะเก็บข้อมูลเหล่านี้ไว้นานเท่าใด นอกจากนี้ คุณยังไม่อยู่ในกลุ่มข้อมูลขนาดใหญ่ที่สามารถถูกร้องขอได้ในครั้งเดียว

สิ่งที่คุณไม่ได้รับ มีดังนี้:

• การเข้ารหัสไม่เปลี่ยนแปลง ข้อความได้รับการเข้ารหัสแบบ end to end ก่อนที่คุณจะติดตั้งระบบนี้ และยังได้รับการเข้ารหัสแบบ end to end หลังจากนั้น การ self-hosting เป็นการตัดสินใจเกี่ยวกับ metadata ไม่ใช่การตัดสินใจเกี่ยวกับ cryptography
• ผู้ให้บริการ VPS ของคุณมองเห็น traffic ที่ไปยัง IP address ของคุณ และเก็บรายละเอียดการเรียกเก็บเงินของคุณไว้ คุณเพียงย้ายความไว้วางใจจากผู้ให้บริการระบบส่งข้อความไปยังผู้ให้บริการ hosting ไม่ได้ลบความไว้วางใจนั้นออกไป
• relay ของคุณมีผู้ใช้งานกลุ่มเล็ก หาก relay ให้บริการเพียง household เดียว การเชื่อมต่อไปยัง relay จะระบุ household นั้น และ hostname ของ relay จะอยู่ใน invitation link ทุกลิงก์ที่คุณส่งจากระบบนั้น public relay ที่มีผู้ใช้งานจำนวนมากจะช่วยซ่อนตัวคุณได้ดีกว่าในแง่นี้ และนี่คือข้อแลกเปลี่ยนที่แท้จริง private search server ก็มีลักษณะเดียวกัน ดังนั้น SearXNG ซ่อนอะไรได้จริงบน VPS ของคุณเอง จึงขึ้นอยู่กับว่ามีผู้ใช้กี่คนแชร์ instance เดียวกับคุณ
• ความพร้อมใช้งานเป็นความรับผิดชอบของคุณแล้ว disk เต็มหรือเครื่องหยุดทำงานจะทำให้ไม่สามารถส่งข้อความได้ และ contact ของคุณไม่มีวิธี routing อ้อมผ่านระบบอื่น

เหตุผลเดียวกันนี้ใช้กับ private service ใดก็ตามที่คุณนำไปรันบนเครื่องที่คุณเป็นเจ้าของ ไม่ว่าจะเป็น relay นี้หรือ WireGuard VPN บน VPS ของคุณเอง คุณกำลังเลือกว่าฝ่ายใดจะมองเห็น metadata คุณไม่ได้ทำให้ metadata หายไป

เมื่อใช้งานไม่ได้

Service เริ่มทำงานแล้วหยุดทันที อ่าน sudo journalctl -u smp-server -n 50 ข้อผิดพลาดจากการ bind จะระบุพอร์ตที่ service ไม่สามารถใช้งานได้ จากนั้นเรียกใช้ sudo ss -tlnp | grep :443 เพื่อดูว่า process ใดกำลังใช้พอร์ตนั้นอยู่ บนเครื่องใหม่มักเป็น nginx, Caddy หรือ XFTP server ที่คุณเพิ่งติดตั้งไปเมื่อ 1 ชั่วโมงก่อน

Init ไม่สามารถเขียน config ได้ การเรียกใช้ smp-server init ในฐานะผู้ใช้ smp ก่อนที่ /etc/opt/simplex จะมีอยู่ จะทำให้เกิดข้อผิดพลาดด้านสิทธิ์ เนื่องจาก /etc/opt มี root เป็นเจ้าของ ให้สร้าง directory ด้วย owner ที่ถูกต้องก่อน แล้วเรียกใช้ init อีกครั้ง

Client ไม่สามารถเชื่อมต่อ relay ได้ ตรวจสอบว่า name resolve ไปยัง address ที่ถูกต้องด้วย dig +short smp1.example.com จากนั้นทดสอบพอร์ตจาก laptop ของคุณ ไม่ใช่จาก server: nc -vz smp1.example.com 5223 หากการเชื่อมต่อจากภายนอกล้มเหลว ขณะที่ ss แสดงว่า socket เปิดอยู่บนเครื่อง นั่นชี้ไปที่ network firewall ของ provider ซึ่งเป็นการควบคุมคนละส่วนกับ ufw

Contact ไม่สามารถเชื่อมต่อผ่าน relay ของคุณได้ fingerprint ใน address ที่คุณแชร์ต้องตรงกับเนื้อหาปัจจุบันของ /etc/opt/simplex/fingerprint หากคุณกำหนด create_password ไว้ภายใต้ [AUTH] address ต้องมี password ดังกล่าวด้วย มิฉะนั้น client จะไม่ได้รับอนุญาตให้สร้าง queue

ไม่มีข้อมูลเคลื่อนย้ายหลังจากเพิ่ม server ใน app นี่เป็นการทำงานตามที่ออกแบบไว้ เฉพาะ contact ใหม่เท่านั้นที่จะใช้ relay ที่เพิ่มเข้ามา Contact เดิมยังคงใช้ queue ที่มีอยู่แล้ว

FAQ

การโฮสต์เซิร์ฟเวอร์ SimpleX ด้วยตนเองทำให้ข้อความของฉันปลอดภัยขึ้นหรือไม่

ไม่ และนี่เป็นการออกแบบโดยตั้งใจ SimpleX เข้ารหัสข้อความแบบ end-to-end ระหว่างอุปกรณ์ ดังนั้น relay จะไม่มี key ไม่ว่าใครจะเป็นผู้ดูแลก็ตาม การโฮสต์ด้วยตนเองเปลี่ยนผู้ที่สามารถสังเกต metadata ของข้อความเหล่านั้น ได้แก่ มี queue ใดอยู่บ้าง มีการอ่านเมื่อใด และมี IP address ใดเชื่อมต่อ นี่เป็นการตัดสินใจเกี่ยวกับ metadata หากเหตุผลที่คุณโฮสต์ด้วยตนเองคือการเข้ารหัสที่รัดกุมกว่า การเข้ารหัสดังกล่าวมีอยู่แล้ว

ผู้ดูแล SimpleX relay มองเห็นอะไรได้จริง

โครงการอธิบายเรื่องนี้ไว้ใน protocol/security.md relay ไม่สามารถอ่านเนื้อหาหรือประเภทของข้อความ ไม่สามารถแก้ไขข้อความแต่ละรายการโดยไม่ให้ตรวจพบ และไม่สามารถทำลายการเข้ารหัสแบบ end-to-end ด้วยการโจมตีเชิงรุกได้ relay สามารถเห็นได้ว่าผู้รับของ queue ออนไลน์เมื่อใด นับจำนวนข้อความที่ผ่าน queue เรียนรู้ IP address ของผู้รับ ทิ้งข้อความในอนาคตของ queue หรือรายงานสถานะของ queue เท็จได้ สิ่งเหล่านี้คือขอบเขตอำนาจที่คุณมีเมื่อ relay อยู่ภายใต้การดูแลของคุณ

จำเป็นต้องมี domain name และ TLS certificate หรือไม่

คุณต้องมี domain สำหรับการตั้งค่าที่ใช้งานได้ และ smp-server init รองรับ --ip หากคุณไม่มี domain จริง ๆ คุณไม่จำเป็นต้องใช้ certificate จาก public authority สำหรับ messaging port: init จะสร้าง authority ของตนเอง และ client จะ pin fingerprint ที่ปรากฏใน address ของ smp:// คุณต้องใช้ certificate ที่ public trust ยอมรับเฉพาะกับ web information page ซึ่งเป็นตัวเลือกเสริมและกำหนดค่าด้วย cert และ key ใน section [WEB] ของ smp-server.ini

จะเกิดอะไรขึ้นหากฉันทำ /etc/opt/simplex หาย

ทุก address ที่คุณแจกจ่ายจะหยุดทำงาน directory ดังกล่าวเก็บ certificate authority ที่มี fingerprint ฝังอยู่ใน server address ของคุณ ดังนั้นการสร้างระบบใหม่จะทำให้ได้ fingerprint อื่น และถือเป็น server คนละเครื่อง Contacts ที่ queue อยู่บน relay นั้นไม่สามารถซ่อมแซมจากฝั่ง client ได้ สำรอง directory นี้ในรูปแบบเข้ารหัสและเก็บไว้นอกเครื่อง และเก็บ ca.key แบบออฟไลน์ตามที่เอกสารแนะนำ เนื่องจากผู้ที่ถือสิ่งนี้สามารถปลอมเป็น relay ของคุณได้

สามารถเรียกใช้ SMP relay และ XFTP file relay บน VPS เดียวกันได้หรือไม่

ได้ แต่ต้องจัดการความขัดแย้งหนึ่งรายการก่อน port ที่เอกสารของ XFTP server ระบุคือ 443 และค่าเริ่มต้นของ SMP config ระบุ port: 5223,443 ดังนั้นทั้งสองบริการจึงต้องการ socket เดียวกัน กำหนดให้บริการใดบริการหนึ่งใช้ 443: ตั้งค่า port: 5223 สำหรับ SMP server หรือย้าย file relay ไปยัง IP address ที่สองหรือ VPS ที่สอง นอกจากนี้ควรกำหนด storage quota ให้สอดคล้องกับพื้นที่ disk ที่มีอยู่จริง เพราะ file relay เป็น component ที่ใช้ disk และ bandwidth