Tự Dựng Server Matrix Riêng

Người dùng tự triển khai Matrix để công ty không còn nắm giữ các cuộc trò chuyện của họ, và điều đó đúng như quảng cáo. Điều khiến họ bất ngờ sau này là bản chất thật sự của thứ họ vừa cài đặt: một homeserver không phải là một hộp riêng tư chỉ tình cờ biết trò chuyện. Đó là một nút sao chép (replication node) trong một mạng lưới công khai, và federation hoạt động giống một giao thức xuất bản hơn nhiều so với những gì hầu hết quản trị viên mới hình dung.

Không có điều nào ở trên là lý do để không tự vận hành server — đó là lý do để bạn vận hành nó một cách có chủ đích. Sự riêng tư mà bạn có được là thật nhưng rất cụ thể: quyền kiểm soát chuyển về tay bạn, tài khoản không thể bị người khác khóa, và các yêu cầu pháp lý sẽ thuộc thẩm quyền mà bạn tự chọn chứ không phải nơi một công ty chọn hộ. Sự riêng tư mà bạn không có được cũng cụ thể không kém, và gần như toàn bộ nó nằm trong khoảng cách giữa "tin nhắn đã được mã hóa" và "không ai biết ai đang nói chuyện với ai". Hướng dẫn này sẽ nói về cả hai nửa đó, rồi đến các chi tiết vận hành quyết định server của bạn có còn khỏe mạnh sau một năm nữa hay không.

Điều gì thực sự thay đổi khi bạn tự vận hành homeserver

Hãy bắt đầu bằng cách tách riêng từng mối lo, vì một homeserver giải quyết trọn vẹn một số vấn đề, giải quyết một phần số khác, và hoàn toàn không đụng tới phần còn lại. Bảng dưới đây là phiên bản trung thực của lời quảng cáo, và bạn nên đọc nó trước khi chọn phần cứng chứ không phải sau.

Hãy đọc kỹ hai dòng cuối, vì đó là nơi kỳ vọng của bạn sẽ vỡ. Nếu mục tiêu của bạn là không ai có thể xác định được rằng một dịch vụ đang tồn tại, Matrix là công cụ sai và một dịch vụ onion mới là lựa chọn gần đúng hơn. Nếu mục tiêu của bạn là quyền kiểm soát, khả năng quản lý và thẩm quyền pháp lý, một homeserver là công cụ tuyệt vời, và phần còn lại của hướng dẫn này nói về cách vận hành nó cho tốt.

Federation là một giao thức sao chép khoác áo giao thức chat

Đây là cơ chế giải thích phần lớn những bất ngờ. Khi một trong những người dùng của bạn tham gia một phòng được lưu trữ ở nơi khác, server của bạn không lấy tin nhắn theo yêu cầu như một ứng dụng email. Nó tham gia phòng đó như một thành viên trong một đồ thị sự kiện phân tán, rồi kéo về và lưu lại một bản sao các sự kiện của phòng, danh sách thành viên, cùng đủ lịch sử trạng thái để xác thực những gì xảy ra tiếp theo. Từ thời điểm đó, máy của bạn giữ một bản sao, và mọi server tham gia khác cũng giữ một bản như vậy.

Hệ quả xảy ra theo cả hai chiều, và không chiều nào dễ đoán. Dữ liệu do người dùng của bạn tạo ra — tên hiển thị, ảnh đại diện, việc tham gia và rời phòng, dấu thời gian, biểu cảm phản hồi — được sao chép sang mọi server có thành viên trong phòng đó, và nó vẫn nằm trong cơ sở dữ liệu của họ bất kể sau này bạn xóa gì trên máy của mình. Việc thu hồi (redaction) chỉ là một yêu cầu gửi tới các server ngang hàng, không phải một mệnh lệnh. Không hề có chuyện "thu hồi tin nhắn" trên toàn bộ một federation gồm các server vận hành độc lập, và việc kỳ vọng điều đó là hiểu lầm phổ biến nhất về giao thức này.

Theo chiều ngược lại, việc tham gia các phòng công khai lớn đồng nghĩa với việc nhập lịch sử của người khác vào ổ đĩa của bạn. Đây là lý do vì sao một homeserver mới tinh chỉ với ba người dùng vẫn có thể mang một cơ sở dữ liệu nặng hàng chục gigabyte: không phải vì ba người dùng đó viết nhiều, mà vì họ đã tham gia các phòng có năm mươi nghìn thành viên và nhiều năm trạng thái tích lũy. Việc chọn phòng một cách có cân nhắc vừa là quyết định về dung lượng, vừa là quyết định về quyền riêng tư.

