Резервный VPN-сервер: автопереключение при падении основного

MAATRIX

Основной VPN-сервер упал — провайдер сделал внеплановые работы, IP попал под блокировку, датацентр ушёл в даунтайм — и вы остались без доступа ровно в тот момент, когда он нужнее всего. Если VPN — это не игрушка, а рабочий канал (доступ к рабочим ресурсам, к ИИ-сервисам, к почте), у вас должен быть план Б: второй сервер, который подхватывает соединение без ручного вмешательства. Ниже — рабочая схема с клиентским скриптом проверки доступности и DNS-failover, которую можно повторить за вечер.

Зачем нужен резервный сервер и когда без него не обойтись

Один VPN-сервер — это единая точка отказа. Причины падения бывают разные, и от них по-разному защищает резерв:

• Технический сбой на стороне провайдера (перезагрузка хоста, миграция, авария в датацентре) — закрывается вторым сервером у *другого* провайдера, а не просто другой VM у того же.
• Блокировка IP — если провайдер VPN идёт через один и тот же адрес долго, его могут внести в списки блокировки по DPI. Второй сервер с другим IP и, желательно, другим протоколом снижает риск остаться совсем без связи.
• Плановые работы — обновление ядра, смена сертификатов, миграция конфига — можно проводить на одном сервере, пока трафик идёт через второй.
• Сетевые проблемы на маршруте — иногда падает не сервер, а магистральный канал до конкретной локации. Второй сервер в другой стране обходит эту проблему географически.

Если у вас единичный клиент и падения на 10 минут раз в месяц не критичны — резерв, скорее всего, избыточен. Но для команды, которая работает через VPN весь день, или для доступа к критичным сервисам (банкинг, ИИ-инструменты, рабочая инфраструктура) простой в час пик — это прямые потери. Ниже разбираем две независимые схемы: клиентский failover (скрипт сам переключается) и DNS-based failover (переключается адрес, к которому обращается клиент). Их можно использовать вместе.

Архитектура: два сервера в разных локациях и у разных провайдеров

Прежде чем писать скрипты, определитесь с топологией. Правильная схема резерва — это не два сервера у одного хостера в одном ДЦ, а разнесение по независимым точкам отказа:

Разные протоколы на основном и резервном сервере — не обязательное требование, но полезная страховка: если блокировка бьёт по конкретной сигнатуре протокола (например, DPI режет OpenVPN over TCP по паттерну), WireGuard на резерве может пройти там, где не прошёл первый. Сравнение протоколов и их устойчивость к блокировкам разбирали в статье WireGuard или OpenVPN — что выбрать для сервера, а базовую установку OpenVPN — в инструкции по установке и настройке OpenVPN на VPS.

Конфиги на резервном сервере держите синхронизированными с основным: те же маршруты, тот же DNS, те же правила firewall — иначе переключение будет заметным по поведению сети, а не прозрачным.

Клиентский скрипт: проверка доступности и переключение

Идея простая: клиент периодически проверяет, жив ли основной сервер (по ping или по TCP-хэндшейку на порт VPN), и если несколько проверок подряд провалились — поднимает туннель к резервному.

Пример для Linux/macOS на bash, работает с OpenVPN (по аналогии переносится на WireGuard — замена openvpn --config на wg-quick up/down):

#!/usr/bin/env bash
# vpn-failover.sh — проверка основного сервера и переключение на резервный

PRIMARY_HOST="203.0.113.10"
PRIMARY_PORT="1194"
BACKUP_CONFIG="/etc/openvpn/client/backup.conf"
PRIMARY_CONFIG="/etc/openvpn/client/primary.conf"
FAIL_THRESHOLD=3      # сколько неудачных проверок подряд до переключения
CHECK_INTERVAL=10     # секунд между проверками
STATE_FILE="/tmp/vpn-failover.state"

check_primary() {
    # TCP-проверка порта VPN вместо ping — ping часто блокируется на границе
    timeout 3 bash -c "echo > /dev/tcp/${PRIMARY_HOST}/${PRIMARY_PORT}" 2>/dev/null
}

fail_count=0
current="primary"
[ -f "$STATE_FILE" ] && current=$(cat "$STATE_FILE")

