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

რას ცვლის გვირაბი და რას კვლავ წყვეტს SSH

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

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

წარუმატებლობის რეჟიმებიც ცალკეა, და სწორედ ეს ხდის გაყოფას სასარგებლოს ინციდენტის დროს.

სამი პირობა, რომლებიც განსაზღვრავენ წვდომის მოდელს

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

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

უპასუხეთ ამ სამს და მოდელი თავად აირჩევა. გამოტოვეთ ისინი და საბოლოოდ SSH-ს საჯაროდ გაამჟღავნებთ კლიენტის გავრცელების თავიდან ასაცილებლად.

დაადასტურეთ კერძო გზა SSH-ის დადანაშაულებამდე

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

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

ეს შეუთანხმებლობა ყველაზე გავრცელებული თვითგამოწვეული SSH წარუმატებლობაა VPN-ზე.

წაიკითხეთ წარუმატებლობის ეტაპი და არა კომბინირებული შეცდომა

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

StageWhat you seeWhat it points at
Before the connectionTimeout, no routeTunnel, route or gateway permission
Connection refusedImmediate resetNothing listening, or a host firewall rejecting
AuthenticationPermission denied after a promptUser, key or server policy

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

დეტალური გამომავალი გიჩვენებთ, რომელ ეტაპს მიაღწიეთ:

ssh -vv [email protected]

შეინარჩუნეთ ჰოსტის გასაღებები და ავტორიზაცია ხელუხლებლად

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

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

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

დაკავშირებული სტატიები