Squid મારફતે એક વધારાના HTTPS પોર્ટને મંજૂરી આપો

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 રક્ષણ દૂર ન કરો.