TLS beskytter en kanal mellom to endepunkter og sier ingenting om hvilke tjenester som ligger inni den. En innpakning gjør den kanalen til én konfigurert videresender, for én lytter, til én destinasjon. Et produkt som selges som SSL VPN, legger vanligvis til et grensesnitt, en rutetabell og en tilgangsmodell rundt den samme primitiven. Å forveksle de to er hvordan en fungerende tunnel blir tatt for nettverkstilgang.

Hva en tjenesteinnpakning faktisk kobler sammen

En innpakning lytter på en lokal port og videresender det som ankommer, til en konfigurert destinasjon, enten et vertsnavn og en port eller et lokalt program. Den destinasjonen velges av den som skrev konfigurasjonsfilen, én lytter om gangen. Installasjon av pakken oppretter ingen ruter, ingen virtuell grensesnitt og ingen tilgjengelighet for noe som ikke er uttrykkelig oppført. Les konfigurasjonen før pakkebeskrivelsen, fordi beskrivelsen dekker en klasse av bruk og filen dekker din.

Så det nyttige spørsmålet om en innpakning 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 ut fra konfigurasjonen og ikke fra markedsnavnet. Hver pil er et eget nettverkshopp med sin egen adresse og sine egne tilgangsregler.

Finn hvor TLS-kanalen ender

Hvis innpakningen terminerer TLS, er alt den videresender 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 undersøkelse, på sin egen adresse og port.

Kontroller lytteren og backenden hver for seg, fordi et vellykket håndtrykk ved fordøren ikke sier noe om tjenesten bak den.

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 innpakning ikke gjør

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

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

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

Sammenlign grensen som svikter

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

En avvist backend-forespørsel bør aldri repareres ved å slå 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, som vanligvis er 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.

Relaterte artikler