フェデレーションが実際に機能する Matrix ホームサーバー

これで作られるもの

example.comのホームサーバーで、matrix.example.com上で動作し、他のすべてのサーバーと適切に連合します。内部はPostgres、前面はnginx、委任は2つの小さなJSONファイルで処理され、登録は閉じられているため、あなたのサーバーが1週間以内に誰かの無料リレーになることはありません。

連合は、これらのインストールが通常失敗する箇所であり、その原因がSynapseであることはほとんどありません。サーバーは動作し、ローカルメッセージは機能しますが、外部からのメッセージは届きません。実際には、原因はほとんどの場合、委任です。サーバーのアイデンティティと、それが存在するアドレスは別物であり、それらを結びつけるメカニズムは、微妙に間違えやすいのです。

始める前に

• R-4は数十人のユーザーには十分です。SynapseはCPUではなくメモリを多く消費し、大規模な連合ルームに参加することが、唯一サーバーに負荷をかける操作です。
• DNSに2つの名前: example.comはサーバーのアイデンティティであり、すべてのユーザーIDに表示されます。matrix.example.comは、ソフトウェアが実際にリッスンする場所です。
• 両方の証明書。最初のものは、2つの静的ファイルを提供するためだけに必要です。

1. データベース、正しい照合順序で

apt update && apt install -y postgresql matrix-synapse nginx certbot
sudo -u postgres psql -c "CREATE USER synapse_user WITH PASSWORD '<a long password>';"
sudo -u postgres psql -c "CREATE DATABASE synapse ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C' TEMPLATE=template0 OWNER synapse_user;"

照合順序は細部ではありません。Synapseは、C以外の照合順序で作成されたデータベースでは起動を拒否し、この設定を間違えたときに表示されるエラーは、データをインポートした後に発生します。今、正しく、一度だけ行ってください。

2. ホームサーバー設定

Debianのパッケージはインストール中にサーバー名を尋ねます。example.comと答え、マシンのホスト名ではないことに注意してください。この回答は、サーバー上のすべてのユーザーIDとルームIDの一部となり、後で変更することはできません。サーバーを放棄しない限り。

次に/etc/matrix-synapse/homeserver.yamlを編集します:

server_name: "example.com"
public_baseurl: "https://matrix.example.com/"
pid_file: /run/matrix-synapse.pid

listeners:
  - port: 8008
    tls: false
    type: http
    x_forwarded: true
    bind_addresses: ['127.0.0.1']
    resources:
      - names: [client, federation]
        compress: false

database:
  name: psycopg2
  args:
    user: synapse_user
    password: "<a long password>"
    database: synapse
    host: 127.0.0.1
    cp_min: 5
    cp_max: 10

enable_registration: false
registration_shared_secret: "<a long random string>"
report_stats: false
suppress_key_server_warning: true
url_preview_enabled: false

media_store_path: /var/lib/matrix-synapse/media
max_upload_size: 100M
media_retention:
  remote_media_lifetime: 30d

rc_message:
  per_second: 0.5
  burst_count: 15

これらの設定のうち2つは、ディスクと苦労を節約します。リモートメディアの保持は、他のサーバーのファイルのキャッシュコピーを1ヶ月後に破棄します。これがないと、メディアストアは、あなたが要求したことのないコンテンツで永遠に成長し続けます。URLプレビューはオフにします。これは、あなたのサーバーがリンクを投稿できる人の代わりに任意のアドレスを取得するようになり、チャットインターフェースが付いたリクエスト伪造エンジンになるためです。

x_forwarded: trueも重要です。これがないと、Synapseはすべてのリクエストがnginxから来ているように見えるため、世界中のすべてのユーザーを1人のクライアントとしてレート制限します。

3. 委任

あなたのアイデンティティはexample.comで、サーバーはmatrix.example.comにあります。2つのファイルがギャップを埋めます。example.comからHTTPSで、正しいコンテンツタイプで提供してください。

/.well-known/matrix/server:

{ "m.server": "matrix.example.com:443" }

/.well-known/matrix/client:

{ "m.homeserver": { "base_url": "https://matrix.example.com" } }

最初のファイルのポートは必須です。省略すると、他のサーバーはポート8448にフォールバックし、何もリッスンしていないため、静かに諦めます。するとユーザーは連合が壊れていると報告しますが、マシン上のすべてのログは健全に見えます。

server {
  listen 443 ssl;
  server_name example.com;
  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  location /.well-known/matrix/ {
    root /var/www/wellknown;
    default_type application/json;
    add_header Access-Control-Allow-Origin *;
  }
}

server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name matrix.example.com;
  ssl_certificate     /etc/letsencrypt/live/matrix.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/matrix.example.com/privkey.pem;
  client_max_body_size 100m;

  location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://127.0.0.1:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
  }
}

well-knownロケーションのAccess-Control-Allow-Originヘッダーは、Webクライアントに必要ですが、ほぼ全員が忘れています。これがないと、デスクトップクライアントは動作しますが、ブラウザクライアントはあなたのサーバーをまったく見つけられません。

mkdir -p /var/www/wellknown/.well-known/matrix
systemctl restart matrix-synapse nginx

4. ユーザー

register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://127.0.0.1:8008

プロンプトに答え、最初のアカウントを管理者にし、オープン登録はオフのままにしてください。オープン登録のホームサーバーは、数日以内にスパムの発生源となり、他のサーバーはあなたが気付くずっと前にあなたのトラフィックを拒否し始めます。

確認する

外側から確認します。まず、ソフトウェアが応答しているか:

curl -s https://matrix.example.com/_matrix/client/versions | head -c 200
curl -s https://matrix.example.com/_matrix/federation/v1/version

次に、委任が正しく提供されているか、ポートが存在し、コンテンツタイプが正しいか:

curl -si https://example.com/.well-known/matrix/server | grep -E "content-type|m.server"
curl -s https://example.com/.well-known/matrix/client

次に、署名キーが解決されるか。他のサーバーは、あなたと通信する前にこれを取得します:

curl -s https://matrix.example.com/_matrix/key/v2/server | head -c 300

最後に、唯一のテストが重要です。クライアントでログインし、あなたのサーバーではないホームサーバーがホストする公開ルームに参加し、メッセージを送信します。その後、クライアントの設定に表示されるアクセストークンを使用して、管理APIから連合状態を読み取ります:

curl -s -H "Authorization: Bearer <admin token>" \
  "https://matrix.example.com/_synapse/admin/v1/federation/destinations" | head -c 400

各宛先は、最近の成功したトランザクションと再試行間隔がないことを示すはずです。retry_intervalが増加している宛先は、到達できないサーバーです。すべての宛先がそのように見える場合、問題はネットワークではなく委任であり、ステップ3を確認してください。

journalctl -u matrix-synapse --since "10 min ago" | grep -i "federation" | tail -20

その後

非常に大きなルームに初めて参加すると、コアが数分間ピン留めされ、大量の状態が取り込まれます。これは正常で、ルームごとに1回発生し、Synapseが遅いと結論付ける主な理由です。音声とビデオには、これに加えてTURNサーバーが必要です。同じインスタンスのcoturnは小さなコミュニティを処理できますが、ファイアウォールで独自のUDPポート範囲が必要です。連合は双方向でチャット量が多いため、サイトを選ぶ際には覚えておく価値があります。私たちのロケーションインデックスには、私たち自身が測定したラウンドトリップタイムがリストされています。