En anslutningshook är sessionspolicy, inte ett paketfilter

Någon vill undersöka vad klienterna skickar genom tunneln, hittar anslutningshooken i dokumentationen och börjar skriva ett skript som aldrig kommer att ta emot ett enda paket. Hooken är verklig och användbar, men dess arbetsenhet är en session, inte en byte. Att välja rätt komponent är en jämförelse mellan tre ställen där arbete kan ske, och den avgörande frågan är vilken enhet var och en faktiskt kan se.

Vad hooken tar emot, och vad den aldrig tar emot

En client-connect-hook körs en gång när en autentiserad klient upprättar en session, i serverns processkontext, med dokumenterade argument och miljövärden som det gemensamma namnet och den tilldelade adressen. Den kan skriva konfiguration per klient, fatta ett admissionsbeslut, tilldela en extern resurs eller registrera att anslutningen skedde. Det den inte kan är att observera trafik, eftersom hooken redan har återvänt när det första paketet korsar tunneln.

Det är inte en begränsning att arbeta sig runt. En sessionsåterkallelse som försökte bearbeta en ström skulle behöva köra under hela anslutningens livstid, och daemonens skriptkontrakt är inte byggt för den formen. Fråga vad hooken är till för innan du bestämmer att den står i vägen.

Återanslutningar spelar också roll. En klient som faller och ansluter igen är en ny session, så allt hooken tilldelar måste vara idempotent eller paras ihop med en frånkopplingshändelse som städar. Tillstånd som läcker vid varje återanslutning är det vanliga första felet i en hookbaserad design.

Sessionspolicy hör hemma i hooken

Admission är hookens naturliga arbete. Du vet vem som anslöt, varifrån och med vilket certifikat, och du kan avgöra om denna session ska fortsätta eller avvisas. Det beslutet är billigt, det sker en gång, och det kräver inte att man tittar på en enda nyttolastbyte.

Konfigurationstilldelning passar i samma form. En hook kan välja klientens adress, skicka alternativ som passar den identiteten eller skriva ett fragment som servern läser för den här klienten. Eftersom beslutet är per session förblir det begripligt när något går fel och någon måste förklara varför en viss klient fick en viss adress.

Registrering är den tredje passformen. En revisionspost som säger att en session tilläts, med identitet och tid, hör precis hit. Det är inte en trafiklogg och bör inte låtsas vara det. Om någon senare frågar vad en klient gjorde inne i tunneln måste svaret komma från någon annanstans.

Pakkearbete hör hemma på en paketväg

Om kravet är att se eller ändra byte under färd måste komponenten ligga på vidarebefordringsvägen: en brandväggsregel med kö, en hook för trafikstyrning eller en vidarebefordrare i användarutrymmet. Dessa mekanismer ser paket, och de har sitt eget tillstånd, sina egna fellägen och sin egen prestandaprofil.

Att redigera nyttolasten på det lagret är svårare än att läsa den. Att ändra en byte kan ogiltigförklara ett längdfält, en kontrollsumma eller en protokolltillståndsmaskin, och en tunnel på tredje lagret skyddar dig inte mot något av det. Det betyder bara att de yttre huvudena inte är de du redigerar. Budgetera det reparationsarbetet innan du lovar någon en innehållsskrivning.

En gränssnittsavlyssning är det billigaste verktyget i den här kategorin, och det är en observation, inte en redigerare. Folk blandar ihop de två eftersom båda beskrivs som att se trafik, men en avlyssning producerar en fil och en paketväg producerar ett beslut.

Applikationsändringar hör hemma i applikationen

När målet är att ändra vad en förfrågan innehåller eller hur ett svar formas är rätt plats tjänsten själv eller en proxy som avslutar protokollet med avsikt. Dessa komponenter förstår redan förfrågningar, svar och den autentisering som applikationen förväntar sig, och det är just den kontext ett paketfilter saknar.

Adressöversättning ligger sist i den här listan av en anledning. Den skriver om adresser och portar och lämnar nyttolasten i fred, så den är inte ett innehållsverktyg, hur ofta den än dyker upp i ett recept som också nämner innehåll.

Att hålla dessa gränser åtskilda är det som gör en design förklarlig. Sessionspolicy i hooken, pakethantering på en paketväg och applikationsändring där protokollet med avsikt avslutas: tre meningar som också tjänar som checklista för granskning.

Där TLS fortfarande avslutar samtalet

En sak överlever allt ovanstående: trafik inne i tunneln som bär HTTPS behåller sin egen transportkryptering. Att ha VPN:ens nycklar ger dig det inre IP-paketet och ger dig inte sessionsnycklarna till webbplatsen i andra änden.

Därför kan en hook inte granska innehåll ens i princip, och därför ser en paketväg chiffertext om inte driftsättningen med avsikt avslutar den inre TLS:en. skriptkontrakt beskriver vad hooken får; det säger ingenting om nyttolast eftersom det inte finns någon nyttolast att ge.