Matrix Synapseでフェデレーションを設定する方法：ステップバイステップガイド

マトリックスフェデレーションを使用すると、Synapseホームサーバーが他のホームサーバーとルームイベントを交換できるため、異なるサーバーを使用しているユーザーが同じルームに参加できます。設定するには、SynapseのフェデレーションAPIにHTTPS経由でアクセスできるようにし、適切なサーバー検出情報を公開し、必要なネットワークトラフィックを許可し、公開エンドポイントをテストします。DNS、TLS、またはプロキシルーティングが間違っている場合、Synapseを起動したり、ポート8448を開いたりするだけでは不十分です。

このガイドでは、一般的なリバースプロキシの展開を使用します。Matrix の ID ドメインはexample.org、Synapse はで実行されmatrix.example.org、プロキシはポート 443 で TLS を処理します。両方の例のドメインを独自のものに置き換えてください。Synapse がで HTTPS 経由で既にアクセスできる場合はexample.org:8448、通常、委任は必要ありません。コマンドとファイルパスは、Synapse をパッケージ、仮想環境、またはコンテナのいずれからインストールしたかによって異なります。

連邦制が機能するためには、どのような条件が満たされていなければならないのか？

Synapse サーバーには安定したパブリックホスト名がありますserver_name。この名前は、などの Matrix ID に表示されます@alex:example.org。後で変更することは、通常のホスト名編集ではありません。
他のホームサーバーはHTTPS経由でフェデレーションAPIにアクセスし、TLS証明書を検証できます。
サーバー検出機能により、リモートホームサーバーは適切なホストとポートに誘導されます。標準のフェデレーションポートは8448番ですが、委任先は443番ポートのHTTPSに設定できます。
ファイアウォールルールは、選択したフェデレーションエンドポイントへの受信トラフィックと、フェデレーションへの送信接続を許可します。

フェデレーションはサーバー間の通信に関するものです。プライベートルームを自動的に公開したり、他のユーザーを招待したりするものではありません。ユーザーは引き続きルームに参加するか招待される必要があり、ルームメンバーシップとルーム設定によって誰が参加できるかが決まります。まず、Matrix ID をどのようにするかを決め、Synapse と同じドメインを使用しますserver_name。

ステップ1：Synapseサーバー名とデプロイメントを確認する

アクティブを開きhomeserver.yaml、それserver_nameが保持したいドメインであることを確認してください。一般的な構成は次のとおりです。

server_name: "example.org"
public_baseurl: "https://matrix.example.org/"

server_nameは、ユーザーの Matrix ID 内のドメインを決定します。public_baseurlは、クライアントに入力する URL など、クライアントに公開される URL です。リバースプロキシの背後では、プロキシ URL を指定する必要があります。これらは異なる目的で使用されるため、サーバー名をバックエンドコンテナ名に置き換えたり、サブドメインに合わせるためだけに変更したりしないでください。サーバーが既に使用されている場合は、ネットワーク設定を変更する前に、構成とデータベースをバックアップしてください。

Synapseのインストール方法と管理方法を確認してください。systemdサービス、Docker Composeスタック、Kubernetesデプロイメント、マネージドホスティング製品では、再起動手順とネットワーク手順が異なります。以下の例を適切な設定ファイルに適用し、既存のリスナーとカスタム設定はそのまま保持してください。

ステップ2：8448番への直接フェデレーション、または443番への委任を選択します。

連邦への参加には、主に2つのルートがあります。

デフォルトポート8448を使用します。ドメインのDNSをserver_nameサーバーに向け、ポート8448でHTTPSを公開し、そのドメインに有効な証明書を提示します。Synapseのドキュメントによると、指定されたドメインのポート8448でAPIが利用可能な場合server_name、委任は不要です。
委任を使用してポート 443 を使用します。JSONを使用しhttps://example.org/.well-known/matrix/serverて他のサーバーを実際のエンドポイントに誘導します。たとえば{"m.server":"matrix.example.org:443"}、。委任されたホスト名はパブリックに解決され、の有効な証明書を提示する必要がありますmatrix.example.org。

