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

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

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

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

Честно говоря, такой запрос я слышал не раз. Причём не только от бухгалтерских аутсорсеров, но и от частных нотариусов. Ситуация, по сути, всегда одна и та же, как под копирку: VPN вдруг отваливается, ноутбук пользователя моментально переключается на общедоступный Wi-Fi в каком-нибудь кафе, и — вуаля! — весь трафик банк-клиента уходит напрямую через провайдера. Да, конечно, он зашифрован по TLS, но ведь через DNS-запросы, заголовки SNI и даже паттерны трафика можно подсветить очень много всего! А самое противное — компания вообще никак это не контролирует. С юридической точки зрения, это откровенная «серая зона». Технически — считайте, открытый канал для потенциальной утечки данных. Ну а организационно отследить что-либо в таком бардаке практически невозможно.

Мы разработали для них решение, которое в нашей IT-тусовке принято называть kill-switch. Сама идея, кстати, пришла к нам из мира мобильных приложений. Помните, как, например, в Anubis Android-приложение просто «замирает», если VPN-туннель пропадает? Вот именно эту логику мы и адаптировали под нужды корпоративного Windows-парка нашего клиента, выстроив целую систему из трёх уровней контроля. Вся эта махина держится на нашем роутере MikroTik, дополненном групповыми политиками Windows Firewall, и, конечно же, нашим собственным PowerShell-агентом, который мы установили на каждый ноутбук.

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

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

Да, список получился довольно компактным, но именно через эти четыре приложения можно получить доступ к 95% и клиентских денег, и их персональных данных. А чтобы точно ничего не упустить, в качестве такого «резервного» варианта мы включили туда ещё и портал Госуслуг для юридических лиц. Ведь именно там, как ни крути, хранятся все важные сертификаты электронных подписей.

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

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

Вся прелесть нашей многослойной системы в том, что каждый уровень, по сути, дублирует предыдущий. Ну вот если вдруг наш MikroTik начнёт барахлить, то его мгновенно прикроют локальные правила на компьютерах. А что, если групповая политика по какой-то причине не доехала или не применилась? Тогда наш агент просто «убьёт» процесс, и никакие данные не уйдут. Важный момент: каждый из этих слоёв работает абсолютно автономно, они не зависят друг от друга.

Что касается серверной части, там у нас по-прежнему уверенно трудится WireGuard на MikroTik CCR2004-16G-2S+, который стоит прямо в офисе. Его внутренний хост — wg.office.local в нашей локальной сети. Мы настроили 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 (например, это может быть IP сервера 1С, адреса Сбер-Бизнеса или портал клиент-Битрикса), мы присваиваем специальную метку — 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-файлов и привязываем его к профилю "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-интерфейс — это наша "доменная" сеть? Здесь помог небольшой трюк. Мы прописали в реестре, через GPP Registry, на ключе NetworkList\Profiles, тип сети 0x01 (Domain Authenticated) для GUID нашего WireGuard-туннеля. Казалось бы, мелочь. Но без этой настройки Windows упрямо считал туннель публичной сетью. А это значит, что весь наш kill-switch просто рассыпался бы на части. Вот так, одна деталь, а меняет всё!

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

Только мы раскатили GPO, как тут же — сюрприз! У двух наших сотрудниц офисные принтеры Kyocera M2540dn наотрез отказались печатать счета-фактуры из 1С. Что произошло? Смотрите: они же печатают на обычный офисный принтер, а это идёт через локальную сеть (LAN). При этом сама 1С работает через WireGuard, и по нашим свежим правилам Windows Firewall, её исходящий трафик разрешён только в 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 и моментально видит: точное время принудительного завершения и ясную причину – "handshake протух 280 секунд назад". Всё понятно! Дальше уже можно идти к сетевику и выяснять, какого черта WireGuard падал именно в 11:43. Так что, это не просто файл, это наш свидетель и помощник.

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

Установку агента мы максимально упростили. Как? Через GPO startup-script. Этот скрипт делает всего пару вещей: копирует папку с нашим PowerShell-сервисом и nssm.exe прямо из netlogon на каждый компьютер, а потом регистрирует сервис. И что в итоге? Представьте себе, всего через час после того, как мы применили политику, наш killswitch уже исправно трудился на всех 28 ноутбуках! Оперативно, правда?

