Рабочий ноутбук в личном VPN: что на самом деле проходит

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

Начинайте с конечной точки, а не со схемы сети

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

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

Три точки пересечения, рассмотренные по отдельности

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

Идентичность и данные образуют вторую точку пересечения. Корпоративные учётные данные, сессионные cookie, загруженные документы и права управления находятся на конечной точке, и присоединение к другой сети само по себе их не раскрывает. Меняется набор сторон, которые могли бы влиять на конечную точку, пока она хранит эти учётные данные, а это вопрос о надёжности личной сети, а не о маршрутизации. Это суждение, которое владелец конечной точки не может вынести в одиночку, и на него не отвечает отсутствие правила переадресации.

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

Просите один ресурс, а не две сети

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

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

Учтите влияние DNS и маршрутов

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

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

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

Проверьте и оставьте путь к отступлению

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

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

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