ポート8448は、すべてのデプロイメントで必須ではありません。443への委任を使用している場合、受信フェデレーションでは代わりに443を使用できます。送信接続が送信ファイアウォールによって制限されている場合は、リモートサーバーがどちらのポートも使用する可能性があるため、443と8448の両方を許可してください。受信ルートを1つ選択し、DNSレコード、TLS証明書、リバースプロキシ、およびファイアウォールがそのルートと一致するようにしてください。

ステップ3：SynapseのフェデレーションAPIをリバースプロキシ経由でルーティングする

Synapse は通常、リバースプロキシの背後にある HTTP ポート 8008 でリッスンします。プロキシは HTTPS を終端し、Matrix エンドポイントを Synapse に転送します。該当するhomeserver.yamlリスナーでは、HTTP リスナーにクライアントリソースとフェデレーションリソースの両方を含め、プロキシヘッダーを信頼するように設定してください。

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

これはリスナーの例であり、すべてのインストール環境における完全な構成をそのまま置き換えるものではありません。Synapseがコンテナ内で実行されている場合、127.0.0.1コンテナ内部にバインドすると、プロキシコンテナがSynapseにアクセスできなくなる可能性があります。その場合は、サービスネットワークと適切なバインドアドレスを使用してください。バックエンドリスナーは非公開にし、プロキシのみを意図どおりに公開してください。

プロキシを設定して、/_matrixおよび/_synapse/clientへのリクエストをポート8008に転送し、X-Forwarded-Forおよびを設定しますX-Forwarded-Proto。NGINXの場合、基本的な場所は次のようになります。

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;
}

ホストまたはコンテナネットワークの正しいアップストリームアドレスを使用してください。書き換えられたパスをに追加しないでくださいproxy_pass。Synapse のプロキシガイダンスでは、エンコードされたリクエストパスを正規化すると、フェデレーション署名検証エラーが発生する可能性があると警告しています。ユーザーがより大きなファイルをアップロードする必要がある場合は、プロキシのアップロードサイズ制限を Synapse のメディアアップロード設定に合わせてください。

ステップ4：TLSとDNSを設定する

フェデレーションを提供するホスト名に対して、公開されている信頼できるTLS証明書を取得してください。上記の逆プロキシ設定では、matrix.example.orgそのホストへの委任を使用する場合に該当します。プロキシが完全な証明書チェーンを提供し、証明書を自動的に更新し、リモートサーバーが接続するポートで正しい証明書を提示していることを確認してください。自己署名証明書や誤ったホスト名の証明書は、他のホームサーバーでの検証に失敗します。

パブリック A レコードを作成し、IPv6 を使用する場合はmatrix.example.orgプロキシを指す AAAA レコードを作成します。両方のレコードが目的のサービスに到達することを確認してください。不正な AAAA レコードは、IPv4 が機能している場合でも、IPv6 対応のリモートサーバーで障害を引き起こす可能性があります。ポート 8448 を直接使用する場合は、DNS がexample.orgリスナーを指し、その証明書がと一致する必要がありますexample.org。

ステップ5：サーバー検出情報を公開する

委任の例では、以下の HTTPS URL がステータス 200 と正確なエンドポイントを含む JSON を返すようにしてください。

https://example.org/.well-known/matrix/server

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

として提供してください。ログインなしで公開読み取り可能であること、ループリダイレクトが発生しないこと、ホスト名とポートがTLSプロキシと一致していることを確認してください。プロキシが実際にフェデレーションを別の場所にルーティングする場合は、ファイルにapplication/json公開しないでください。matrix.example.org

serve_server_wellknown: trueSynapse は、リクエストが適切に Synapse にルーティングされた場合にのみ、このファイルを自身で配信できますhttps://<server_name>/。サーバー名がでexample.org、Synapse がでホストされている場合matrix.example.org、の静的 Web サーバーまたはリバースプロキシの方example.orgが、委任応答を配信するのに適した場所となることがよくあります。

よくある誤解として、サーバーファイルとクライアントファイルを同じものとして扱うことが挙げられます/.well-known/matrix/client。/.well-known/matrix/serverサーバーファイルは、他のホームサーバーが受信したフェデレーションを検出するのに役立ちます。クライアントファイルは、クライアント向けのホームサーバーのURLを公開するもので、フェデレーションには必須ではありません。互換性のあるクライアントがユーザーのMatrix IDからクライアントURLを検出できるようにする場合にのみ、クライアントファイルを別途設定してください。

