Squid-ის SO_ORIGINAL_DST შეცდომის წაკითხვა
სანამ Squid-ში საწყისი დანიშნულების ძიების წარუმატებლობას გამოიძიებთ, შეამოწმეთ, მიაღწია თუ არა ცალსახად კონფიგურირებულმა კლიენტმა ჩარევის მსმენელს.
NF getsockopt(SO_ORIGINAL_DST) საწყისი დანიშნულების ძიებაზე მიუთითებს. ჩარევის კონფიგურაციაში Squid-მა უნდა აღადგინოს, სად მიდიოდა თავდაპირველად გადამისამართებული კავშირი.
ცალსახად კონფიგურირებული ბრაუზერი მოთხოვნებს პროქსის განზრახ უგზავნის. ეს კავშირი NAT ჩარევის ისტორიას არ იძენს მხოლოდ იმიტომ, რომ Squid-ის მსმენელის პორტის გვერდით intercept წერია.
ამიტომ ეს შეუთანხმებლობა შეიძლება ჩავარდეს მანამ, სანამ დანიშნულების სერტიფიკატი აქტუალური გახდება.
დაიწყეთ იმით, როგორ ჩამოვიდა კავშირი
- თუ აპლიკაციას პროქსის მისამართი აქვს კონფიგურირებული, განსაზღვრეთ ჩვეულებრივი გამტარი პროქსის მსმენელი, რომელიც უნდა გამოიყენოს.
- თუ გეითვეი სხვაგვარად პირდაპირ ტრაფიკს გადამისამართებს, შეამოწმეთ, რომ ის მიაღწევს განზრახ ჩარევის მსმენელს და რომ მხარდაჭერილი NAT დიზაინი ინახავს საჭირო დანიშნულების ინფორმაციას.
- თუ ორივე რეჟიმი არსებობს, შეამოწმეთ, რომელ მისამართსა და პორტს დაუკავშირდა რეალურად წარუმატებელი კლიენტი.
Squid-ის http_port დოკუმენტაცია განსხვავებას ნათლად ხსნის: რეჟიმის დროშის გამოტოვება ირჩევს გამტარი პროქსის რეჟიმს; intercept IP დონეზე NAT ჩარევას მოელის.
შემდეგ ტრანსპორტის უსაფრთხოება ცალკე განიხილეთ. HTTP პროქსის შეუძლია HTTPS CONNECT-ით გადაიტანოს. პროქსისკენ TLS კავშირი მოითხოვს თავსებად მსმენელსა და კლიენტის კონფიგურაციას. დანიშნულების ტრაფიკის გაშიფვრა კიდევ ერთი არჩევითი შესაძლებლობაა.
არ დააკოპიროთ ძველი “HTTPS გადაწყვეტა”, რომელიც სერტიფიკატების გენერაციას რთავს მხოლოდ იმიტომ, რომ დანიშნულების URL HTTPS-ით იწყება. ჯერ გაასწორეთ კლიენტისა და მსმენელის შეთანხმება. თუ ამის შემდეგ რეალური TLS შეცდომა დარჩა, ის უფრო სასარგებლო შეცდომა იქნება გამოსაძიებლად.