VPN или TLS: как выбрать технологию защищенного подключения

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

Нужно связать офис и ЦОД, филиалы или сегмент АСУ ТП, дать доступ к RDP, файловым ресурсам и толстым клиентам – это территория VPN. Нужно опубликовать веб-приложения для сотрудников, подрядчиков и внешних пользователей, в том числе с неуправляемых устройств, – это территория TLS-шлюза в режиме прокси.

Принципиальная разница: уровень, на котором работает защита

VPN и TLS ставят в один ряд, потому что обе технологии «шифруют трафик». Но точка приложения у них разная, и именно она определяет все остальное: состав клиентского ПО, гранулярность контроля доступа, объем метаданных, видимых в канале, и трудоемкость эксплуатации.

• VPN работает под приложениями. Классический IPsec встраивается в обработку IP-пакета на сетевом уровне: приложение отправляет пакет обычным способом, стек операционной системы или криптошлюз перехватывает его, шифрует и упаковывает в новый пакет. Приложение о туннеле не знает и переделывать его не нужно. OpenVPN и WireGuard устроены иначе технически – туннель поднимается поверх UDP или TCP, – но с точки зрения приложения ведут себя так же: это виртуальный сетевой интерфейс.

• TLS работает внутри приложения. Соединение защищает не сеть, а само приложение: браузер, почтовый клиент, драйвер СУБД, библиотека HTTP-клиента. Защищена ровно одна TCP-сессия; все остальное, что делает тот же хост, идет мимо этой защиты.

• Отсюда практическое следствие, которое чаще всего упускают при проектировании: VPN дает связность, TLS дает доступ к сервису. Это не синонимы, и подменять одно другим без пересмотра модели угроз нельзя.

🔍 Увеличить

×

Схема 1. Уровень обработки трафика и структура пакета: что именно шифруется в VPN и в TLS

Что остается видимым в канале

Разница хорошо видна по метаданным. В туннельном режиме IPsec наружу выходят только адреса криптошлюзов: внутренняя адресация, номера портов, состав опубликованных сервисов и сам факт обращения к конкретной системе скрыты. У TLS видны IP-адреса и порты обеих сторон, размеры и тайминги записей, а также имя запрашиваемого сервера в поле SNI – оно передается открытым текстом и в TLS 1.2, и в TLS 1.3, если не задействовано расширение Encrypted Client Hello, которое пока не является общепринятым. Для многих задач это несущественно, но для значимых объектов КИИ и систем, где чувствителен сам факт обращения, разница принципиальная.

Справедливо и обратное. Скрытность IPsec не бесплатна: криптошлюз видит только IP-пакеты и не понимает, легитимный ли внутри запрос к учетной системе или выгрузка базы наружу. Контроль содержимого приходится строить отдельным слоем – межсетевым экраном нового поколения, DLP, прикладным прокси.

VPN: защита на уровне сети

Как это устроено

В основе корпоративного VPN лежит IPsec – набор протоколов, где IKEv2 отвечает за взаимную аутентификацию сторон и согласование ключей, а ESP – за шифрование и контроль целостности самих пакетов. В туннельном режиме исходный IP-пакет целиком помещается внутрь нового: наружу видны только адреса шлюзов. В транспортном режиме исходный заголовок сохраняется, поэтому он применяется в основном между конечными узлами.

В российских проектах под VPN почти всегда понимают ГОСТ VPN – тот же IPsec, но с отечественной криптографией: блочные шифры «Кузнечик» и «Магма» по ГОСТ Р 34.12-2015, хэширование по ГОСТ Р 34.11-2012, электронная подпись по ГОСТ Р 34.10-2012.

Реализуют его сертифицированные криптошлюзы – ViPNet Coordinator, «С-Терра Шлюз», «Континент», «Застава», Dionis. Ключевое отличие от зарубежного IPsec лежит не столько в криптографии, сколько в режиме эксплуатации: СКЗИ требует формуляров, поэкземплярного учета, журналов ключевых документов и соблюдения правил пользования.

Два сценария применения

