Privoxy: HTTP პროქსი კლიენტის SOCKS გვირაბთან დაკავშირება
დააკავშირეთ მხოლოდ HTTP-ის მიმღები პროქსი კლიენტი SOCKS გვირაბთან ლოკალური HTTP პროქსის მეშვეობით, გვირაბის პორტის გადარქმევის ნაცვლად.
SSH დინამიკური გვირაბი, მათ შორის PuTTY-ის დინამიკური გადაგზავნა, გვაძლევს SOCKS ინტერფეისს. აპლიკაცია, რომელიც მხოლოდ HTTP პროქსის იღებს, ვერ გამოიყენებს ამ პორტს მხოლოდ იმით, რომ მას HTTP უწოდებს.
მათ შორის შეიძლება იყოს ლოკალური პროტოკოლის ხიდი. აპლიკაცია HTTP პროქსის მოთხოვნებს ხიდს უგზავნის, ხიდი კი დანიშნულების კავშირებს SOCKS სერვისის მეშვეობით ხსნის.
Privoxy ამ განლაგებას თავისი გადაგზავნის წესებით აღწერს. არსებული ლოკალური SOCKS5 გვირაბისთვის კონფიგურაციის ფრაგმენტია:
forward-socks5 / 127.0.0.1:1080 .აპლიკაცია უკავშირდება Privoxy-ის HTTP მსმენელს და არა 1080 პორტს. შეინახეთ ეს მსმენელი ლოკალურად განსაზღვრული წვდომის პოლიტიკის მიხედვით. წესის ბოლო წერტილს დოკუმენტირებული მნიშვნელობა აქვს; ეს არ არის დაკარგული ინტერნეტ ჰოსტის სახელის ჩანაცვლება.
ეს პროტოკოლის თარგმანია
Privoxy-ის გადაგზავნის დოკუმენტაცია ხსნის SOCKS გადაგზავნის სინტაქსსა და ჰოსტის სახელების დამუშავებას. ჩვეულებრივი TCP პორტის გადაგზავნა იმავე თარგმანს არ აკეთებს: კლიენტის HTTP ბაიტებს უცვლელად გადააქვს SOCKS მსმენელთან, რომელიც ჯერ კიდევ SOCKS მოლაპარაკებას ელოდება.
ხიდი ასევე ხდება იმ კონფიგურაციის ნაწილი, რომელიც უნდა გაიგოთ. Privoxy-ს შეიძლება ჰქონდეს საკუთარი შიგთავსის ფილტრაციისა და წვდომის პარამეტრები. მისი დამატება არ არის იგივე, რაც თავდაპირველი აპლიკაციისთვის SOCKS-ის ბუნებრივი მხარდაჭერა.
HTTPS საიტებისთვის აპლიკაცია ჩვეულებრივ HTTP ხიდს CONNECT-ს სთხოვს, ხიდი კი დანიშნულების კავშირს SOCKS-ით იღებს. საიტის ჩვეულებრივი TLS რჩება აპლიკაცია-საიტ ურთიერთობად; ხიდს არ სჭირდება საიტის განსახიერება ამ გზის მისაცემად.
თუ აპლიკაციას შეუძლია SOCKS-ის უშუალოდ გამოყენება, დამატებითი კომპონენტი შეიძლება ზედმეტი იყოს. გამოიყენეთ ხიდი რეალური პროტოკოლური შეუთანხმებლობის გადასაჭრელად, მსმენელისა და ზედა ნაკადის მკაფიო გამიჯვნით.