Un hook de connexion est une politique de session, pas un filtre de paquets

Quelqu'un veut inspecter ce que les clients envoient par le tunnel, trouve le hook de connexion dans la documentation et commence à écrire un script qui ne recevra jamais un seul paquet. Le hook est réel et utile, mais son unité de travail est une session, pas un octet. Choisir le bon composant est une comparaison entre trois endroits où le travail peut se produire, et la question décisive est quelle unité chacun peut réellement voir.

Ce que le hook reçoit, et ce qu'il ne reçoit jamais

Un hook de connexion client s'exécute une fois lorsqu'un client authentifié établit une session, dans le contexte du processus du serveur, avec des arguments documentés et des valeurs d'environnement comme le nom commun et l'adresse attribuée. Il peut écrire une configuration par client, prendre une décision d'admission, allouer une ressource externe ou consigner que la connexion a eu lieu. Ce qu'il ne peut pas faire, c'est observer le trafic, car au moment où le premier paquet traverse le tunnel, le hook a déjà rendu la main.

Ce n'est pas une limitation à contourner. Un rappel de session qui tenterait de traiter un flux devrait s'exécuter pendant toute la durée de la connexion, et le contrat de script du démon n'est pas conçu pour cette forme. Demandez à quoi sert le hook avant de décider qu'il vous gêne.

Les reconnexions comptent aussi. Un client qui tombe et se reconnecte est une nouvelle session, donc tout ce que le hook alloue doit être idempotent ou associé à un événement de déconnexion qui nettoie. Un état qui fuit à chaque reconnexion est le premier bug habituel d'une conception fondée sur un hook.

La politique de session appartient au hook

L'admission est le travail naturel du hook. Vous savez qui s'est connecté, d'où et avec quel certificat, et vous pouvez décider si cette session doit continuer ou être refusée. Cette décision est bon marché, elle a lieu une fois et elle ne demande pas de regarder un seul octet de charge utile.

L'attribution de configuration relève de la même forme. Un hook peut sélectionner l'adresse du client, pousser des options adaptées à cette identité ou écrire un fragment que le serveur lit pour ce client. Comme la décision est par session, elle reste compréhensible quand quelque chose tourne mal et que quelqu'un doit expliquer pourquoi un client donné a reçu une adresse donnée.

L'enregistrement est la troisième adéquation. Une entrée d'audit qui dit qu'une session a été admise, avec son identité et son heure, appartient exactement ici. Ce n'est pas un journal de trafic et il ne doit pas prétendre l'être. Si quelqu'un demande plus tard ce qu'un client a fait à l'intérieur du tunnel, la réponse doit venir d'ailleurs.

Le travail sur les paquets appartient à un chemin de paquets

Si l'exigence est de voir ou de modifier des octets en vol, le composant doit se trouver sur le chemin de transfert : une règle de pare-feu avec une file, un hook de contrôle du trafic ou un transfert en espace utilisateur. Ces mécanismes voient les paquets, et ils ont leur propre état, leurs propres modes de défaillance et leur propre profil de performance.

Modifier la charge utile à cette couche est plus difficile que de la lire. Changer un octet peut invalider un champ de longueur, une somme de contrôle ou une machine à états de protocole, et un tunnel de couche trois ne vous protège de rien de tout cela. Cela signifie seulement que les en-têtes externes ne sont pas ceux que vous modifiez. Prévoyez ce travail de réparation avant de promettre à quiconque une réécriture de contenu.

Une capture d'interface est l'outil le moins cher de cette catégorie, et c'est une observation, pas un éditeur. Les gens confondent les deux parce que les deux sont décrits comme voir le trafic, mais une capture produit un fichier et un chemin de paquets produit une décision.

Les changements d'application appartiennent à l'application

Quand l'objectif est de changer ce que contient une requête ou la façon dont une réponse est formée, le bon endroit est le service lui-même ou un proxy qui termine le protocole exprès. Ces composants comprennent déjà les requêtes, les réponses et l'authentification que l'application attend, et c'est précisément le contexte qui manque à un filtre de paquets.

La traduction d'adresses est en bas de cette liste pour une raison. Elle réécrit les adresses et les ports et laisse la charge utile tranquille, donc ce n'est pas un outil de contenu, quelle que soit la fréquence à laquelle elle apparaît dans une recette qui mentionne aussi le contenu.

Garder ces frontières séparées est ce qui rend une conception explicable. Politique de session dans le hook, traitement des paquets sur un chemin de paquets et changement d'application là où le protocole est délibérément terminé : trois phrases qui servent aussi de liste de vérification pour la revue.

Là où TLS termine encore la conversation

Une chose survit à tout ce qui précède : le trafic à l'intérieur du tunnel qui porte HTTPS conserve son propre chiffrement de transport. Détenir les clés du VPN vous donne le paquet IP interne et ne vous donne pas les clés de session du site web à l'autre bout.

C'est pourquoi un hook ne peut pas inspecter le contenu même en principe, et pourquoi un chemin de paquets voit du texte chiffré à moins que le déploiement ne termine exprès le TLS interne. contrat de script décrit ce que le hook reçoit ; il ne dit rien de la charge utile parce qu'il n'y a pas de charge utile à donner.