SSH-ით გადაგზავნილი პორტი ყოველთვის SOCKS პროქსი არ არის
განასხვავეთ SSH-ის ფიქსირებული ლოკალური გადაგზავნა დინამიკური SOCKS მსმენელისგან, სანამ აპლიკაციას დააკონფიგურირებთ.
ქმნით SSH გვირაბს, შეიყვანთ 127.0.0.1-ს და მის პორტს ბრაუზერის პროქსის პარამეტრებში და არაფერი იტვირთება. შესაძლოა მსმენელი სრულყოფილად მუშაობს. შესაძლოა ის უბრალოდ არასწორი ტიპის ტრაფიკს ელოდება.
| გადაგზავნა | რას აგზავნის ლოკალური აპლიკაცია | დანიშნულების არჩევა |
|---|---|---|
-L | სამიზნე სერვისის ჩვეულებრივი პროტოკოლი | დაფიქსირებულია SSH ბრძანებაში |
-D | SOCKS მოლაპარაკება, შემდეგ აპლიკაციის ტრაფიკი | მოთხოვნილია SOCKS კლიენტის მიერ |
ერთი ვებ-სერვერისთვის ეს ფიქსირებული გადაგზავნაა:
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]ეწვიეთ http://127.0.0.1:9080/-ს ვებსაიტად. არ მონიშნოთ პორტი 9080 როგორც SOCKS: ის ბაიტებს გადასცემს ბრძანებაში დასახელებულ ერთ ვებ-სერვერს. საიტის სხვა ჰოსტის სახელით გახსნამ შეიძლება გავლენა მოახდინოს მის ვირტუალურ ჰოსტინგზე, გადამისამართებებზე ან ქუქიებზე.
SOCKS მსმენელის შემთხვევაში ფორმა იცვლება:
ssh -N -D 127.0.0.1:1080 [email protected]დააკონფიგურირეთ აპლიკაცია, რომ გამოიყენოს SOCKS 127.0.0.1:1080-ზე. ამ მისამართის პირდაპირ ბრაუზერის მისამართების ზოლში შეყვანა ვებ-მოთხოვნას SOCKS მსმენელთან აგზავნის, პროტოკოლის კიდევ ერთი შეუთავსებლობა.
OpenSSH-ის სახელმძღვანელო აღწერს ორივე ფორმას. არსებობს სასარგებლო გამონაკლისი: არსებული HTTP პროქსის გადაგზავნა -L -ის მეშვეობით ქმნის ლოკალურ პორტს, რომელიც HTTP პროქსის პროტოკოლით საუბრობს, რადგან მისი ფიქსირებული დანიშნულება თავად HTTP პროქსია. შორეულ ბოლოში არსებული სერვისი განსაზღვრავს, რა ეკუთვნის ფიქსირებულ გადაგზავნას. არსებული პროქსის გადაგზავნა SSH-ით ინარჩუნებს ამ პროქსის პროტოკოლსა და ანგარიშს.