Чи дає обгортка TLS приватну мережу? Зазвичай ні

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 робить внесок у цей опис, але не завершує його.