n Koppelhaak is sessiebeleid, nie n pakkiefilter nie

Iemand wil ondersoek wat kliënte deur die tonnel stuur, vind die koppelhaak in die dokumentasie, en begin n script skryf wat nooit n enkele pakkie sal ontvang nie. Die haak is werklik en nuttig, maar sy werkeenheid is n sessie, nie n greep nie. Om die regte komponent te kies, is n vergelyking tussen drie plekke waar werk kan gebeur, en die beslissende vraag is watter eenheid elkeen werklik kan sien.

Wat die haak ontvang, en wat hy nooit ontvang nie

n Koppelhaak vir kliënte loop een keer wanneer n geauthentiseerde kliënt n sessie vestig, in die bediener se proseskonteks, met gedokumenteerde argumente en omgewingswaardes soos die algemene naam en toegewysde adres. Dit kan per-kliënt-konfigurasie skryf, n toelatingsbesluit neem, n eksterne hulpbron toeken of aanteken dat die verbinding plaasgevind het. Wat dit nie kan doen nie, is om verkeer waar te neem, want teen die tyd dat die eerste pakkie die tonnel oorsteek, het die haak reeds teruggekeer.

Dit is nie n beperking om te omseil nie. n Sessie-terugroep wat n stroom probeer verwerk, sou vir die leeftyd van die verbinding moes loop, en die daemon se scripting-kontrak is nie vir daardie vorm gebou nie. Vra waarvoor die haak is voordat jy besluit dit is in jou pad.

Herverbindings maak ook saak. n Kliënt wat verloor en weer verbind, is n nuwe sessie, so enigiets wat die haak toeken, moet idempotent wees of gepaard gaan met n ontkoppel-gebeurtenis wat opruim. Toestand wat by elke herverbinding lek, is die gewone eerste fout in n haakgebaseerde ontwerp.

Sessiebeleid hoort in die haak

Toelating is die haak se natuurlike werk. Jy weet wie verbind het, van waar, en met watter sertifikaat, en jy kan besluit of hierdie sessie moet voortgaan of geweier word. Daardie besluit is goedkoop, dit gebeur een keer, en dit vereis nie dat jy na n enkele greep data kyk nie.

Konfigurasietoewysing pas in dieselfde vorm. n Haak kan die kliënt se adres kies, opsies stoot wat by daardie identiteit pas, of n fragment skryf wat die bediener vir hierdie kliënt lees. Omdat die besluit per sessie is, bly dit verstaanbaar wanneer iets verkeerd gaan en iemand moet verduidelik hoekom n bepaalde kliënt n bepaalde adres gekry het.

Aantekening is die derde pas. n Ouditinskrywing wat sê dat n sessie toegelaat is, met sy identiteit en tyd, hoort presies hier. Dit is nie n verkeerslog nie en moet nie voorgee dat dit een is nie. As iemand later vra wat n kliënt binne die tonnel gedoen het, moet die antwoord van elders kom.

Pakkiewerk hoort op n pakkiepad

As die vereiste is om grepe in vlug te sien of te wysig, moet die komponent in die aanstuurpad wees: n firewall-reël met n tou, n verkeersbeheerhaak, of n gebruikerspasie-aanstuurder. Daardie meganismes sien pakkies, en hulle het hul eie toestand, hul eie foutmodusse en hul eie prestasieprofiel.

Om die vrag op daardie laag te wysig, is moeiliker as om dit te lees. Om n greep te verander, kan n lengteveld, n kontrolesom of n protokol-toestandmasjien ongeldig maak, en n laag-drie-tonnel beskerm jou nie daarteen nie. Dit beteken net dat die buitenste opkoppe nie die is wat jy wysig nie. Begroot vir daardie herstelwerk voordat jy iemand n inhoudsherskrywing belowe.

n Koppelvlak-opname is die goedkoopste instrument in hierdie kategorie, en dit is n waarneming eerder as n redigeerder. Mense verwar die twee omdat albei beskryf word as om verkeer te sien, maar n opname lewer n lêer en n pakkiepad lewer n besluit.

Toepassingsveranderinge hoort in die toepassing

Wanneer die doel is om te verander wat n versoek bevat of hoe n antwoord gevorm word, is die regte plek die diens self of n volmag wat die protokol doelbewus termineer. Daardie komponente verstaan reeds versoeke, antwoorde en die verifikasie wat die toepassing verwag, en dit is presies die konteks wat n pakkiefilter kort.

Adresvertaling staan om n rede onderaan hierdie lys. Dit herskryf adresse en poorte en laat die vrag alleen, so dit is nie n inhoudsinstrument nie, maak nie saak hoe dikwels dit in n resep verskyn wat ook inhoud noem nie.

Om hierdie grense apart te hou, is wat n ontwerp verklaarbaar maak. Sessiebeleid in die haak, pakkiehantering op n pakkiepad, en toepassingsverandering waar die protokol doelbewus getermineer word: drie sinne wat ook as n hersieningskontrolelys dien.

Waar TLS steeds die gesprek beëindig

Een ding oorleef al die bogenoemde: verkeer binne die tonnel wat HTTPS dra, behou sy eie vervoerversigteling. Om die VPN se sleutels te hou, gee jou die binneste IP-pakkie, en dit gee jou nie die sessiesleutels vir die webwerf aan die ander kant nie.

Dit is hoekom n haak nie eens in beginsel inhoud kan inspekteer nie, en hoekom n pakkiepad ciphertext sien tensy die ontplooiing die binneste TLS doelbewus termineer. scripting-kontrak beskryf wat die haak gegee word; dit sê niks oor vrag nie, want daar is geen vrag om te gee nie.