Kill-switch для 1С и банк-клиента: как мы заблокировали приложения юрфирмы при падении VPN

К нам пришла юридическая фирма 28 РМ из ЦАО с простым запросом: «Нужно, чтобы 1С и Сбер-Бизнес не работали никогда, если VPN до офиса упал». Сотрудники работают наполовину из офиса, наполовину удалённо и из командировок. Один раз бухгалтер открыл банк-клиент в гостиничном Wi-Fi, когда WireGuard молча отвалился. Партнёр фирмы сказал: «Такое не должно быть технически возможно». Мы сделали kill-switch на трёх уровнях — расскажу что и зачем.

Откуда взялась задача и почему важна именно юристам

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

Технически тот же запрос мы слышали и раньше от бухгалтерских аутсорсеров, и от частных нотариусов. Сценарий повторяется: у сотрудника падает VPN, ноутбук молча подхватывает Wi-Fi кафе, и трафик банк-клиента — да, зашифрованный TLS, но с лёгкой подсветкой DNS-запросов, заголовков SNI, паттернов трафика — уходит через провайдера без какого-либо контроля со стороны компании. Юридически — серая зона, технически — потенциальный канал утечки, организационно — почти невозможно отследить.

Решение, которое мы построили, в индустрии называется kill-switch. Концепция взята из мобильных приложений вроде Anubis, где Android-приложение замораживается при пропадании туннеля. Мы перенесли эту логику на корпоративный Windows-парк через три уровня контроля: роутер MikroTik, групповые политики Windows Firewall и собственный PowerShell-агент на каждом ноутбуке.

Что входит в чувствительный список

Перед стартом я сел с партнёром и мы выписали приложения, которым строго запрещено работать без VPN. Получилось четыре: 1С-Клиент 8.3.24.1668 (тонкий клиент к серверу 1С в офисе), Сбер-Бизнес Онлайн (sbbol-cli.exe и его браузерный режим), портал клиента-Битрикс24 (доступ через служебный домен), правовая система КонсультантПлюс. Браузер, почта, мессенджеры — без ограничений, работают по обычным каналам.

Список ограниченный, но именно эти четыре приложения дают 95% доступа к деньгам и персональным данным доверителей. Резервно мы добавили туда же портал Госуслуг для юрлиц — там сертификаты подписей живут.

Архитектура: три уровня защиты вместо одного

Сначала был соблазн обойтись одним механизмом — типа «настроим Windows Firewall и хватит». По моему опыту, один уровень всегда оставляет дыру. Сотрудник случайно отключит файрвол, политика не применится из-за GPO-сбоя, кто-то поставит сторонний VPN-клиент с собственным интерфейсом. Поэтому архитектура у нас трёхслойная: первый слой — MikroTik в офисе, второй — GPO Windows Firewall, третий — собственный агент на ПК.

Идея слоёв: каждый дублирует другой. Если MikroTik сходит с ума, прикроют локальные правила. Если GPO не приехало, агент убьёт процесс. Каждый слой делает свою работу автономно, не зная про другие.

Серверная часть — это всё ещё WireGuard на MikroTik CCR2004-16G-2S+ в офисе (хост wg.office.local внутри LAN), 28 пиров клиентов, по одному на сотрудника. Тоннель идёт на UDP 51820, по белому IP офиса с резервом через мобильную SIM в LTE-модеме того же MikroTik. На клиентских ноутбуках стоит официальный WireGuard for Windows 0.5.3 с автоподключением при старте системы.

Почему не Cisco AnyConnect или OpenVPN

Слышу часто: «А вот Cisco AnyConnect умеет kill-switch из коробки». Это правда. Но Cisco AnyConnect требует ASA-сервера или Firepower — это совсем другой бюджет. Для офиса 28 РМ это перебор. OpenVPN — тоже умеет, но с задержками handshake до 8 секунд при переподключении, а WireGuard переподключается за 0.5-1 секунду. Для юрфирмы быстрота переключения критична — не хочется, чтобы при кратком провале мобильного интернета 1С падал на 8 секунд.

WireGuard выиграл по совокупности: быстрый handshake, низкая нагрузка на батарею ноутбука, простой конфиг, MikroTik 7.16 умеет его нативно. Минус — нет встроенного kill-switch, надо строить руками. Что мы и сделали.

Слой 1: MikroTik routing-mark и firewall

На офисном MikroTik мы поставили задачу: чувствительные приложения должны идти на свои сервера только через интерфейс wireguard1, а не через ether1 (обычный гейтвей). Если wireguard1 ляжет, маршрут до этих сервисов исчезнет, и трафик дропается.

