Gir en TLS-wrapper deg et privat nettverk? Vanligvis ikke

TLS beskytter en kanal mellom to endepunkter og sier ingenting om hvilke tjenester som befinner seg inni den. En wrapper gjør den kanalen om til én konfigurert videresender, for én lytter, mot én destinasjon. Et produkt som markedsføres som SSL VPN, legger normalt til et grensesnitt, en rutetabell og en tilgangsmodell rundt den samme primitiven. Å forveksle disse to er hvordan en velfungerende tunnel blir oppfattet som nettilgang.

Hva en wrapper for tjenester faktisk kobler sammen

En wrapper lytter på en lokal port og sender videre det som kommer inn, til en konfigurert destinasjon, enten det er et vertsnavn og en port eller et lokalt program. Den destinasjonen velges av den som skrev konfigurasjonsfilen, én lytter av gangen. Installasjon av pakken lager ingen ruter, ingen virtuell grensesnitt og ingen tilgjengelighet for noe som ikke er uttrykkelig listet. Les konfigurasjonen før pakkebeskrivelsen, fordi beskrivelsen dekker en bruksklasse og filen dekker din.

Så det nyttige spørsmålet om en wrapper er ikke om den krypterer, men hva som står i hver ende av kjeden den bygger.

application -> local listener -> TLS connection -> remote listener -> configured backend

Les den kjeden fra konfigurasjonen og ikke fra markedsnavnet. Hver pil er et eget nettverkshopp med sin egen adresse og egne tilgangsregler.

Finn hvor TLS-kanalen ender

Hvis wrapperen terminerer TLS, er alt den sender videre en ny forbindelse med nye egenskaper. Strømmen kan være klartekst på et privat segment, eller den kan bære en annen beskyttet protokoll inni seg. Å anta det ene eller det andre uten å lese backend-konfigurasjonen er hvordan folk konkluderer med at det ytre laget beskytter data det aldri ser igjen. Det videresendte hoppet fortjener sin egen inspeksjon, på sin egen adresse og port.

Kontroller lytteren og backend-en separat, fordi et vellykket håndtrykk ved inngangsdøren ikke sier noe om tjenesten bak.

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

Den første kommandoen viser hvilken prosess som eier porten, og hvilken adresse den lytter på. Den andre skriver ut sertifikatet klienten faktisk mottar, og det er identitetskontrollen som et portnummer ikke kan erstatte.

Hva en rutet VPN tilfører som en wrapper ikke gjør

En rutet VPN installerer et grensesnitt, tar eierskap til utvalgte prefikser og integreres med vertens ruting og tilgangspolicy. Alle applikasjoner på maskinen nyter godt av det uten å vite at tunnelen finnes. En wrapper gir den rekkevidden til én konfigurert lytter og stopper der.

Adgang er igjen en separat sak. En VPN som autentiserer en klient trenger fortsatt en autorisasjon som sier hvilke ressurser klienten kan nå, og en wrapper som autentiserer en peer trenger fortsatt en backend som håndhever egne tillatelser.

Det finnes en legitim kombinasjon: en VPN-protokoll båret inne i en TLS-wrapper på et bevisst støttet TCP-oppsett. Det stabler to lag, og det gjør ikke wrapperen og VPN-en til samme type objekt.

Sammenlign grensen som svikter

Skriv ned frontend-adressen, lytteren, peer-identiteten, backend-målet og applikasjonsoperasjonen før du endrer noe. Sammenlign så likt med likt: en suksess gjennom et annet vertsnavn eller en annen port beviser ikke at brannmur- og sertifikatvilkårene var identiske.

En avvist backend-forespørsel bør aldri repareres ved å skru av frontend-identitetsverifisering. Det bytter en diagnostiserbar autorisasjonsfeil mot en udiagnostiserbar tillitsfeil.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

Å feste navnet til en valgt adresse skiller navneoppslag fra tilgjengelighet, og det er vanligvis den raskeste måten å avgjøre hvilken av de to som er ødelagt.

Sammenligningen som betyr noe, navngir det beskyttede endepunktparet, nyttelasten som bæres, applikasjonene som bruker den og tillatelsen som håndheves ved destinasjonen. TLS bidrar til den beskrivelsen uten å fullføre den.