.NET socket-ს სჭირდება SOCKS ხელის ჩამორთმევა

Socket.Connect()-ის SOCKS სერვერისკენ მიმართვა ხსნის TCP კავშირს ამ სერვერთან. მომდევნო ბაიტებმა მაინც უნდა ისაუბრონ SOCKS-ზე. აპლიკაციის პროტოკოლის დაუყოვნებლივ გაგზავნა სერვერს სხვა საუბრის მოლოდინში ტოვებს.

SOCKS5-ის შემთხვევაში, კავშირის დამყარება მოიცავს მეთოდის მოლაპარაკებას, შერჩეულ ავთენტიფიკაციის გაცვლას და მოთხოვნას, რომელიც ასახელებს დანიშნულებას. მხოლოდ წარმატებული პასუხი ხსნის გზას აპლიკაციის ბაიტებისთვის. ეს ეტაპები განსაზღვრულია RFC 1928-ში.

მოლაპარაკება კავშირის შრეში დატოვეთ

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

ხელით დაწერილი იმპლემენტაცია, რომელიც კითხულობს ერთ ფიქსირებული ზომის ბუფერს და წარმატებას ვარაუდობს, მყიფეა. TCP არ ინარჩუნებს SOCKS შეტყობინებების საზღვრებს. სანამ აპლიკაციის პროტოკოლს დაიწყებთ, წაიკითხეთ სრული პასუხი, რომელიც მისი მისამართის ტიპით არის აღწერილი. .NET 7+-ის CONNECT პასუხის მკითხველი აჩვენებს ამ ნაბიჯს.

თუ მხარდაჭერილი ბიბლიოთეკა უკვე გვაწვდის ამ კავშირის შრეს, შეამოწმეთ მისი მხარდაჭერილი SOCKS ვერსიები, ავთენტიფიკაციის მეთოდები და სამიზნე framework. ათი წლის ფორუმის ბმული გამოკვლევის საწყისი წერტილია და არა მიმდინარე თავსებადობის მტკიცებულება.

HTTP კლიენტის კონფიგურაციას ცალკე არე აქვს

HTTP კლიენტის პროქსის პარამეტრი აკონფიგურირებს სწორედ ამ HTTP კლიენტს. ის არ ცვლის პროცესში ყველა ნედლ socket-ს. Socket API იღებს ქსელურ საბოლოო წერტილს და უმაღლესი დონის მოლაპარაკებას გამომძახებელს უტოვებს.

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