Những gì mã hóa bảo vệ, và những gì vẫn lộ ra ngoài

Matrix mã hóa nội dung tin nhắn bằng Megolm, và trong các phòng riêng tư tính năng này được bật mặc định. Điều đó bảo vệ phần mà mọi người quan tâm nhất, và nó thực sự hiệu quả — server của bạn chỉ lưu văn bản mật mã mà nó không đọc được, một đặc tính có thật và hữu ích khi server là phần cứng đi thuê. Phần bao bọc quanh tin nhắn lại là một câu chuyện khác, và khoảng trống đó rộng hơn nhiều so với những gì hầu hết các bài tóm tắt thừa nhận.

Hiểu theo cách thực tế: mã hóa bảo vệ cái gì được nói, còn federation lại công khai ai, khi nào và với tần suất ra sao. Với hầu hết cộng đồng, sự đánh đổi này hoàn toàn chấp nhận được, và sự trung thực chính là điểm mấu chốt. Còn với mô hình đe dọa mà sơ đồ quan hệ xã hội mới là phần nhạy cảm, một giao thức liên hợp về bản chất có hình dạng sai, và không có cờ cấu hình nào thay đổi được điều đó.

Synapse, Dendrite hay Conduit — nên chạy phần mềm nào

Trong thực tế có ba bản triển khai đáng quan tâm, và việc lựa chọn chủ yếu là quyết định về tài nguyên chứ không phải triết lý.

• Synapse là server tham chiếu, viết bằng Python, và là bản duy nhất mà mọi tính năng hoạt động ngay từ ngày đầu. Nó cũng "ngốn" tài nguyên nhất: bộ nhớ tăng theo số lượng và kích thước các phòng mà người dùng của bạn tham gia, và một server bận rộn sớm muộn sẽ cần tách thành các worker process. Hãy chọn nó khi bạn cần spaces, công cụ kiểm duyệt, bridge và các API quản trị hoạt động đúng như tài liệu mô tả.
• Dendrite là bản viết lại bằng Go. Nhẹ hơn Synapse rõ rệt và hoàn toàn dùng tốt cho một server nhỏ, đổi lại một số tính năng ra sau. Đây là lựa chọn trung dung hợp lý khi Synapse có vẻ quá nặng so với số người bạn thực sự có.
• Conduit và bản fork đang được phát triển tích cực của nó, conduwuit, viết bằng Rust và chỉ là một tệp nhị phân duy nhất kèm cơ sở dữ liệu nhúng sẵn. Chúng chạy tốt một server cho gia đình hay cộng đồng nhỏ trên gói rẻ nhất mà chúng tôi bán, không phàn nàn gì. Đánh đổi là một hệ sinh thái nhỏ hơn: một số công cụ quản trị và vài bridge chỉ hỗ trợ Synapse.

Với server đầu tiên chỉ có vài người dùng, phần mềm họ Conduit trên một VPS nhỏ là con đường ít đau đầu nhất để có một hệ thống hoạt động tốt mà vẫn rẻ. Với bất cứ thứ gì bạn kỳ vọng sẽ lớn lên — một cộng đồng công khai, một công ty, một dự án có dùng bridge — hãy bắt đầu ngay với Synapse và bỏ qua bước di chuyển sau này, vì chuyển đổi giữa các bản triển khai về sau là cả một quá trình xuất dữ liệu rồi dựng lại chứ không đơn thuần là đổi cấu hình.

Cấu hình ủy quyền (delegation) mà ai cũng làm sai

Matrix tách riêng cái tên xuất hiện trong ID người dùng của bạn khỏi cỗ máy thực sự phục vụ lưu lượng, và làm ngược thứ tự này là sai lầm vĩnh viễn phổ biến nhất khi tự triển khai. server_name của bạn chính là tên miền xuất hiện sau dấu hai chấm trong mọi ID người dùng trên server của bạn. Nó trở thành một phần danh tính của bạn trong federation ngay khi sự kiện đầu tiên được ký, và nó không thể thay đổi sau đó nếu không muốn từ bỏ toàn bộ tài khoản và phòng trên máy đó.

