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 на каждый компьютер, а затем регистрирует сервис. Представьте, уже через час после применения политики служба killswitch работала на всех 28 ноутбуках!

Обновляем агента мы просто: перезаписываем файлы в 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 ПК, и последний день — на полноценную раскатку и обучение. По стоимости: внедрение обошлось в 96 000 ₽, плюс 12 000 ₽ в месяц за сопровождение. Важный момент: лицензии Windows Server и MikroTik у клиента были свои, мы железо не продаём.

Итог

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