Apache-ის AllowCONNECT და HTTPS დანიშნულების პორტები
გამოყავით პორტი, რომლითაც კლიენტები Apache-ის პროქსის აღწევენ, იმ დანიშნულების პორტებისგან, რომლებსაც mod_proxy_connect გვირაბებში უშვებს.
თქვენი Apache-ის პროქსი 3128 პორტზე უსმენს. კლიენტი წარმატებით აღწევს მას, მაგრამ 8443 პორტზე HTTPS სერვისი ვერ მუშაობს. პროქსის მოსმენის პორტის შეცვლა ნაკლებად სავარაუდოა, რომ გადაჭრას ეს კონკრეტული განსხვავება.
კლიენტი ჯერ პროქსის მსმენელს უკავშირდება. შემდეგ მისი CONNECT მოთხოვნა ცალკე დანიშნულების ჰოსტსა და პორტს ასახელებს. Apache-ს შეუძლია პირველი კავშირი მიიღოს და მეორე ოპერაცია უარყოს.
წაიკითხეთ AllowCONNECT დანიშნულების პოლიტიკად
Apache 2.4-ისთვის mod_proxy_connect ამუშავებს შემომავალ CONNECT მოთხოვნებს. მისი AllowCONNECT დირექტივა მართავს ამ მოთხოვნებისთვის ხელმისაწვდომ დანიშნულების პორტებს. დოკუმენტირებული ნაგულისხმევია 443 და 563.
AllowCONNECT 443 8443ეს მაგალითი ირჩევს იმ ორ დანიშნულების პორტს. ის ცვლის ნაგულისხმევ არჩევანს; ის არ ამატებს 8443-ს და ამავდროულად ჩუმად არ ინარჩუნებს ყველა ნაგულისხმევ პორტს. გამოიყენეთ დირექტივა შესაბამისი სერვერის ან ვირტუალური ჰოსტის კონფიგურაციაში.
შეინარჩუნეთ პროქსის კლიენტის ავტორიზაციის წესები ადგილზე. ნებადართული დანიშნულების პორტი არაფერს ამბობს იმაზე, რომელი კლიენტი შეიძლება სარგებლობდეს სერვისით, და ის არ ცვლის დანიშნულების ჰოსტის შეზღუდვას, როცა ეს საჭიროა.
საპირისპირო პროქსის მაგალითი სხვა კითხვას პასუხობს
Apache-ისა და HTTPS-ის ძიების შედეგები ხშირად აჩვენებს საჯარო ვებსაიტს, რომელიც ფიქსირებულ backend-ზე გადასცემს. ეს კონფიგურაცია არ არის ის გზა, რომლითაც ბრაუზერი წინა პროქსის სთხოვს CONNECT გვირაბის გახსნას არჩეულ ვებსაიტზე. მისი მარშრუტიზაციის დირექტივების კოპირებამ შეიძლება თავდაპირველი პროქსის პრობლემა ხელუხლებლად დატოვოს.
წარუმატებლობის დიაგნოსტიკისას ჩაწერეთ მსმენელი, რომელსაც კლიენტი მიაღწია, მოთხოვნილი CONNECT ავტორიტეტი და პროქსის პასუხი. თუ CONNECT წარმატებულია და TLS შემდეგ ვარდება, დანიშნულების პორტის ნებართვამ უკვე შეასრულა თავისი როლი. გააგრძელეთ TLS შეცდომით და არა AllowCONNECT-ის განმეორებით გაფართოებით.