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

หน้าที่ของเซิร์ฟเวอร์แชท SimpleX แบบ self-hosted

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

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

คำสั่ง, path, พอร์ต และ flag ทั้งหมดด้านล่างนี้อ้างอิงมาจากเอกสารของโปรเจกต์โดยตรง ได้แก่ หน้าการโฮสต์เซิร์ฟเวอร์ SMP, หน้าเซิร์ฟเวอร์ XFTP และ เอกสารความปลอดภัยของโปรโตคอล ในกรณีที่มีตัวเลขสำคัญกำกับไว้ จะมีการระบุชื่อหน้าที่มาของข้อมูลนั้นไว้ข้างๆ

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

SimpleX ไม่มีชื่อผู้ใช้ ไม่มีหมายเลขโทรศัพท์ และไม่มี ID บัญชี รายชื่อติดต่อคือคิวทางเดียว (unidirectional queue) ซึ่งเป็นที่อยู่บน relay แห่งหนึ่งที่ฝ่ายหนึ่งเขียนข้อความลงไปและอีกฝ่ายหนึ่งอ่านออกมา รายชื่อติดต่อสองรายการของคุณไม่มีตัวระบุใดๆ ที่เซิร์ฟเวอร์จะสามารถนำมาเชื่อมโยงกันได้

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

hostname ของ relay เป็นส่วนหนึ่งของที่อยู่คิว ดังนั้นมันจึงอยู่ในทุกลิงก์คำเชิญที่คุณแจกจ่ายออกไป โปรดคำนึงถึงเรื่องนี้เมื่อคุณอ่านแบบจำลองภัยคุกคาม (threat model) ในช่วงท้ายของเอกสาร

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

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

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

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

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

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

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

ติดตั้งเวอร์ชันที่ระบุเจาะจง แทนการใช้ "latest"

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

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

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 ไม่มีสิทธิ์เขียนไดเรกทอรี 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

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

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

ติดตั้งโดยให้ root เป็นเจ้าของไฟล์โดยเจตนา เนื่องจากเซอร์วิสนี้รันในฐานะ smp ดังนั้นหากเซอร์วิสถูกบุกรุก ผู้โจมตีจะไม่สามารถเขียนทับไฟล์ binary ที่ใช้เริ่มต้นระบบได้

เริ่มต้นใช้งานเซิร์ฟเวอร์และจัดเก็บค่าความลับสองรายการที่แสดงผล

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

• --store-log (-l) จะเขียนบันทึกแบบ 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 จะอนุญาตให้ใครก็ได้สร้างคิวบน relay ของคุณ หากต้องการจำกัดความเป็นส่วนตัว ให้ตั้งค่า create_password ภายใต้ [AUTH] ใน /etc/opt/simplex/smp-server.ini หลังจากเริ่มต้นระบบ แทนการส่งค่า --password ในขั้นตอนนี้ เนื่องจากคำสั่งที่พิมพ์ผ่าน command line จะปรากฏในประวัติ shell และในรายการ process ขณะที่โปรแกรมทำงาน

กระบวนการ init จะสร้างใบรับรองและแสดงค่าสองรายการที่คุณต้องเก็บรักษาไว้ ค่าแรกคือ fingerprint ซึ่งเป็นสตริง base64 ที่ถูกเขียนลงใน /etc/opt/simplex/fingerprint ด้วย ค่าที่สองคือที่อยู่เซิร์ฟเวอร์แบบเต็ม ซึ่งประกอบด้วย fingerprint รวมกับชื่อโฮสต์ของคุณ ให้คัดลอกค่าทั้งสองไว้ทันที

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

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

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

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

การเริ่มต้นที่สมบูรณ์จะบันทึกที่อยู่เซิร์ฟเวอร์ลงใน log จากนั้นให้ยืนยันว่า socket เปิดใช้งานอยู่จริง:

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

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

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

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

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

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

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

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

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

การเพิ่ม XFTP file relay

XFTP (SimpleX file transfer protocol) คือส่วนการรับส่งไฟล์ของเครือข่าย โดยทำงานเป็น daemon แยกต่างหากและมีที่อยู่เป็นของตนเอง ตามที่ระบุไว้ใน ประกาศเกี่ยวกับ XFTP ของโครงการ relay จะไม่มีข้อมูล metadata ของไฟล์เลย โดยจะมองเห็นเพียงข้อมูลเป็นส่วนๆ (chunks) ขนาด 256kb, 1mb หรือ 4mb ซึ่งการเข้าถึงจะได้รับอนุญาตผ่าน anonymous credentials ผู้ส่งสามารถกระจายส่วนของไฟล์หนึ่งไฟล์ไปยัง 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/"

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

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

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

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

มีไดเรกทอรีสำคัญ 2 แห่ง /etc/opt/simplex/ คือตัวตนของเซิร์ฟเวอร์ ประกอบด้วย smp-server.ini, ใบรับรองและคีย์ของเซิร์ฟเวอร์ 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

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

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

TLS: ใบรับรองสองใบที่ทำหน้าที่ต่างกัน

