Un hook de conexión é política de sesión, non un filtro de paquetes

Alguén quere inspeccionar o que os clientes envían polo túnel, atopa o hook de conexión na documentación e comeza a escribir un script que nunca recibirá un só paquete. O hook é real e útil, pero a súa unidade de traballo é unha sesión, non un byte. Escoller o compoñente correcto é unha comparación entre tres lugares onde pode ocorrer o traballo, e a pregunta decisiva é que unidade pode ver realmente cada un.

Que recibe o hook e que non recibe nunca

Un hook de conexión de cliente execútase unha vez cando un cliente autenticado establece unha sesión, no contexto do proceso do servidor, con argumentos documentados e valores de contorno como o nome común e o enderezo asignado. Pode escribir configuración por cliente, tomar unha decisión de admisión, asignar un recurso externo ou rexistrar que a conexión ocorreu. O que non pode facer é observar o tráfico, porque cando o primeiro paquete cruza o túnel o hook xa volveu.

Iso non é unha limitación que haxa que sortear. Unha devolución de chamada de sesión que intentase procesar un fluxo tería que executarse durante toda a vida da conexión, e o contrato de scripts do daemon non está feito para esa forma. Pregunta para que serve o hook antes de decidir que estorba.

As reconexións tamén importan. Un cliente que cae e se reconecta é unha sesión nova, así que todo o que asigne o hook debe ser idempotente ou ir acompañado dun evento de desconexión que limpe. O estado que se filtra en cada reconexión é o primeiro erro habitual nun deseño baseado en hooks.

A política de sesión pertence ao hook

A admisión é o traballo natural do hook. Sabes quen se conectou, desde onde e con que certificado, e podes decidir se esta sesión debe continuar ou ser rexeitada. Esa decisión é barata, ocorre unha vez e non require mirar un só byte de carga útil.

A asignación de configuración encaixa na mesma forma. Un hook pode seleccionar o enderezo do cliente, empurrar opcións axeitadas a esa identidade ou escribir un fragmento que o servidor le para este cliente. Como a decisión é por sesión, segue sendo comprensible cando algo vai mal e alguén ten que explicar por que un cliente concreto recibiu un enderezo concreto.

O rexistro é o terceiro encaixe. Unha entrada de auditoría que diga que unha sesión foi admitida, coa súa identidade e hora, pertence exactamente aquí. Non é un rexistro de tráfico e non debe pretender selo. Se máis tarde alguén pregunta que fixo un cliente dentro do túnel, a resposta ten que vir doutro sitio.

O traballo de paquetes pertence a unha ruta de paquetes

Se o requisito é ver ou modificar bytes en voo, o compoñente ten que estar na ruta de reenvío: unha regra de cortalumes cunha cola, un hook de control de tráfico ou un reenviador en espazo de usuario. Eses mecanismos ven paquetes e teñen o seu propio estado, os seus propios modos de fallo e o seu propio perfil de rendemento.

Editar a carga útil nesa capa é máis difícil que lela. Cambiar un byte pode invalidar un campo de lonxitude, unha suma de comprobación ou unha máquina de estados de protocolo, e un túnel de capa tres non te protexe de nada diso. Só significa que as cabeceiras externas non son as que editas. Orzamenta ese traballo de reparación antes de prometer a alguén unha reescritura de contido.

Unha captura de interface é a ferramenta máis barata desta categoría, e é unha observación, non un editor. A xente confunde as dúas porque ambas se describen como ver tráfico, pero unha captura produce un ficheiro e unha ruta de paquetes produce unha decisión.

Os cambios de aplicación pertencen á aplicación

Cando o obxectivo é cambiar que contén unha petición ou como se forma unha resposta, o lugar correcto é o servizo mesmo ou un proxy que termina o protocolo a propósito. Eses compoñentes xa entenden peticións, respostas e a autenticación que a aplicación espera, que é precisamente o contexto que lle falta a un filtro de paquetes.

A tradución de enderezos está ao final desta lista por unha razón. Reescribe enderezos e portos e deixa a carga útil tranquila, así que non é unha ferramenta de contido por moi a miúdo que apareza nunha receita que tamén menciona contido.

Manter estas fronteiras separadas é o que fai explicable un deseño. Política de sesión no hook, tratamento de paquetes nunha ruta de paquetes e cambio de aplicación onde o protocolo se termina deliberadamente: tres frases que tamén serven de lista de comprobación para a revisión.

Onde TLS aínda termina a conversa

Unha cousa sobrevive a todo o anterior: o tráfico dentro do túnel que leva HTTPS conserva o seu propio cifrado de transporte. Ter as claves da VPN dache o paquete IP interno e non che dá as claves de sesión do sitio web do outro extremo.

Por iso un hook non pode inspeccionar contido nin sequera en principio, e por iso unha ruta de paquetes ve texto cifrado a menos que o despregamento termine o TLS interno a propósito. contrato de scripts describe que recibe o hook; non di nada da carga útil porque non hai carga útil que dar.