Ці дае 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 дапамагае гэтаму апісанню, але не завяршае яго.