while true; do
    if check_primary; then
        fail_count=0
        if [ "$current" = "backup" ]; then
            echo "$(date): основной сервер снова доступен, переключаюсь обратно"
            systemctl stop openvpn-client@backup
            systemctl start openvpn-client@primary
            echo "primary" > "$STATE_FILE"
            current="primary"
        fi
    else
        fail_count=$((fail_count + 1))
        echo "$(date): проверка не прошла ($fail_count/$FAIL_THRESHOLD)"
        if [ "$fail_count" -ge "$FAIL_THRESHOLD" ] && [ "$current" = "primary" ]; then
            echo "$(date): основной сервер недоступен, переключаюсь на резервный"
            systemctl stop openvpn-client@primary
            systemctl start openvpn-client@backup
            echo "backup" > "$STATE_FILE"
            current="backup"
        fi
    fi
    sleep "$CHECK_INTERVAL"
done

Запускать скрипт удобнее не напрямую, а через systemd — так он переживёт перезагрузку и его состояние можно наблюдать через systemctl status:

# /etc/systemd/system/vpn-failover.service
[Unit]
Description=VPN Failover Monitor
After=network-online.target

[Service]
ExecStart=/usr/local/bin/vpn-failover.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload && sudo systemctl enable --now vpn-failover.service

Важные нюансы:

• Порог из нескольких проверок подряд, а не одной — иначе одиночная потеря пакета вызовет ложное переключение. Три проверки с интервалом 10 секунд — разумный компромисс между скоростью реакции и устойчивостью к шуму.
• Проверяйте TCP-порт VPN, а не ICMP-ping — многие провайдеры и сети режут ICMP на границе, и ложные срабатывания будут постоянными.
• Возврат на основной сервер после восстановления — не всегда нужен автоматически. Если переключение туда-обратно дорого (разрыв активных сессий, смена IP на выходе), можно сделать возврат только вручную или с задержкой в 10-15 минут устойчивой доступности.

Для Windows аналог реализуется через PowerShell и планировщик задач — та же логика проверки порта и перезапуска подключения, только на PowerShell вместо bash и через Task Scheduler вместо systemd.

DNS-based failover: один адрес, несколько серверов

Клиентский скрипт хорош, когда вы управляете конфигом клиента (свои устройства, корпоративный парк). Но если VPN-сервер используется по доменному имени в конфигах, которые вы не контролируете полностью (например, раздаёте .ovpn-профиль пользователям), удобнее переключать не клиента, а DNS-запись.

Схема: клиенты подключаются не к IP, а к vpn.example.com. Health-check скрипт на отдельной машине (или на самом резервном сервере) проверяет основной сервер и, если он недоступен, обновляет A-запись на IP резервного через API DNS-провайдера.

Пример с Cloudflare API (аналогично работает с любым DNS-провайдером, у которого есть REST API — Route53, DigitalOcean DNS и т.д.):

#!/usr/bin/env bash
# dns-failover.sh — переключение A-записи vpn.example.com при падении основного сервера

ZONE_ID="ваш_zone_id"
RECORD_ID="ваш_record_id"
API_TOKEN="ваш_api_token"
PRIMARY_IP="203.0.113.10"
BACKUP_IP="198.51.100.20"
DOMAIN="vpn.example.com"

check_host() {
    timeout 3 bash -c "echo > /dev/tcp/${1}/1194" 2>/dev/null
}

