Gjev ein TLS-innpakning deg eit privat nettverk? Som regel ikkje

TLS vernar ein kanal mellom to endepunkt og seier ingenting om kva tenester som ligg inni han. Ei innpakning gjer den kanalen til éin konfigurert videresendar, for éin lyttar, til éin destinasjon. Eit produkt som vert selt som SSL VPN, legg vanlegvis til eit grensesnitt, ei rutetabell og ein tilgangsmodell rundt den same primitiven. Å blande dei to er korleis ein fungerande tunnel vert teken for nettilgang.

Kva ei tenesteinnpakning faktisk knyter saman

Ei innpakning lyttar på ein lokal port og sender vidare det som kjem, til ein konfigurert destinasjon, anten eit vertsnamn og ein port eller eit lokalt program. Den destinasjonen vert vald av den som skreiv konfigurasjonsfila, éin lyttar om gongen. Installeringa av pakken skapar ingen ruter, ingen virtuell grensesnitt og inga tilgjenge for noko som ikkje er uttrykkeleg lista opp. Les konfigurasjonen før pakkeskildringa, fordi skildringa dekkjer ein klasse av bruk og fila dekkjer di.

Så det nyttige spørsmålet om ei innpakning er ikkje om ho krypterer, men kva som står i kvar ende av kjeda ho byggjer.

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

Les den kjeda ut frå konfigurasjonen og ikkje frå marknadsnamnet. Kvar pil er eit eige nettverkshopp med si eiga adresse og sine eigne tilgangsreglar.

Finn kvar TLS-kanalen endar

Viss innpakninga terminerer TLS, er alt ho sender vidare, eit nytt samband med nye eigenskapar. Straumen kan vere klartekst på eit privat segment, eller han kan bere ein annan verna protokoll inni seg. Å gå ut frå det eine eller det andre utan å lese backend-konfigurasjonen er korleis folk konkluderer med at det ytre laget vernar data det aldri ser att. Det videresende hoppet fortener si eiga undersøking, på si eiga adresse og port.

Kontroller lyttaren og backend-en kvar for seg, fordi eit vellukka handtrykk ved framdøra seier ingenting om tenesta bak henne.

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 kva prosess som eig porten, og kva adresse han lyttar på. Den andre skriv ut sertifikatet klienten faktisk får, og det er identitetskontrollen som eit portnummer ikkje kan erstatta.

Kva eit ruta VPN legg til som ei innpakning ikkje gjer

Eit ruta VPN installerer eit grensesnitt, tek eigarskap over utvalde prefiks og integrerer seg med rutinga og tilgangspolitikken til verten. Kvar applikasjon på maskina nyt godt av det utan å vite at tunnelen finst. Ei innpakning gjev den rekkevidda til éin konfigurert lyttar og stoppar der.

Tilgang er igjen separat. Eit VPN som autentiserer ein klient treng framleis ein autorisasjon som seier kva ressursar klienten kan nå, og ei innpakning som autentiserer ein peer treng framleis ein backend som handhevar sine eigne løyve.

Det finst ein legitim kombinasjon: ein VPN-protokoll boren inne i ei TLS-innpakning på eit medvite støtta TCP-oppsett. Det stablar to lag, og det gjer ikkje innpakninga og VPN-en til same slags objekt.

Samanlikn grensa som sviktar

Skriv ned frontend-adressa, lyttaren, peer-identiteten, backend-målet og applikasjonsoperasjonen før du endrar noko. Samanlikn deretter likt med likt: ein suksess gjennom eit anna vertsnamn eller ein annan port beviser ikkje at brannmur- og sertifikatvilkåra var identiske.

Ei avvist backend-førespurnad bør aldri reparerast ved å slå av frontend-identitetsverifisering. Det byter ein diagnostiserbar autorisasjonsfeil mot ein udiagnostiserbar tillitsfeil.

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

Å feste namnet til ei vald adresse skil namneoppslag frå tilgjenge, som vanlegvis er den snøggaste måten å avgjere kva av dei to som er øydelagd.

Samanlikninga som betyr noko, namngjev det verna endepunktparet, nyttelasta som vert boren, applikasjonane som brukar henne og løyvet som vert handheva ved destinasjonen. TLS bidreg til den skildringa utan å fullføre henne.