socat SOCKS ხიდები: შეინარჩუნეთ საიტის TLS ჰოსტის სახელი

გამოიყენეთ loopback TCP მსმენელი ერთი SOCKS დანიშნულებისთვის, HTTP და TLS იდენტობის შენარჩუნებით აპლიკაციაში.

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

SOCKS4A-ს მიმწოდებელი socat აწყობებისთვის საილუსტრაციო განლაგებაა:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS ბოლო წერტილი ლოკალური პორტი 1080-ია. ადაპტერი ისმენს ლოკალურ პორტ 9443-ზე და ამ ბოლო წერტილს სთხოვს service.example.net:443. ეს სანიმუშო მნიშვნელობებია, არა სერვისის სრული განლაგება.

ადაპტერს ერთი ფიქსირებული სამიზნე აქვს

ყოველი მიღებული TCP კავშირი იმავე სერვისს ითხოვს. 9443-ზე მიერთებული აპლიკაცია თავის ჩვეულ პროტოკოლურ ბაიტებს აწვდის; socat SOCKS4A მოლაპარაკებას აწვდის. 9443-ზე ახალი HTTP CONNECT მოთხოვნის გაგზავნა სხვა დანიშნულებას არ აირჩევს—ის ამ ბაიტებს ფიქსირებულ სერვისს გადაუგზავნის.

SOCKS4A ჰოსტის სახელს აწვდის SOCKS ბოლო წერტილს დისტანციური გადაწყვეტისთვის. ეს განსხვავდება SOCKS4 ფორმისგან, რომელიც კლიენტის მიერ არჩეულ მისამართს იყენებს. არჩეულმა ზედა ნაკადმა—მათ შორის SOCKS4 პროქსების სიიდან საჯარო კანდიდატმა—უნდა დაუჭიროს მხარი SOCKS4A ჰოსტის სახელის დამუშავებას და საჭირო ავთენტიფიკაციას; ეს მაგალითი SOCKS5 პაროლით შესვლის რეცეპტი არ არის.

დაუკავშირდით ლოკალურად, ამოიცანით ნამდვილი სერვისი

HTTPS URL-ის https://127.0.0.1:9443/-ად შეცვლა ცვლის ჰოსტის სახელს, რომელსაც კლიენტი TLS-ისა და HTTP-ისთვის გამოიყენებს. service.example.net-ის სერტიფიკატი loopback-ისთვის ვალიდურ სერტიფიკატად არ იქცევა.

სადაც კლიენტი ცალკე კავშირის მარშრუტიზაციას უჭერს მხარს, შეინარჩუნეთ საწყისი URL-ის იდენტობა. Curl-ს შეუძლია ამ განსხვავების ჩვენება:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

სოკეტი ლოკალურ ადაპტერთან მიდის, ხოლო TLS შემოწმება და HTTP დანიშნულება service.example.net-ად რჩება. სხვა აპლიკაციებს საკუთარი ეკვივალენტური მხარდაჭერილი კონტროლი სჭირდებათ; ყველა კლიენტი ამას არ იძლევა.

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

დაკავშირებული სტატიები