შეინარჩუნეთ ლოკალური SSH, როცა ჰოსტი გამავალ VPN-ს იყენებს

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

ქვემოთ მოცემული ნაბიჯები ვარაუდობს, რომ ადმინისტრატორი იმავე LAN-ზეა.დისტანციური ადმინისტრირება სხვა პასუხის მქონე სხვა პრობლემაა.

მიაბით SSH იმ მისამართს, რომელსაც ადმინისტრატორები იყენებენ

დაიწყეთ მსმენელიდან.ss -ltnp | grep :22 გვიჩვენებს, რასთან არის sshd მიბმული, და 0.0.0.0-ზე მსმენელი იღებს კავშირებს ყველა ინტერფეისიდან, გვირაბის ჩათვლით. LAN-ის მისამართზე მიბმა უფრო ვიწროა და განზრახვას თვალსაჩინოს ხდის:ListenAddress 192.168.10.20 ფაილში sshd_config, რასაც მოჰყვება კონფიგურაციის ტესტი და გადატვირთვა. ამ მისამართში ბეჭდვითი შეცდომა უფრო თვალსაჩინოა, ვიდრე ვაილდკარდი, რადგან sshd უარს ამბობს გაშვებაზე, როცა მისამართი არ არსებობს.

დატოვეთ ჰოსტის გასაღების შემოწმება და თითოეული მომხმარებლის ავთენტიფიკაცია ზუსტად ისე, როგორც არის. „ეს მხოლოდ ლოკალური ქსელია“ ავთენტიფიკაციის მეთოდი არ არის, და მართვის არხი, რომელიც გამოტოვებს გასაღების შემოწმებას იმიტომ, რომ მარშრუტი მოკლეა, არის მართვის არხი, რომელიც ბოროტად გამოყენებას ელოდება. DHCP-ის დაჯავშნა ან სტატიკური მისამართი სამიზნეს წინასწარმეტყველებად აქცევს, სერვერის საჯარო იდენტობად ქცევის გარეშე.

შეინარჩუნეთ LAN-ის მარშრუტი გვირაბის გარეთ

ჰოსტს, რომლის მისამართი 192.168.10.0/24-შია, აქვს დაკავშირებული მარშრუტი ამ პრეფიქსისთვის, და უფრო კონკრეტული მარშრუტი იმარჯვებს VPN-ის ნაგულისხმევზე იმავე ცხრილში. ამიტომ ლოკალური SSH ხშირად თავისით აგრძელებს მუშაობას, როცა გვირაბი ადის. გადაამოწმეთ ეს და ნუ ივარაუდებთ:ip route get 192.168.10.50 ასახელებს ინტერფეისს და წყაროს მისამართს, რომელსაც ბირთვი გამოიყენებდა, და პასუხი LAN-ის მოწყობილობა უნდა იყოს, არა გვირაბი. გაიმეორეთ შემოწმება ადმინისტრატორის მანქანიდანაც, რადგან მისი საკუთარი ცხრილი წყვეტს, საერთოდ მივა თუ არა პაკეტები. ერთსა და იმავე მავთულზე მყოფი ორი ჰოსტი შეიძლება არ დაეთანხმოს, რომელი მიმართულებაა ხელმისაწვდომი.

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

მარშრუტიზებული მართვის VLAN-ები სხვა შემთხვევაა. თუ ადმინისტრატორი ზის 192.168.50.0/24-ზე ლოკალური როუტერის უკან, სერვერს სჭირდება ცხადი მარშრუტი ამ პრეფიქსისთვის 192.168.10.1-ის გავლით, და ეს მარშრუტი უნდა გადაურჩეს ხელახლა დაკავშირებას. შეინარჩუნეთ გამონაკლისი მართვის პრეფიქსზე კონკრეტული; კერძო დიაპაზონების ფართო გამონაკლისი გვირაბის მიზანს აუარებელს ხდის.

გახადეთ firewall-ის გამონაკლისი ისეთივე ვიწრო, როგორც წესი

თუ ჰოსტზე firewall მუშაობს, დაუშვით SSH მხოლოდ მართვის წყაროდან და მხოლოდ LAN-ის ინტერფეისზე. წესი, რომელიც 22 პორტს ყველგან უშვებს, მოთხოვნაზე ფართოა და განხილვაზე გამართლება უფრო რთულია. nftables ჰოსტზე წესი შეყვანის ჯაჭვშია ინტერფეისისა და წყაროს დამთხვევით; iptables ჰოსტზე ეკვივალენტი -i და -s ზე ორი დამთხვევის წყვილია. დააკომენტარეთ წესი იმ ადმინისტრატორთა ჯგუფით, რომელსაც ემსახურება, რათა მომდევნო აუდიტმა არ მოუწიოს გამოცნობა, რატომ არის 22 პორტი ღია.

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

შეამოწმეთ ორივე მდგომარეობა

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

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

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

ჩაწერეთ აღდგენის გზა runbook-ში

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

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