Un hook di connessione è politica di sessione, non un filtro di pacchetti

Qualcuno vuole ispezionare ciò che i client inviano attraverso il tunnel, trova l'hook di connessione nella documentazione e inizia a scrivere uno script che non riceverà mai un solo pacchetto. L'hook è reale e utile, ma la sua unità di lavoro è una sessione, non un byte. Scegliere il componente giusto è un confronto tra tre luoghi in cui il lavoro può avvenire, e la domanda decisiva è quale unità ciascuno possa vedere davvero.

Cosa riceve l'hook e cosa non riceve mai

Un hook di connessione client viene eseguito una volta quando un client autenticato stabilisce una sessione, nel contesto del processo del server, con argomenti documentati e valori d'ambiente come il nome comune e l'indirizzo assegnato. Può scrivere configurazione per client, prendere una decisione di ammissione, allocare una risorsa esterna o registrare che la connessione è avvenuta. Ciò che non può fare è osservare il traffico, perché quando il primo pacchetto attraversa il tunnel l'hook è già tornato.

Non è una limitazione da aggirare. Una callback di sessione che tentasse di elaborare un flusso dovrebbe girare per tutta la vita della connessione, e il contratto di scripting del daemon non è costruito per quella forma. Chiediti a cosa serve l'hook prima di decidere che ti intralcia.

Anche le riconnessioni contano. Un client che cade e si riconnette è una nuova sessione, quindi tutto ciò che l'hook alloca deve essere idempotente o abbinato a un evento di disconnessione che pulisce. Lo stato che perde a ogni riconnessione è il primo bug abituale in un progetto basato su hook.

La politica di sessione appartiene all'hook

L'ammissione è il lavoro naturale dell'hook. Sai chi si è connesso, da dove e con quale certificato, e puoi decidere se questa sessione debba proseguire o essere rifiutata. Quella decisione costa poco, avviene una volta e non richiede di guardare un solo byte di payload.

L'assegnazione della configurazione rientra nella stessa forma. Un hook può selezionare l'indirizzo del client, inviare opzioni adatte a quell'identità o scrivere un frammento che il server legge per questo client. Poiché la decisione è per sessione, resta comprensibile quando qualcosa va storto e qualcuno deve spiegare perché un certo client ha ricevuto un certo indirizzo.

La registrazione è la terza corrispondenza. Una voce di audit che dice che una sessione è stata ammessa, con la sua identità e la sua ora, appartiene esattamente qui. Non è un registro del traffico e non deve fingere di esserlo. Se più tardi qualcuno chiede cosa ha fatto un client dentro il tunnel, la risposta deve venire da altrove.

Il lavoro sui pacchetti appartiene a un percorso di pacchetti

Se il requisito è vedere o modificare byte in volo, il componente deve stare sul percorso di inoltro: una regola di firewall con una coda, un hook di controllo del traffico o un inoltratore nello spazio utente. Quei meccanismi vedono i pacchetti e hanno un proprio stato, propri modi di guasto e un proprio profilo di prestazioni.

Modificare il payload a quel livello è più difficile che leggerlo. Cambiare un byte può invalidare un campo di lunghezza, un checksum o una macchina a stati di protocollo, e un tunnel di livello tre non ti protegge da nulla di tutto ciò. Significa solo che le intestazioni esterne non sono quelle che modifichi. Metti in budget quel lavoro di riparazione prima di promettere a qualcuno una riscrittura del contenuto.

Una cattura d'interfaccia è lo strumento più economico di questa categoria, ed è un'osservazione, non un editor. Le persone confondono le due cose perché entrambe sono descritte come vedere il traffico, ma una cattura produce un file e un percorso di pacchetti produce una decisione.

I cambiamenti applicativi appartengono all'applicazione

Quando l'obiettivo è cambiare cosa contiene una richiesta o come si forma una risposta, il posto giusto è il servizio stesso o un proxy che termina il protocollo di proposito. Quei componenti già capiscono richieste, risposte e l'autenticazione che l'applicazione si aspetta, ed è precisamente il contesto che manca a un filtro di pacchetti.

La traduzione degli indirizzi sta in fondo a questo elenco per una ragione. Riscrive indirizzi e porte e lascia in pace il payload, quindi non è uno strumento per il contenuto, per quanto spesso compaia in una ricetta che menziona anche il contenuto.

Tenere separati questi confini è ciò che rende un progetto spiegabile. Politica di sessione nell'hook, gestione dei pacchetti su un percorso di pacchetti e cambiamento applicativo dove il protocollo viene terminato deliberatamente: tre frasi che servono anche da lista di controllo per la revisione.

Dove TLS termina ancora la conversazione

Una cosa sopravvive a tutto quanto sopra: il traffico dentro il tunnel che porta HTTPS conserva la propria crittografia di trasporto. Avere le chiavi della VPN ti dà il pacchetto IP interno e non ti dà le chiavi di sessione del sito web all'altro capo.

Per questo un hook non può ispezionare il contenuto nemmeno in linea di principio, e per questo un percorso di pacchetti vede testo cifrato a meno che il deployment non termini di proposito il TLS interno. contratto di scripting descrive ciò che riceve l'hook; non dice nulla sul payload perché non c'è payload da dare.