Я уже рассказывал ранее, что у меня на дублирующем сервере с мониторингом Gatus перестали работать уведомления на Telegram, потому что заблокировали д…

Я уже рассказывал ранее, что у меня на дублирующем сервере с мониторингом Gatus перестали работать уведомления на Telegram, потому что заблокировали доступ к api.telegram.com. Я всё думал, как лучше решить эту проблему. Изначально планировал перейти на что-то вроде ntfy.sh или gotify. В итоге не захотелось поддерживать ещё один сервис. Пошёл по самому простому пути.

У меня все служебные виртуалки объединены в единую сеть с помощью, как это ни странно, openvpn (управляющий сервер располагается в Москве). Я не буду ничего пояснять, скажу только, что у меня она везде, где мне надо, работает. Технические моменты, к сожалению, описывать нельзя, это в наше время незаконно. Так что заметка будет по сути про маршрутизацию в openvpn.

В этой сети обычно есть 1-2 машины с полным доступом к Telegram. В openvpn удобно устроена маршрутизация. Там по сути есть собственная реализация динамической маршрутизации. На сервере с мониторингом я настроил маршруты к api.telegram.com через виртуалку, где этот доступ есть.

Покажу, как это реализовано на практике. Как по мне, так это очень удобно. Те, кто плотно не работает с openvpn, может просто не знать, как это может быть реализовано для совершенно разных задач, не только для описываемой.

В виртуалке с мониторингом я добавил маршруты к api телеги через tun интерфейс, а в качестве шлюза указал IP адрес openvpn сервера:

91.108.4.0/22 via 10.8.0.1 dev tun1
91.108.8.0/22 via 10.8.0.1 dev tun1
91.108.12.0/22 via 10.8.0.1 dev tun1
91.108.16.0/22 via 10.8.0.1 dev tun1
91.108.20.0/22 via 10.8.0.1 dev tun1
91.108.56.0/22 via 10.8.0.1 dev tun1
149.154.160.0/22 via 10.8.0.1 dev tun1
205.172.60.0/22 via 10.8.0.1 dev tun1

Все свои IP адреса Telegram публикует у себя на сайте. Больше мы сервер мониторинга трогать не будет. На нём маршруты остаются неизменны. Он просто будет отправлять все запросы в приватную сеть. Дальнейшей маршрутизацией будет заниматься openvpn сервер.

Клиент, который имеет доступ к api телеграма, подключается к openvpn серверу со следующими параметрами:

iroute 91.108.4.0 255.255.252.0
iroute 91.108.8.0 255.255.252.0
iroute 91.108.12.0 255.255.252.0
iroute 91.108.16.0 255.255.252.0
iroute 91.108.20.0 255.255.252.0
iroute 91.108.56.0 255.255.252.0
iroute 149.154.160.0 255.255.240.0
iroute 205.172.60.0 255.255.252.0

То есть он объявляет, что за эти маршруты отвечает он и все запросы надо отправлять ему. Параметры эти хранит сервер и выдаёт на основании сертификата клиента, с которым тот подключается.

Вот, собственно, и всё. Если нам нужно сменить клиента, мы просто арендуем новую VPS. Настраиваем там подключение к openvpn серверу. Он подключается и объявляет, что за указанные маршруты отвечает он. Об этом узнаёт сервер и все запросы от других клиентов он будет адресовать сюда.

Я ничего подобного не знаю у других реализаций серверов приватных сетей. Обычно нужно отдельно настраивать OSPF или что-то подобное поверх настроенных туннелей. С одной стороны это более универсальный подход, когда каждый решает одну поставленную задачу, но с другой стороны в простых ситуациях и не очень больших сетях, реализация на базе openvpn проще в настройке и поддержке.

Подобную маршрутизацию я обычно использую при объединении распределённой сети филиалов. Один раз их настроил, отправил нужные подсети в туннель и больше не трогаешь. Сервер openvpn сам знает, в какой филиал отправить тот или иной запрос. Всё это управляется централизованно на сервере.

#openvpn