SSH ლოკალური გადამისამართება არსებულ HTTP პროქსიზე: ორი loopback მისამართი
არსებულ პროქსის SSH ჰოსტზე შეუძლია ერთი აპლიკაცია მოემსახუროს ერთი ლოკალური გადამისამართებით. გამოყავით ორი loopback მისამართი და პროქსის პროტოკოლი.
თქვენი დამტკიცებული პროქსი მუშაობს ნახტომ ჰოსტზე, სადაც ის მხოლოდ loopback-ზე უსმენს, ამიტომ ამ მანქანის გარეთ ვერაფერი ვერ მიაღწევს მას. თქვენ არ გჭირდებათ VPN ან ახალი პროქსი; გჭირდებათ ამ მანქანის ერთი პორტი, გადატანილი თქვენს ერთ პორტზე. ლოკალური გადამისამართება ზუსტად ამას აკეთებს და მას სჭირდება ერთი ბრძანება პლუს აპლიკაციის ერთი პარამეტრი. დაბნეულობა ჩვეულებრივ იმის არევით ჩნდება, თუ რომელი loopback მისამართი რომელ მანქანას ეკუთვნის.
გადაწყვიტეთ, უკვე არსებობს თუ არა ფიქსირებული პროქსი
ეს ტექნიკა გადასცემს სერვისს, რომელიც უკვე მუშაობს. თუ დისტანციურ ჰოსტს მხოლოდ SSH დემონი აქვს და პროქსი არა, გადამისამართების არც ერთი რაოდენობა არ შექმნის მას და კავშირი უარყოფილი იქნება დისტანციური მხრიდან. დარწმუნდით, რომ პროქსი მიბმულია, რომელია მისი პორტი და უსმენს თუ არა ის 127.0.0.1-ზე თუ კონკრეტულ ინტერფეისის მისამართზე, რადგან სწორედ ეს მისამართი უნდა იყოს გადამისამართების სამიზნე.
ამის წინასწარ დადასტურება გიხსნით იმ გვირაბის გამართვისგან, რომელიც არასოდეს არაფერზე იყო მიერთებული.
ააგეთ გადამისამართება და წაიკითხეთ ბრძანება
სასურველი ფორმა აკავშირებს loopback პორტს თქვენს ლეპტოპზე და აკავშირებს მას სერვერის მხრიდან პროქსის მისამართთან, როგორც სერვერი ხედავს მას.
ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
-L 127.0.0.1:13128:127.0.0.1:3128 [email protected]-N თრგუნავს დისტანციურ ბრძანებას, ხოლო -T თრგუნავს termios-ის გამოყოფას, რადგან გსურთ გვირაბი და არა გარსი. პირველი loopback მისამართი არის ადგილი, სადაც ლეპტოპი უსმენს; მეორეს SSH სერვერი წყვეტს, ამიტომ 127.0.0.1 იქ ნიშნავს პროქსის იმ მანქანაზე. ExitOnForwardFailure აიძულებს ბრძანებას ხმამაღლა ჩავარდეს, თუ ლოკალური პორტი უკვე დაკავებულია, ნაცვლად იმისა, რომ დაიწყოს სესია, რომელიც არაფერს გადასცემს. დაწერეთ სამიზნე მისამართი ისე, როგორც სერვერი წყვეტს მას, რადგან სახელი, რომლის ამოხსნაც მხოლოდ თქვენს ლეპტოპს შეუძლია, მეორე მხარეს ჩავარდება.
სერვერის საკუთარი პოლიტიკა მოქმედებს მანამ, სანამ ამიდან რამე იმუშავებს. AllowTcpForwarding უნდა დაუშვას ეს, ხოლო PermitOpen შეიძლება შეზღუდოს, რომელ დანიშნულებებსა და პორტებზე შეიძლება მიაღწიოს სესიამ, ამიტომ გადამისამართება, რომელსაც კლიენტი იღებს, სერვერმა მაინც შეიძლება უარყოს. უარყოფა კლიენტზე ჩნდება როგორც გადამისამართების ან არხის შეცდომა, და ამ შეტყობინების წაკითხვა უფრო სწრაფია, ვიდრე ბრძანების რედაქტირება.
მიმართეთ ერთი აპლიკაცია გადამისამართებას
დააყენეთ აპლიკაცია ისე, რომ გამოიყენოს HTTP პროქსი http://127.0.0.1:13128-ზე, სერტიფიკატებით, თუ დისტანციური პროქსი მოითხოვს მათ. შეინარჩუნეთ აპლიკაციის საკუთარი სერტიფიკატის შემოწმება HTTPS დანიშნულებებისთვის, რადგან პროქსის გვირაბი მას არ ცვლის. ეს ერთი სერვისის ფიქსირებული გადამისამართებაა, ამიტომ აპლიკაციას უნდა ვუთხრათ პროქსის შესახებ და არ დავუტოვოთ მას თავად აღმოჩენა.
სწრაფი შემოწმება ნებისმიერი მუდმივი კონფიგურაციის წინ: curl -x http://127.0.0.1:13128 -I https://example.com, რომელიც ვარჯიშობს HTTP CONNECT მეთოდს, რომელიც პროქსმა უნდა დაუჭიროს მხარი.
შეინარჩუნეთ უფლებამოსილება იქ, სადაც იყო
დისტანციური პროქსი კვლავ წყვეტს, რომელ დანიშნულებებსა და მეთოდებს უშვებს, და SSH შესვლამ არ უნდა ჩუმად მისცეს ყველა ანგარიშს ზოგადი ვებ რელე. ლეპტოპზე 127.0.0.1-ზე მიბმა თავიდან აიცილებს პორტის თქვენს ლოკალურ ქსელში გამოქვეყნებას, და ის პორტს არ ხდის პირადულს იმავე მანქანის სხვა პროცესებისგან. ამ მიბმის wildcard მისამართით ჩანაცვლება პროქსის გასაზიარებლად სწორედ ის გზაა, რომლითაც უმართავი ღია რელე იქმნება.
SSH ტრანსპორტი იცავს ნახტომს სერვერამდე. ამ წერტილის შემდეგ პროქსი ხსნის საკუთარ კავშირს, ამიტომ დანიშნულებაზე ჩვეულებრივი HTTP მოთხოვნა სერვერის შემდეგაც ჩვეულებრივი რჩება, თუმცა პირველი მონაკვეთი დაშიფრული იყო.
შეამოწმეთ ორივე ბოლო, შემდეგ გაასუფთავეთ
ლოკალური გვირაბის მოწყობა და დისტანციური სერვისის წარმატება სხვადასხვა შედეგია, და ბრძანების გასვლის სტატუსი მხოლოდ პირველზე გეუბნებათ. შეამოწმეთ, რომ მსმენელი არსებობს ss -ltn-ით, შემდეგ გააკეთეთ დაშვებული აპლიკაციის მოთხოვნა და მოთხოვნა, რომელიც პროქსმა უნდა უარყოს. თუ ორივე მოსალოდნელად იქცევა, გზა რეალურია; თუ გვირაბი მუშაობს და ყველა მოთხოვნა ჩავარდება, პროქსი უარყოფს ან ვერ აღწევს დანიშნულებას.
როცა დაასრულებთ, შეაჩერეთ მფლობელი SSH პროცესი, წაშალეთ პროქსის პარამეტრი აპლიკაციიდან და დაადასტურეთ, რომ ლოკალური პორტი გაქრა, ნაცვლად იმისა, რომ დატოვოთ მსმენელი, რომელიც დავალებაზე დიდხანს იცოცხლებს.