Установка собственного matrix сервера

Данная статья описывает установку собственного сервера matrix, который будет работать в общей федеративной сети серверов матрикс, но к которому доступ клиентов будет только из сети yggdrasil. При этом все фишки типа «Персональных сообщений» и «Шифрованных комнат» также будут работать

Если вам не нужна связность с другими серверами - ставьте сервер в режиме standalone и не мучайтесь

• Во первых Matrix является федеративной сетью. Т.е. подразумевается что каждый из серверов может напрямую общаться с другими, при этом никаких Relay серверов не предусмотрено. Т.е. сервер должен иметь «белый» адрес (заметка на полях - людей, у которых есть только «белый» IPv6 адрес, ждут примерно аналогичные страдания).
• Во вторых обязательно используются SSL сертификаты.
• Соответственно, в третьих, обязательно используются «белые» домены (т.е. домены, на который такой сертификат может быть выписан).

То есть, если вы хотите поднять сервер, который будет иметь возможность общаться с другими серверами в сети - он должен соответствовать этим трём требованиям.

К счастью, предусмотрена ситуация когда есть домен example.com но сервер разместить под этим именем возможности нет. Зато есть возможность разместить его под именем server.example.com. Вот, собственно, этой возможностью мы и воспользуемся.

И так, что нам потребуется:

Ну, собственно, потребуется машина для установки самого сервера Matrix.

У этой машины должен быть выход в клирнет. Доступ к этой машине нужен только со стороны прокси, т.е. она вполне может сидеть где-то внедрах сети за NAT.

Домен может быть любым, который Вам доступен. Главное - он должен быть «белым» (т.е. резолвиться из клирнета) и у Вас должна быть возможность вносить туда записи. Я использовал для этого twinkle.ygg.at

Так же Вам потребуется имя для прокси сервера с белым адресом. Если вы использовали как основной домен .ygg.at вас ждёт неприятность - в этом домене нельзя указать какой либо IP кроме yggdrasil. Если вы используете что-то типа mybestowndomain.com - вам никто не мешает сделать для этого имя server.mybestowndomain.com. Я использовал ygg.twinkle.lol

Этот адрес дожен быть прописан на основном домене, который вы выбрали в прошлом пункте. У меня это 300:dada:feda:f443::12

Этот адрес должен быть назначен как «внешний» на прокси сервере. Никаких особенных требований, ну кроме того, что как минимум должен быть открыты порты 443 и 8448 на вход. У меня это 193.111.115.214

Так как у нас на основном домене используется «серый» адрес, получить SSL по простому - не получится. Нужно будет получать через «DNS авторизацию». Я пользуюсь для этого вот этим плагином для certbot.

ВАЖНО
Если вы будете пользоваться этим плагином - он вам выведет строчку, которую нужно прописать в DNS. Если, при этом, вы пользуетесь доменом .ygg.at, при прописывании его в Alfis от имени оставьте только _acme-challenge а в самом CNAME уберите последнюю точку (должно получиться .auth.acme-dns.io в конце). От этой точки alfis шизеет.

• Ставим сервер Matrix. Подробности я опущу - весь интернет завален описанием этой процедуры
• Прописываем для основного домена «серый» IP адрес.
• Прописываем для прокси «белый» IP адрес.
• Получаем тем или иным способом SSL сертификат на основной домен.
• Не обязательно, но лучше сделать - получаем SSL сертификат на прокси сервер. Я ниже расскажу зачем.
• Добавляем в основной домен такие строки (у Вас они, понятно, будут другие):

  _matrix._tcp SRV 1 1 8448 ygg.twinkle.lol
  _matrix-fed._tcp SRV 1 1 8448 ygg.twinkle.lol

  Обратите внимание, тут должно быть указанно именно имя а не адрес. Именно по этому у прокси сервера должно быть имя. Почему их две? Потому что первая - depricated.

