El ganxo de connexió és política de sessió, no un filtre de paquets

Algú vol inspeccionar què envien els clients pel túnel, troba el ganxo de connexió a la documentació i comença a escriure un script que no rebrà mai ni un sol paquet. El ganxo és real i útil, però la seva unitat de treball és una sessió, no un byte. Triar el component correcte és una comparació entre tres llocs on pot passar la feina, i la pregunta decisiva és quina unitat pot veure realment cadascun.

Què rep el ganxo i què no rep mai

Un ganxo de connexió de client s'executa una vegada quan un client autenticat estableix una sessió, en el context del procés del servidor, amb arguments documentats i valors d'entorn com el nom comú i l'adreça assignada. Pot escriure configuració per client, prendre una decisió d'admissió, assignar un recurs extern o registrar que la connexió ha passat. El que no pot fer és observar el trànsit, perquè quan el primer paquet travessa el túnel el ganxo ja ha retornat.

Això no és una limitació que calgui esquivar. Una devolució de trucada de sessió que intentés processar un flux hauria de córrer tota la vida de la connexió, i el contracte dels scripts del dimoni no està fet per a aquesta forma. Pregunta per a què serveix el ganxo abans de decidir que et fa nosa.

Les reconnexions també compten. Un client que cau i es reconnecta és una sessió nova, així que tot el que assigni el ganxo ha de ser idempotent o anar acompanyat d'un esdeveniment de desconnectació que netegi. L'estat que es perd a cada reconnexió és el primer error habitual en un disseny basat en ganxos.

La política de sessió pertany al ganxo

L'admissió és la feina natural del ganxo. Saps qui s'ha connectat, d'on i amb quin certificat, i pots decidir si aquesta sessió ha de continuar o ser rebutjada. Aquesta decisió és barata, passa una vegada i no requereix mirar ni un byte de càrrega útil.

L'assignació de configuració encaixa en la mateixa forma. Un ganxo pot seleccionar l'adreça del client, empènyer opcions adequades a aquesta identitat o escriure un fragment que el servidor llegeix per a aquest client. Com que la decisió és per sessió, continua sent comprensible quan alguna cosa va malament i algú ha d'explicar per què un client concret va rebre una adreça concreta.

El registre és el tercer encaix. Una entrada d'auditoria que digui que una sessió ha estat admesa, amb la seva identitat i hora, pertany exactament aquí. No és un registre de trànsit i no ha de pretendre ser-ho. Si més endavant algú pregunta què ha fet un client dins del túnel, la resposta ha de venir d'un altre lloc.

La feina de paquets pertany a un camí de paquets

Si el requisit és veure o modificar bytes en vol, el component ha d'estar al camí de reenviament: una regla de tallafoc amb una cua, un ganxo de control de trànsit o un reenviador en espai d'usuari. Aquests mecanismes veuen paquets i tenen el seu propi estat, els seus propis modes de fallada i el seu propi perfil de rendiment.

Editar la càrrega útil en aquesta capa és més difícil que llegir-la. Canviar un byte pot invalidar un camp de longitud, una suma de comprovació o una màquina d'estats de protocol, i un túnel de capa tres no et protegeix de res d'això. Només vol dir que les capçaleres externes no són les que edites. Pressuposta aquesta feina de reparació abans de prometre a algú una reescriptura de contingut.

Una captura d'interfície és l'eina més barata d'aquesta categoria, i és una observació, no un editor. La gent confon les dues coses perquè totes dues es descriuen com a veure trànsit, però una captura produeix un fitxer i un camí de paquets produeix una decisió.

Els canvis d'aplicació pertanyen a l'aplicació

Quan l'objectiu és canviar què conté una petició o com es forma una resposta, el lloc correcte és el servei mateix o un proxy que acaba el protocol a propòsit. Aquests components ja entenen peticions, respostes i l'autenticació que l'aplicació espera, que és precisament el context que li falta a un filtre de paquets.

La traducció d'adreces és al final d'aquesta llista per una raó. Reescriu adreces i ports i deixa la càrrega útil tranquil·la, així que no és una eina de contingut per molt sovint que aparegui en una recepta que també esmenta contingut.

Mantenir aquestes fronteres separades és el que fa explicable un disseny. Política de sessió al ganxo, tractament de paquets en un camí de paquets i canvi d'aplicació on el protocol s'acaba deliberadament: tres frases que també serveixen de llista de comprovació per a la revisió.

On TLS encara acaba la conversa

Una cosa sobreviu a tot l'anterior: el trànsit dins del túnel que porta HTTPS conserva la seva pròpia xifra de transport. Tenir les claus de la VPN et dona el paquet IP intern i no et dona les claus de sessió del lloc web de l'altre extrem.

Per això un ganxo no pot inspeccionar contingut ni tan sols en principi, i per això un camí de paquets veu text xifrat tret que el desplegament acabi el TLS intern a propòsit. contracte dels scripts descriu què rep el ganxo; no diu res de la càrrega útil perquè no hi ha cap càrrega útil a donar.