Cách cấu hình bạn gần như luôn muốn dùng: server_name là tên miền trần của bạn, còn phần mềm thì chạy trên một tên miền phụ. Bạn kết nối hai thứ này bằng cơ chế ủy quyền, theo một trong hai cách. Cách đơn giản là một tệp JSON tĩnh được phục vụ tại /.well-known/matrix/server trên tên miền trần, khai báo host và cổng thực sự. Cách khác là một bản ghi DNS, _matrix._tcp, trỏ đến đúng nơi đó. Hãy phục vụ luôn tệp phía client tại /.well-known/matrix/client, để các ứng dụng tìm được homeserver chỉ từ một địa chỉ duy nhất.

Định cỡ server một cách trung thực

Trong vận hành bình thường, Matrix không bị giới hạn bởi CPU; nó bị giới hạn bởi bộ nhớ và hành vi của cơ sở dữ liệu. Các con số công bố cho Synapse là một mức sàn hữu ích: khoảng 2 GB RAM để bắt đầu, khoảng 4 GB khi có mười đến năm mươi người dùng hoạt động, và 8 GB trở lên khi vượt quá một trăm người. Các server họ Conduit thấp hơn nhiều so với mức đó. Điều những con số này không nói ra là mức tiêu thụ đi theo số phòng đã tham gia, chứ không phải số người đã đăng ký — năm người dùng trong một trăm phòng công khai lớn tốn nhiều tài nguyên hơn hẳn năm mươi người dùng trong vài phòng riêng tư nhỏ.

Từ đó rút ra hai nguyên tắc thực tế. Đặt cơ sở dữ liệu trên ổ lưu trữ nhanh và để dư chỗ cho nó phát triển, vì kiểu ghi dữ liệu ở đây nhỏ và đều đặn chứ không dồn dập từng đợt. Và đừng định cỡ theo số người dùng hiện tại: hãy định cỡ theo số phòng mà những người dùng đó sẽ tham gia trong tháng đầu tiên, đây thường mới là nơi ẩn chứa bất ngờ. Gói khởi điểm của chúng tôi gánh tốt một server Conduit hoặc Dendrite nhỏ, còn một instance Synapse cho một cộng đồng thực sự nên nằm ở gói tầm trung trở lên — trang lưu trữ chat liệt kê các gói mà chúng tôi khuyến nghị cho từng quy mô đó.

Thời gian hoạt động liên tục (uptime) ở đây quan trọng hơn so với hầu hết các loại tải khác, vì một chat server bị sập không chỉ đơn giản là không truy cập được — nó còn âm thầm bỏ lỡ các sự kiện mà các server ngang hàng sẽ thử gửi lại một thời gian rồi thôi. Federation khá khoan dung với vài phút gián đoạn nhưng không dễ chịu chút nào với vài ngày.

Kho lưu trữ media là một quả bom ổ đĩa nổ chậm

Mọi hình ảnh, video và tệp đi qua một phòng mà người dùng của bạn có mặt đều có thể bị lưu đệm (cache) trên ổ đĩa của bạn, kể cả media từ xa mà chính người dùng của bạn chưa từng mở. Chính sách lưu giữ mặc định của Synapse giữ những thứ đó vô thời hạn. Kết quả hoàn toàn có thể đoán trước nhưng vẫn khiến nhiều người bất ngờ: một server có cơ sở dữ liệu ổn định nhưng thư mục media âm thầm phình to cho đến khi ổ đĩa đầy, và lúc đó triệu chứng không phải là "hết dung lượng" mà là "server hoạt động kỳ lạ".

Hãy đặt chính sách lưu giữ cho media từ xa ngay từ ngày đầu, thay vì sau lần gián đoạn đầu tiên. Synapse cung cấp các thiết lập lưu giữ trong homeserver.yaml, cùng các endpoint quản trị để dọn lịch sử cũ và tệp đã lưu đệm; synapse-compress-state có thể thu hồi một lượng đáng ngạc nhiên từ các bảng trạng thái trên một server đã chạy lâu. Hãy theo dõi cả cơ sở dữ liệu lẫn đường dẫn media, và đặt cảnh báo theo dung lượng trống còn lại thay vì chỉ khi dịch vụ đã sập — triệu chứng thứ hai thường đến sau triệu chứng đầu vài ngày.