Site-to-site связывает сети целиком. Криптошлюзы стоят на границах площадок, туннель поднимается один раз и держится постоянно, маршрутизация направляет в него нужные подсети. Пользователи и серверы о туннеле не знают. Это основной способ соединить офис с ЦОД, головную организацию с филиалами, а также вынести сегмент АСУ ТП на удаленную площадку.

Remote access дает доступ отдельным пользователям. На устройстве работает VPN-клиент с СКЗИ, при подключении он проходит аутентификацию на концентраторе и получает адрес из пула. С этого момента устройство фактически становится узлом корпоративной сети – со всеми вытекающими последствиями для модели угроз.

🔍 Увеличить

×

Схема 2. Топологии VPN: постоянный канал между площадками и удаленный доступ пользователей

Преимущества VPN

• Прозрачность для приложений. Ничего не нужно переписывать и перенастраивать: работают легаси-системы, толстые клиенты, самописный софт без поддержки TLS.

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

• Поддержка любых протоколов. UDP, мультикаст, ICMP, промышленные протоколы АСУ ТП, телефония, репликация СУБД – то, что через HTTP-прокси не проходит в принципе.

• Сокрытие топологии и метаданных. Внешний наблюдатель не видит внутренней адресации и состава сервисов.

• Единая точка криптографии. Ключи и алгоритмы сосредоточены на шлюзах, а не размазаны по десяткам приложений.

• Зрелая сертифицированная база. Российские криптошлюзы имеют многолетнюю практику внедрения и понятную регуляторную позицию.

Недостатки и риски VPN

• «Плоский» доступ в сеть. Подключенный клиент становится сетевым узлом. Без микросегментации, контроля состояния устройства и ограничения маршрутов компрометация одного ноутбука равна проходу за периметр. Это самый частый и самый дорогой архитектурный дефект.

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

• Слепая зона по содержимому. Шлюз не разбирает прикладной трафик и не отличает работу в 1С от эксфильтрации данных.

• Транспортные сложности. ESP нередко режется провайдерами и гостевыми сетями, требуется NAT-T на UDP/4500. Инкапсуляция уменьшает полезный MTU: без корректировки MSS появляется фрагментация и труднодиагностируемые «зависания» отдельных приложений.

• Производительность под нагрузкой. Паспортные цифры криптошлюзов обычно приводятся для крупных кадров. На реальном профиле трафика, близком к IMIX, и при большом числе одновременных сессий результат отличается в разы – проверять нужно на своем профиле по методике, сопоставимой с RFC 2544.

• Организационная нагрузка. Учет СКЗИ, ключевые документы, ограничения на изменение конфигурации, обученный персонал, требования к помещениям для отдельных классов.

TLS: защита на уровне соединения

TLS устанавливает защищенное соединение поверх TCP. В ходе рукопожатия стороны согласуют версию протокола и криптонабор, сервер (а при взаимной аутентификации – и клиент) предъявляет сертификат, вырабатывается сеансовый ключ, после чего прикладные данные передаются в виде зашифрованных записей. TLS 1.3 сократил рукопожатие до одного круга, убрал устаревшие механизмы обмена ключами и шифрует большую часть служебных сообщений, включая сертификат сервера.

Российские криптонаборы для TLS стандартизованы: для TLS 1.2 это рекомендации по стандартизации Р 1323565.1.020-2020, опубликованные также как RFC 9189, для TLS 1.3 – Р 1323565.1.030-2020 и RFC 9367. Идентификаторы криптонаборов внесены в реестр IANA, то есть ГОСТ-режим TLS является международно зарегистрированным, а не самодельным расширением. На клиентской стороне ГОСТ-криптография обеспечивается СКЗИ (КриптоПро CSP, ViPNet CSP и аналоги) в связке с браузером, поддерживающим отечественные алгоритмы.

Разгружать веб-серверы и централизовать ГОСТ-криптографию призван TLS-шлюз (TLS-криптошлюз). На российском рынке это «КриптоПро NGate», «Континент TLS» (развивается под названием «Континент WEB»), ViPNet TLS Gateway, «С-Терра TLS». Именно у TLS-шлюза есть два принципиально разных режима работы, которые в проектной документации регулярно путают между собой.

Режим прокси: терминация TLS и портал приложений

