Un hook de conexión es política de sesión, no un filtro de paquetes

Alguien quiere inspeccionar qué envían los clientes por el túnel, encuentra el hook de conexión en la documentación y empieza a escribir un script que nunca recibirá un solo paquete. El hook es real y útil, pero su unidad de trabajo es una sesión, no un byte. Elegir el componente correcto es una comparación entre tres lugares donde puede ocurrir el trabajo, y la pregunta decisiva es qué unidad puede ver realmente cada uno.

Qué recibe el hook y qué no recibe nunca

Un hook de conexión de cliente se ejecuta una vez cuando un cliente autenticado establece una sesión, en el contexto del proceso del servidor, con argumentos documentados y valores de entorno como el nombre común y la dirección asignada. Puede escribir configuración por cliente, tomar una decisión de admisión, asignar un recurso externo o registrar que la conexión ocurrió. Lo que no puede hacer es observar el tráfico, porque cuando el primer paquete cruza el túnel el hook ya ha retornado.

Eso no es una limitación que haya que sortear. Una devolución de llamada de sesión que intentara procesar un flujo tendría que ejecutarse durante toda la vida de la conexión, y el contrato de scripts del demonio no está hecho para esa forma. Pregunta para qué sirve el hook antes de decidir que estorba.

Las reconexiones también importan. Un cliente que se cae y se reconecta es una sesión nueva, así que todo lo que asigne el hook debe ser idempotente o ir acompañado de un evento de desconexión que limpie. El estado que se filtra en cada reconexión es el primer error habitual en un diseño basado en hooks.

La política de sesión pertenece al hook

La admisión es el trabajo natural del hook. Sabes quién se conectó, desde dónde y con qué certificado, y puedes decidir si esta sesión debe continuar o ser rechazada. Esa decisión es barata, ocurre una vez y no requiere mirar un solo byte de carga útil.

La asignación de configuración encaja en la misma forma. Un hook puede seleccionar la dirección del cliente, empujar opciones adecuadas a esa identidad o escribir un fragmento que el servidor lee para este cliente. Como la decisión es por sesión, sigue siendo comprensible cuando algo sale mal y alguien tiene que explicar por qué un cliente concreto recibió una dirección concreta.

El registro es el tercer encaje. Una entrada de auditoría que diga que una sesión fue admitida, con su identidad y su hora, pertenece exactamente aquí. No es un registro de tráfico y no debe pretender serlo. Si más tarde alguien pregunta qué hizo un cliente dentro del túnel, la respuesta tiene que venir de otro sitio.

El trabajo de paquetes pertenece a una ruta de paquetes

Si el requisito es ver o modificar bytes en vuelo, el componente tiene que estar en la ruta de reenvío: una regla de cortafuegos con una cola, un hook de control de tráfico o un reenviador en espacio de usuario. Esos mecanismos ven paquetes y tienen su propio estado, sus propios modos de fallo y su propio perfil de rendimiento.

Editar la carga útil en esa capa es más difícil que leerla. Cambiar un byte puede invalidar un campo de longitud, una suma de comprobación o una máquina de estados de protocolo, y un túnel de capa tres no te protege de nada de eso. Solo significa que las cabeceras externas no son las que editas. Presupuesta ese trabajo de reparación antes de prometer a alguien una reescritura de contenido.

Una captura de interfaz es la herramienta más barata de esta categoría, y es una observación, no un editor. La gente confunde las dos porque ambas se describen como ver tráfico, pero una captura produce un archivo y una ruta de paquetes produce una decisión.

Los cambios de aplicación pertenecen a la aplicación

Cuando el objetivo es cambiar qué contiene una petición o cómo se forma una respuesta, el lugar correcto es el servicio mismo o un proxy que termina el protocolo a propósito. Esos componentes ya entienden peticiones, respuestas y la autenticación que la aplicación espera, que es precisamente el contexto que le falta a un filtro de paquetes.

La traducción de direcciones está al final de esta lista por una razón. Reescribe direcciones y puertos y deja la carga útil en paz, así que no es una herramienta de contenido por muy a menudo que aparezca en una receta que también menciona contenido.

Mantener estas fronteras separadas es lo que hace explicable un diseño. Política de sesión en el hook, tratamiento de paquetes en una ruta de paquetes y cambio de aplicación donde el protocolo se termina deliberadamente: tres frases que también sirven de lista de comprobación para la revisión.

Donde TLS todavía termina la conversación

Una cosa sobrevive a todo lo anterior: el tráfico dentro del túnel que lleva HTTPS conserva su propio cifrado de transporte. Tener las claves de la VPN te da el paquete IP interno y no te da las claves de sesión del sitio web del otro extremo.

Por eso un hook no puede inspeccionar contenido ni siquiera en principio, y por eso una ruta de paquetes ve texto cifrado a menos que el despliegue termine el TLS interno a propósito. contrato de scripts describe qué recibe el hook; no dice nada de la carga útil porque no hay carga útil que dar.