Конкретно делается через routing-mark + routing table. Каждому пакету от клиента-офиса с конкретными destination IP (сервер 1С, IP Сбер-Бизнеса, портал клиент-Битрикса) мы вешаем mark и направляем в таблицу маршрутизации wg-only, где default route — через wireguard1. Если интерфейс падает, маршрут исчезает, пакет дропается. Это работает в обе стороны: входящий трафик к ноутбуку сотрудника через мобильный канал на чувствительные порты тоже дропается.

/routing/table
add disabled=no fib name=wg-only

/ip/firewall/mangle
add chain=prerouting action=mark-routing new-routing-mark=wg-only \
    dst-address=10.20.30.40 comment="server-1c-prod"
add chain=prerouting action=mark-routing new-routing-mark=wg-only \
    dst-address-list=sberbank-bizn comment="sber-business-online"

/ip/firewall/address-list
add list=sberbank-bizn address=online.sberbank.ru
add list=sberbank-bizn address=sbi.sberbank.ru
add list=sberbank-bizn address=sbbol.ru

/ip/route
add disabled=no distance=1 dst-address=0.0.0.0/0 \
    gateway=10.99.99.1 routing-table=wg-only \
    comment="default via wireguard1 only"

Тонкий момент — address-list для Сбер-Бизнеса. DNS-имена банка резолвятся в кучу IP, поэтому мы используем динамический address-list, который обновляется через cron-скрипт раз в час: резолвит имена в IP, добавляет в список. Если не делать, после ребаланса CDN банка половина адресов перестаёт совпадать.

Что мы упустили в первой итерации

В первый день после развёртывания на половине ноутбуков 1С перестал подключаться вообще. Разобрались за час: сервер 1С слушает на 10.20.30.40 в офисе, и мы корректно завернули трафик в WireGuard. Но WireGuard конфиг на ноутбуке имел AllowedIPs = 10.20.30.0/24, а сервер 1С отвечал клиенту с публичного интерфейса 10.10.0.1 (мы делаем NAT на роутере). Пришлось добавить AllowedIPs = 10.10.0.0/16 и переподписать конфиги для всех 28 пиров.

После этого пилот заработал, но всплыла вторая проблема: командировочные сотрудники жаловались на тормоза 1С через мобильный 4G. Оказалось, маршрут стал жёстко через WireGuard, и в плохой связи это болезненно — handshake переподключается медленно. Снизили MTU на интерфейсе с 1420 до 1380, включили mss-clamping — стало пристойно.

Слой 2: GPO Windows Firewall с привязкой к интерфейсу

Параллельно с MikroTik мы развернули политику Windows Firewall через GPO. Идея — добавить правило, которое разрешает 1С, Сбер-Бизнес, КонсультантПлюс и Битрикс24-клиент только когда интерфейс WireGuard активен. Если активного интерфейса нет, правила запрещают исходящие соединения этих процессов вообще.

Тонкая часть — Windows Firewall в GPO умеет привязывать правила к именованным интерфейсам, но не умеет напрямую к WireGuard'у. Поэтому мы пошли через комбинацию: создаём правило allow для конкретных exe-файлов с привязкой к profile "Domain", а интерфейс WireGuard в групповой политике помечаем как Domain Profile. Если туннеля нет, профиль Domain не активен, правила не работают, default deny рубит трафик.

$AppPaths = @(
    'C:\Program Files (x86)\1cv8\8.3.24.1668\bin\1cv8c.exe',
    'C:\Program Files\Sberbank\sbbol-cli\sbbol-cli.exe',
    'C:\Program Files (x86)\Consultant\cons.exe',
    'C:\Program Files\Bitrix24\Bitrix24.exe'
)

foreach ($app in $AppPaths) {
    $name = [System.IO.Path]::GetFileNameWithoutExtension($app)
    New-NetFirewallRule -DisplayName "KillSwitch-Allow-$name" `
        -Direction Outbound -Action Allow `
        -Program $app -Profile Domain `
        -PolicyStore "corp.lawfirm.local\KillSwitch-GPO"
    New-NetFirewallRule -DisplayName "KillSwitch-Deny-$name" `
        -Direction Outbound -Action Block `
        -Program $app -Profile Private,Public `
        -PolicyStore "corp.lawfirm.local\KillSwitch-GPO"
}

Чтобы Windows понимал, что WireGuard-интерфейс — это Domain-сеть, мы прописали в реестре через GPP Registry на ключе NetworkList\Profiles тип сети 0x01 (Domain Authenticated) для GUID WireGuard-туннеля. Это маленький трюк, но без него Windows считает туннель Public-сетью, и kill-switch разваливается.