• Настраиваем прокси сервер. Нам нужно прописать конфиг для двух хостнеймов, основного и прокси. У меня это выглядит так (у меня nginx, если у Вас что-то другое - делайте по аналогии): Основной домен

  twinkle.ygg.at

  server {
      listen [300:dada:feda:f443::12]:443 ssl;
      listen [300:dada:feda:f443::12]:8448 ssl;
      server_name twinkle.ygg.at;
  
      ssl_certificate /etc/letsencrypt/live/twinkle.ygg.at/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/twinkle.ygg.at/privkey.pem;
      client_max_body_size 1000M;
  
      location /_matrix {
          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 X-Real-IP $remote_addr;
          proxy_set_header Host $host;
          client_max_body_size 500M;
      }
  
      location /.well-known/matrix/client {
          return 200 '{"m.homeserver": {"base_url": "https://twinkle.ygg.at"}}';
          add_header Content-Type application/json;
          add_header Access-Control-Allow-Origin *;
      }
  }
  
  server {
      listen 193.111.115.214:443 ssl;
      listen 193.111.115.214:8448 ssl;
      server_name twinkle.ygg.at;
  
      ssl_certificate /etc/letsencrypt/live/twinkle.ygg.at/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/twinkle.ygg.at/privkey.pem;
      client_max_body_size 1000M;
  
      location /_matrix/client {
          return 404;
      }
  
      location /_matrix {
          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 X-Real-IP $remote_addr;
          proxy_set_header Host $host;
          client_max_body_size 500M;
      }
  
      location /.well-known/matrix/client {
          return 200 '{"m.homeserver": {"base_url": "https://twinkle.ygg.at"}}';
          add_header Content-Type application/json;
          add_header Access-Control-Allow-Origin *;
      }
  }
  

  Прокси:

  ygg.twinkle.lol

  server {
      listen 193.111.115.214:443 ssl;
      listen 193.111.115.214:8448 ssl;
      listen [300:dada:feda:f443::12]:443 ssl;
      listen [300:dada:feda:f443::12]:8448 ssl;
      server_name ygg.twinkle.lol;
  
      ssl_certificate /etc/letsencrypt/live/ygg.twinkle.lol/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/ygg.twinkle.lol/privkey.pem;
      client_max_body_size 1000M;
  
      location /_matrix/client/ {
          return 404;
      }
  
      location /_matrix {
          proxy_pass http://[322:a76c:9a9e:5085:1::8]:8008;
          proxy_set_header X-Forwarded-For $remote_addr;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header Host $host;
          client_max_body_size 500M;
      }
  
      location /.well-known/matrix/client {
          return 200 '{"m.homeserver": {"base_url": "https://twinkle.ygg.at"}}';
          add_header Content-Type application/json;
          add_header Access-Control-Allow-Origin *;
      }
  }

Собственно - на этом можно было-бы ставить точку. Правильно собранное устройство в дополнительной настройке не нуждается. Но я обещал рассказать зачем SSL на имя прокси, да и вобще стоит описать происходящее. И так…

Сервер приходит в домен twinkle.ygg.at за srv записью, получает её и идёт на прокси сервер ygg.twinkle.lol (с основным доменом в урле, кстати, а вовсе не с проксёвым). И дальше сервера спокойно между собой общаются. Соответственно на прокси не должен никто приходить с его именем. Клиент из белой сети приходит в домен twinkle.ygg.at, получает ygg адрес и плача уходит. Клиент из ygg приходит в домен twinkle.ygg.at, получает ygg адрес и радостно работает.

Сервер приходит в домен twinkle.ygg.at и сначала пытается получить /.well-known/matrix/server. Не может. Пытается получить новый вариант SRV. Если не может - пытается получить старый. Дальше он идёт на указанный прокси, и общается с ним, в основном, по правильному имени основного домена. Но иногда, некоторые серверы, некоторые запросы шлют на доменное имя прокси сервера. Именно по этому лучше получить SSL на это имя и обрабатывать запросы и на него. Но так как мы не хотим, что-бы клиенты из белой сети могли заходить на наш сервер - мы рубим на корню клиентское API.

Вот теперь - действительно всё.