TLS VPN против IPsec: пять полей, которые стоит проверить

Сортировка TLS VPN против IPsec VPN по семейству протоколов отвечает на вопрос, которого никто не задавал, и обычно ссылается на конструкцию, от которой оба семейства отказались годы назад. То, что проверяющий действительно может оценить, — это согласованная защита, идентичность узла, модель клиента и открытый сервис. Эти четыре вещи видны в развёртывании, и ни одна из них не следует из этикетки продукта. Попросите пять полей, и разговор станет конкретным.

Пять полей, и этикетки среди них нет

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

Этикетка SSL VPN охватывает как минимум три разных продукта: полноценный сетевой клиент, прокси приложений и устаревший портал на основе браузера. Они открывают разные сервисы и отказывают по-разному, поэтому этикетка не может заменить поле охвата.

Что на самом деле меняет аутентифицированное шифрование

TLS 1.3 требует аутентифицированного шифрования, что убирает из протокола более старую конструкцию MAC-then-encrypt, а не оставляет её необязательной. В IPsec ESP наборы аутентифицированного шифрования существуют столь же давно, причём AES-GCM определён в отдельном RFC. В обоих семействах гарантия исходит из согласованного набора, а не из названия семейства, поэтому список полей начинается с версии. Проверяющему, который не может назвать набор, нечего оценивать.

Поэтому историческое сравнение вводит в заблуждение. Развёртывание, закреплённое на старой версии TLS с набором CBC, и другое, где работает TLS 1.3 с набором AEAD, — это не одна и та же позиция безопасности, хотя оба являются TLS VPN. Тот же раскол есть на стороне IPsec между современным набором ESP и устаревшей комбинацией.

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

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

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

Идентичность узла — отдельный вопрос

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

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

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

Граница, которую открывает продукт

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

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

Охват на уровне приложения ещё сужает поверхность и меняет поведение при отказе, когда туннель падает. Проект, предполагающий полный охват туннеля, ломается так, как проект на уровне приложения не ломается, и нагрузка на поддержку следует за этим.

Решите результат отказа и жизненный цикл

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

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

Запишите пять полей, политику отказа и владельца жизненного цикла на одну страницу. Эта страница — проверка; сравнение семейств протоколов — мнение.