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

Что на самом деле соединяет обёртка службы

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

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

application -> local listener -> TLS connection -> remote listener -> configured backend

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

Найдите, где заканчивается канал TLS

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

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

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

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

Что добавляет маршрутизируемый VPN, а обёртка нет

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

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

Есть законное сочетание: протокол VPN, переносимый внутри обёртки TLS на намеренно поддерживаемой схеме TCP. Это складывает два слоя и не делает обёртку и VPN одним и тем же видом объекта.

Сравните границу, которая даёт сбой

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

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

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

Закрепление имени за выбранным адресом отделяет разрешение имён от доступности, и обычно это самый быстрый способ понять, что из двух сломано.

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

Похожие статьи