Un wrapper TLS vous donne-t-il un réseau privé ? Généralement non

TLS protège un canal entre deux extrémités et ne dit rien des services qui s’y trouvent. Un wrapper transforme ce canal en un seul redirecteur configuré, pour un seul écouteur, vers une seule destination. Un produit vendu comme SSL VPN ajoute généralement une interface, une table de routage et un modèle d’accès autour de la même primitive. Confondre les deux, c’est ainsi qu’un tunnel fonctionnel est pris pour un accès au réseau.

Ce qu’un wrapper de service relie réellement

Un wrapper écoute sur un port local et redirige ce qui arrive vers une destination configurée, qu’il s’agisse d’un hôte et d’un port ou d’un programme local. Cette destination est choisie par celui qui a écrit le fichier de configuration, un écouteur à la fois. L’installation du paquet ne crée ni routes, ni interface virtuelle, ni atteignabilité pour quoi que ce soit qui ne soit pas explicitement listé. Lisez la configuration avant la description du paquet, car la description couvre une classe d’usage et le fichier couvre le vôtre.

La bonne question sur un wrapper n’est donc pas de savoir s’il chiffre, mais ce qui se trouve à chaque extrémité de la chaîne qu’il construit.

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

Lisez cette chaîne dans la configuration plutôt que dans le nom commercial. Chaque flèche est un saut réseau distinct avec sa propre adresse et ses propres règles d’accès.

Trouvez où se termine le canal TLS

Si le wrapper termine TLS, tout ce qu’il redirige ensuite est une nouvelle connexion aux propriétés nouvelles. Le flux peut être en clair sur un segment privé, ou transporter un autre protocole protégé à l’intérieur. Supposer l’un ou l’autre sans lire la configuration du backend, c’est ainsi que l’on conclut que la couche externe protège des données qu’elle ne revoit jamais. Le saut relayé mérite sa propre inspection, sur sa propre adresse et son propre port.

Vérifiez l’écouteur et le backend séparément, car une poignée de main qui réussit à la porte d’entrée ne dit rien du service derrière.

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

La première commande montre quel processus possède le port et sur quelle adresse il écoute. La seconde imprime le certificat que le client reçoit réellement, et c’est le contrôle d’identité qu’un numéro de port ne peut pas remplacer.

Ce qu’un VPN routé ajoute et qu’un wrapper ne fait pas

Un VPN routé installe une interface, prend possession de préfixes choisis et s’intègre au routage et à la politique d’accès de l’hôte. Chaque application de la machine en profite sans savoir que le tunnel existe. Un wrapper donne cette portée à un seul écouteur configuré et s’arrête là.

L’admission est encore autre chose. Un VPN qui authentifie un client a toujours besoin d’une autorisation qui dit à quelles ressources il peut accéder, et un wrapper qui authentifie un pair a toujours besoin d’un backend qui applique ses propres permissions.

Il existe une combinaison légitime : un protocole VPN transporté dans un wrapper TLS sur un agencement TCP délibérément pris en charge. Cela empile deux couches et ne fait pas du wrapper et du VPN le même type d’objet.

Comparez la frontière qui échoue

Notez l’adresse frontale, l’écouteur, l’identité du pair, la cible du backend et l’opération applicative avant de changer quoi que ce soit. Comparez ensuite ce qui est comparable : un succès via un autre nom d’hôte ou un autre port ne prouve pas que les conditions du pare-feu et du certificat étaient identiques.

Une requête backend rejetée ne devrait jamais être réparée en désactivant la vérification d’identité frontale. Cela échange un échec d’autorisation diagnosticable contre un échec de confiance non diagnosticable.

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

Épingler le nom sur une adresse choisie sépare la résolution de noms de l’atteignabilité, ce qui est généralement le moyen le plus rapide de savoir lequel des deux est cassé.

La comparaison qui compte nomme la paire d’extrémités protégées, la charge transportée, les applications qui l’utilisent et la permission appliquée à la destination. TLS contribue à cette description sans la compléter.