რეალურად რა აპლიკაციის ტრაფიკს გადაიტანს SSH გადაგზავნა?

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

დაასახელეთ ინტერფეისი, სანამ რაიმეს შეადარებთ

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

• ჭურვი: პროგრამა დისტანციურ მანქანაზე მუშაობს, ლოკალურად არაფერი უსმენს.
• ლოკალური გადაგზავნა: თქვენს ლეპტოპს პორტი აქვს, დისტანციური ჰოსტი გამავალ კავშირს ამყარებს.
• დისტანციური გადაგზავნა: დისტანციურ მხარეს პორტი აქვს, ტრაფიკი თქვენკენ ბრუნდება.
• დინამიკური: SOCKS პროქსი კლიენტზე, იყენებენ მხოლოდ პროქსის გაგებული აპები.

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

ლოკალური, დისტანციური და დინამიკური გადაგზავნები იმით განსხვავდებიან, თუ ვინ უსმენს

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

პირველი ბრძანება ლეპტოპზე პორტ 5432-ს აბამს და მონაცემთა ბაზისკენ გადააგზავნის ისე, როგორც ის ბასტიონიდან ჩანს. მეორე პორტ 1080-ზე SOCKS პროქსის ქმნის. მესამე ბრძანება ადასტურებს, რომელი პროცესები უსმენენ სინამდვილეში, და ეს ერთადერთი მტკიცებულებაა, რომ გადაგზავნა არსებობს და არ ჩავარდნილა ჩუმად პორტების კონფლიქტის გამო.

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

გვირაბის მოწყობილობის რეჟიმი ერთადერთი ნამდვილი ქსელური გამონაკლისია

OpenSSH ასევე მხარს უჭერს -w გვირაბის მოწყობილობის გადაგზავნას, რომელიც TCP-ის მსმენელის ნაცვლად წერტილიდან წერტილამდე ინტერფეისს გადასცემს. ეს ნამდვილი ქსელური გვირაბია და განზრახ კონფიგურირდება, არა ჭურვის გახსნის გვერდითი ეფექტი.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

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

მაშინაც კი გვირაბი შორეულ ჰოსტზე მთავრდება. რაც დაცვა მისცა SSH ტრანსპორტმა, იქ მთავრდება და შემდგომი კავშირი ცალკე ნახტომია. VPN კარიბჭეს საზღვრის იგივე ფორმა აქვს, ამიტომ შედარება უნდა იყოს ფარგლებსა და დასრულებაზე და არა იმაზე, რომელი ხელსაწყო უფრო ძლიერია. ამ საზღვრის ხმამაღლა დასახელება ასევე ამთავრებს კამათს იმაზე, „შიფრავს თუ არა გვირაბი ყველაფერს“, რადგან აშკარად არ შიფრავს.

შეამოწმეთ, რომ თქვენი აპი იყენებს თქვენ მიერ აშენებულ ინტერფეისს

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

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

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