VPN-зависимые приложения в корпсети: failover для 1С-Облака и банк-клиентов

К нам в ITfresh пришла бухгалтерская фирма из ЦАО Москвы — 22 рабочих места, обслуживают 80+ юрлиц на аутсорсе. Жалоба простая и неприятная: «Каждую неделю-другую у нас рвётся 1С-Облако, иногда теряем платёж в Сбере, я больше так не могу». Ситуация, которую мы видим у каждого второго бухгалтерского клиента: их рабочий день критически зависит от трёх облачных приложений (1С, СберБизнес, АльфаБизнес), а корпоративный канал держится на одном проводе и одной молитве. Дальше — наш проект VPN-failover за 11 рабочих дней с историей о том, как разбирались с особенностями каждого VPN-зависимого сервиса и как сделали так, что бухгалтерия перестала жаловаться.

Почему обычный «второй провайдер» не решает проблему

Когда клиент впервые ставит вопрос «у нас иногда нет интернета», стандартный ответ — «купите второго провайдера». На бумаге это работает: маршрутизатор автоматически переключается, пакеты идут через резерв, бизнес не страдает. На практике с VPN-зависимыми приложениями всё хуже. У 1С-Облака и банк-клиентов соединения long-lived: один TLS-сессия живёт часами, и сервер привязан к исходному IP клиента. Когда роутер переключает WAN — ваш публичный IP меняется. Сессия с 1cfresh.com рвётся. КриптоПро в банк-клиенте отбрасывает токен. Платёж теряется.

В моей практике у 8 из 10 клиентов с двумя провайдерами стоит обычный mangle на роутере «маршрут через WAN1, при недоступности через WAN2». Это совсем не failover для приложений уровня 1С — это failover для голого ping. Один партнёр клиента, услышав от меня эту разницу, сказал фразу, которую я часто потом цитирую коллегам: «Мы платим за два провайдера, чтобы не падать. И всё равно падаем — так в чём смысл?». Смысл — в том, что failover должен быть на уровне приложения, а не сети.

Что мы спроектировали для бухгалтерской фирмы

Один публичный IP — два WAN-канала

Главный трюк: VPN-зависимым приложениям нельзя показывать смену IP. Поэтому мы строим failover не как «два провайдера до интернета», а как «два туннеля до одного облачного шлюза с одним публичным IP». Шлюз — небольшая виртуалка в Я.Облаке, через неё проходит весь трафик в 1С-Облако и банк-клиенты. Какой бы канал ни работал в данный момент — для серверов 1cfresh.com и sberbank.ru мы всегда «одни и те же», с одного IP.

Два независимых туннеля с разной природой

Туннель №1 — IKEv2/IPSec поверх оптики Билайн. Туннель №2 — SoftEther с TLS-маскировкой поверх LTE-модема МТС. Разные провайдеры, разные физические каналы, разные протоколы — это правильный failover. Если у Билайна проблемы на оптике — спасает МТС. Если ТСПУ начнёт резать IKEv2 — спасает SoftEther. Два корня — две независимые причины отказа.

Переключение по Netwatch с порогом, не по ping

Стандартный Netwatch на MikroTik делает ping каждые 10 секунд и при потере 3-х подряд переключается. Для приложений это плохо: 30 секунд провала — это уже отвалившийся 1С. Мы делаем агрессивнее: ping каждые 2 секунды, переключение после 2-х подряд потерь = 4 секунды на детекцию. Плюс корреляция: если оба ping (через WAN1 и через туннель 1) теряются — переключаемся, если падает только канал — нет, ждём до 30 секунд. Это спасает от ложных переключений во время кратких микропростоев.

Конфигурация: пошагово

Облачный шлюз — Yandex.Cloud Compute

Поднял виртуалку s3.medium (2 vCPU, 4 GB RAM, 20 GB SSD), Ubuntu 22.04 LTS, публичный IP 51.250.84.211. На ней — strongSwan 5.9 как IPSec-сервер и SoftEther 4.41 как TLS-туннель. Стоимость — 1 800 ₽/мес.

# /etc/swanctl/conf.d/buh-office.conf
connections {
    buh-office-tunnel {
        version = 2
        local_addrs = 51.250.84.211
        remote_addrs = %any

        proposals = aes256gcm16-prfsha384-ecp384

        local {
            auth = pubkey
            certs = cloud-gateway.pem
            id = gw.buh-cloud.itfresh.ru
        }
        remote {
            auth = pubkey
            cacerts = ITfresh-RootCA.pem
            id = office-mt.buh.itfresh.ru
        }
        children {
            corp-tunnel {
                local_ts  = 10.10.0.0/16
                remote_ts = 192.168.10.0/24
                esp_proposals = aes256gcm16-ecp384
                rekey_time = 1h
                dpd_action = restart
                start_action = trap
                mode = tunnel
            }
        }
    }
}