Có một thiết lập đáng để bạn tự quyết định thay vì dùng mặc định. Xem trước liên kết (URL preview) khiến server của bạn tự tải bất kỳ liên kết nào được đăng trong phòng, nghĩa là địa chỉ IP của server sẽ gửi một yêu cầu ra ngoài tới bên thứ ba ngay khi có ai đó dán một liên kết — kể cả một liên kết được cố tình chọn để xem ai "cắn câu". Nếu homeserver của bạn nằm sau một lớp che chắn và địa chỉ thật của nó có ý nghĩa quan trọng, hãy cân nhắc kỹ điều này; hướng dẫn của chúng tôi về che giấu địa chỉ server gốc nói chi tiết hơn về cùng dạng rò rỉ này.

Đăng ký, spam và danh tiếng bạn thừa hưởng

Mở đăng ký tự do trên một homeserver công khai là một lời mời gọi, nhưng không phải loại bạn muốn. Các lượt đăng ký tự động sẽ biến một server nhỏ thành nguồn phát spam chỉ trong vài ngày, và hậu quả không dừng ở phạm vi cục bộ: các homeserver khác sẽ đưa tên miền của bạn vào danh sách kiểm soát truy cập, và một khi tên của bạn xuất hiện trên đủ nhiều danh sách đó, người dùng hợp lệ của bạn sẽ không còn tham gia được các phòng ở nơi khác. Khôi phục lại một danh tiếng tên miền đã "cháy" khó hơn rất nhiều so với việc tránh để nó xảy ra, hệt như với khả năng gửi email đến đích.

Các thiết lập mặc định đáng tin cậy khá đơn giản. Giữ enable_registration ở trạng thái tắt đối với một server riêng tư và tự tay cấp tài khoản. Nếu bạn muốn mở cửa, hãy đặt một lớp kiểm soát: registration_requires_token biến việc đăng ký thành một hệ thống mời mà không cần dịch vụ bên thứ ba nào, và captcha giúp chặn phần thô sơ nhất của vấn đề. Với những phòng do bạn quản trị, các bot kiểm duyệt thuộc họ Mjolnir và Draupnir cho phép bạn áp dụng danh sách cấm và ACL của phòng trên toàn bộ cộng đồng thay vì từng phòng một.

Đáng biết theo chiều ngược lại: dải địa chỉ của chúng tôi không nằm trong các danh sách chặn ACL của Matrix vẫn lưu hành giữa các homeserver, vì vậy một server mới khởi đầu với danh tiếng sạch. Chuyện gì xảy ra với danh tiếng đó về sau là do cách bạn vận hành việc đăng ký quyết định, không phải do máy chủ đặt ở đâu.

Bridge, và hóa đơn metadata đi kèm

Bridge là lý do chính đáng khiến nhiều người vẫn gắn bó với Matrix: một client duy nhất cho các phòng vốn sống trên những mạng khác. Chúng cũng làm thay đổi vị thế an ninh của server bạn theo cách rất dễ bị bỏ qua. Một bridge nắm giữ thông tin đăng nhập cho tài khoản ở mạng từ xa, và tại điểm giao nhau giữa hai giao thức, nó buộc phải xử lý tin nhắn ở dạng có thể chuyển đổi được — nghĩa là tiến trình bridge nhìn thấy văn bản thuần cho lưu lượng vốn được mã hóa đầu cuối ở cả hai phía của nó.

Đó không phải là lý do để tránh dùng bridge. Đó là lý do để coi máy chạy bridge là hạ tầng nhạy cảm: nó là cỗ máy mà nếu bị xâm nhập, sẽ làm lộ các tài khoản mà nó đại diện. Mỗi bridge làm tăng gần gấp đôi lượng bộ nhớ tiêu tốn của một server nhỏ, vì vậy hãy tính toán dung lượng cho phù hợp, và dành cho nơi nó chạy sự cân nhắc kỹ lưỡng như bạn đã dành cho chính homeserver — lập luận trong hướng dẫn chọn thẩm quyền pháp lý của chúng tôi càng đúng hơn nữa với một máy đang giữ thông tin đăng nhập của nhiều mạng cùng lúc.

Giữ cho server sống khỏe: khóa, sao lưu và nâng cấp

