რატომ აღრიცხავს Squid HTTPS ჰოსტს, მაგრამ არა გვერდის ბილიკს
ხსნის HTTPS ბილიკების არარსებობას ჩვეულებრივ Squid CONNECT ჟურნალებში, TLS ჩარევის ჩვეულებრივ ჟურნალის კორექტირებად მიჩნევის გარეშე.
shop.example:443-ის ჩანაწერი Squid-ს არ აძლევს /orders/42 ბილიკს. CONNECT ითხოვს ჰოსტს/პორტს; შემდეგ დანიშნულების TLS HTTP ბილიკს გვირაბის შიგნით გადაიტანს.
| მტკიცებულება | ჩვეულებრივი CONNECT გადაცემა |
|---|---|
| სამიზნე ჰოსტი/პორტი და გვირაბის შედეგი | ხელმისაწვდომია პროქსისთვის. |
| შიდა HTTPS ბილიკი და აპლიკაციის მოთხოვნა | დაშიფრული კლიენტსა და საიტს შორის. |
ბრაუზერის URL-ის ფრაგმენტი, რომელიც იწყება #-ით | ჩვეულებრივ კლიენტში რჩება, პროქსის ჟურნალის გარეთაც. |
ჟურნალის ფორმატი შეიძლება ჩაწეროს ის ველები, რაც Squid-ს აქვს, და არა გაშიფროს უნახავი შეტყობინებები. ჩვეულებრივი HTTP გადაცემა განსხვავებულია, რადგან შუამავალი იღებს იმ HTTP მოთხოვნას. უფრო დეტალური გამომავალი CONNECT საზღვარს არ ცვლის.
მართული TLS ჩარევა ცვლის კლიენტის ნდობასა და ადმინისტრაციულ მოთხოვნებს. ეს არ არის პატარა ჟურნალის გადამრთველი და ზედმეტია IP-ის შემცვლელი ჩვეულებრივი გადამისამართების პროქსისთვის.
თუ აპლიკაცია თქვენია და გჭირდებათ გვერდის დონის დიაგნოსტიკა, გამოიყენეთ მისი ჟურნალები ან სათანადოდ შექმნილი კლიენტის ტელემეტრია. პროქსის წარუმატებლობისას შეინარჩუნეთ სამიზნე ჰოსტი, დრო, სტატუსი და დასრულებული კავშირის ეტაპი; ისინი ხშირად პოულობენ პრობლემას პირადი გვერდის ბილიკების შეგროვების გარეშე.