# SoftEther — конфиг резервного TLS-туннеля
[Listeners]
Port_443=enabled

[Hub.HUB_BUH]
Online=true

[Listeners.Listener_443]
TLSAlpnList=h2,http/1.1
HostnameForCertificate=gw.buh-cloud.itfresh.ru

На шлюзе SNAT всех пакетов туннеля на 51.250.84.211, чтобы наружу всё уходило с одного IP:

# iptables на облачном шлюзе
*nat
-A POSTROUTING -s 192.168.10.0/24 -o eth0 -j SNAT --to-source 51.250.84.211
-A POSTROUTING -s 192.168.10.0/24 -o ipsec0 -j SNAT --to-source 51.250.84.211
COMMIT

*filter
-A FORWARD -s 192.168.10.0/24 -d 1cfresh.com -j ACCEPT
-A FORWARD -s 192.168.10.0/24 -p tcp --dport 443 -j ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT

Офисный MikroTik CCR2004

Базовая конфигурация: два WAN (ether1 — Билайн оптика, ether2 — LTE-модем МТС через USB-роутер), VLAN 10 для офиса, два IPSec-конфига до облачного шлюза.

/interface ethernet
set [find name=ether1] comment="WAN1 - Bilain optica 200/200"
set [find name=ether2] comment="WAN2 - LTE MTS via USB router"

/ip address
add address=192.168.10.1/24 interface=bridge_lan comment="LAN gateway"

/ip dhcp-client
add interface=ether1 default-route-distance=10 comment="Bilain primary"
add interface=ether2 default-route-distance=20 comment="MTS backup"

# Туннель 1: IKEv2 поверх Билайна
/ip ipsec peer
add name=cloud-via-bilain address=51.250.84.211 \
    profile=corp-cloud exchange-mode=ike2 \
    src-address=0.0.0.0 \
    local-address=%physical-bilain-ip%

# Туннель 2: SoftEther через LTE МТС
# (поднимается через openvpn-style клиент, в RouterOS поднимается через PPP)
/ppp profile
add name=softether-buh use-encryption=required dns-server=10.10.0.1

/ip route
# Маршрут до 1С-Облака идёт ВСЕГДА через ipsec-туннель,
# который сам выбирает физический WAN
add dst-address=51.250.84.211/32 gateway=ether1 \
    distance=1 comment="Force tunnel via primary WAN"
add dst-address=51.250.84.211/32 gateway=ether2 \
    distance=10 comment="Backup via MTS LTE"

Netwatch — агрессивный мониторинг

/tool netwatch
add host=51.250.84.211 interval=2s timeout=1s \
    src-address=192.168.10.1 \
    type=icmp \
    up-script="\
:log info \"Cloud GW UP — switching to primary IPSec\"; \
/ip route enable [find comment=\"Tunnel via primary WAN\"]; \
/ip route disable [find comment=\"Tunnel via backup MTS\"]; \
" \
    down-script="\
:log warning \"Cloud GW DOWN via WAN1 — switching to MTS backup\"; \
/ip route disable [find comment=\"Tunnel via primary WAN\"]; \
/ip route enable [find comment=\"Tunnel via backup MTS\"]; \
"

# Дополнительный watchdog: проверяем доступность 1cfresh.com через туннель
add host=84.201.143.42 interval=5s timeout=2s \
    src-address=192.168.10.1 \
    type=icmp \
    down-script="\
:log warning \"1C cloud unreachable — kicking IPSec session\"; \
/ip ipsec installed-sa flush; \
"

Особенности каждого VPN-зависимого приложения

1С-Облако (1cfresh.com): толстый клиент против веба

В нашем кейсе бухгалтерия использует толстый клиент 1С 8.3.24, не веб-версию. Толстый клиент держит долгое HTTP-соединение через тонкий клиент-сервер. Особенность: сервер 1cfresh.com при смене IP клиента сбрасывает сессию через 30-60 секунд после восстановления — пользователь видит «Соединение разорвано».

Решение через единый IP облачного шлюза работает идеально: даже когда офис переключается с Билайна на МТС, для 1cfresh.com мы остаёмся «теми же». На замерах за месяц после внедрения — ноль обрывов 1С.

