Een verbindingshook is sessiebeleid, geen pakketfilter

Iemand wil inspecteren wat clients door de tunnel sturen, vindt de verbindingshook in de documentatie en begint een script te schrijven dat nooit één pakket zal ontvangen. De hook is echt en nuttig, maar de werkeenheid is een sessie, niet een byte. De juiste component kiezen is een vergelijking tussen drie plaatsen waar werk kan gebeuren, en de beslissende vraag is welke eenheid elk ervan werkelijk kan zien.

Wat de hook ontvangt, en wat hij nooit ontvangt

Een client-connect-hook draait één keer wanneer een geauthenticeerde client een sessie opzet, in de procescontext van de server, met gedocumenteerde argumenten en omgevingswaarden zoals de common name en het toegewezen adres. Hij kan configuratie per client schrijven, een toelatingsbeslissing nemen, een externe resource toewijzen of vastleggen dat de verbinding plaatsvond. Wat hij niet kan, is verkeer observeren, want tegen de tijd dat het eerste pakket de tunnel oversteekt, is de hook al teruggekeerd.

Dat is geen beperking om te omzeilen. Een sessie-callback die een stream zou proberen te verwerken, zou de hele levensduur van de verbinding moeten draaien, en het scriptcontract van de daemon is niet voor die vorm gebouwd. Vraag waarvoor de hook is voordat je besluit dat hij in de weg staat.

Herverbindingen tellen ook. Een client die wegvalt en opnieuw verbindt, is een nieuwe sessie, dus alles wat de hook toewijst, moet idempotent zijn of gepaard gaan met een verbrekingsgebeurtenis die opruimt. Toestand die bij elke herverbinding weglekt, is de gebruikelijke eerste fout in een op hooks gebaseerd ontwerp.

Sessiebeleid hoort in de hook

Toelating is het natuurlijke werk van de hook. Je weet wie verbonden is, van waar en met welk certificaat, en je kunt beslissen of deze sessie doorgaat of geweigerd wordt. Die beslissing is goedkoop, gebeurt één keer en vereist geen blik op één payload-byte.

Configuratietoewijzing past in dezelfde vorm. Een hook kan het adres van de client kiezen, opties pushen die bij die identiteit passen of een fragment schrijven dat de server voor deze client leest. Omdat de beslissing per sessie is, blijft hij begrijpelijk wanneer er iets misgaat en iemand moet uitleggen waarom een bepaalde client een bepaald adres kreeg.

Vastleggen is de derde pasvorm. Een auditregel die zegt dat een sessie is toegelaten, met zijn identiteit en tijd, hoort precies hier. Het is geen verkeerslog en moet zich niet als zodanig voordoen. Als iemand later vraagt wat een client binnen de tunnel deed, moet het antwoord van elders komen.

Pakketwerk hoort op een pakketpad

Als de eis is om bytes onderweg te zien of te wijzigen, moet de component op het doorstuurpad zitten: een firewallregel met een wachtrij, een hook voor verkeersbeheer of een doorstuurtool in de gebruikersruimte. Die mechanismen zien pakketten, en ze hebben hun eigen toestand, hun eigen faalmodi en hun eigen prestatieprofiel.

Payload op die laag bewerken is moeilijker dan lezen. Een byte wijzigen kan een lengteveld, een controlesom of een protocoltoestandsmachine ongeldig maken, en een tunnel op de derde laag beschermt je daar niet tegen. Het betekent alleen dat de buitenste headers niet degene zijn die je bewerkt. Begroot dat herstelwerk voordat je iemand een inhoudsherschrijving belooft.

Een interface-opname is het goedkoopste gereedschap in deze categorie, en het is een observatie, geen editor. Mensen halen de twee door elkaar omdat beide als verkeer zien worden beschreven, maar een opname levert een bestand en een pakketpad levert een beslissing.

Applicatiewijzigingen horen in de applicatie

Wanneer het doel is te wijzigen wat een verzoek bevat of hoe een antwoord wordt gevormd, is de juiste plek de dienst zelf of een proxy die het protocol bewust beëindigt. Die componenten begrijpen al verzoeken, antwoorden en de authenticatie die de applicatie verwacht, en dat is precies de context die een pakketfilter mist.

Adresvertaling staat met een reden onderaan deze lijst. Het herschrijft adressen en poorten en laat de payload met rust, dus het is geen inhoudsgereedschap, hoe vaak het ook opduikt in een recept dat ook inhoud noemt.

Deze grenzen gescheiden houden is wat een ontwerp uitlegbaar maakt. Sessiebeleid in de hook, pakketbehandeling op een pakketpad en applicatiewijziging waar het protocol bewust wordt beëindigd: drie zinnen die ook als checklist voor de beoordeling dienen.

Waar TLS het gesprek nog beëindigt

Eén ding overleeft alles hierboven: verkeer binnen de tunnel dat HTTPS draagt, behoudt zijn eigen transportversleuteling. De sleutels van de VPN hebben geeft je het binnenste IP-pakket en geeft je niet de sessiesleutels van de website aan de andere kant.

Daarom kan een hook inhoud zelfs in principe niet inspecteren, en daarom ziet een pakketpad versleutelde tekst, tenzij de uitrol bewust de binnenste TLS beëindigt. scriptcontract beschrijft wat de hook krijgt; het zegt niets over payload, omdat er geen payload te geven is.