არსებული HTTP ან SOCKS პროქსის მიღწევა SSH-ის გავლით
მიაღწიეთ დისტანციურ loopback HTTP ან SOCKS პროქსის SSH-ის გავლით მისი მსმენის საჯაროდ გამოვლენის გარეშე.
თუ relay.example.net უკვე აშვებს SOCKS-ს საკუთარ 127.0.0.1:1080-ზე, გადაამისამართეთ წვდომა იმ მსმენის საჯაროდ გამოვლენის ნაცვლად:
ssh -N -L 127.0.0.1:1081:127.0.0.1:1080 [email protected]| ბოლო წერტილი | როლი |
|---|---|
ნოუთბუქი 127.0.0.1:1081 | SOCKS მისამართი, რომელიც უნდა დაყენდეს ნოუთბუქის აპლიკაციაში. |
რელე 127.0.0.1:1080 | არსებული პროქსი, რომელსაც SSH სერვერის მხრიდან ვაღწევთ. |
ლოკალური გადამისამართების სინტაქსი ფიქსირებულ დანიშნულებას სერვერის მხარეს ანიჭებს. HTTP პროქსი დისტანციურ loopback პორტზე 3128 ან ინტრანეტის ბოლო წერტილი, როგორიცაა proxy.internal.example:8080, იმავე პრინციპით მუშაობს. დააყენეთ კლიენტი იმ არსებული HTTP პროტოკოლისთვის და ანგარიშისთვის; SSH-ით მისი გატარება არ ქმნის SOCKS-ს ან TLS-ით ჩართულ HTTPS მსმენს.
არსებული სერვისი კვლავ ირჩევს მხარდაჭერილ პროტოკოლის ვერსიებს, ავთენტიფიკაციას, დანიშნულებებს და საბოლოო გასასვლელს. თუ სხვა SSH პროცესმა შექმნა ეს დისტანციური პროქსი, ორივე პროცესი უნდა დარჩეს ცოცხალი. მარშრუტი ნოუთბუქი→რელე→კარიბჭე ვებსაიტს ბოლო გარე კავშირს აჩვენებს და არა იდენტობას, რომელსაც ლოკალური პორტი 1081 ანიჭებს.
შეინარჩუნეთ ნოუთბუქის მიბმა მკაფიოდ ლოკალური. უფრო ფართო გამოვლენა ცვლის, ვის შეუძლია სერვისზე მიღწევა, და SSH-შესვლა SOCKS პაროლს არ ამატებს მსმენს. უარის შემთხვევაში შეამოწმეთ ნოუთბუქის მსმენი, SSH ტრანსპორტი და დისტანციური პროქსი ცალკეულ ეტაპებად.