В режиме прокси шлюз выступает обратным прокси-сервером. Он завершает («терминирует») ГОСТ-соединение от клиента, расшифровывает запрос, проверяет пользователя и его права, разбирает HTTP и только после этого открывает собственное соединение к внутреннему веб-серверу. Криптосессий получается две, и они независимы: между клиентом и шлюзом может использоваться ГОСТ, а между шлюзом и сервером – обычный TLS с RSA/AES или вовсе открытый HTTP внутри доверенной зоны.

🔍 Увеличить

×

Схема 3. Режим прокси: две независимые криптосессии, разбор HTTP и публикация конкретных приложений

Практические следствия режима прокси:

• клиенту не нужен агент – достаточно браузера и СКЗИ, поэтому режим подходит для подрядчиков, BYOD и внешних пользователей, на устройства которых нельзя ставить корпоративное ПО;

• публикуются приложения и отдельные URL, а не подсети, поэтому поверхность атаки заметно уже;

• контроль доступа возможен на прикладном уровне: по URL, HTTP-методу, заголовкам, cookie, роли пользователя из каталога; отсюда естественная интеграция с WAF, SSO и SIEM;

• клиент не получает адрес в локальной сети и не видит соседние сервисы;

• работают только HTTP(S)-приложения – RDP, SMB, SSH и толстые клиенты через этот режим не пройдут.

Разновидность режима – «портал приложений»: единая точка входа, где после аутентификации пользователю показывается список доступных ему ресурсов, а разграничение выполняется по данным каталога LDAP или Active Directory.

Режим туннеля: SSL VPN на базе TLS

В режиме туннеля TLS используется как транспорт для произвольного трафика. На устройстве устанавливается специализированный клиент, который создает виртуальный сетевой адаптер и получает IP-адрес из пула. Пакеты приложений инкапсулируются, отправляются внутри TLS-соединения (как правило, на TCP/443), а шлюз распаковывает их и маршрутизирует в корпоративный сегмент. Функционально это VPN удаленного доступа, просто построенный не на IPsec, а на TLS.

🔍 Увеличить

×

Схема 4. Режим туннеля: единая TLS-сессия переносит инкапсулированные IP/TCP-пакеты

Практические следствия режима туннеля:

• работает все, что использует TCP: RDP, SSH, файловые ресурсы, толстый клиент 1С, клиенты СУБД;

• нужен агент и права на его установку, поэтому неуправляемые устройства фактически отпадают;

• контроль доступа опускается на сетевой и транспортный уровень – адрес, порт, маршрут; разбора HTTP и логики WAF здесь нет;

• клиент снова становится узлом сети, то есть возвращается главный риск классического VPN удаленного доступа;

• туннелирование TCP внутри TCP плохо переносит потери: два уровня повторных передач начинают конфликтовать, и на плохом канале скорость падает сильнее, чем у IPsec поверх UDP.

Режимы работы TLS-шлюза: прокси и туннель

Терминологическая ловушка

Слово «прокси» в контексте TLS используют минимум в трех разных значениях, и обсуждение архитектуры часто буксует именно из-за этого:

1. Обратный прокси (TLS-шлюз). Тот случай, который разобран выше: шлюз терминирует ГОСТ-соединение от клиента и проксирует запрос к внутреннему серверу.

2. Прямой прокси с методом CONNECT. Браузер просит прокси-сервер открыть TCP-соединение к внешнему узлу и прокладывает через него собственный TLS. Прокси видит только имя хоста и порт, содержимое не расшифровывается. Это тоже называют «туннелем», но с TLS-туннелем шлюза он не имеет ничего общего.

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

Перед проектированием стоит убедиться, что все участники обсуждения имеют в виду одно и то же – это экономит недели переделок.

Преимущества TLS

• Гранулярность доступа. Публикуется приложение, а не сеть. Пользователь получает ровно тот сервис, который ему нужен, и не видит остальных.

• Работа без агента. В режиме прокси достаточно браузера, поэтому технология пригодна для подрядчиков, партнеров, граждан и любых неуправляемых устройств.

• Прикладной контекст в журналах. Видно, кто, когда и к какому ресурсу обращался, а не только «была сессия с адреса».

