Giver en TLS-indpakning dig et privat netværk? Som regel ikke

TLS beskytter en kanal mellem to endepunkter og siger intet om, hvilke tjenester der ligger indeni. En indpakning gør den kanal til én konfigureret videresender, for én lytter, til én destination. Et produkt, der sælges som SSL VPN, tilføjer normalt en grænseflade, en rutetabel og en adgangsmodel omkring den samme primitiv. At forveksle de to er, hvordan en fungerende tunnel bliver taget for netværksadgang.

Hvad en serviceindpakning faktisk forbinder

En indpakning lytter på en lokal port og videresender det, der ankommer, til en konfigureret destination, enten et værtsnavn og en port eller et lokalt program. Den destination vælges af den, der skrev konfigurationsfilen, én lytter ad gangen. Installation af pakken opretter ingen ruter, ingen virtuel grænseflade og ingen tilgængelighed for noget, der ikke er udtrykkeligt angivet. Læs konfigurationen før pakkebeskrivelsen, fordi beskrivelsen dækker en klasse af brug, og filen dækker din.

Så det nyttige spørgsmål om en indpakning er ikke, om den krypterer, men hvad der står i hver ende af den kæde, den bygger.

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

Læs den kæde ud fra konfigurationen frem for fra marketingnavnet. Hver pil er et separat netværksspring med sin egen adresse og sine egne adgangsregler.

Find hvor TLS-kanalen ender

Hvis indpakningen terminerer TLS, er alt, hvad den videresender, en ny forbindelse med nye egenskaber. Strømmen kan være klartekst på et privat segment, eller den kan bære en anden beskyttet protokol indeni. At antage det ene eller det andet uden at læse backend-konfigurationen er, hvordan folk når den konklusion, at det ydre lag beskytter data, det aldrig ser igen. Det videresendte spring fortjener sin egen undersøgelse, på sin egen adresse og port.

Kontroller lytteren og backenden hver for sig, fordi et vellykket håndtryk ved fordøren intet siger om tjenesten bag 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 kommando viser, hvilken proces der ejer porten, og hvilken adresse den lytter på. Den anden udskriver det certifikat, klienten faktisk modtager, hvilket er den identitetskontrol, som et portnummer ikke kan erstatte.

Hvad en routed VPN tilføjer, som en indpakning ikke gør

En routed VPN installerer en grænseflade, overtager ejerskabet af udvalgte præfikser og integrerer med værtens routing og adgangspolitik. Hver applikation på maskinen får gavn uden at vide, at tunnelen findes. En indpakning giver den rækkevidde til én konfigureret lytter og stopper der.

Adgang er igen separat. En VPN, der autentificerer en klient, har stadig brug for autorisation, der siger, hvilke ressourcer klienten må nå, og en indpakning, der autentificerer en peer, har stadig brug for en backend, der håndhæver sine egne tilladelser.

Der findes en legitim kombination: en VPN-protokol båret inde i en TLS-indpakning på et bevidst understøttet TCP-arrangement. Det stabler to lag, og det gør ikke indpakningen og VPN’en til samme slags objekt.

Sammenlign den grænse, der fejler

Skriv frontend-adressen, lytteren, peer-identiteten, backend-målet og applikationsoperationen ned, før du ændrer noget. Sammenlign derefter ens med ens: en succes gennem et andet værtsnavn eller en anden port beviser ikke, at firewall- og certifikatbetingelserne var identiske.

En afvist backend-anmodning bør aldrig repareres ved at slå frontend-identitetsverifikation fra. Det bytter en diagnosticerbar autorisationsfejl for en udiagnosticerbar tillidsfejl.

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

At fastgøre navnet til en valgt adresse adskiller navneopløsning fra tilgængelighed, hvilket normalt er den hurtigste måde at afgøre, hvilken af de to der er brudt.

Den sammenligning, der betyder noget, navngiver det beskyttede endepunktpar, den bårede nyttelast, de applikationer, der bruger den, og den tilladelse, der håndhæves ved destinationen. TLS bidrager til den beskrivelse uden at fuldføre den.