მიეცით დისტანციურ Pi-ს SOCKS პროქსი თქვენი SSH კლიენტის მეშვეობით

თქვენ ვარაუდობთ, რომ SOCKS პროქსი უნდა მუშაობდეს იქ, სადაც ქსელში წვდომა უკვე არსებობს. OpenSSH-ს შეუძლია მსმენელი სრულიად სხვა ადგილას განათავსოს. დისტანციური დინამიკური გადაგზავნა ხსნის SOCKS პორტს დისტანციურ ჰოსტზე და ყოველ კავშირს იწყებს თქვენი ლოკალური SSH კლიენტიდან, რომელიც ატარებს თქვენი ლეპტოპის დამტკიცებულ VPN მარშრუტს. Pi იღებს შეზღუდულ პროქსის; ის არ იმკვიდრებს თქვენს გვირაბს ან თქვენს პრივილეგიებს.

მსმენელი და კავშირის წყაროს მხარე შეიძლება განსხვავდებოდეს

ჩვეულებრივი ssh -D 1080 მსმენელს თქვენსავე მანქანაზე უშვებს და კავშირებს იქიდან აგზავნის. დისტანციური დინამიკური გადაგზავნა ამას აბრუნებს: მსმენელი ჩნდება დისტანციურ ჰოსტზე და ყოველი კავშირი, რომელსაც ის იღებს, იხსნება ლოკალური მხრიდან. OpenSSH კლიენტის სახელმძღვანელო აღწერს -R-ს ფიქსირებული დანიშნულების გარეშე ზუსტად როგორც ამ SOCKS4/5 განლაგებას.

ლეპტოპიდან მხარდაჭერილი ბრძანება ასე გამოიყურება, სადაც ანგარიში, ჰოსტები და პორტი დროებითი მნიშვნელობებია:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

სამი დეტალი სასარგებლო სამუშაოს ასრულებს იქ. -S none სესიას საერთო კონტროლის მასტერისგან მოშორებით ინახავს, ExitOnForwardFailure სწრაფად ვარდება ნახევრად ღია სესიის დატოვების ნაცვლად, და PermitRemoteOpen ზღუდავს, თუ სად შეიძლება მიაღწიოს დისტანციურმა მსმენელმა. გამოიყენეთ ავტორიზებული Pi ანგარიში და გადაამოწმეთ ჰოსტის გასაღები, სანამ რომელიმეს დაამატებთ.

რას ამჟღავნებს დისტანციური მსმენელი სინამდვილეში

შეამოწმეთ სერვერის გადაგზავნის პოლიტიკა, სანამ მსმენელს დაეყრდნობით. GatewayPorts no-ით დისტანციური გადაგზავნა loopback-ზე დაბმული რჩება და ეს არის ის გამოვლენა, რომელიც გსურთ. სერვერი, რომელიც wildcard გადაგზავნას აიძულებს, იმავე პორტს ყველა ინტერფეისზე აქვეყნებს, რაც პირად პროქსის ლოკალური ქსელისთვის მისაწვდომ რამედ აქცევს.

loopback ასევე არ არის მომხმარებლის საზღვარი. Pi-ზე სხვა პროცესს შეუძლია 127.0.0.1:1080-ს დაუკავშირდეს, თუ პორტი იცის, ამიტომ Pi-ის ლოკალური ანგარიშები და ყველაფერი, რაც მასზე მუშაობს, თქვენი წვდომის დიზაინის ნაწილია. ეს დანიშნულებათა სიის ვიწროდ შენახვის მიზეზია და არა პოლიტიკის შემოწმების გამოტოვების.

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

ერთი აპლიკაცია გაატარეთ პროქსიდან

Pi-ზე პროქსის გამგებ კლიენტს შეუძლია შემდეგ მოთხოვნის გაგზავნა. socks5h პრეფიქსი დანიშნულების სახელს პროქსის გადასცემს, ამიტომ ძებნაც და კავშირიც ლეპტოპის მხარეს ხდება, და ეს ემთხვევა PermitRemoteOpen-ში დასახელებულ დანიშნულებას:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

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

ლეპტოპს კვლავ სჭირდება საკუთარი მარშრუტი და რეზოლვერთან წვდომა როგორც SSH სერვერზე, ისე აპლიკაციაზე. მისი SSH კლიენტის ტრაფიკი დამტკიცებული VPN პოლიტიკით უნდა შეირჩეს, და split-tunnel გამონაკლისმა შეიძლება ეს ტრაფიკი თქვენ მიერ შემოწმებულისგან განსხვავებულ გზაზე გაგზავნოს.

დაამტკიცეთ გზა და დახურეთ ის

დაადასტურეთ, რომ მსმენელი იქ არის, სადაც ელოდებით და პასუხობს მხოლოდ განზრახული დანიშნულება:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

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

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

მუდმივი წვდომისთვის გამოიყენეთ ნაცვლად ქსელის მფლობელის მხარდაჭერილი რეგისტრაცია ან მართული კარიბჭე. საპირისპირო პროქსი არასწორი იარაღია VPN-ის მოწყობილობის ან რესურსის შეზღუდვების ასარიდებლად; მათ შიგნით გამოყენებისას ის უბრალოდ ერთი ავტორიზებული აპლიკაციური გზაა მკაფიო საზღვრებით.