443 वरील नेहमीचे HTTPS चालत असले तरी पोर्ट 8443 वरील HTTPS सेवा योग्यरीत्या संरचित Squid प्रॉक्सीतून अयशस्वी होऊ शकते. क्लायंटचा प्रॉक्सी प्रोटोकॉल बदलण्यापूर्वी 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 संरक्षण काढू नका.

संबंधित लेख