Дали TLS обвивката ви дава приватна мрежа? Обично не

TLS штити канал меѓу два краја и не кажува ништо за тоа кои услуги се наоѓаат внатре. Обвивката го претвора тој канал во еден конфигуриран препраќач, за еден слушател, кон една дестинација. Производот што се продава како SSL VPN обично додава интерфејс, табела за рутирање и модел на пристап околу истиот примитив. Мешањето на двете е начинот на кој функционален тунел се замени за мрежен пристап.

Што всушност поврзува обвивката на услугата

Обвивката слуша на локален порт и го препраќа она што пристигнува кон конфигурирана дестинација, било тоа да е домаќин и порт или локална програма. Таа дестинација ја избира тој што ја напишал конфигурациската датотека, еден слушател по еднаш. Инсталирањето на пакетот не создава рути, виртуелен интерфејс или достапност за ништо што не е експлицитно наведено. Читајте ја конфигурацијата пред описот на пакетот, бидејќи описот покрива класа на употреба, а датотеката ја покрива вашата.

Затоа корисното прашање за обвивката не е дали таа шифрира, туку што стои на секој крај од синџирот што таа го гради.

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

Читајте го тој синџир од конфигурацијата, а не од маркетинг името. Секоја стрелка е посебен мрежен скок со сопствена адреса и сопствени правила за пристап.

Најдете каде завршува TLS каналот

Ако обвивката го завршува TLS, сѐ што препраќа понатаму е нова врска со нови својства. Текот може да биде отворен текст на приватен сегмент, или во себе да носи друг заштитен протокол. Да се претпостави било кое од двете без читање на конфигурацијата на backend е начинот на кој луѓето доаѓаат до заклучок дека надворешниот слој штити податоци што веќе не ги гледа. Препратениот скок заслужува сопствена проверка, на сопствена адреса и порт.

Проверете го слушателот и backend одделно, бидејќи успешното ракување на влезната врата не кажува ништо за услугата зад неа.

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 што автентификува клиент сѐ уште бара авторизација која кажува на кои ресурси клиентот смее да пристапи, а обвивката што автентификува партнер сѐ уште бара backend што ги спроведува сопствените дозволи.

Има легитимна комбинација: VPN протокол пренесен внатре во TLS обвивка на намерно поддржан TCP распоред. Тоа наредува два слоја и не ги прави обвивката и VPN исти вид објект.

Споредете ја границата што откажува

Запишете ја адресата на предниот крај, слушателот, идентитетот на партнерот, целта на backend и операцијата на апликацијата пред да промените нешто. Потоа споредете споредливо со споредливо: успех преку друго име на домаќин или порт не докажува дека условите на ѕидот и сертификатот биле идентични.

Одбиено барање до backend никогаш не треба да се поправа со исклучување на проверката на идентитетот на предниот крај. Тоа заменува дијагностицирана грешка во авторизацијата со недијагностицирана грешка во довербата.

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

Прицврстувањето на името на избрана адреса го одделува решавањето имиња од достапноста, и тоа обично е најбрзиот начин да се открие кое од двете е расипано.

Споредбата што е важна ги именува заштитениот пар крајни точки, пренесениот товар, апликациите што го користат и дозволата што се спроведува на дестинацијата. TLS придонесува за тој опис, но не го комплетира.