SSH დინამიკური გადამისამართება როგორც SOCKS პროქსი თქვენს VPN-ზე
აპლიკაციას, რომელიც მხოლოდ SOCKS-ზე საუბრობს, ჩვეულებრივ VPN-ზე პროქსის საბოლოო წერტილი არ აქვს. ორი ნახტომი, ერთი loopback მსმენელი და ერთი სახელის ძიება, რომელიც თავად SSH სერვერმა უნდა შეასრულოს.
აპლიკაციას, რომელიც მხოლოდ SOCKS-ზე საუბრობს, ჩვეულებრივ VPN-ზე სალაპარაკო არაფერი აქვს, რადგან გვირაბი პაკეტებს გადააქვს, აპლიკაციას კი პროქსის საბოლოო წერტილი სურს. OpenSSH-ს შეუძლია ამ წერტილის მიწოდება, როცა წვდომის მფლობელი ნებას რთავს, რადგან დინამიკური გადამისამართება ერთ SSH სესიას ლოკალურ პროქსად აქცევს. შემდეგ ორი ნახტომია ცალ-ცალკე შესანარჩუნებელი: გვირაბი, რომელიც SSH ჰოსტამდე აღწევს, და კავშირი, რომელსაც ეს ჰოსტი შემდეგ ხსნის. მათი გამიჯვნა ხსნის, რატომ მუშაობს ეს მოწყობა და რას არასოდეს გააკეთებს.
რა ხდება SSH მსმენელი და რა არა
დინამიკური გადამისამართება აიძულებს SSH კლიენტს ლოკალურად მოისმინოს და SOCKS4-ით ან SOCKS5-ით ისაუბროს ყველაფერთან, რაც უკავშირდება. თითოეული მოთხოვნა ასახელებს დანიშნულებას და SSH სერვერი შემდეგ კავშირს ხსნის, ამიტომ დანიშნულების ძიება შორეულ მხარეს შეიძლება მოხდეს. ეს აპლიკაციის დონის TCP გადამისამართებაა და არა VPN მთელი მოწყობილობისთვის. ის არ ატარებს არც UDP გაერთიანებას, არც ICMP-ს და არც არაფერს იმ აპლიკაციებისთვის, რომლებიც პროქსის პარამეტრებს სრულიად უგულებელყოფენ. SSH სერვერიდან აპლიკაციამდე ნახტომი ასევე თქვენი გვირაბის შიგნით არ არის, რაც მნიშვნელოვანია, როცა დანიშნულება ტრაფიკს მხოლოდ ცნობილი ქსელებიდან იღებს.
წინაპირობები რეალურია: მარშრუტი SSH ჰოსტამდე, ავტორიზებული ანგარიში, დადასტურებული სერვერის ჰოსტის გასაღები და გადამისამართების ნებართვა. არცერთ მათგანს პროქსი არ ქმნის, და უკანასკნელი ჩვეულებრივ პირველი აკლია. დაადასტურეთ ოთხივე სხვა რამის გამართვამდე, რადგან კლიენტის მხრიდან წარუმატებლობა ერთნაირად გამოიყურება, რომელი აკლია არ აქვს მნიშვნელობა.
გაუშვით ის loopback-ზე ცხადი პორტით
აირჩიეთ გამოუყენებელი ლოკალური პორტი და ცხადად მიაბით ის loopback-ს, მისამართის გამოტოვების ნაცვლად. ქვემოთ მოცემული სამი ვარიანტი თითოეული ერთი მიზეზის გამო არსებობს.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N შორეულ ბრძანებას გამოტოვებს, -T კი ფსევდოტერმინალს, ასე რომ სესია მხოლოდ გადასამისამართებლად არსებობს. ExitOnForwardFailure აიძულებს კლიენტს გავიდეს, როცა მსმენელის შექმნა შეუძლებელია, თქვენ მიერ მოთხოვნილი გადამისამართების გარეშე მუშაობის ნაცვლად. ControlPath=none სესიას არსებული მულტიპლექსირებული კავშირის გარეთ ინახავს, რომელსაც შეიძლება საკუთარი გადამისამართებები დაუმატოს. Loopback მსმენელს LAN-ის გარეთ ინახავს, მაგრამ გაზიარებულ მანქანაზე ეს ავტორიზაციის საზღვარი არ არის, რადგან სხვა ლოკალური პროცესებიც შეიძლება მას მიაღწიონ. OpenSSH კლიენტის ცნობარი ამ ყველა დროშას აღწერს, და loopback-ის გაფრთხილება იქიდან გამომდინარეობს, თუ რა არის მსმენი socket.
სახელები პროქსის მეშვეობით გაატარეთ, და არა მის გარშემო
SOCKS5 კლიენტს შეუძლია დანიშნულება თავად გადაწყვიტოს ან პროქსის სთხოვოს ეს, და ეს არჩევანი განსაზღვრავს, რომელი გადამწყვეტი გასცემს პასუხს. socks5h-ით curl ჰოსტის სახელს პროქსის მეშვეობით აგზავნის, ამიტომ ძიება SSH სერვერზე ხდება. უბრალო socks5-ით ლეპტოპი ჯერ თვითონ წყვეტს და მხოლოდ კავშირი მოგზაურობს, რაც ჩუმად აუქმებს მიზანს, როცა სახელი შიდაა. ქვემოთ მოცემული მოთხოვნა პროქსის გარეშე სიასაც ასუფთავებს, რათა მემკვიდრეობით მიღებულმა NO_PROXY მნიშვნელობამ ის პროქსის გარშემო ვერ გაატაროს.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthსერტიფიკატის შემოწმება და აპლიკაციის საკუთარი შესვლა კვლავ ძალაშია, რადგან პროქსი არცერთ მათგანს არ ცვლის. ორი ძიება რჩება: ლეპტოპმა უნდა მიაღწიოს SSH ჰოსტს დაშვებული VPN და DNS გზით, და SSH სერვერმა თავად უნდა გადაწყვიტოს აპლიკაციის სახელი. მეორე ცალკე შეიძლება შემოწმდეს მანამ, სანამ რაიმე ტრაფიკი პროქსის გავლით წავა.
ssh [email protected] getent hosts app.corp.exampleდაამტკიცეთ ერთი დაშვებული დანიშნულება, შემდეგ დახურეთ სესია
შეამოწმეთ დანიშნულება, რომელსაც პოლიტიკა უშვებს, და ის, რომელიც უნდა უარყოს, რადგან მომუშავე გადამისამართება მხოლოდ იმას ამტკიცებს, რომ მსმენელი მუშაობს და მეტს არაფერს. აპლიკაცია ხედავს წყაროს მისამართს, რომელსაც SSH სერვერი ირჩევს, და ეს თქვენი ლეპტოპის გვირაბის მისამართი არ არის. სადაც შორეული მხარე კავშირებს წყაროს მიხედვით იწერს, ეს განსხვავება პირველია, რაც უნდა შემოწმდეს მოთხოვნის უარყოფისას.
შეაჩერეთ სესია იმ პროცესის მეშვეობით, რომელსაც ის ეკუთვნის, და არა დაუკავშირებელი shell-ის მოკვლით. შემდეგ დაადასტურეთ, რომ მსმენელი გაქრა, რადგან ჯერ კიდევ პასუხის მომცემი პორტი ის სესიაა, რომელიც სინამდვილეში არ დაგიხურავთ. მოხსენით მხოლოდ ის პროქსის პარამეტრი, რომელიც ამ სავარჯიშომ შემოიტანა, და დატოვეთ აპლიკაციის დანარჩენი კონფიგურაცია უშფოთველად. ზედამხედველობის გარეშე დარჩენილი ტერმინალი, რომელიც გადამისამართების წესს ინახავს, სერვისი არ არის, და მუდმივ პროქსის სჭირდება დამტკიცებული სასიცოცხლო ციკლი და არა დავიწყებული ფანჯარა.
ss -ltn | grep 1080მარცხები, რომელთა გამოსწორებაც ამ მოწყობას არ შეუძლია
ზოგი სიმპტომი პირდაპირ ზემოთ მოცემულ საზღვრებზე მიუთითებს, და მათი ადრეული ამოცნობა პროქსის გამართვის ნახევარ დღეს ზოგავს. ცხრილი აკავშირებს იმას, რასაც ხედავთ, იმასთან, რასაც ეს ჩვეულებრივ ნიშნავს. ბოლო სვეტში ყველაფერი დიზაინის საკითხია და არა კონფიგურაციის შეცდომა.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
პირველი სამი სტრიქონია ის, რასაც ხალხი არასწორად ადგენს, რადგან თითოეული კავშირის მცდელობას იძლევა და არა შეცდომას თავად პროქსის შესახებ. სახელი, რომელიც ლეპტოპზე წყდება, სერვერის გადამწყვეტზე არაფერს ამბობს, და მარცხი სამაგიეროდ სერტიფიკატის ან ვადის პრობლემად იკითხება. მხოლოდ UDP-ზე მომუშავე აპლიკაციები დიზაინის გარეთ დგანან და არა შიგნით გატეხილი, და არცერთი დამატებითი ssh პარამეტრი ამას არ ცვლის. ბრაუზერის სტრიქონი ჩვეულებრივი შეხსენებაა, რომ პროქსის პარამეტრები თითოეული აპლიკაციისთვისაა. ბოლო სტრიქონი დახურვის შემოწმების არსებობის მიზეზია: ჯერ კიდევ მსმენი პორტი ნიშნავს, რომ ახლა სხვა რაღაც ფლობს მას.