update_dns() {
    local target_ip="$1"
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records/${RECORD_ID}" \
        -H "Authorization: Bearer ${API_TOKEN}" \
        -H "Content-Type: application/json" \
        --data "{\"type\":\"A\",\"name\":\"${DOMAIN}\",\"content\":\"${target_ip}\",\"ttl\":60,\"proxied\":false}"
}

if check_host "$PRIMARY_IP"; then
    update_dns "$PRIMARY_IP" > /dev/null
    echo "$(date): основной сервер доступен, DNS указывает на primary"
else
    update_dns "$BACKUP_IP" > /dev/null
    echo "$(date): основной сервер недоступен, DNS переключён на backup"
fi

Ключевой момент — TTL записи. По умолчанию у многих провайдеров TTL 3600 секунд (час), что делает переключение почти бесполезным: клиенты будут держать в кэше старый IP до истечения TTL. Ставьте TTL 60-120 секунд на записи, участвующей в failover — это увеличит нагрузку на DNS-резолверы незначительно, зато переключение станет реально быстрым. Общий разбор геораспределённого DNS и когда он нужен — в статье Geo DNS: что это и когда нужен.

Минус DNS-based подхода: он не мгновенный (нужно время на распространение записи и на то, чтобы клиент переспросил DNS) и не решает проблему клиентов, которые закешировали IP на уровне ОС дольше TTL. Для быстрого переключения на управляемых устройствах комбинируйте оба метода: DNS-failover как базовый слой для всех, клиентский скрипт — как более быстрый механизм для устройств, которыми вы управляете напрямую.

Настройка на роутере и на клиентских устройствах

Если VPN раздаётся на весь дом или офис через роутер, логика failover переезжает туда. На роутерах с полноценной ОС можно настроить её без написания собственного скрипта:

• MikroTik: скрипт на RouterOS через Scheduler, пингующий основной сервер, плюс netwatch-правило, меняющее активный VPN-интерфейс в маршрутизации при недоступности.
• OpenWrt: пакет mwan3 — multi-WAN менеджер, который умеет проверять доступность каждого аплинка (в том числе VPN-туннеля) и переключать маршрут по умолчанию автоматически.
• Keenetic: готового failover между двумя VPN-туннелями нет, но его можно эмулировать связкой "скрипт по cron + перезапуск профиля подключения" при наличии Entware.

Для клиентов, которые просто получают .ovpn или .conf-файл и не готовы разбираться со скриптами, практичнее раздать профиль с доменным именем сервера (не IP) и положиться на DNS-failover: пользователь ничего не меняет, переключение прозрачно происходит на уровне DNS.

Мониторинг обоих серверов и алерты при падении

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

Минимальный набор:

1. Внешний мониторер доступности обоих серверов независимо от failover-скрипта — например, Uptime Kuma с HTTP(S) или TCP-проверкой порта VPN на каждом сервере. Подробная настройка — в статье Uptime Kuma: мониторинг сайта и сервера.
2. Уведомление именно о факте переключения, а не только о падении — добавьте в скрипт vpn-failover.sh функцию notify() с curl к Telegram Bot API или webhook Slack, вызывайте её в момент смены current, а не при каждой неудачной проверке.
3. Отдельный внешний watchdog (не на тех же серверах, что VPN) — если оба сервера физически недоступны одновременно (редко, но бывает при сбое магистрали), локальный мониторинг тоже замолчит. Внешний сервис с cron-пингом от обоих серверов подстрахует и от этого сценария.

Общий принцип: сам факт наличия резерва не должен снижать бдительность. Резерв покупает вам время на исправление основного сервера, а не отменяет необходимость его чинить.

Тестирование failover и типичные ошибки

Схема, которую ни разу не тестировали, работает только в вашем воображении. Проверяйте её регулярно и намеренно:

• Плановое отключение основного сервера раз в месяц-два (например, во время окна на обновления) — это одновременно и тест failover, и повод обновить систему без риска для пользователей.
• Проверка обратного переключения — убедитесь, что при восстановлении основного сервера логика не начинает мигать туда-обратно (флаппинг) из-за нестабильного, но частично живого сервера. Добавьте задержку/гистерезис перед возвратом.
• Проверка с реального клиентского места, а не только с сервера мониторинга — доступность порта VPN с самого сервера мониторинга и с ноутбука пользователя за домашним роутером с NAT — разные вещи.

Частые ошибки при внедрении:

• Сертификаты выпущены только под основной сервер — при переключении клиент не сможет подключиться к резервному. Выпускайте ключи для обоих серверов заранее (или используйте общий CA).
• Конфиги основного и резервного расходятся (маршруты, push-DNS, MTU) — после переключения пользователь теряет доступ к ресурсам, которые "работали" только благодаря настройке, забытой на резерве.
• TTL DNS-записи понижен только в момент аварии — старое высокое значение всё равно ещё какое-то время действует у части резолверов, которые успели закешировать ответ раньше.
• Резервный сервер не обновляется наравне с основным — та же версия ПО, те же пользователи, те же патчи безопасности. Забытый на полгода резерв в момент аварии может преподнести свои сюрпризы.

Частые вопросы