Дополнительно: на клиенте 1С через файл inet.cfg пробросил длинные таймауты, чтобы микропровалы (1-2 секунды) не приводили к сбросу:

# 1cv8\inet.cfg
ConnectionTimeout=30
ResponseTimeout=120
KeepAliveTimeout=60

СберБизнес: HTTPS + КриптоПро

СберБизнес работает через обычный HTTPS на api.sberbank.ru, но ключевая особенность — подпись платежей через КриптоПро CSP с токеном Рутокен ЭЦП 2.0. При обрыве канала между подписью и отправкой пакета банк не принимает платёж и его надо переотправлять. У клиента до failover это случалось 2-3 раза в месяц.

Failover на VPN-уровне эту проблему не решает полностью — переключение всё равно занимает 1-2 секунды, и в момент клика «Подписать и отправить» этого может хватить для срыва. Решение комплексное: failover минимизирует частоту обрывов, плюс в самом банк-клиенте включаем offline-mode (платёж сначала готовится, потом отправляется одним пакетом).

АльфаБизнес: WebSocket-соединение для real-time

АльфаБизнес у нашего клиента — это веб-версия в Chrome. Бухгалтер открывает её утром и держит вкладку весь день. Через WebSocket приходят push-уведомления о платежах, новых клиентах, статусе подписей. WebSocket плохо переживает смену сетевого пути — после переключения иногда «зависает» и бухгалтеру приходится обновлять страницу.

Решилось двумя способами. Первое — failover через единый облачный шлюз убрал смену IP. Второе — на роутере выставили sticky-routing для портов 443/TCP к alfabank.ru: соединение держится через тот же канал, через который пришёл первый пакет, до явного разрыва TCP. Это уменьшило количество обновлений страниц с 4-5 раз в день до 0-1.

# MikroTik: sticky routing для AlfaBank
/ip firewall mangle
add chain=prerouting src-address=192.168.10.0/24 \
    dst-address-list=AlfaBank protocol=tcp dst-port=443 \
    connection-mark=no-mark \
    action=mark-connection new-connection-mark=conn-alfabank \
    passthrough=yes

add chain=prerouting connection-mark=conn-alfabank \
    action=mark-routing new-routing-mark=via-tunnel-primary \
    passthrough=no

Особенности приложений и DNS

VPN-зависимые приложения часто используют DNS-разрешение, которое уходит через основной DNS, а не через туннель. Это проблема: офисный DNS видит реальные IP, потом приложение пытается ходить по этим IP мимо туннеля, и failover не работает.

Я решил это через локальный DNS-резолвер на офисном MikroTik с условной переадресацией: запросы к доменам критичных сервисов (1cfresh.com, sberbank.ru, alfabank.ru) идут на DNS внутри облачного шлюза, остальные — на 77.88.8.8.

# MikroTik: split-horizon DNS
/ip dns
set servers=77.88.8.8,1.1.1.1 allow-remote-requests=yes

/ip dns static
add name=1cfresh.com type=FWD forward-to=10.10.0.1 \
    comment="Resolve through cloud GW DNS"
add name=login.sberbank.ru type=FWD forward-to=10.10.0.1
add name=alfabank.ru type=FWD forward-to=10.10.0.1
add name=online.alfabank.ru type=FWD forward-to=10.10.0.1

Мониторинг и алерты

Failover, который не мониторится — это failover, в существовании которого вы не уверены. На MikroTik настроил отправку алертов в Telegram через скрипт при каждом переключении канала, плюс еженедельный отчёт о времени работы по каждому туннелю.

/system script
add name=tg-alert source="\
:local message \$1; \
:local botToken \"123456789:ABCdef...\"; \
:local chatId \"-100123456789\"; \
/tool fetch url=\"https://api.telegram.org/bot\$botToken/sendMessage\" \
  http-method=post \
  http-data=\"chat_id=\$chatId&text=\$message\" \
  output=none keep-result=no; \
"

# Использовать в netwatch:
# down-script: /system script run tg-alert "FAILOVER_TO_MTS"
# up-script: /system script run tg-alert "RESTORED_BILAIN"

Параллельно подключил Zabbix-мониторинг по SNMP с сервера ITfresh: трапы по доступности туннелей, графики jitter и потерь, алерт в дежурный канал при двух подряд failover за час (это может означать, что у клиента более глубокая проблема).

Цифры проекта и история одного субботнего платежа

Развернули за 11 рабочих дней. Стоимость: 89 000 ₽ за инженерную работу (16 часов проектирования и настройки + пилот), 1 800 ₽/мес за виртуалку в Я.Облаке, 800 ₽/мес за резервный LTE-модем МТС. Роутер у клиента уже был — его не меняли.

