Gibt ein TLS-Wrapper dir ein privates Netzwerk? Meistens nicht
Ein Wrapper schützt eine konfigurierte Verbindung zwischen seinen Endpunkten. Ein geroutetes VPN überträgt den Verkehr jeder Anwendung, was ein anderes Zugriffsmodell ist.
TLS schützt einen Kanal zwischen zwei Endpunkten und sagt nichts darüber, welche Dienste darin sitzen. Ein Wrapper macht diesen Kanal zu einem einzigen konfigurierten Weiterleiter, für einen Listener, zu einem Ziel. Ein als SSL VPN verkauftes Produkt ergänzt um dieselbe Grundfunktion meist eine Schnittstelle, eine Routentabelle und ein Zugriffsmodell. Die beiden zu verwechseln ist der Grund, warum ein funktionierender Tunnel für Netzzugang gehalten wird.
Was ein Dienst-Wrapper tatsächlich verbindet
Ein Wrapper lauscht auf einem lokalen Port und leitet das Ankommende an ein konfiguriertes Ziel weiter, entweder einen Host und Port oder ein lokales Programm. Dieses Ziel wählt, wer die Konfigurationsdatei geschrieben hat, jeweils ein Listener. Die Installation des Pakets erzeugt keine Routen, keine virtuelle Schnittstelle und keine Erreichbarkeit für irgendetwas, das nicht ausdrücklich aufgeführt ist. Lies die Konfiguration vor der Paketbeschreibung, denn die Beschreibung deckt eine Nutzungsklasse ab und die Datei deckt deine ab.
Die nützliche Frage an einen Wrapper ist also nicht, ob er verschlüsselt, sondern was an jedem Ende der Kette steht, die er aufbaut.
application -> local listener -> TLS connection -> remote listener -> configured backend
Lies diese Kette aus der Konfiguration statt aus dem Marketingnamen. Jeder Pfeil ist ein eigener Netzwerksprung mit eigener Adresse und eigenen Zugriffsregeln.
Finde, wo der TLS-Kanal endet
Beendet der Wrapper TLS, ist alles, was er weiterleitet, eine neue Verbindung mit neuen Eigenschaften. Der Strom kann im Klartext auf einem privaten Segment liegen oder ein anderes geschütztes Protokoll in sich tragen. Eines von beidem anzunehmen, ohne die Backend-Konfiguration zu lesen, ist der Grund, aus dem Leute schließen, die äußere Schicht schütze Daten, die sie nie wieder sieht. Der weitergeleitete Sprung verdient eine eigene Prüfung, auf eigener Adresse und eigenem Port.
Prüfe Listener und Backend getrennt, denn ein erfolgreicher Handshake an der Vordertür sagt nichts über den Dienst dahinter.
ss -ltnp | grep -F 443 openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates
Der erste Befehl zeigt, welcher Prozess den Port besitzt und auf welcher Adresse er lauscht. Der zweite gibt das Zertifikat aus, das der Client tatsächlich erhält, und das ist die Identitätsprüfung, die eine Portnummer nicht ersetzen kann.
Was ein geroutetes VPN hinzufügt und ein Wrapper nicht
Ein geroutetes VPN installiert eine Schnittstelle, übernimmt die Kontrolle über ausgewählte Präfixe und integriert sich in Routing und Zugriffsrichtlinie des Hosts. Jede Anwendung auf der Maschine profitiert, ohne vom Tunnel zu wissen. Ein Wrapper gibt diese Reichweite einem einzigen konfigurierten Listener und hört dort auf.
Die Zulassung ist wieder etwas anderes. Ein VPN, das einen Client authentifiziert, braucht trotzdem eine Autorisierung, die angibt, welche Ressourcen der Client erreichen darf, und ein Wrapper, der einen Peer authentifiziert, braucht trotzdem ein Backend, das seine eigenen Berechtigungen durchsetzt.
Es gibt eine legitime Kombination: ein VPN-Protokoll, das in einem TLS-Wrapper über eine bewusst unterstützte TCP-Anordnung transportiert wird. Das stapelt zwei Schichten und macht Wrapper und VPN nicht zur selben Art von Objekt.
Vergleiche die Grenze, die versagt
Schreibe die Frontend-Adresse, den Listener, die Peer-Identität, das Backend-Ziel und die Anwendungsoperation auf, bevor du etwas änderst. Vergleiche dann Gleiches mit Gleichem: ein Erfolg über einen anderen Hostnamen oder Port beweist nicht, dass die Firewall- und Zertifikatsbedingungen identisch waren.
Eine abgelehnte Backend-Anfrage sollte niemals durch Abschalten der Frontend-Identitätsprüfung repariert werden. Das tauscht einen diagnostizierbaren Autorisierungsfehler gegen einen nicht diagnostizierbaren Vertrauensfehler.
curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30
Den Namen an eine gewählte Adresse zu binden trennt Namensauflösung von Erreichbarkeit, was meist der schnellste Weg ist, um zu erkennen, welches der beiden kaputt ist.
Der Vergleich, auf den es ankommt, benennt das geschützte Endpunktpaar, die transportierte Nutzlast, die Anwendungen, die sie nutzen, und die am Ziel durchgesetzte Berechtigung. TLS trägt zu dieser Beschreibung bei, ohne sie zu vervollständigen.