Um hook de conexão é política de sessão, não um filtro de pacotes

Alguém quer inspecionar o que os clientes enviam pelo túnel, encontra o hook de conexão na documentação e começa a escrever um script que nunca receberá um único pacote. O hook é real e útil, mas sua unidade de trabalho é uma sessão, não um byte. Escolher o componente correto é uma comparação entre três lugares onde o trabalho pode acontecer, e a pergunta decisiva é qual unidade cada um consegue realmente ver.

O que o hook recebe e o que nunca recebe

Um hook de conexão de cliente executa uma vez quando um cliente autenticado estabelece uma sessão, no contexto do processo do servidor, com argumentos documentados e valores de ambiente como o nome comum e o endereço atribuído. Ele pode escrever configuração por cliente, tomar uma decisão de admissão, alocar um recurso externo ou registrar que a conexão aconteceu. O que ele não pode fazer é observar o tráfego, porque quando o primeiro pacote atravessa o túnel o hook já retornou.

Isso não é uma limitação a contornar. Um retorno de chamada de sessão que tentasse processar um fluxo teria de rodar por toda a vida da conexão, e o contrato de scripts do daemon não é construído para esse formato. Pergunte para que serve o hook antes de decidir que ele atrapalha.

As reconexões também importam. Um cliente que cai e se reconecta é uma sessão nova, então tudo o que o hook alocar precisa ser idempotente ou estar pareado com um evento de desconexão que limpe. Estado que vaza a cada reconexão é o primeiro bug habitual em um projeto baseado em hook.

A política de sessão pertence ao hook

A admissão é o trabalho natural do hook. Você sabe quem se conectou, de onde e com qual certificado, e pode decidir se esta sessão deve continuar ou ser recusada. Essa decisão é barata, acontece uma vez e não exige olhar um único byte de payload.

A atribuição de configuração cabe no mesmo formato. Um hook pode selecionar o endereço do cliente, enviar opções adequadas a essa identidade ou escrever um fragmento que o servidor lê para este cliente. Como a decisão é por sessão, ela continua compreensível quando algo dá errado e alguém precisa explicar por que determinado cliente recebeu determinado endereço.

O registro é o terceiro encaixe. Uma entrada de auditoria dizendo que uma sessão foi admitida, com sua identidade e hora, pertence exatamente aqui. Não é um log de tráfego e não deve fingir ser. Se mais tarde alguém perguntar o que um cliente fez dentro do túnel, a resposta tem de vir de outro lugar.

O trabalho de pacotes pertence a um caminho de pacotes

Se o requisito é ver ou modificar bytes em trânsito, o componente precisa estar no caminho de encaminhamento: uma regra de firewall com fila, um hook de controle de tráfego ou um encaminhador em espaço de usuário. Esses mecanismos veem pacotes e têm seu próprio estado, seus próprios modos de falha e seu próprio perfil de desempenho.

Editar o payload nessa camada é mais difícil do que lê-lo. Mudar um byte pode invalidar um campo de comprimento, um checksum ou uma máquina de estados de protocolo, e um túnel de camada três não protege você de nada disso. Significa apenas que os cabeçalhos externos não são os que você edita. Orçe esse trabalho de reparo antes de prometer a alguém uma reescrita de conteúdo.

Uma captura de interface é a ferramenta mais barata desta categoria, e é uma observação, não um editor. As pessoas confundem as duas porque ambas são descritas como ver o tráfego, mas uma captura produz um arquivo e um caminho de pacotes produz uma decisão.

Mudanças de aplicação pertencem à aplicação

Quando o objetivo é mudar o que uma requisição contém ou como uma resposta é formada, o lugar certo é o próprio serviço ou um proxy que termina o protocolo de propósito. Esses componentes já entendem requisições, respostas e a autenticação que a aplicação espera, e é precisamente o contexto que falta a um filtro de pacotes.

A tradução de endereços está no fim desta lista por uma razão. Ela reescreve endereços e portas e deixa o payload em paz, então não é uma ferramenta de conteúdo, por mais que apareça em uma receita que também menciona conteúdo.

Manter essas fronteiras separadas é o que torna um projeto explicável. Política de sessão no hook, tratamento de pacotes em um caminho de pacotes e mudança de aplicação onde o protocolo é terminado deliberadamente: três frases que também servem de lista de verificação para a revisão.

Onde o TLS ainda termina a conversa

Uma coisa sobrevive a tudo o que foi dito: o tráfego dentro do túnel que carrega HTTPS mantém a própria criptografia de transporte. Ter as chaves da VPN dá a você o pacote IP interno e não dá as chaves de sessão do site do outro lado.

É por isso que um hook não pode inspecionar conteúdo nem em princípio, e por isso um caminho de pacotes vê texto cifrado, a menos que a implantação termine o TLS interno de propósito. contrato de scripts descreve o que o hook recebe; não diz nada sobre o payload porque não há payload a dar.