რეკურსიული მარშრუტიზაცია: როცა გვირაბი საკუთარ პაკეტებს იჭერს

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

ჯერ გარე გზა შეამოწმეთ

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

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

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

რატომ ძლებს სესია ერთი წუთით

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

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

გაარკვიეთ, ვის ეკუთვნის ბოლო წერტილის გამონაკლისი

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

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

ქსელის შეცვლის შემდეგ ხელახლა შეამოწმეთ

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

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

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