Ĉu TLS-ĉirkaŭaĵo donas al vi privatan reton? Kutime ne

TLS protektas kanalon inter du finpunktoj kaj diras nenion pri tio, kiuj servoj troviĝas ene. Ĉirkaŭaĵo transformas tiun kanalon en unu agorditan plusendilon, por unu aŭskultanto, al unu celo. Produkto vendata kiel SSL VPN kutime aldonas interfacon, enkursigan tabelon kaj alirmodelon ĉirkaŭ la sama primitivo. Konfuzi la du estas kiel funkcianta tunelo estas prenita por reta aliro.

Kion serva ĉirkaŭaĵo fakte konektas

Ĉirkaŭaĵo aŭskultas sur loka pordo kaj plusendas tion, kio alvenas, al agordita celo, ĉu gastiganto kaj pordo, ĉu loka programo. Tiun celon elektas tiu, kiu skribis la agordan dosieron, po unu aŭskultanto. Instali la pakaĵon kreas neniujn enkursigojn, neniun virtualan interfacon kaj neniun atingeblon por io ajn, kio ne estas eksplicite listigita. Legu la agordon antaŭ la pakaĵa priskribo, ĉar la priskribo kovras klason de uzo kaj la dosiero kovras vian.

Do la utila demando pri ĉirkaŭaĵo ne estas, ĉu ĝi ĉifras, sed kio staras ĉe ĉiu fino de la ĉeno, kiun ĝi konstruas.

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

Legu tiun ĉenon el la agordo prefere ol el la merkatika nomo. Ĉiu sago estas aparta reta salto kun sia propra adreso kaj siaj propraj alirreguloj.

Trovu, kie finiĝas la TLS-kanalo

Se la ĉirkaŭaĵo finas TLS, ĉio, kion ĝi plusendas, estas nova konekto kun novaj ecoj. La fluo povas esti plata teksto sur privata segmento, aŭ ĝi povas porti alian protektitan protokolon ene. Supozi ajnan el la du sen legi la agordon de la postaĵo estas kiel homoj konkludas, ke la ekstera tavolo protektas datumojn, kiujn ĝi neniam plu vidas. La plusendita salto meritas sian propran inspektadon, sur sia propra adreso kaj pordo.

Kontrolu la aŭskultanton kaj la postaĵon aparte, ĉar sukcesa manpremo ĉe la antaŭa pordo diras nenion pri la servo malantaŭ ĝi.

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

La unua komando montras, kiu procezo posedas la pordon kaj sur kiu adreso ĝi aŭskultas. La dua presas la atestilon, kiun la kliento efektive ricevas, kaj tio estas la identeckontrolo, kiun pordnumero ne povas anstataŭigi.

Kion enkursigita VPN aldonas kaj ĉirkaŭaĵo ne

Enkursigita VPN instalas interfacon, prenas posedon de elektitaj prefiksoj kaj integriĝas kun la enkursigado kaj alirpolitiko de la gastiganto. Ĉiu aplikaĵo sur la maŝino profitas sen scii, ke la tunelo ekzistas. Ĉirkaŭaĵo donas tiun atingon al unu agordita aŭskultanto kaj haltas tie.

Akcepto estas denove aparta. VPN, kiu aŭtentigas klienton, ankoraŭ bezonas rajtigon, kiu diras, kiujn rimedojn la kliento povas atingi, kaj ĉirkaŭaĵo, kiu aŭtentigas samtavolanon, ankoraŭ bezonas postaĵon, kiu plenumas siajn proprajn permesojn.

Ekzistas legitima kombinaĵo: VPN-protokolo portata ene de TLS-ĉirkaŭaĵo sur intence subtenata TCP-aranĝo. Tio stakigas du tavolojn, kaj ĝi ne igas la ĉirkaŭaĵon kaj la VPN la saman specon de objekto.

Komparu la limon, kiu malsukcesas

Notu la antaŭan adreson, la aŭskultanton, la identecon de la samtavolano, la celon de la postaĵo kaj la aplikaĵan operacion antaŭ ol ŝanĝi ion ajn. Poste komparu similon kun similo: sukceso tra alia gastigantnomo aŭ pordo ne pruvas, ke la kondiĉoj de fajroŝirmilo kaj atestilo estis identaj.

Rifuzita peto al la postaĵo neniam riparu per malŝalto de la antaŭa identeckontrolo. Tio interŝanĝas diagnozeblan rajtigan malsukceson kontraŭ nediagnozeblan fidan malsukceson.

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

Fiksi la nomon al elektita adreso apartigas nomrezolucion de atingeblo, kio kutime estas la plej rapida maniero vidi, kiu el la du estas rompita.

La komparo, kiu gravas, nomas la protektitan finpunktan paron, la portatan ŝarĝon, la aplikaĵojn, kiuj uzas ĝin, kaj la permeson plenumatan ĉe la celo. TLS kontribuas al tiu priskribo sen ĝin kompletigi.