Un hook de conectare este politică de sesiune, nu un filtru de pachete

Cineva vrea să inspecteze ce trimit clienții prin tunel, găsește hookul de conectare în documentație și începe să scrie un script care nu va primi niciodată un singur pachet. Hookul este real și util, dar unitatea lui de lucru este o sesiune, nu un octet. Alegerea componentei potrivite este o comparație între trei locuri în care poate avea loc munca, iar întrebarea decisivă este ce unitate poate vedea de fapt fiecare dintre ele.

Ce primește hookul și ce nu primește niciodată

Un hook de conectare a clientului rulează o dată când un client autentificat stabilește o sesiune, în contextul procesului serverului, cu argumente documentate și valori de mediu precum numele comun și adresa atribuită. Poate scrie configurație pe client, poate lua o decizie de admitere, poate aloca o resursă externă sau poate înregistra că conexiunea a avut loc. Ceea ce nu poate face este să observe traficul, pentru că atunci când primul pachet traversează tunelul, hookul a revenit deja.

Aceasta nu este o limitare de ocolit. Un callback de sesiune care ar încerca să proceseze un flux ar trebui să ruleze pe toată durata conexiunii, iar contractul de scripturi al demonului nu este construit pentru această formă. Întrebați la ce folosește hookul înainte de a decide că vă încurcă.

Reconectările contează și ele. Un client care cade și se reconectează este o sesiune nouă, așa că tot ce alocă hookul trebuie să fie idempotent sau împerecheat cu un eveniment de deconectare care curăță. Starea care se pierde la fiecare reconectare este prima eroare obișnuită într-un design bazat pe hook.

Politica de sesiune aparține hookului

Admiterea este munca naturală a hookului. Știți cine s-a conectat, de unde și cu ce certificat, și puteți decide dacă această sesiune continuă sau este refuzată. Decizia este ieftină, are loc o singură dată și nu cere să priviți un singur octet din încărcătură.

Atribuirea configurației se potrivește aceleiași forme. Un hook poate selecta adresa clientului, poate trimite opțiuni potrivite acelei identități sau poate scrie un fragment pe care serverul îl citește pentru acest client. Pentru că decizia este pe sesiune, rămâne inteligibilă când ceva merge prost și cineva trebuie să explice de ce un anumit client a primit o anumită adresă.

Înregistrarea este a treia potrivire. O intrare de audit care spune că o sesiune a fost admisă, cu identitatea și ora ei, aparține exact aici. Nu este un jurnal de trafic și nu trebuie să pretindă că este. Dacă mai târziu cineva întreabă ce a făcut un client în interiorul tunelului, răspunsul trebuie să vină de altundeva.

Munca pe pachete aparține unei căi de pachete

Dacă cerința este să vedeți sau să modificați octeți în zbor, componenta trebuie să fie pe calea de forwarding: o regulă de firewall cu coadă, un hook de control al traficului sau un forwarder în spațiul utilizatorului. Acele mecanisme văd pachete și au propria stare, propriile moduri de eșec și propriul profil de performanță.

Editarea încărcăturii la acel nivel este mai grea decât citirea ei. Schimbarea unui octet poate invalida un câmp de lungime, o sumă de control sau o mașină de stări de protocol, iar un tunel de nivel trei nu vă protejează de nimic din toate acestea. Înseamnă doar că anteturile exterioare nu sunt cele pe care le editați. Bugetați acea muncă de reparare înainte de a promite cuiva o rescriere de conținut.

O captură de interfață este cea mai ieftină unealtă din această categorie și este o observație, nu un editor. Oamenii le confundă pentru că ambele sunt descrise ca vedere a traficului, dar o captură produce un fișier, iar o cale de pachete produce o decizie.

Modificările de aplicație aparțin aplicației

Când scopul este să schimbați ce conține o cerere sau cum se formează un răspuns, locul potrivit este serviciul însuși sau un proxy care termină protocolul intenționat. Acele componente înțeleg deja cereri, răspunsuri și autentificarea pe care o așteaptă aplicația, iar acesta este exact contextul care îi lipsește unui filtru de pachete.

Traducerea adreselor stă la baza acestei liste dintr-un motiv. Rescrie adrese și porturi și lasă încărcătura în pace, așa că nu este unealtă de conținut, oricât de des ar apărea într-o rețetă care menționează și conținut.

Păstrarea separată a acestor granițe este ceea ce face un design explicabil. Politică de sesiune în hook, tratarea pachetelor pe o cale de pachete și modificare de aplicație acolo unde protocolul este terminat deliberat: trei propoziții care servesc și ca listă de verificare pentru revizuire.

Unde TLS încă termină conversația

Un lucru supraviețuiește tuturor celor de mai sus: traficul din interiorul tunelului care transportă HTTPS își păstrează propria criptare de transport. Deținerea cheilor VPN vă dă pachetul IP interior și nu vă dă cheile de sesiune ale site-ului de la celălalt capăt.

De aceea un hook nu poate inspecta conținut nici măcar în principiu și de aceea o cale de pachete vede text cifrat, dacă implementarea nu termină intenționat TLS-ul interior. contract de scripturi descrie ce primește hookul; nu spune nimic despre încărcătură pentru că nu există încărcătură de dat.