Несколько remote в OpenVPN: список failover, а не объединение каналов

Две строки remote в одном профиле выглядят как вторая полоса; на деле это вторая попытка. Когда первый endpoint перестаёт отвечать, клиент переходит дальше, и сеанс не становится шире. Назовите список failover сразу, иначе будете крутить не ту ручку.

Что даёт список remote

Считайте профиль упорядоченным набором попыток, а не пулом ёмкости. Каждая запись получает свой ход на подъём туннеля, а сеанс живёт на той, что ответила. Более длинный список повышает шансы подключиться, а не размер трубы.

Настоящая агрегация — другая машина. Чтобы разнести один поток по нескольким путям, нужен софт на обоих концах, который разделит и соберёт трафик обратно по порядку.

Поставщик, обещающий более быстрые туннели с большего числа серверов, продаёт именно вторую модель, а не длинный список. Если клиент только перебирает endpoint по очереди, пять записей меняют шансы и ничего больше. Посмотрите на сбой: сеанс падает и возвращается в другом месте, и в журнале это новый endpoint, а не более широкая труба.

Блоки, которые держат настройки при одном endpoint

Обычная строка remote несёт адрес, а иногда порт и протокол. Когда endpoint нужен прокси или транспорт, который не использует остальная часть файла, положите эти настройки в блок соединения, который держит их вместе с ним. Встроенные блоки работают и в одном файле .ovpn, и именно так поставляется большинство профилей.

Всё вне блока действует как значение по умолчанию для записей, которые его не перекрывают. Поэтому один собранный блок и четыре обычных remote ведут себя так, что список адресов этого не объяснит.

Удаление блока, который вы не узнаёте, — не косметика. Endpoint, которому он принадлежал, возвращается к значениям файла по умолчанию, а они могут быть другим транспортом, чем тот, на котором он слушает. Уберите неверную обёртку, и одна запись откажет, пока остальные работают, поэтому это выглядит как плохой сервер, а не сломанный профиль. Прочитайте каждый remote вместе с его транспортом, портом и прокси перед правкой.

Порядок повторов и цена remote-random

Порядок важен, потому что каждая мёртвая запись стоит времени до следующей попытки. Поставьте нужный endpoint первым, а остальные считайте ранжированными запасными.

remote-random перемешивает стартовый порядок: нагрузка расходится по равноценным серверам, но при явно главном endpoint это бьёт в обратную сторону. В любом случае фиксируйте в журнале endpoint, выбранный клиентом; имя профиля ничего не говорит, когда соединение кажется медленным. Поиск строки соединения в подробном журнале показывает, куда приземлился сеанс.

Смешивание операторов ломает заявление о доверии

Профиль — это ещё и заявление об идентичности: эти адреса и есть услуга, к которой вы хотели попасть, и закреплённый сертификат принадлежит ей. Если бросить в этот файл бесплатные публичные серверы, заявление ломается: их сертификаты и ваш описывают разные услуги. Обычный исход — сбой идентичности или учётные данные, предложенные хосту вне сети вашего провайдера. Держите альтернативы внутри набора, который распространяет ваш оператор, с совпадающими учётными данными и материалом доверия.

Если вам нужны endpoint от двух провайдеров, это маршрутизация, а не правка профиля. Решите это над туннелем, где можно сказать, какой трафик идёт каким путём.

Проверяйте каждую запись, а не предполагайте

После одобренного обновления профиля намеренно подключитесь к каждому нужному endpoint и подтвердите, какой транспорт поднялся. Подробный запуск делает это видимым. Запустите openvpn --config office.ovpn --verb 4 и прочитайте строку соединения для ожидаемого адреса. Затем проверьте ресурсы за туннелем; запись может завершить рукопожатие и всё равно никуда вас не направить.

Failover требует собственной проверки, а не надежды. Заблокируйте первый endpoint в лаборатории, запустите клиент и замерьте, сколько времени нужно, чтобы перейти дальше. Длинный список за медленной первой записью хуже короткого, который хорошо стартует.

Перепроверяйте список каждый раз, когда оператор его меняет. Импортированный набор полезен, только пока его записи существуют и говорят на транспорте, который описывают ваши блоки. Руководство OpenVPN 2.6 описывает здесь директивы remote, connection и random-order, и это та версия, которую стоит проверять при сомнениях в синтаксисе.