როგორ შეიძლება ერთმა პროქსი პორტმა მიიღოს როგორც HTTP, ისე SOCKS

შერეულ პროქსი მსმენელს შეუძლია მიიღოს HTTP და SOCKS ერთ TCP პორტზე, რადგან სერვერი ამოწმებს პროტოკოლის საწყის ბაიტებს. პორტის ნომერი ამ ამოცნობას არ ასრულებს.

HTTP პროქსი მოთხოვნა იწყება HTTP მეთოდით, მაგალითად GET ან CONNECT. SOCKS მისალმება იწყება ორობითი პროტოკოლის ველებით. ამ შეყვანებისთვის შექმნილ პროგრამულ უზრუნველყოფას შეუძლია კავშირი შესაბამის დამმუშავებელს გადასცეს.

ეს გამოკვეთილი იმპლემენტაციის თვისებაა. ჩვეულებრივი Squid HTTP მსმენელი შერეული არ ხდება იმის გამო, რომ მისი პორტი 1080-ზე იცვლება, და მხოლოდ SOCKS მსმენელი HTTP-ს ბრაუზერის პარამეტრიდან არ სწავლობს.

TLS კიდევ ერთ საზღვარს ამატებს: დაშიფრული პროქსი კავშირი იწყება TLS-ით, და არა ხილული HTTP მეთოდით. იმავე ბოლო წერტილზე მისი მხარდაჭერა დამატებით განზრახ დამუშავებას მოითხოვს; ღია HTTP-ისა და SOCKS-ის ამოცნობა ამ უნარს არ ადასტურებს.

გამოიყენეთ ბოლო წერტილისთვის დოკუმენტირებული კლიენტის პროტოკოლი. თუ ორივე მუშაობს, ეს მტკიცებულებაა იმ სერვერის შერეულ მსმენელზე, და არა მიზეზი, რომ პროტოკოლი ყველა კლიენტში გაურკვეველი დარჩეს.

Glider-ის შერეული მსმენელი კონკრეტულ მაგალითს იძლევა: ის ერთ ბაიტს უყურებს მისი მოხმარების გარეშე, 0x05-ს თავის SOCKS5 დამმუშავებელს უგზავნის, სხვა შემთხვევაში კი თავის HTTP პარსერს იძახებს. ეს პარსერი მაინც ამოწმებს შემომავალ მოთხოვნას; გაგზავნის არჩევანი თვითნებურ შეყვანას ვალიდურ HTTP-დ არ აქცევს.

TCP მსმენელის გაზიარება თავისთავად SOCKS5 UDP ასოციაციას არ იძლევა. Glider თავის UDP მსმენელს ცალკე რთავს. TCP პროტოკოლის არჩევა და მოგვიანებით დატაგრამების გადაცემა ცალკე შესაძლებლობებია.