ステップ6：必要なファイアウォールパスを開く

直接フェデレーションの場合は、TLSリスナーまたはプロキシへの受信TCP 8448を許可します。委任の例では、プロキシへの受信TCP 443を許可します。クライアント接続は通常、443番ポートでHTTPSを使用します。送信ネットワークアクセスが制限されている場合は、SynapseがTCP 443番ポートと8448番ポートを介してリモートホームサーバーに接続できるようにします。リバースプロキシがパブリックエントリポイントとなる場合は、Synapseバックエンドポート8008をパブリックインターネットに開放しないでください。

サーバーがクラウドファイアウォール、ルーター、コンテナネットワーク、ホストファイアウォールの背後にある場合は、各レイヤーを確認してください。ポート8008へのローカルリクエストが成功したとしても、それはSynapseがローカルで応答することを示しているだけであり、リモートのMatrixサーバーがドメインを解決したり、TLSを検証したり、パブリックリスナーに到達できることを示しているわけではありません。

ステップ7：安全に再起動し、公開エンドポイントを確認します。

再起動する前に、インストール方法でサポートされている検証コマンドを使用してYAMLを検証してください。その後、Synapseサービスまたはデプロイメントを再起動し、ログを確認して構成エラーまたはリスナーエラーがないか確認してください。プライベートネットワーク外のマシンから、検出ファイルとフェデレーションバージョンのエンドポイントを要求してください。

curl -i https://example.org/.well-known/matrix/server
curl -i https://matrix.example.org/_matrix/federation/v1/version

最初のコマンドでは、正しい情報を含むJSONボディを持つHTTPSレスポンスが返されるはずですm.server。2番目のコマンドでは、プロキシエラー、証明書警告、接続タイムアウトではなく、Synapseからの正常なHTTPSレスポンスが返されるはずです。レスポンスボディの正確な内容は、Synapseのバージョンによって異なる場合があります。

次に、 Matrix Federation TesterにMatrix （プロキシホスト名である必要はありません。server_name例えば、）を入力します。報告された DNS、委任、証明書、またはエンドポイントのエラーを修正し、テストを再度実行します。最後に、別のホームサーバーのユーザーをテストルームに招待するか、別の場所でホストされているルームに参加します。テストが成功すれば、パブリック接続のチェックとして役立ちますが、すべてのリモートサーバー、ルームポリシー、ファイアウォール、またはクライアント構成が同じように動作することを保証するものではありません。example.org

誤解が、設定の不具合や予期せぬ事態につながる

「ポート8448は常に公開しなければならない。」いいえ。デフォルトは8448ですが、サーバー委任によって受信フェデレーションを443にルーティングできます。公開したディスカバリルートで実際に使用するポートを開いてください。
「クライアントの既知のファイルによってフェデレーションが可能になります。」いいえ、そうではありません。フェデレーションの検出には、サーバーの既知のエンドポイントまたはサポートされているDNSフォールバックが使用されます。クライアントのエンドポイントは別の目的で使用されます。
「フェデレーションによって、すべてのローカルルームが公開される」というのは間違いです。フェデレーションはサーバー間の通信を可能にするものであり、ルームの可視性とメンバーシップによって参加が制御されます。必要なユースケースを確認するには、テストルームにリモートアカウントを招待してください。
「ローカルヘルスチェックで緑色のチェックが出れば、フェデレーションが証明される」というのは間違いです。ローカルチェックでは、パブリックDNS、外部TLS検証、NAT、クラウドファイアウォールルール、プロキシルーティングはテストされません。外部からテストを行い、フェデレーションテスターを使用してください。

Synapseの公式ドキュメントでは、TLS終端にリバースプロキシを使用することを推奨しており、クライアントポートとフェデレーションポートが別々に必要であることを説明しています。リバースプロキシの設定、受信フェデレーション委任、Synapseの設定オプション、ファイアウォールとセキュリティに関するガイダンスについては、公式ガイドを参照してください。サーバー検出ルールについては、Matrix Server-Server API仕様を参照してください。ここでの例では、HTTPSリバースプロキシの背後にある標準のSynapseを想定しています。コンテナネットワーク、マネージドデプロイメント、カスタマイズされたリスナーレイアウトでは、異なる値が必要になる場合があります。