Подводный камень: split-tunneling и принтеры

После раскатки GPO выяснилось, что у двух сотрудниц офисные принтеры Kyocera M2540dn перестали печатать счета-фактуры из 1С. Они печатают на офисный принтер через интерфейс LAN, а 1С работает через WireGuard. По правилам Windows Firewall, исходящий трафик 1С разрешён только в Domain-сети, и попытка принтового задания через локальный интерфейс дропалась.

Решили исключением: разрешили процессу 1cv8c.exe исходящие соединения на офисный принт-сервер (192.168.10.5:9100) во всех профилях. Не самое красивое решение, но альтернатива — публиковать принтер через WireGuard — слишком тяжело при печати 10-страничного договора.

Слой 3: PowerShell-агент с периодической проверкой

Третий уровень — собственный сервис, который раз в 5 секунд проверяет состояние WireGuard и при падении на 30+ секунд завершает процессы из чувствительного списка. Зачем третий уровень, когда есть два? У GPO бывают сбои применения, у MikroTik бывает деградация link-state. Агент — это последняя страховка.

Агент написан на PowerShell, упакован в Windows Service через nssm. Один экземпляр на машину, стартует при загрузке системы под NT AUTHORITY\SYSTEM, пишет лог в C:\ProgramData\ITfresh\killswitch.log. Раз в 5 секунд читает данные WireGuard через wg.exe show, парсит последний handshake. Если handshake старше 180 секунд — считает туннель упавшим, отправляет SIGTERM процессам из списка. Если процесс не закрывается за 10 секунд — kill -9.

$Apps = @('1cv8c', 'sbbol-cli', 'cons', 'Bitrix24')
$WGBin = 'C:\Program Files\WireGuard\wg.exe'
$LogPath = 'C:\ProgramData\ITfresh\killswitch.log'

while ($true) {
    $output = & $WGBin show all latest-handshakes 2>$null
    $tunnelAlive = $false

    if ($output) {
        $now = [int][double]::Parse((Get-Date -UFormat %s))
        foreach ($line in $output) {
            $parts = $line -split '\s+'
            $lastHs = [int]$parts[-1]
            if ($lastHs -gt 0 -and ($now - $lastHs) -lt 180) {
                $tunnelAlive = $true
                break
            }
        }
    }

    if (-not $tunnelAlive) {
        foreach ($app in $Apps) {
            $procs = Get-Process -Name $app -ErrorAction SilentlyContinue
            foreach ($p in $procs) {
                Add-Content -Path $LogPath -Value "$(Get-Date -Format o): KILL $($p.ProcessName) PID=$($p.Id)"
                Stop-Process -Id $p.Id -Force
            }
        }
    }
    Start-Sleep -Seconds 5
}

Лог нужен для разборок: сотрудник придёт жаловаться «у меня 1С упал», админ открывает killswitch.log и видит время kill и причину — handshake протух 280 секунд назад. Дальше идём к сетевику смотреть, почему WireGuard падал в 11:43.

Развёртывание агента на 28 машин без рук

Установку агента мы оформили через GPO startup-script. Скрипт копирует папку с PowerShell-сервисом и nssm.exe из netlogon на каждый ПК и регистрирует сервис. Через час после применения политики у всех 28 ноутбуков служба killswitch уже работала.

Обновление агента делаем через перезаписывание файлов в netlogon и рестарт сервиса через psexec по группе компьютеров. По нашему опыту, обновлять агент чаще раза в месяц не имеет смысла — стабильный код.

Что упало в первую неделю и как чинили

Боевая раскатка была в понедельник 6 апреля. К утру вторника у нас было 11 обращений от пользователей. Разберу основные кейсы.

Кейс 1: банк-клиент Сбер-Бизнеса работал нестабильно — то открывался, то нет. Расследование заняло пять часов. Виноват оказался Сбер-Бизнес, который при загрузке делает запросы к CloudFront-CDN банка. Адреса CDN меняются по геолокации запроса. Сбер видит, что запрос приходит с белого офисного IP, и отдаёт другие CDN-узлы, чем те, что я прописал в address-list MikroTik. Решили двумя способами: расширили address-list масками на crl.sbi.sberbank.ru и cdn.sbbol.ru, плюс прописали явные сервера Сбербанка по AS-номеру через RouterOS BGP-фильтр AS35237.

Кейс 2: командировочный юрист в Сочи жаловался, что 1С падает каждые 20 минут. Причина — мобильный оператор МТС в Краснодарском крае режет UDP-соединения старше 15 минут как «протоколы P2P». Решение — поставили на офисный MikroTik альтернативный wireguard2 на 443/TCP через udp2raw, дали клиенту в Сочи второй конфиг и инструкцию переключаться на него в случае проблем. Связки UDP+TCP-fallback хватило.

