SSH მეორე კერძო გზაზე, სანამ VPN აქტიური რჩება
გვირაბის მისამართზე მიბმული SSH დემონი ახალ კერძო ინტერფეისზე არ უპასუხებს. დაამატეთ მიბმა და შეამოწმეთ ახალი სესია ძველის დახურვამდე.
ერთი მანქანა მეორეს VPN-ით აღწევს და ახლა ვიღაცას სურს იგივე shell პროვაიდერის კერძო ქსელში. მარშრუტი არსებობს, ping წარმატებით სრულდება, მაგრამ SSH მაინც უარს ამბობს. ჩვეულებრივი მიზეზი ისაა, რომ დემონი ახალ მისამართზე არასდროს უსმენდა, ამიტომ დასაკავშირებელი არაფერია. ეს მისამართის მიბმის პრობლემაა, სანამ firewall-ის პრობლემა გახდება.
რატომ არ ქმნის ახალი მარშრუტი ახალ მსმენელს
მსმენი socket-ს ქმნის პროცესი, რომელიც ასახელებს მისამართებს, სადაც მიიღებს კავშირებს. მარშრუტი მხოლოდ ეუბნება პაკეტებს, სად უნდა იმოძრაონ; ის არ ქმნის მსმენელს დანიშნულების ადგილზე. როდესაც sshd კონფიგურირებულია ერთი ListenAddress-ით, ნებისმიერ სხვა ლოკალურ მისამართზე კავშირები უარყოფილია, თუმცა ინტერფეისი მუშაობს. იგივე ეხება socket ერთეულს, რომელიც ფლობს პორტს, ამიტომ პირველი შემოწმება ყოველთვის ისაა, თუ რა უსმენს რეალურად.
შეადარეთ ორი გზა დანიშნულების მისამართით და არა ინტერფეისის სახელით. კლიენტი უერთდება მისამართს და ეს მისამართი უნდა იყოს მიბმული, სანამ რომელიმე firewall წესი მნიშვნელოვანი გახდება.
ჩამოთვალეთ მისამართები და მსმენელები
სანამ რაიმეს შეასწორებთ, ჩაწერეთ ჰოსტზე არსებული მისამართები და ახლა არსებული socket-ები.
ip -br addr
ss -ltnp | grep ':22'მისამართების სია გვიჩვენებს, რომელი კერძო მისამართია რეალური და რომელ ინტერფეისზე, ხოლო socket-ების სია გვიჩვენებს, მიბმულია თუ არა რამე მასზე. 0.0.0.0:22 მისამართზე მსმენელი უკვე იღებს ყველა მისამართს, ამიტომ ახალი მიბმა არაფერს უმატებს. კონკრეტულ მისამართზე მსმენელი დაუყოვნებლივ ხსნის უარის მიზეზს. თუ პორტი socket ერთეულს ეკუთვნის და არა დემონს, დემონის კონფიგურაცია მთელი ისტორია არ არის.
დაამატეთ მიბმა და შეინარჩუნეთ ძველი
OpenSSH იღებს რამდენიმე ListenAddress ჩანაწერს, ამიტომ VPN გზა შეიძლება დარჩეს, სანამ კერძო გზა ემატება. შეამოწმეთ ფაილი ხელახლა ჩატვირთვამდე.
sshd -t
systemctl reload sshdწარუმატებელი კონფიგურაციის ტესტი მუშა დემონს ხელუხლებლად ტოვებს და სწორედ ეს გსურთ, როცა დაკავშირებული ხართ იმ გზით, რომელსაც ასწორებთ. შეინახეთ არსებული ჩანაწერი, დაამატეთ ახალი ლოკალური მისამართი და დაადასტურეთ, რომ სერვისი ხელახლა იტვირთება მიმდინარე სესიის გაწყვეტის გარეშე. socket-ით გააქტიურებულ ინსტალაციებში მისამართი დაამატეთ socket ერთეულს და ხელახლა ჩატვირთეთ ის ერთეული. შემდეგ კიდევ წაიკითხეთ მსმენელების სია, რადგან მიბმა, რომელიც არასდროს გამოჩნდა, ნიშნავს, რომ არასწორი კომპონენტი შეასწორეთ.
შეამოწმეთ ახალი სესია ძველის დახურვამდე
დაუკავშირდით ახალ მისამართს, სანამ ორიგინალური სესია ჯერ კიდევ ღიაა, და გამოიყენეთ დეტალური გამოსავალი, რომ ნახოთ რომელი მისამართი და გასაღები გამოიყენეს. ორიგინალური სესია ღიად დატოვეთ, სანამ შემოწმება ორჯერ არ წარმატდება.
ssh -v [email protected]წაიკითხეთ გამართვის ხაზები დანიშნულების მისამართისა და წარდგენილი ჰოსტის გასაღების შესახებ. ჰოსტის გასაღების თითის ანაბეჭდი შეადარეთ უკვე სანდო მნიშვნელობას, ნაცვლად იმისა, რომ უცნობი გასაღები მიიღოთ იმიტომ, რომ ქსელი კერძოდ არის აღწერილი. ახალ დანიშნულებას საკუთარი known_hosts ჩანაწერი სჭირდება და ეს მოსალოდნელია. ძველი მართვის სესია მხოლოდ მაშინ უნდა დაიხუროს, როცა კერძო გზა მუშაობს.
SSH იცავს ტრანსპორტს, მაგრამ ცალკე აღებული ის ორ ქსელს ეკვივალენტურად არ აქცევს. გადაწყვიტეთ, შეესაბამება თუ არა კერძო გავლის ნდობა მონაცემებს, სანამ მას დაეყრდნობით.