Dává vám obal TLS privátní síť? Většinou ne

TLS chrání kanál mezi dvěma konci a neříká nic o tom, které služby v něm sedí. Obal promění tento kanál v jediný nakonfigurovaný přesměrovač: jeden posluchač, jeden cíl. Produkt prodávaný jako SSL VPN obvykle kolem stejného primitiva přidává rozhraní, směrovací tabulku a model přístupu. Zaměnit obojí je způsob, jakým se funkční tunel považuje za síťový přístup.

Co obal služby skutečně propojuje

Obal naslouchá na místním portu a to, co dorazí, přesměruje na nakonfigurovaný cíl, ať už jde o hostitele a port, nebo místní program. Tento cíl vybírá ten, kdo napsal konfigurační soubor, vždy jeden posluchač. Instalace balíčku nevytváří žádné trasy, žádné virtuální rozhraní ani dostupnost pro cokoli, co není výslovně uvedeno. Čtěte konfiguraci dříve než popis balíčku, protože popis pokrývá třídu použití a soubor to vaše.

Užitečná otázka o obalu tedy není, zda šifruje, ale co stojí na každém konci řetězce, který staví.

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

Čtěte tento řetězec z konfigurace, ne z marketingového názvu. Každá šipka je samostatný síťový skok s vlastní adresou a vlastními pravidly přístupu.

Najděte, kde kanál TLS končí

Pokud obal ukončuje TLS, vše, co dál předává, je nové spojení s novými vlastnostmi. Proud může být na privátním segmentu v otevřeném textu, nebo v sobě může nést jiný chráněný protokol. Předpokládat kteroukoli z těchto možností bez čtení konfigurace backendu je způsob, jakým lidé dospějí k závěru, že vnější vrstva chrání data, která už nikdy neuvidí. Přesměrovaný skok si zaslouží vlastní kontrolu, na své adrese a portu.

Kontrolujte posluchač a backend odděleně, protože úspěšný handshake u vchodových dveří nic neříká o službě za nimi.

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

První příkaz ukazuje, který proces vlastní port a na jaké adrese naslouchá. Druhý vypíše certifikát, který klient skutečně obdrží, což je kontrola identity, kterou číslo portu nahradit nemůže.

Co přidává směrovaná VPN a obal ne

Směrovaná VPN instaluje rozhraní, přebírá vlastnictví vybraných prefixů a integruje se se směrováním a přístupovou politikou hostitele. Každá aplikace na stroji z toho těží, aniž by věděla, že tunel existuje. Obal dává tento dosah jednomu nakonfigurovanému posluchači a tam končí.

Vpuštění je opět oddělené. VPN, která autentizuje klienta, stále potřebuje autorizaci, která říká, ke kterým zdrojům klient smí dosáhnout, a obal, který autentizuje protistranu, stále potřebuje backend, který vynucuje vlastní oprávnění.

Existuje legitimní kombinace: protokol VPN nesený uvnitř obalu TLS na záměrně podporovaném uspořádání TCP. To skládá dvě vrstvy a nedělá z obalu a VPN stejný druh objektu.

Porovnejte hranici, která selhává

Zapište adresu předního konce, posluchač, identitu protistrany, cíl backendu a operaci aplikace, než cokoli změníte. Pak porovnávejte srovnatelné: úspěch přes jiné jméno hostitele nebo port neprokazuje, že podmínky firewallu a certifikátu byly stejné.

Odmítnutý požadavek na backend by se nikdy neměl opravovat vypnutím ověřování identity na předním konci. To vyměňuje diagnostikovatelné selhání autorizace za nediagnostikovatelné selhání důvěry.

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

Připnutí jména k vybrané adrese odděluje překlad jmen od dostupnosti, což je obvykle nejrychlejší způsob, jak zjistit, které z těch dvou je rozbité.

Srovnání, na kterém záleží, pojmenovává chráněnou dvojici koncových bodů, přenášený obsah, aplikace, které jej používají, a oprávnění vynucované v cíli. TLS k tomuto popisu přispívá, aniž by jej dokončovalo.