მხოლოდ VPN-ით ხელმისაწვდომ HTTPS საიტზე წვდომა SSH გადაგზავნით

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

პირველი ნაბიჯი: დაადასტურეთ სამი წინაპირობა

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

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

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

მეორე ნაბიჯი: მიაბით loopback პორტი და შეინარჩუნეთ სესია ცოცხალი

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

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

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

მესამე ნაბიჯი: შეინარჩუნეთ HTTPS სახელი, როცა სოკეტი ლოკალურია

https://127.0.0.1:9443/-ზე დათვალიერება ცვლის TLS სერვერის სახელს და აპლიკაციის უფლებამოსილებას. portal.lab.example-სთვის გაცემული სერტიფიკატი არ დამოწმდება loopback მისამართის წინააღმდეგ, და შედეგად მიღებული შეცდომა გატეხილ სერტიფიკატს ჰგავს და არა გადაგზავნის მოკლე გზას. ბრძანების სტრიქონის ტესტისთვის შეინარჩუნეთ ნამდვილი URL და შეცვალეთ მხოლოდ სოკეტის დანიშნულება. ამას აკეთებს --connect-to, და curl-ის სახელმძღვანელო აღწერს ქვემოთ გამოყენებულ ოთხველიან ფორმას.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

სახელი რჩება URL-ში, TLS ხელის ჩამორთმევაში და Host სათაურში, ხოლო TCP კავშირი მიდის ლოკალურ მსმენელთან. პროქსის გარეშე ვარიანტი ტესტს ამ გადაგზავნაზე ტოვებს, ნაცვლად იმისა, რომ კონფიგურირებულ HTTP პროქსის მისი ჩაჭრის საშუალება მისცეს, და სერტიფიკატის შემოწმების ჩართული შენარჩუნებაა ის, რაც შედეგს მნიშვნელოვანს ხდის.

მეოთხე ნაბიჯი: იცოდეთ, რას არ ფარავს ერთი გადაგზავნა

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

UDP, SMB აღმოჩენა და დომენში შესვლა საერთოდ არ გადის TCP გადაგზავნით. თუ ნამდვილი მოთხოვნა ზოგადი ქსელური წვდომაა, ეს კონსტრუქცია არასწორი ინსტრუმენტია და მხარდაჭერილი დისტანციური წვდომის კარიბჭეა სწორი.

მეხუთე ნაბიჯი: გაასუფთავეთ და ჩაწერეთ

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

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