• Простое масштабирование. Горизонтальное наращивание и балансировка на прикладном уровне даются проще, чем кластеризация криптошлюзов с переносом состояний.

• Разгрузка серверов. ГОСТ-криптография выносится на шлюз, приложения остаются без изменений – это часто единственный реальный способ перевести legacy-портал на отечественные алгоритмы.

• Нет влияния на MTU. Не появляется фрагментация и связанные с ней трудноуловимые сбои.

Недостатки и риски TLS

• Только TCP и, в режиме прокси, только HTTP. Промышленные протоколы, мультикаст и UDP-сервисы остаются за бортом.

• Открытые метаданные. IP-адреса, порты и имя сервера в SNI видны наблюдателю; факт обращения к конкретному ресурсу не скрыт.

• Зависимость от клиентской криптографии. Нужны СКЗИ на рабочем месте, совместимый браузер и корректно выпущенные сертификаты. Обновление ОС или браузера способно сломать доступ.

• Стоимость рукопожатия. Операции с ГОСТ Р 34.10-2012 заметно нагружают процессор. Профиль «много коротких сессий» упирается не в мегабиты, а в число рукопожатий в секунду – этот параметр и надо закладывать в требования.

• Шлюз становится критичным узлом. Он держит закрытые ключи, видит расшифрованный трафик и является единой точкой отказа; резервирование и защита самого шлюза обязательны.

• Риск переоценки защищенности. TLS защищает канал, но не приложение. Уязвимое веб-приложение остается уязвимым – просто эксплуатируется по зашифрованному каналу.

Сводное сравнение VPN и TLS

VPN и TLS: сравнение по ключевым критериям выбора

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

Точкой терминации VPN при этом все чаще выступает межсетевой экран нового поколения, который заодно дает контроль содержимого внутри туннеля.

Регуляторный контекст: что учитывать в России

Выбор технологии в российской практике редко бывает чисто инженерным. Как только в системе есть персональные данные, государственная информация или значимый объект КИИ, вступают в силу требования ФСБ России к криптографии и ФСТЭК России к защите информации.

Криптография: класс СКЗИ определяется моделью нарушителя

И ГОСТ VPN, и ГОСТ TLS реализуются средствами криптографической защиты информации, сертифицированными ФСБ России. Классы СКЗИ – КС1, КС2, КС3, КВ1, КВ2, КА1 – различаются тем, какого нарушителя средство обязано выдержать: от внешнего, действующего за пределами контролируемой зоны (КС1), до нарушителя, располагающего возможностями специализированных научных центров (КА1). Класс не выбирается «по желанию»: он вытекает из модели угроз и нарушителя.

• для информационных систем персональных данных ориентиры задают постановление Правительства Российской Федерации от 01.11.2012 № 1119 (уровни защищенности) и приказ ФСБ России от 10.07.2014 № 378, увязывающий уровень защищенности с минимально допустимым классом СКЗИ;

• общие правила разработки и эксплуатации шифровальных средств установлены приказом ФСБ России от 09.02.2005 № 66 (ПКЗ-2005);

• практический вывод: для КС2 и особенно КС3 появляются требования к среде функционирования – доверенная загрузка, контроль доступа в помещения, ограничения на состав ПО. Это влияет на стоимость проекта сильнее, чем цена самих лицензий.

Требования по защите информации

• Государственные информационные системы. С 1 марта 2026 года действует приказ ФСТЭК России от 11.04.2025 № 117, заменивший приказ № 17 от 2013 года. Состав мероприятий и мер детализирован отдельным методическим документом ФСТЭК России 2026 года.

• Персональные данные. На момент подготовки материала действует приказ ФСТЭК России от 18.02.2013 № 21. При этом регулятором вынесен на общественное обсуждение проект приказа, отменяющего его и вводящего иной состав мер, – статус документа перед публикацией необходимо проверить по первоисточнику.

• Критическая информационная инфраструктура. Требования к значимым объектам установлены приказом ФСТЭК России от 25.12.2017 № 239; для субъектов КИИ дополнительно действуют обязанности по взаимодействию с ГосСОПКА.

