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

რას ამბობს დაბმის შეცდომა სინამდვილეში

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

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

რომელი პროცესი ფლობს პორტს

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

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

გახადეთ მზადყოფნა გამოკვეთილი, და არა ძილი

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

ip -4 addr show dev tun0
systemctl edit ssh.service

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

შეამოწმეთ სუფთა ჩატვირთვა და ხელახალი დაკავშირება

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

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

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

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