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-ը կրկին ու կրկին լայնացնելու փոխարեն։