За три месяца после запуска: четыре автоматических переключения (одно — реальное падение Билайна на 17 минут утром в среду, три — кратковременные провалы 30-90 секунд), ноль жалоб от бухгалтерии, ноль потерянных платежей.

Самая показательная история случилась в субботу второго месяца после внедрения. Главбух вышла на работу подписать срочный платёж в Сбере — 2,3 млн ₽ за партию запчастей для производственного клиента, чтобы успеть до закрытия операционного дня. В момент подписи у Билайна на улице порвало кабель экскаваторщиком (потом выяснилось). Раньше бы это означало: прерванный платёж, переотправка, ожидание понедельника, штраф 50 000 ₽ от поставщика. С failover — три-четыре секунды задержки, и платёж ушёл через МТС. Главбух заметила только потому, что в Telegram прилетел алерт от роутера. Директор клиента после этого случая написал отдельное благодарственное письмо — в нашей практике это редкость.

Грабли, на которые мы наступили

Грабля #1: Sticky session в Я.Облаке

В первый раз облачная виртуалка получала пакеты от двух туннелей одновременно (когда оба канала живые), и kernel routing выбирал «свежий», что приводило к ассимметричному маршруту: запросы туда шли через WAN1, ответы возвращались через WAN2. Решилось через ip rule с маркировкой пакетов в conntrack.

Грабля #2: МТС LTE-модем перегревался

Стоковый USB-модем Huawei E3372h при постоянной работе через две недели начинал перегреваться и сбрасывать соединение. Заменили на промышленный TP-Link MR400 v3 с внешним питанием — за 3 месяца ни одного сбоя.

Грабля #3: Бухгалтер забыла обновить КриптоПро

Через месяц после внедрения у одного бухгалтера началось «не подписывает». Оказалось — обновился сертификат КриптоПро на токене, а на компьютере осталась старая версия драйвера. К failover отношения не имеет, но напомнило мне: VPN-failover решает только сетевые проблемы. Криптография, токены, версии ПО — отдельный пласт работы.

FAQ: что чаще всего спрашивают клиенты

Какие приложения в корпсети чаще всего страдают от обрывов VPN?

Топ-3 в нашей практике: 1С-Облако (особенно толстый клиент), банк-клиенты СберБизнес и АльфаБизнес (которые требуют постоянного TLS-соединения с банком и не любят NAT-перебивы), и КриптоПро CSP при работе с подписью в банк-клиентах. Все три критичны для бухгалтерии — отвалились на 5 минут — рабочий день остановился.

Что такое failover для VPN и зачем оно бухгалтерии 22 РМ?

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

Какое железо нужно для VPN-failover на 22 РМ?

У нашего клиента стоит MikroTik CCR2004-1G-12S+2XS (около 76 000 ₽), который умеет одновременно работать с двумя WAN и поднимать IPSec-туннели в облако. Альтернатива — два роутера попроще (например, MikroTik RB5009 за 20 000 ₽ каждый) с CARP/VRRP между ними. Для 22 РМ хватает с большим запасом.

Сколько стоит обрыв VPN для бухгалтерии в деньгах?

У нашего клиента до внедрения failover в среднем 3-5 раз в месяц рвался канал в банк, что приводило к 1-2 часам простоя в месяц. Это 4 бухгалтера × 1,5 часа × 700 ₽/час = около 4 200 ₽ в месяц только зарплат. Плюс отозванные платежи (комиссия 50-300 ₽ за каждый) и нервы директора. Грубо — 8-12 тысяч ₽ потерь в месяц на пустом месте.

Сколько стоит проект VPN-failover для бухгалтерии?

Полный комплект: 14-18 рабочих часов инженера на проектирование и настройку (75-95 тысяч ₽), 76 тысяч ₽ на роутер MikroTik (если не было), плюс 1 200 ₽/мес на резервный мобильный канал. Окупается за 3-4 месяца только на зарплатах простоя бухгалтерии.

Итог

VPN-failover для VPN-зависимых приложений — это не «второй провайдер», а архитектурный приём с единым публичным IP в облаке и двумя независимыми туннелями к нему. Для бухгалтерской фирмы 22 РМ внедрение окупилось в течение 3 месяцев, а для главбуха — окупилось одной субботой, когда срочный 2,3-млн платёж ушёл вовремя. По нашему тарифу это порядка 90 тысяч ₽ единовременно и 2 600 ₽/мес на эксплуатацию — ровно та цена, за которую бухгалтерия в Москве получает спокойствие на год вперёд.