12개 구축

페더레이션이 실제로 작동하는 Matrix 홈서버

소형 Ryzen 인스턴스에서 Postgres와 함께 Synapse, SRV 레코드 대신 well-known 파일을 통한 위임, 그리고 다른 서버에 도달하는 검증.

이 빌드가 만드는 것

example.com의 홈서버, matrix.example.com에서 실행되며 다른 모든 서버와 제대로 연합됩니다. PostgreSQL이 뒤에서, nginx가 앞에서, 위임은 두 개의 작은 JSON 파일로 처리하며, 등록은 닫혀 있어서 서버가 일주일 안에 누군가의 무료 릴레이가 되지 않습니다.

연합은 이런 설치에서 보통 실패하는 부분이며, 거의 항상 Synapse 때문은 아닙니다. 서버는 실행되고, 로컬 메시지는 작동하지만, 외부에서 아무것도 도착하지 않습니다. 실제로 원인은 거의 항상 위임입니다: 서버의 정체성과 서버가 살고 있는 주소는 서로 다른 두 가지이며, 이 둘을 연결하는 메커니즘은 미묘하게 잘못되기 쉽습니다.

시작하기 전에

  • R-4는 수십 명의 사용자에게 충분합니다. Synapse는 CPU보다 메모리를 많이 사용하며, 큰 연합 방에 참여하는 것이 유일하게 부하를 주는 일입니다.
  • DNS에 두 개의 이름: example.com는 서버의 정체성이며 모든 사용자 ID에 나타나고, matrix.example.com는 소프트웨어가 실제로 수신 대기하는 곳입니다.
  • 두 이름 모두에 대한 인증서. 첫 번째는 두 개의 정적 파일을 제공하는 데만 필요합니다.

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

그 설정 중 두 가지는 디스크와 고통을 아껴줍니다. 원격 미디어 보존은 다른 서버의 파일 캐시를 한 달 후에 삭제하며, 이 설정이 없으면 미디어 저장소는 요청한 적 없는 콘텐츠로 영원히 커집니다. URL 미리보기는 링크를 게시할 수 있는 사람을 대신해 서버가 임의의 주소를 가져오게 만들기 때문에 꺼져 있으며, 이는 채팅 인터페이스가 붙은 요청 위조 엔진입니다.

x_forwarded: true도 중요합니다. 이것이 없으면 Synapse는 모든 요청이 nginx에서 온 것처럼 보이기 때문에 전 세계의 모든 사용자를 하나의 클라이언트로 취급하여 속도를 제한합니다.

3. 위임

당신의 정체성은 example.com이고 서버는 matrix.example.com에 있습니다. 두 개의 파일이 차이를 메웁니다. https://example.com에서 올바른 콘텐츠 유형으로 제공하십시오.

/.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 헤더는 웹 클라이언트에 필요하며 거의 모든 사람이 잊습니다. 이것이 없으면 데스크톱 클라이언트는 작동하지만 브라우저 클라이언트는 서버를 전혀 찾을 수 없습니다.

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

이후

매우 큰 방에 처음 참여하면 몇 분 동안 코어가 고정되고 많은 상태를 가져옵니다. 이는 정상이며, 방당 한 번 발생하며, 사람들이 Synapse가 느리다고 결론 내리는 주요 이유입니다. 음성 및 화상 통화에는 이 서버와 함께 TURN 서버가 필요합니다. 같은 인스턴스의 coturn은 소규모 커뮤니티를 처리하지만, 방화벽에 자체 UDP 포트 범위가 필요합니다. 연합은 양방향으로 수다스럽기 때문에 사이트를 선택할 때 기억할 가치가 있습니다: 우리의 위치 색인은 우리가 직접 측정한 왕복 시간을 나열합니다.

준비 완료

도시를 고르고, 크기를 고르고, 코인으로 결제하세요.

신원 확인 양식도, 승인을 기다리는 담당자도, 검증을 위한 전화도 없습니다. 청구서가 결제되면 자격 증명이 받은 편지함에 도착합니다.