• Средства защиты. Межсетевые экраны, включая шлюзы, на которых терминируется удаленный доступ, должны соответствовать профилям защиты ФСТЭК России; требования к многофункциональным межсетевым экранам уровня сети установлены приказом ФСТЭК России от 07.03.2023 № 44. Для закупок значение имеет также наличие продукта в реестре российского ПО.

Как выбрать: дерево решений

Практический алгоритм умещается в четыре вопроса. Отвечать на них нужно по порядку – первый утвердительный ответ дает решение для этого сценария.

🔍 Увеличить

×

Схема 5. Дерево выбора технологии защищенного подключения

Типовые сценарии и подходящие решения

Семь ошибок, которые дорого обходятся

1. Считать, что VPN сам по себе является контролем доступа. Туннель обеспечивает конфиденциальность канала, а не разграничение прав. Без сегментации и списков доступа он лишь надежно доставляет злоумышленника внутрь.

2. Выдавать удаленным пользователям доступ ко всей подсети. Правило «разрешить 10.0.0.0/8» в конфигурации концентратора – типовая находка при аудите.

3. Путать режимы TLS-шлюза на этапе ТЗ. Закупается портальный режим, а бизнес ждет RDP и файловые ресурсы. Выясняется это на приемке.

4. Игнорировать сайзинг по рукопожатиям. Шлюз, рассчитанный по пропускной способности, ложится на массовом одновременном входе пользователей утром.

5. Забывать про MTU. Симптом – «почта работает, а 1С зависает на больших документах». Лечится корректировкой MSS, но ищется долго.

6. Не планировать жизненный цикл сертификатов и ключей. Просроченный сертификат шлюза останавливает работу тысяч пользователей одномоментно.

7. Оставлять шлюз без резервирования и мониторинга. И VPN-концентратор, и TLS-шлюз – единая точка отказа для всего удаленного доступа.

Чек-лист выбора решения

• Определены сценарии доступа: связь площадок, пользователи, интеграции сервисов.

• Составлен перечень приложений с указанием протоколов: что действительно веб, а что нет.

• Определена модель угроз и нарушителя, из нее выведен требуемый класс СКЗИ.

• Проверена категория системы: ГИС, ИСПДн, значимый объект КИИ, АСУ ТП – и применимые приказы.

• Оценено число одновременных пользователей и профиль подключений (постоянные сессии или частые входы).

• Заданы требования по производительности: пропускная способность на профиле IMIX и число рукопожатий в секунду.

• Проверена совместимость клиентской части: операционные системы, браузеры, СКЗИ, мобильные платформы.

• Продуман сценарий для неуправляемых устройств и подрядчиков.

• Заложены многофакторная аутентификация и проверка состояния рабочего места.

• Спроектирована микросегментация: что именно доступно после подключения.

• Определена схема отказоустойчивости и обслуживания без простоя.

• Продуман жизненный цикл сертификатов и ключевых документов, включая отзыв и плановую замену.

• Настроена передача событий в SIEM и, при необходимости, в ГосСОПКА.

• Проверено наличие продукта в реестре российского ПО и действующих сертификатов ФСБ и ФСТЭК России.

• Запланировано нагрузочное тестирование на пилоте до закупки основного объема лицензий.

Подведем итог

Спор «VPN против TLS» на практике почти всегда оказывается спором о неверно поставленном вопросе. Правильная формулировка звучит иначе: какой слой защиты закрывает какой сценарий доступа. ГОСТ VPN дает связность сетей и работает с любыми протоколами, но выдает пользователю кусок корпоративной сети и требует агента на каждом устройстве. TLS-шлюз дает точечный доступ к приложениям, обходится без агента в режиме прокси и приносит прикладной контекст в журналы, но ограничен HTTP и не скрывает метаданные. Осознанная архитектура почти всегда сочетает оба слоя, а не выбирает один.

И последнее, что стоит проверить до закупки: соответствуют ли заявленные производителем показатели вашему реальному профилю трафика и числу одновременных подключений. Разница между паспортными и фактическими значениями на пилоте – самая частая причина пересмотра проекта уже после внедрения.

Часто задаваемые вопросы