სრულმა გვირაბმა თქვენი SSH სესია მოკლა: დააფიქსირეთ დაბრუნების მარშრუტი

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

რას ამონტაჟებს რეალურად redirect-gateway

თავის def1 ფორმაში redirect-gateway ამატებს 0.0.0.0/1 და 128.0.0.0/1 ნაგულისხმევი მარშრუტის გადაწერის ნაცვლად. ეს ორი ნახევარი მთელ მისამართთა სივრცეს ფარავს, და ორივე რჩება უფრო გრძელ პრეფიქსად, ვიდრე 0.0.0.0/0, ამიტომ ნებისმიერი დანიშნულება უფრო კონკრეტული დამთხვევის გარეშე ახლა გვირაბში შედის. ეს არის ის მექანიზმი, რომელიც უნდა დაიმახსოვროთ, რადგან ქვემოთ მოცემული ყოველი შესწორება მუშაობს უფრო კონკრეტული დამთხვევის დაყენებით.

თქვენი ადმინისტრაციული მისამართი ერთ-ერთი ასეთი დანიშნულებაა.

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

ip route show table main | head -n 20
ip route get 198.51.100.23

იპოვეთ თქვენი წყაროს მისამართი და გზა გვირაბამდე

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

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

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

დააფიქსირეთ ჰოსტის მარშრუტი, რომელიც აღემატება ნახევარ-ნაგულისხმევებს

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

შეამოწმეთ ძებნით და არა ცხრილის დათვალიერებით: პასუხმა უნდა დაასახელოს eth0 და კარიბჭე, არასოდეს tun0.

OpenVPN უკვე ამატებს ჰოსტის მარშრუტს თავად VPN სერვერის მისამართზე იმავე მიზეზით, ამიტომ ნიმუში ნაცნობია და ადმინისტრაციული მისამართი უბრალოდ კიდევ ერთი გამონაკლისია. ნუ მიმართავთ route-nopull ამის გამოსასწორებლად, რადგან ის ყრის გვირაბისთვის საჭირო გაგზავნილ მარშრუტებს, მათ შორის დისტანციურ ქსელსა და DNS პარამეტრებს.

გახადეთ ის ხელახლა დაკავშირების მიმართ გამძლე

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

როგორც route-up სკრიპტიც და ქსელის მენეჯერის pre-up კაუჭიც მუშაობს, და საიმედო შემოწმებაა ხელახლა დაკავშირება და მის შემდეგ იგივე ძებნა.

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

როცა დაფიქსირებული მარშრუტი მაინც არ კმარა

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

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

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