8443 պորտի HTTPS ծառայությունը կարող է չաշխատել ճիշտ կարգավորված Squid պրոքսիի միջոցով, նույնիսկ եթե սովորական HTTPS-ը 443-ով աշխատում է։ Մինչև հաճախորդի պրոքսի արձանագրությունը փոխելը ստուգեք CONNECT-ի մերժումը և նպատակակետ պորտերի քաղաքականությունը։

Squid 6.13-ի սովորական մուտքի քաղաքականությունում կարևոր են երկու ստուգումներ․ նպատակակետը պետք է անցնի Safe_ports-ը, իսկ CONNECT-ը՝ SSL_ports-ը։ Պորտը միայն մեկ ACL-ում ավելացնելը կարող է մյուս մերժումը թողնել ուժի մեջ։

Մտածված ընդլայնեք առկա սահմանումները

Սովորական վեբ պորտերը և մեկ լրացուցիչ HTTPS պորտ թույլատրող քաղաքականության համար․

acl Safe_ports port 80 443 8443
acl SSL_ports port 443 8443

Փոխարինեք կամ խմբագրեք համապատասխան սահմանումները, որպեսզի հին արժեքների անսպասելի հավաքածու չմնա։ Պահպանեք ոչ անվտանգ պորտերի և CONNECT-ի մերժման սովորական կանոնները, ինչպես նաև նախատեսված հաճախորդների սահմանափակումները։

Նեղ պահեք բացառությունը

Եթե լրացուցիչ պորտն անհրաժեշտ է միայն մեկ վերահսկվող նպատակակետի համար, հաճախորդին թույլատրող կանոնից առաջ ավելացրեք թիրախային մերժում․

acl extra_tls_port port 8443
acl approved_tls_target dst 203.0.113.20/32
http_access deny CONNECT extra_tls_port !approved_tls_target

Հասցեն փաստաթղթերի համար օրինակային արժեք է։ Օգտագործեք ձեր կառավարվող կամ ձեզ հասանելիության իրավունք տրված նպատակակետը և հաշվի առեք դրա հասցեի իրական փոփոխությունները։ Սա սահմանափակում է լրացուցիչ պորտի բացառությունը՝ 8443-ով բոլոր նպատակակետերը թույլատրելու փոխարեն։

Կատարեք ամբողջ ակտիվ կազմաձևման շարահյուսական վերլուծություն և ստուգեք կանոնների հերթականությունը։ Հաճախորդին թույլատրող համընկնող կանոնից հետո դրված ճիշտ գրված մերժումը չի ապահովի նախատեսված սահմանափակումը։

Ստուգեք հաստատված հոսթի անունն իր իրական վկայականով և պորտով, ապա ստուգեք վերահսկվող նպատակակետ, որը պետք է մնա արգելված։ Միացված պահեք TLS ստուգումը՝ նպատակակետի ինքնության սխալները պրոքսիի քաղաքականության սխալներից տարբերելու համար։ Մի հեռացրեք ամբողջ CONNECT պաշտպանությունը՝ հատուկ պորտին ուղղված մեկ հարցում աշխատեցնելու համար։

Առնչվող հոդվածներ