Вот есть у меня арендованный сервер, и я хочу иметь его резервную копию. Ясное дело, владелец площадки мне такую копию дать не может или не хочет, что для меня непринципиально. Однако есть же Veeam Backup & Replication! Версия Community вполне себе для домашнего пользования подходит. Однако ж, сервер veeam находится за NAT, а сервер в аренде – в интернете. И при попытке сделать резервную копию, получаем ошибку “failed to connect to the endpoint”. Кроме того, видно, что клиент упорно пытается использовать серый адрес сервера. Как же это победить??
Официально – никак. Сервер и клиент должны находиться в одной напрямую маршрутизируемой сети. NAT не поддерживается. Всё, все свободны. Ладно, шучу – всё не так ужасно, мы же всё же в 21 веке живем. Способа есть два.
Один способ – надо просто сделать так, чтобы оба хоста оказались в одной сети. Как? VPN же! В моем случае, OpenVPN Access Server, который был поднят триста лет назад для… Ну, в общем, нужен 🙂 Однако, если бы всё было совсем просто, этой статьи не было бы.
Как поднять подобный сервер и как спрятать его управлялку, я уже вроде писал. Для нас сейчас важно, что сервер живет в режиме “выпускаем интернет через себя всех, кто авторизовался”. Однако, для пары сервер-клиент veeam такой режим не подходит. Кроме того, сервер обслуживает разных людей и перемешивать их между собой не стоит, наверное.
Итак, первое – заводим отдельную группу доступа, что позволит не только удобно и просто изолировать серверные учётки, но и управлять параметрами массово. Если заморачиваться с отдельной группой лениво или вдруг почему-то нет нужды – можно сразу переходить к созданию учетных записей.
В параметрах группы ставим галочку «Allow Auto-login», чтобы соединение могло устанавливаться без лишних запросов. Плюс, указываем отдельную подсеть для учёток и диапазон для автоматической выдачи. Далее, создаём учетные записи – логин, пароль посложнее, группу доступа и статический адрес из выбранной подсети, поскольку на DNS надеяться не приходится. На стороне сервера OpenVPN AS, в принципе, все настройки завершены.
Переходим к настройке клиентской части. Заходим в веб-морду нашего сервера и вытягиваем autologin profile для обоих серверов. После чего заходим в сохраненные файлы и добавляем строчку route-nopull, которая говорит клиенту наплевать с высокой колокольни на все маршруты, которые пытается навязать сервер вообще и на default route в частности. Файлу для *nix-сервера сразу меняем расширение на .conf
Для windows – примерно вот отсюда качаем клиентскую часть и сразу ставим её. Необходимые компоненты типа tap-адаптера уже включены в дистрибутив и установятся сами. Далее заходим в службы и убеждаемся, что OpenVPNService запускается автоматически вместе с системой. Скачанный файл с профилем кладем в \Program Files\OpenVPN\config-auto и можно проверять – перезапускаем руками службу или перезагружаем ПК. Туннель должен подняться и комп должен получить ранее указанный адрес. В интернет ПК при этом должен ходить НЕ через OpenVPN.
Вторую часть я делал на CentOS, поэтому инструкция будет для неё. Добавляем репозиторий EPEL и ставим оттуда OpenVPN
sudo yum install epel-release
sudo yum install openvpnФайл с профилем, у которого мы уже сменили расширение, кладем в каталог /etc/openvp, добавляем сервис в автозапуск и, собственно, запускаем его. Для файла с именем my_server_profile.conf строчка будет выглядеть примерно следующим образом:
sudo systemctl enable openvpn@my_server_profile
sudo systemctl start openvpn@my_server_profile
Должен появиться новый интерфейс с заданным ранее адресом.
Второй способ найден на форумах Veeam’а и несколько сомнителен, на мой взгляд. На роутере TCP настраиваем прямой проброс портов 10001,10005,10006, 49152-65535,2500-5000 на машину с Veeam и на самом хосте вторым адресом добавляем внешний белый адрес с маской /32. Если серверов используется несколько, всё это делаем для сервера с ролью Veeam Backup Proxy. Из минусов – порты, которые входят в список, могут уже использоваться для каких-нибудь нужд. Кроме того, надо не забывать менять второй адрес на хосте с Veeam’ом.