Да ли вам 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 доприноси том опису, али га не употпуњује.