Ar TLS apvalkalas suteikia jums privatų tinklą? Paprastai ne

TLS apsaugo kanalą tarp dviejų galų ir nieko nesako apie tai, kokios paslaugos yra jo viduje. Apvalkalas paverčia tą kanalą vienu sukonfigūruotu peradresuotoju, vienam klausytojui, į vieną paskirties vietą. Produktas, parduodamas kaip SSL VPN, paprastai prideda sąsają, maršrutų lentelę ir prieigos modelį aplink tą patį primityvą. Sumaišius abu, veikiantis tunelis palaikomas tinklo prieiga.

Ką iš tikrųjų sujungia paslaugos apvalkalas

Apvalkalas klausosi vietinio prievado ir perduoda tai, kas ateina, į sukonfigūruotą paskirties vietą – ar tai būtų mazgas ir prievadas, ar vietinė programa. Tą paskirties vietą pasirenka tas, kuris parašė konfigūracijos failą, po vieną klausytoją. Paketo įdiegimas nesukuria maršrutų, virtualios sąsajos ar pasiekiamumo niekam, kas nėra aiškiai išvardyta. Skaitykite konfigūraciją prieš paketo aprašymą, nes aprašymas apima naudojimo klasę, o failas – jūsų atvejį.

Taigi naudingas klausimas apie apvalkalą yra ne tai, ar jis šifruoja, o tai, kas stovi kiekviename jo kuriamos grandinės gale.

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

Skaitykite tą grandinę iš konfigūracijos, o ne iš rinkodaros pavadinimo. Kiekviena rodyklė yra atskiras tinklo šuolis su savo adresu ir savo prieigos taisyklėmis.

Raskite, kur baigiasi TLS kanalas

Jei apvalkalas užbaigia TLS, viskas, ką jis toliau perduoda, yra naujas ryšys su naujomis savybėmis. Srautas gali būti atviras tekstas privačiame segmente arba savyje nešti kitą apsaugotą protokolą. Daryti prielaidą apie bet kurį iš jų neskaičius backend konfigūracijos – tai būdas, kuriuo žmonės padaro išvadą, kad išorinis sluoksnis saugo duomenis, kurių jis niekada daugiau nebemato. Perduotas šuolis nusipelno savo patikrinimo, savo adresu ir prievadu.

Tikrinkite klausytoją ir backend atskirai, nes sėkmingas rankos paspaudimas prie priekinių durų nieko nesako apie paslaugą už jų.

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

Pirmoji komanda parodo, kuris procesas valdo prievadą ir kokiu adresu jis klausosi. Antroji atspausdina sertifikatą, kurį klientas iš tikrųjų gauna, ir tai yra tapatybės patikra, kurios prievado numeris negali pakeisti.

Ką prideda maršrutizuotas VPN, ko apvalkalas nedaro

Maršrutizuotas VPN įdiegia sąsają, perima pasirinktų prefiksų nuosavybę ir integruojasi su mazgo maršrutizavimu ir prieigos politika. Kiekviena mašinos programa gauna naudą nežinodama, kad tunelis egzistuoja. Apvalkalas suteikia tą pasiekiamumą vienam sukonfigūruotam klausytojui ir sustoja ten.

Priėmimas vėl atskiras. VPN, autentifikuojantis klientą, vis dar reikia autorizacijos, kuri nurodo, kuriuos išteklius klientas gali pasiekti, o apvalkalas, autentifikuojantis partnerį, vis dar reikia backend, kuris vykdo savo leidimus.

Yra teisėta kombinacija: VPN protokolas, perduodamas TLS apvalkalo viduje, sąmoningai palaikomoje TCP struktūroje. Tai sluoksniuoja du sluoksnius ir nepadaro apvalkalo ir VPN to paties tipo objektu.

Palyginkite ribą, kuri nepavyksta

Užsirašykite priekinės dalies adresą, klausytoją, partnerio tapatybę, backend tikslą ir programos operaciją prieš ką nors keisdami. Tada lyginkite palyginamą su palyginamu: sėkmė per kitą mazgo vardą ar prievadą neįrodo, kad ugniasienės ir sertifikato sąlygos buvo identiškos.

Atmestas backend užklausos negalima taisyti išjungiant priekinės dalies tapatybės patikrą. Tai keičia diagnozuojamą autorizacijos gedimą į nediagnozuojamą pasitikėjimo gedimą.

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

Vardo priskyrimas pasirinktam adresui atskiria vardų sprendimą nuo pasiekiamumo, ir tai paprastai yra greičiausias būdas sužinoti, kuri iš dviejų yra sugedusi.

Svarbus palyginimas įvardija apsaugotą galinių taškų porą, perduodamą naudingąją apkrovą, ją naudojančias programas ir paskirties vietoje vykdomą leidimą. TLS prisideda prie šio aprašymo, bet jo neužbaigia.