TLS ուղիղ պրոքսիի ունկնդրող Squid 6.13-ում

Squid 6.13-ը կարող է TLS-ով ընդունել ուղիղ պրոքսիի հարցումներ, եթե հավաքված է GnuTLS-ով կամ OpenSSL-ով։ Սա պաշտպանում է հաճախորդ–պրոքսի կապը՝ առանց HTTPS նպատակակետի առանձին նստաշրջանին միջամտելու։

1. Ձեռք բերեք սերտիֆիկատ այն հոսթի անվան համար, որով հաճախորդները հասնելու են Squid-ին։ Մասնավոր բանալին սահմանափակեք միայն դրա կարիքն ունեցող ծառայության ինքնություններով։
2. Ավելացրեք TLS ունկնդրող՝ ձեզ հատկացված հասցեով և սերտիֆիկատների իրական ուղիներով․

https_port 192.0.2.10:3129 tls-cert=/etc/squid/proxy-chain.pem tls-key=/etc/squid/proxy-key.pem

Պահպանեք թույլատրված հաճախորդների ցանկն ու նպատակակետի սահմանափակումները, ինչպես նաև իսկորոշման քաղաքականությունը։ Ունկնդրողը մուտքի իրավունք չի տալիս։ Գոյություն ունեցող http_port-ը նույնպես մնում է ակտիվ․ հեռացրեք կամ սահմանափակեք հին ունկնդրողը, եթե հաճախորդների բոլոր կապերը պետք է TLS օգտագործեն։ Արագացուցիչի, միջամտության կամ սերտիֆիկատ ստեղծելու ռեժիմ պետք չէ։

Նախքան նախատեսված ծառայությունը վերաբեռնելը վերլուծեք կարգավորումները։ Վերլուծիչի ստուգումը հաստատում է կառուցվածքն ու սերտիֆիկատի բեռնումը, ոչ թե ցանցային հասանելիությունը։ Հաջող վերաբեռնումից հետո թույլատրված հաճախորդից հարցում կատարեք TLS միացման կետով․

curl --proxy https://proxy.example:3129 --proxy-cacert approved-proxy-ca.pem --connect-timeout 5 --max-time 15 https://example.com/

Օգտագործեք իրական պրոքսի հոսթի անունը և հաստատված CA ֆայլը։ Հանրայնորեն վստահելի պրոքսիի սերտիֆիկատը գուցե առանձին փաթեթի կարիք չունենա։ --proxy-cacert-ը սահմանում է պրոքսիի վստահությունը՝ նպատակակետի ստուգումը թողնելով առանձին․ պահեք երկու ստուգումներն էլ։

Ստուգեք իրական ունկնդրողն ու սերտիֆիկատի անունը, ապա փորձարկեք նաև վերահսկվող աղբյուրը, որը պետք է մերժվի։ Միայն հաջող վերլուծությունը չի հաստատում հաճախորդի վստահությունը կամ մուտքի սահմանը։