А как мы обновляем агента? Тоже просто. Перезаписываем нужные файлы в netlogon, а затем через psexec перезапускаем сервис сразу по всей группе компьютеров. Всё, готово! Да и, по нашему опыту, обновлять его чаще раза в месяц просто нет смысла. Код там уже настолько стабильный, что лишний раз его трогать нет нужды.

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

Настоящая "боевая" раскатка нашего решения прошла в понедельник, 6 апреля. И что вы думаете? Уже к утру вторника мы получили 11 обращений от пользователей. Да-да, сразу столько! Сейчас я в деталях расскажу вам, с какими основными кейсами нам пришлось столкнуться.

Кейс первый: наш банк-клиент Сбер-Бизнеса жутко сбоил. Ну просто невозможно было работать — то запустится, то снова вылетает. На то, чтобы разобраться с этой загадкой, у нас ушло целых пять часов. Оказалось, корень зла скрывался в самом Сбер-Бизнесе! При загрузке он отправляет запросы к CloudFront-CDN банка. Но вот что интересно: адреса этих CDN, как выяснилось, каждый раз меняются в зависимости от геолокации запроса. То есть, Сбер видит, что запрос идёт с "белого" офисного IP, и в ответ выдаёт совсем другие CDN-узлы! Не те, что мы заранее заботливо прописали в address-list MikroTik. Пришлось действовать решительно. Мы справились с проблемой двумя путями: во-первых, расширили наш address-list, добавив маски на crl.sbi.sberbank.ru и cdn.sbbol.ru; во-вторых, прописали явные сервера Сбербанка по AS-номеру прямо через RouterOS BGP-фильтр AS35237. Теперь всё работает как часы.

Кейс второй: наш юрист, работая в командировке где-то в Сочи, без устали жаловался — "1С падает каждые 20 минут! Невозможно работать!". Причина, скажу я вам, оказалась совершенно неожиданной. Оказывается, мобильный оператор МТС в Краснодарском крае просто брал и резал UDP-соединения, если они длились дольше 15 минут. Они классифицировали их как "протоколы P2P". Вот так вот! Что мы сделали? Мы настроили на офисном MikroTik альтернативный wireguard2 на 443/TCP через udp2raw. А юристу в Сочи выдали второй конфиг и чёткую инструкцию: как переключиться на него, если опять начнутся проблемы. В итоге, эта связка с UDP+TCP-fallback оказалась более чем достаточной.

И последний, третий кейс: один из ноутбуков, это был Lenovo ThinkPad T14 G3, после долгого сна — часов на 8! — никак не хотел восстанавливать WireGuard. Интересно, что тачпад и Wi-Fi работали отлично, да и wg-quick отзывался. Но вот peer никак не находился. В чём же было дело? Помогло простое решение: reload интерфейса через скрипт. Мы добавили этот скрипт в Power Events: каждый раз при выходе из сна он перезапускает WireGuard-туннель. И вот, начиная с 9 апреля 2026 года, эта проблема больше ни разу не давала о себе знать. Удобно!

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

Внедрение у нас заняло 5 рабочих дней и потребовало лишь одного инженера. За весь проект мы заплатили 96 000 ₽. После того как всё было настроено, я целый месяц внимательно следил за статистикой kill-switch. И знаете, только за апрель наш агент «убил» процессы 18 раз на 8 разных компьютерах! Из них 9 случаев — это были реальные падения WireGuard, ну, так называемые «флапы провайдеров». Ещё 6 раз — когда ноутбук выходил из режима сна, а туннель почему-то не восстанавливался. И трижды, представьте, сотрудники пытались открыть Сбер-Бизнес после того, как вручную отключали 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-трафик. Если это keepalive, то на 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 рабочих дней и потребовала лишь одного инженера. Могу расписать по дням: один день ушёл на проектирование, два дня — на детальную настройку MikroTik и GPO. Ещё один день мы потратили на пилот в небольшой группе из 4 ПК. И последний день — это уже полноценная раскатка решения и обучение. Что по стоимости? Само внедрение обошлось в 96 000 ₽, плюс 12 000 ₽ в месяц за сопровождение. Очень важный момент: лицензии Windows Server и MikroTik у клиента были свои, мы железо не продаём и не навязываем.

Итог

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