การรับส่งข้อมูลผ่าน SMP ไม่ได้ใช้หน่วยงานออกใบรับรอง (Certificate Authority) สาธารณะ กระบวนการเริ่มต้น (Init) จะสร้างหน่วยงานออกใบรับรองส่วนตัวและใบรับรองเซิร์ฟเวอร์ขึ้นมา โดยค่าลายนิ้วมือ (fingerprint) ของหน่วยงานนั้นจะถูกรวมอยู่ในที่อยู่ของเซิร์ฟเวอร์ ฝั่งไคลเอนต์จะตรวจสอบสิ่งที่เซิร์ฟเวอร์ส่งมาเทียบกับลายนิ้วมือที่ระบุไว้ ซึ่งโครงการอธิบายว่าเป็นวิธีการปกป้องการเชื่อมต่อระหว่างไคลเอนต์และเซิร์ฟเวอร์จากการโจมตีแบบ 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 ไว้หน้าเซิร์ฟเวอร์เพื่อการนี้โดยเฉพาะ ซึ่งจะช่วยออกใบรับรองให้โดยอัตโนมัติ

การเข้าถึง 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

โปรดอ่านบรรทัด mode ทั้งสองบรรทัดอย่างละเอียด การตั้งค่าแบบ single hop และ non-anonymous หมายความว่าตำแหน่งที่ตั้งของ relay จะไม่ถูกซ่อนไว้ onion address มีความเร็วสูงและช่วยให้ client สามารถเชื่อมต่อเข้ามาได้โดยไม่เปิดเผย IP address ของตนให้คุณทราบ แต่ตัวเซิร์ฟเวอร์เองยังคงสามารถถูกค้นพบได้ผ่าน public IP ของมัน onion hostname จาก /var/lib/tor/simplex-smp/hostname จะต้องนำไปต่อท้ายที่อยู่ของเซิร์ฟเวอร์โดยคั่นด้วยเครื่องหมายจุลภาค หากคุณต้องการซ่อนตำแหน่งที่ตั้งของเซิร์ฟเวอร์ด้วย นั่นจะเป็นการตั้งค่าแบบอื่น ซึ่ง การรัน onion service จริงบน VPS ได้อธิบายถึงข้อแลกเปลี่ยนในส่วนนี้ไว้ ความแตกต่างในสิ่งที่เครื่องมือแต่ละชนิดปกปิดคือหัวข้อของ การเปรียบเทียบ Tor กับ VPN ซึ่งสามารถนำมาประยุกต์ใช้กับกรณีนี้ได้โดยตรง

แบบจำลองภัยคุกคาม: สิ่งที่เปลี่ยนไปเมื่อคุณทำ Self-hosting

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

สิ่งที่คุณไม่ได้รับ (กล่าวอย่างตรงไปตรงมา):

• การเข้ารหัสยังคงเหมือนเดิม: ข้อความมีการเข้ารหัสแบบ end-to-end ก่อนที่คุณจะสร้างระบบนี้ และยังคงมีการเข้ารหัสแบบ end-to-end หลังจากนั้น การทำ self-hosting เป็นการตัดสินใจในระดับข้อมูลเมตา ไม่ใช่การตัดสินใจในระดับวิทยาการรหัสลับ
• ผู้ให้บริการ VPS ของคุณเห็นทราฟฟิกที่วิ่งไปยัง IP address ของคุณและถือครองข้อมูลการเรียกเก็บเงินของคุณ คุณเพียงแค่ย้ายความไว้วางใจจากผู้ให้บริการรับส่งข้อความไปยังผู้ให้บริการโฮสติ้ง คุณไม่ได้กำจัดความไว้วางใจนั้นออกไป
• Relay ของคุณเป็นกลุ่มขนาดเล็ก: หากมันให้บริการเพียงครัวเรือนเดียว การเชื่อมต่อเข้ากับมันจะระบุตัวตนของครัวเรือนนั้นได้ และ hostname ของมันจะปรากฏอยู่ในทุกลิงก์คำเชิญที่คุณส่งออกไป ในแง่นี้ Relay สาธารณะที่มีผู้ใช้งานหนาแน่นจะช่วยปกปิดตัวตนของคุณได้ดีกว่า และนี่คือข้อแลกเปลี่ยนที่แท้จริง
• ความพร้อมใช้งานกลายเป็นความรับผิดชอบของคุณ: หากดิสก์เต็มหรือเซิร์ฟเวอร์ล่ม ข้อความจะหยุดการส่ง และผู้ติดต่อของคุณไม่มีทางเลือกอื่นในการส่งข้อมูลผ่านช่องทางอื่น

ตรรกะเดียวกันนี้ใช้กับบริการส่วนตัวใดๆ ที่คุณนำไปวางไว้บนเครื่องที่คุณเป็นเจ้าของ ไม่ว่าจะเป็น Relay นี้ หรือ WireGuard VPN บน VPS ของคุณเอง คุณกำลังเลือกฝ่ายที่จะเห็นข้อมูลเมตาของคุณ คุณไม่ได้ทำให้ข้อมูลเหล่านั้นหายไปไหน

เมื่อระบบไม่ทำงาน

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

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

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

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

ไม่มีข้อมูลใดๆ เคลื่อนไหวหลังจากที่คุณเพิ่มเซิร์ฟเวอร์ในแอป นี่เป็นพฤติกรรมปกติ เฉพาะคู่สนทนาใหม่เท่านั้นที่จะใช้ relay ที่เพิ่มเข้ามาใหม่ ส่วนคู่สนทนาเดิมจะยังคงใช้คิวที่พวกเขามีอยู่เดิมต่อไป

FAQ

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

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

ผู้ดูแล SimpleX relay สามารถมองเห็นอะไรได้บ้าง?

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

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

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

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

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

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

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