howto-db/data/pages/yggdrasil/matrix_server.txt
2024-02-10 12:53:55 +00:00

154 lines
12 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

====== Установка собственного 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**
==== "Серый" (ygg) адрес ====
Этот адрес дожен быть прописан на основном домене, который вы выбрали в прошлом пункте. У меня это **300:dada:feda:f443::12**
==== Белый IP адрес ====
Этот адрес должен быть назначен как "внешний" на прокси сервере. Никаких особенных требований, ну кроме того, что как минимум должен быть открыты порты 443 и 8448 на вход. У меня это **193.111.115.214**
==== SSL сертификат ====
Так как у нас на основном домене используется "серый" адрес, получить SSL по простому - не получится. Нужно будет получать через "DNS авторизацию". Я пользуюсь для этого вот этим [[https://github.com/joohoi/acme-dns-certbot-joohoi/|плагином для certbot]].
^:!: ВАЖНО^
|Если вы будете пользоваться этим плагином - он вам выведет строчку, которую нужно прописать в DNS. Если, при этом, вы пользуетесь доменом **.ygg.at**, при прописывании его в Alfis от имени оставьте только **_acme-challenge** а в самом CNAME уберите последнюю точку (должно получиться **.auth.acme-dns.io** в конце). От этой точки alfis шизеет.|
===== Собираем всё в кучу =====
* Ставим сервер Matrix. Подробности я опущу - весь интернет завален описанием этой процедуры
* Прописываем для основного домена "серый" IP адрес.
* Прописываем для прокси "белый" IP адрес.
* Получаем тем или иным способом SSL сертификат на основной домен.
* :!: **Не обязательно, но лучше сделать** - получаем SSL сертификат на прокси сервер. Я ниже расскажу зачем.
* Добавляем в основной домен такие строки (у Вас они, понятно, будут другие):<code>
_matrix._tcp SRV 1 1 8448 ygg.twinkle.lol
_matrix-fed._tcp SRV 1 1 8448 ygg.twinkle.lol
</code>Обратите внимание, тут должно быть указанно именно имя а не адрес. Именно по этому у прокси сервера должно быть имя. Почему их две? Потому что первая - depricated.
* Настраиваем прокси сервер. Нам нужно прописать конфиг для двух хостнеймов, основного и прокси. У меня это выглядит так (у меня nginx, если у Вас что-то другое - делайте по аналогии): Основной домен <file - 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 *;
}
}
</file>Прокси:<file - 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 *;
}
}
</file>
Собственно - на этом можно было-бы ставить точку. **Правильно собранное устройство в дополнительной настройке не нуждается.** Но я обещал рассказать зачем 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.
----
Вот теперь - действительно всё.
~~DISCUSSION~~