რატომ არღვევს წყაროს პორტის წესი თქვენს ერთ-ერთ SSH გზას

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

ორი შესასვლელი, ერთი სერვისის პორტი

ჰოსტს აქვს LAN-ის მხარეს მისამართი და VPN მისამართი, და sshd ორივეზე უსმენს. ამიტომ პირდაპირი სესია და გვირაბის სესია იზიარებენ სერვისის პორტს და განსხვავდებიან მხოლოდ იმით, თუ რომელი ლოკალური მისამართი იღებს კავშირს.

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

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

წაიკითხეთ წესი, შემდეგ ცხრილი

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

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

ip -4 rule show
ip route show table 100
ip route show table main

ეს ორი გამომავალი ერთად ხსნის შედეგს; თითოეული მათგანი ცალკე არასწორ დასკვნას იწვევს.

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

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

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

გამოყავით მსმენელი, ნებართვა და პასუხის არჩევა

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

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

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

დაამტკიცეთ ახალი სესიით და არა ძველით

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

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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