HTTP CONNECT: როგორ ამუშავებს HTTP პროქსი HTTPS-ს
მიჰყევით HTTPS მოთხოვნას HTTP პროქსის გავლით, გამოყავით CONNECT პასუხი საწყისი სერვერის პასუხისგან და იპოვეთ გვირაბის ჩავარდნის ეტაპი.
„200 Connection Established“ ნიშნავს, რომ პროქსიმ გვირაბი მიიღო. ვებსაიტს ჯერ გვერდი არ დაუბრუნებია. შემდეგ მოდის TLS დანიშნულების სერვერთან, მერე კი თავად HTTPS მოთხოვნა.
პროქსისთან კავშირიდან ვებსაიტის პასუხამდე
- კლიენტი პროქსის ბოლო წერტილს უკავშირდება.
- პროქსის სთხოვს, დაუკავშირდეს დანიშნულების ჰოსტსა და პორტს.
- პროქსი ამ მოთხოვნას იღებს ან უარყოფს.
- მიღების შემდეგ კლიენტი გვირაბით დანიშნულების სერვერთან TLS-ს ათანხმებს.
- კლიენტი აგზავნის HTTPS მოთხოვნას და ვებსაიტის პასუხს TLS-ის შიგნით იღებს.
პროქსისთან კავშირის უარყოფა, გვირაბის უარყოფა და სერტიფიკატის შეცდომა ამ მიმდევრობის სხვადასხვა ადგილას ხდება. პარამეტრების შეცვლამდე იპოვეთ ბოლო დასრულებული ნაბიჯი.
CONNECT გაცვლა
HTTP/1.1-ში გამარტივებული გაცვლა ასე გამოიყურება:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
HTTP/1.1 200 Connection Established
მოთხოვნის სამიზნე ჰოსტი და პორტია, ვებსაიტის ბილიკისა თუ მოთხოვნის პარამეტრების გარეშე. წარმატებული CONNECT პასუხის შემდეგ კავშირი გვირაბის ბაიტებს ატარებს. HTTPS დანიშნულებისთვის კლიენტის შემდეგი გაცვლა TLS ხელის ჩამორთმევაა.
წაიკითხეთ რიცხვითი სტატუსი და არა ინგლისური განმარტებითი ფრაზის ზუსტი დამთხვევა. პროქსებმა ერთი და იმავე სტატუსისთვის შეიძლება სხვადასხვა ტექსტი გამოიყენონ.
დააკვირდით curl-ით
ლოკალურ 8080 პორტზე HTTP პროქსისთვის:
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/მოსმენის მისამართი თქვენი ბოლო წერტილით შეცვალეთ. თუ კანდიდატები გჭირდებათ, ნახეთ HTTP პროქსიების სია და გამოსცადეთ არჩეული ჩანაწერი. გვერდის ავლის ცარიელი სია უზრუნველყოფს, რომ ეს გამოძახება პროქსის აირჩევს. დროითი მიმდევრობით მოძებნეთ პროქსისთან კავშირი, CONNECT პასუხი, დანიშნულების სერტიფიკატის შემოწმება და ვებსაიტის პასუხი. ჟურნალის ზუსტი ტექსტი curl-ის აგებაზეა დამოკიდებული.
დანიშნულების სერვერმა შეიძლება 404, 429 ან 500 დააბრუნოს მას შემდეგ, რაც პროქსი გვირაბს მიიღებს. ჩავარდნა TLS-ის დროსაც შეიძლება მოხდეს, ნებისმიერი HTTP პასუხის დაბრუნებამდე.
სად გაჩერდა?
| დაკვირვება | რა გამოიკვლიოთ შემდეგ |
|---|---|
| პროქსისთან კავშირი უარყოფილია | პროქსის მისამართი, მოსმენის პორტი, პროცესი და ქსელური წვდომა. |
| პროქსი აბრუნებს 407-ს | პროქსის ანგარიში და ავთენტიფიკაციის სქემა. |
| პროქსი უარყოფს დანიშნულებას ან პორტს | წვდომის პოლიტიკა და დაშვებული CONNECT დანიშნულებები. |
| გვირაბი იხსნება, შემდეგ TLS შემოწმება ვერ სრულდება | დანიშნულების სახელი, ნდობის საცავი, საათი და შესაძლო მართული TLS ჩარევა. |
| TLS წარმატებულია და ვებსაიტი შეცდომას აბრუნებს | ვებსაიტის პასუხი. |
შედარებისას ერთი მხარე უცვლელი დატოვეთ: იმავე პროქსით სხვა დანიშნულება სცადეთ, ან იგივე დანიშნულება დაშვებული პირდაპირი მარშრუტით შეადარეთ.
გვირაბს მაინც ჰყავს ოპერატორი
პროქსიმ იცის CONNECT დანიშნულება და ამუშავებს ტრაფიკის დროსა და მოცულობას. ჩვეულებრივი ბოლოდან ბოლომდე TLS ვებსაიტის აპლიკაციის შიგთავსს იცავს პროქსისგან, რომელიც ამ TLS სესიას თავისთან არ ასრულებს. კლიენტის მიერ სანდოდ მიჩნეულ მართულ ჩამჭრელ პროქსის აქვს ნდობის განსხვავებული მოდელი.