Кейс 3: один из ноутбуков (Lenovo ThinkPad T14 G3) после засыпания на 8 часов не восстанавливал WireGuard. Touchpad и Wi-Fi работали, а wg-quick тоже отвечал, но peer не находился. Помог reload интерфейса через скрипт, который мы добавили в Power Events: при выходе из сна перезапускать WireGuard-туннель. С 2026-04-09 такого больше не повторилось.

Цифры результата и личное впечатление

Внедрение заняло 5 рабочих дней инженера, 96 000 ₽ — за весь проект. После раскатки в течение месяца я смотрел статистику kill-switch: всего за апрель агент убил процессы 18 раз на 8 разных ПК. Из них 9 — реальные падения WireGuard (флапы провайдеров), 6 — выход ноутбука из режима сна без восстановления туннеля, 3 — сотрудник вручную выключил WireGuard и попытался открыть Сбер-Бизнес. Все три попытки залогированы, партнёр поговорил с сотрудниками — больше не пробовали.

Главный плюс, по мнению партнёра: спокойствие. Теперь он точно знает — банк-клиент и 1С физически не работают без офисного периметра. Если случится утечка через сторонний канал, это уже не «техника подвела», а человеческая ошибка совсем другого уровня.

Мой личный вывод после этого проекта: kill-switch — это не про техническую необходимость для каждой компании. Большинству офисов хватает обычного VPN с уведомлением о разрыве. Но если у вас бухгалтерия или работа с банками — стоит закладывать. Стоимость низкая, эффект ощутимый.

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

Зачем юридической фирме kill-switch для 1С и банк-клиента?

Юрфирма работает с персональными данными доверителей, банковскими реквизитами, договорами под NDA. Если ноутбук бухгалтера в командировке внезапно теряет WireGuard и автоматически переподключается через Wi-Fi отеля без шифрования, банковский трафик пойдёт открыто. Kill-switch гарантирует, что приложение даже не запустится без активного туннеля до офисного периметра. Это закрытие технического риска утечки и одновременно требование 152-ФЗ к мобильным рабочим местам.

Чем kill-switch отличается от обычного VPN-клиента?

Обычный VPN-клиент при падении тоннеля просто пишет уведомление, а трафик начинает идти через прямой интерфейс — в открытом виде. Kill-switch — это сетевой ров, который запрещает трафику чувствительных приложений выходить мимо VPN-интерфейса. Реализуется на уровне роутера (MikroTik routing-mark), Windows Firewall (правила на исполняемый файл с привязкой к интерфейсу) или агента на ПК, который убивает процесс.

Что делать, если WireGuard падает 3-5 раз в день?

Сначала разбираем причину: чаще всего это keepalive отключён или провайдер режет UDP. На MikroTik включаем persistent-keepalive 25 секунд, на клиенте — PersistentKeepalive=25 в конфиге. Если режется UDP — поднимаем резервный канал по 443/TCP через udp2raw или wstunnel. У клиента-юрфирмы после правильной настройки keepalive падения сошли с 4 раз в день до 1 раза в неделю.

Будут ли пользователи саботировать kill-switch?

Будут пытаться. Сотрудник видит, что 1С не работает, и просит отключить «эту вашу штуку». Поэтому kill-switch внедряется с обязательным регламентом и в первую очередь — для критичных приложений (банк-клиент, 1С, CRM с клиентскими данными). А мессенджеры, браузер, почта — пусть работают и без VPN. В первый месяц у нас было 6 обращений «отключите», к концу второго — ни одного, привыкли.

Сколько стоит внедрение kill-switch для офиса 25-30 РМ?

У юрфирмы на 28 РМ работа заняла 5 рабочих дней инженера: 1 день на проектирование, 2 дня на настройку MikroTik и GPO, 1 день на пилот в группе из 4 ПК, 1 день на раскатку и обучение. Стоимость — 96 000 ₽ за внедрение + 12 000 ₽/мес в рамках сопровождения. Лицензии Windows Server и MikroTik — у клиента свои, мы не продаём железо.

Итог

Kill-switch — это узкоспециализированная защита для офисов, где работа с банками и персональными данными требует жёсткой границы между «есть туннель» и «нет туннеля». Для юрфирмы 28 РМ из ЦАО он стал страховкой от человеческой ошибки: сотрудник теперь не может случайно открыть Сбер-Бизнес в открытом гостиничном Wi-Fi. Цена вопроса — 96 тысяч единовременно, а спокойствия партнёра — не измерить.