Một server Matrix có một tệp mà việc mất nó là không thể khắc phục, theo cách chẳng liên quan gì đến dung lượng dữ liệu. Khóa ký — signing.key trong Synapse — là thứ chứng minh rằng các sự kiện tự nhận đến từ tên miền của bạn thực sự đúng như vậy. Mất nó, bạn không còn có thể đáng tin là chính server của mình nữa; các server ngang hàng sẽ từ chối các sự kiện được ký bởi một kẻ lạ nắm giữ cái tên của bạn. Hãy sao lưu nó tách biệt khỏi mọi thứ khác, và giữ bản sao đó ở ngoài máy chủ.

Nâng cấp là việc bình thường nhưng không phải tùy chọn. Các bản phát hành của homeserver mang theo các migration schema, và bỏ qua nhiều phiên bản liền sẽ biến một lần nâng cấp năm phút thành cả một buổi chiều. Hãy đọc ghi chú phát hành trước khi nhảy phiên bản, nâng cấp đủ đều đặn để mỗi bước đi nhỏ thôi, và thực hiện vệ sinh cơ bản cho host theo danh sách kiểm tra bảo mật giờ đầu tiên — một chat server là một dịch vụ hướng ra internet, tồn tại lâu dài và có gắn cơ sở dữ liệu, nó xứng đáng được đối xử như vậy.

Nơi đặt server vẫn là yếu tố quyết định kết quả cuối cùng

Mọi thứ ở trên đều là cấu hình. Phần mà cấu hình không thể chạm tới là hệ thống pháp luật nào sẽ nhận được yêu cầu liên quan đến người dùng của bạn, và với một server giao tiếp, câu hỏi đó nặng ký hơn nhiều so với một trang web thông thường. Một homeserver lưu giữ ghi chép thành viên, dấu thời gian và dữ liệu sơ đồ quan hệ xã hội ở dạng không mã hóa ngay cả khi nội dung tin nhắn đã được mã hóa — vì vậy thẩm quyền pháp lý nơi đặt server chính là thẩm quyền quản lý quyền truy cập vào ghi chép đó.

Đó là lý do thực tế để bạn chọn một địa điểm một cách có chủ đích, thay vì chỉ dựa vào độ trễ mạng. Chúng tôi vận hành tại bảy nơi, và các đánh đổi giữa chúng được trình bày trong hướng dẫn chọn thẩm quyền pháp lý và trên trang địa điểm. Nửa còn lại của cùng câu hỏi đó là nhà cung cấp biết bạn là ai: một tài khoản không gắn danh tính thì không thể xuất trình giấy tờ tùy thân mà nó chưa từng thu thập, đó chính là lý do đơn giản khiến dịch vụ lưu trữ không KYC và các dịch vụ giao tiếp tự triển khai luôn xuất hiện cùng nhau trong cùng một câu chuyện. Cả hai đều không phải là lá chắn trước một tòa án đã biết tên bạn, và hướng dẫn OpSec của chúng tôi nói thẳng về ranh giới đó nằm ở đâu.

Tóm tắt ngắn gọn

Nếu chỉ nhớ sáu điều từ trang này, hãy nhớ những điều sau:

• Chọn server_name trước khi cài bất cứ thứ gì — đây là quyết định duy nhất bạn không bao giờ sửa lại được.
• Ủy quyền bằng /.well-known/matrix/server hoặc một bản ghi SRV, và giữ TLS hợp lệ trên cả hai tên miền.
• Định cỡ theo số phòng người dùng của bạn sẽ tham gia, chứ không phải theo số người dùng bạn đang có.
• Đặt chính sách lưu giữ media ngay từ ngày đầu, và tự quyết định về việc xem trước liên kết thay vì để mặc định.
• Giữ đăng ký ở trạng thái đóng hoặc yêu cầu token; khôi phục một danh tiếng tên miền đã cháy rất tốn kém.
• Sao lưu signing.key riêng biệt, và không bao giờ đưa cơ sở dữ liệu quay lại phía sau các server ngang hàng của bạn.

Làm được những điều đó, server của bạn sẽ trở nên bình thường đến mức chẳng có gì đáng nói — và đó chính xác là điều một chat server nên như vậy. Thứ bạn nhận lại đáng để nhìn nhận rõ ràng: không phải sự vô hình, cũng không phải một giao thức giấu được ai đang nói chuyện với ai, mà là những cuộc trò chuyện có nội dung thuộc về bạn, một tài khoản không ai khác có thể khóa, và một cỗ máy nằm dưới hệ thống pháp luật mà chính bạn đã chọn một cách có chủ đích. Hãy đặt một homeserver ở nơi bạn tự chọn, và để federation tự tìm đến nó.