Apache AllowCONNECT અને HTTPS ગંતવ્ય પોર્ટ

તમારી Apache પ્રોક્સી પોર્ટ 3128 પર સાંભળે છે. એક ક્લાયન્ટ સફળતાપૂર્વક તેના સુધી પહોંચે છે, પણ પોર્ટ 8443 પરની HTTPS સેવા નિષ્ફળ જાય છે. પ્રોક્સીનો સાંભળવાનો પોર્ટ બદલવાથી એ ચોક્કસ ભેદ સંભવતઃ ઉકેલાશે નહીં.

ક્લાયન્ટ પહેલાં પ્રોક્સી શ્રોતા સાથે જોડાય છે. તેની CONNECT વિનંતી પછી અલગ ગંતવ્ય યજમાન અને પોર્ટનું નામ આપે છે. Apache પહેલું જોડાણ સ્વીકારી શકે છે અને બીજી ક્રિયા નકારી શકે છે.

AllowCONNECT ને ગંતવ્ય નીતિ તરીકે વાંચો

Apache 2.4 માટે, mod_proxy_connect આવતી CONNECT વિનંતીઓ સંભાળે છે. તેની AllowCONNECT સૂચના એ વિનંતીઓ માટે ઉપલબ્ધ ગંતવ્ય પોર્ટ નિયંત્રિત કરે છે. દસ્તાવેજીકૃત ડિફૉલ્ટ 443 અને 563 છે.

AllowCONNECT 443 8443

આ ઉદાહરણ એ બે ગંતવ્ય પોર્ટ પસંદ કરે છે. તે ડિફૉલ્ટ પસંદગીને બદલે છે; તે 8443 ઉમેરતું નથી અને દરેક ડિફૉલ્ટ પોર્ટ ચૂપચાપ જાળવી રાખતું નથી. સૂચનાનો લાગુ સર્વર અથવા વર્ચ્યુઅલ-હોસ્ટ રૂપરેખાંકનમાં ઉપયોગ કરો.

રાખો પ્રોક્સીના ક્લાયન્ટ અધિકૃતિ નિયમો યથાવત્. મંજૂર ગંતવ્ય પોર્ટ એ નથી કહેતું કે કયો ક્લાયન્ટ સેવા વાપરી શકે, અને જ્યારે ગંતવ્ય-યજમાન પ્રતિબંધની જરૂર હોય ત્યારે તે તેનો વિકલ્પ નથી.

રિવર્સ-પ્રોક્સી ઉદાહરણ બીજા પ્રશ્નનો જવાબ આપે છે

Apache અને HTTPS માટેના શોધ પરિણામો ઘણી વાર નિશ્ચિત બેકએન્ડ તરફ ફોરવર્ડ કરતી જાહેર વેબસાઇટ દર્શાવે છે. એ રૂપરેખાંકન એ રીત નથી જે રીતે બ્રાઉઝર ફોરવર્ડ પ્રોક્સીને પસંદ કરેલી વેબસાઇટ સુધી CONNECT ટ્યુનલ ખોલવા કહે છે. તેની રૂટિંગ સૂચનાઓની નકલ કરવાથી મૂળ પ્રોક્સી સમસ્યા અસ્પૃષ્ટ રહી શકે છે.

નિષ્ફળતાનું નિદાન કરતી વખતે, ક્લાયન્ટ જે શ્રોતા સુધી પહોંચ્યો, વિનંતી કરેલ CONNECT સત્તા અને પ્રોક્સીનો જવાબ નોંધો. જો CONNECT સફળ થાય અને પછી TLS નિષ્ફળ જાય, તો ગંતવ્ય-પોર્ટ પરવાનગીએ પોતાનો ભાગ પહેલેથી કરી લીધો છે. આગળ વધો TLS નિષ્ફળતા સાથે, AllowCONNECT વારંવાર પહોળું કરવાને બદલે.