Разместите VPN-шлюз рядом с Windows XP, а не внутри него

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

Начните с адаптера хоста, а не с VPN-клиента

Откройте свойства адаптера и дайте хосту фиксированный адрес в небольшом выделенном сегменте, а шлюз сделайте его маршрутом по умолчанию. Тогда хосту не нужны ни клиент туннеля, ни учётные данные туннеля, ни записи таблицы маршрутизации в более широкую корпоративную сеть. Если приложению нужна одна удалённая подсеть, добавьте ровно этот один маршрут.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

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

Поместите туннель на оборудование, которое можно обновлять

Шлюзу нужны два интерфейса: один в сторону сегмента хоста и один в сторону того места, где живёт приложение, причём туннель завершается на втором. Это устройство может получать обновления прошивки, заменять криптографическую конфигурацию и вести журнал потоков, никто не трогает старую машину. Его поставщик также выпускает исправления для реализации туннеля, которые хост никогда не получит. Две машины и срок — не причина копировать рецепт со статическим секретом из сообщения на форуме.

Дайте каждому шлюзу собственную идентичность узла вместо клонирования одной клиентской конфигурации на весь парк. Когда устройство заменяют, отзывайте старую идентичность в тот же момент, когда включаете новую, иначе останутся две неуправляемые копии, аутентифицирующиеся на одной конечной точке. Храните ключи там, где их ожидает плоскость управления шлюза, относитесь к резервной копии конфигурации как к секрету и проверяйте, кто может отправлять эту конфигурацию, потому что теперь это определяет, куда может добраться старый хост.

Разрешайте службы, а не сети

Напишите политику в терминах протокола, порта и направления между двумя подключениями. Один разрешённый порт к одному адресу приложения — обычный ответ, а административный путь через промежуточный хост покрывает остальное.

Удалённое администрирование старого хоста не должно идти по тому же правилу, что и приложение, и проверка отказа так же важна, как написание правила. Отправьте один запрос с хоста на пункт назначения, который должен быть отклонён, и подтвердите, что отказ исходит из политики, а не из отсутствующего маршрута. Записывайте разрешённые потоки, пока проект новый, чтобы видеть, что приложение действительно использует, а не что утверждает его документация. Объединение двух подсетей потому, что учебник с мостом выглядел короче, — это способ, которым старый сегмент тихо становится плацдармом.

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

Восстановление должно работать без туннеля

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

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

Сертификаты, часы и предупреждения о подписи

Истечение срока сертификата установщика само по себе не предсказывает, что сегодня скажет проверка подписи. Руководство Microsoft по временным меткам Authenticode объясняет, что временная метка может сохранить подпись проверяемой после истечения срока сертификата подписи, и проверка по-прежнему зависит от подписи, цепочки доверия и проверяющего. Поэтому две машины с разными хранилищами доверия могут расходиться во мнениях об одном и том же файле. Истёкший подписант не является доказательством того, что бинарный файл вредоносен, а действительная подпись не является доказательством того, что программное обеспечение поддерживается.

Не переводите системные часы назад и не отключайте проверки подписи, чтобы запустить старый установщик. Получите авторизованный артефакт у того, кто всё ещё поддерживает приложение, и пусть они скажут, что принимает платформа. Публикации, утверждающие, что определённая сборка была последней для XP, воспринимайте как историю, а не как цель установки, потому что реальное требование зависит от приложения; если работа по сохранению действительно нужна, держите её на изолированном сегменте вдали от производственного доступа и документируйте, почему она существует.