Vai TLS ietvars dod jums privātu tīklu? Parasti nē

TLS aizsargā kanālu starp diviem galiem un neko nesaka par to, kādi pakalpojumi tajā atrodas. Ietvars pārvērš šo kanālu vienā konfigurētā pāradresētājā — vienam klausītājam, uz vienu mērķi. Produkts, kas tiek pārdots kā SSL VPN, parasti pievieno saskarni, maršrutu tabulu un piekļuves modeli ap to pašu primitīvu. Abu sajaukšana ir tas, kā strādājošs tunelis tiek uzskatīts par tīkla piekļuvi.

Ko pakalpojuma ietvars faktiski savieno

Ietvars klausās lokālajā portā un pārsūta to, kas pienāk, uz konfigurētu mērķi — vai nu resursdatoru un portu, vai lokālu programmu. Šo mērķi izvēlas tas, kurš rakstīja konfigurācijas failu, pa vienam klausītājam. Pakotnes instalēšana nerada maršrutus, virtuālu saskarni vai sasniedzamību nekam, kas nav skaidri uzskaitīts. Lasiet konfigurāciju pirms pakotnes apraksta, jo apraksts aptver lietošanas klasi, bet fails — jūsējo.

Tāpēc lietderīgais jautājums par ietvaru nav par to, vai tas šifrē, bet par to, kas stāv katrā tā veidotās ķēdes galā.

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

Lasiet šo ķēdi no konfigurācijas, nevis no mārketinga nosaukuma. Katra bultiņa ir atsevišķs tīkla lēciens ar savu adresi un saviem piekļuves noteikumiem.

Atrodiet, kur beidzas TLS kanāls

Ja ietvars pabeidz TLS, viss, ko tas pārsūta tālāk, ir jauns savienojums ar jaunām īpašībām. Straume var būt atklāts teksts privātā segmentā, vai arī tā var saturēt sevī citu aizsargātu protokolu. Pieņemt jebkuru no tiem, neizlasot backend konfigurāciju, ir tas, kā cilvēki nonāk pie secinājuma, ka ārējais slānis aizsargā datus, kurus tas vairs nekad neredz. Pārsūtītais lēciens ir pelnījis savu pārbaudi, savā adresē un portā.

Pārbaudiet klausītāju un backend atsevišķi, jo veiksmīga rokasspiediena pie priekšējām durvīm neko nepasaka par pakalpojumu aiz tām.

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

Pirmā komanda parāda, kurš process pieder portam un kurā adresē tas klausās. Otrā izdrukā sertifikātu, kuru klients faktiski saņem, un tā ir identitātes pārbaude, kuru porta numurs nevar aizstāt.

Ko pievieno maršrutēts VPN, ko ietvars nedara

Maršrutēts VPN instalē saskarni, pārņem īpašumtiesības uz atlasītajiem prefiksiem un integrējas ar resursdatora maršrutēšanu un piekļuves politiku. Katra mašīnas lietotne gūst labumu, nezinot, ka tunelis pastāv. Ietvars dod šo sasniedzamību vienam konfigurētam klausītājam un tur apstājas.

Uzņemšana atkal ir atsevišķa. VPN, kas autentificē klientu, joprojām nepieciešama autorizācija, kas nosaka, kurus resursus klients drīkst sasniegt, un ietvaram, kas autentificē partneri, joprojām nepieciešams backend, kas īsteno savas atļaujas.

Pastāv likumīga kombinācija: VPN protokols, kas tiek pārvadāts TLS ietvarā uz apzināti atbalstīta TCP izkārtojuma. Tas sakrauj divus slāņus un nepadara ietvaru un VPN par vienu un to pašu objekta veidu.

Salīdziniet robežu, kas neizdodas

Pirms kaut ko maināt, pierakstiet priekšējās daļas adresi, klausītāju, partnera identitāti, backend mērķi un lietotnes darbību. Pēc tam salīdziniet salīdzināmo: panākums caur citu resursdatora nosaukumu vai portu nepierāda, ka ugunsmūra un sertifikāta nosacījumi bija identiski.

Noraidītu backend pieprasījumu nekad nevajadzētu labot, izslēdzot priekšējās daļas identitātes pārbaudi. Tas diagnosticējamu autorizācijas kļūmi aizstāj ar nediagnosticējamu uzticēšanās kļūmi.

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

Nosaukuma piesaistīšana izvēlētai adresei atdala nosaukumu izšķiršanu no sasniedzamības, un tas parasti ir ātrākais veids, kā noskaidrot, kurš no abiem ir salūzis.

Svarīgais salīdzinājums nosauc aizsargāto galapunktu pāri, pārvadāto kravu, to izmantojošās lietotnes un galamērķī īstenoto atļauju. TLS sniedz ieguldījumu šajā aprakstā, bet to nepabeidz.