VPN ამბობს, რომ დაკავშირებულია, მაგრამ ნაგულისხმევი მარშრუტი მკვდარია
Wi-Fi-დან Ethernet-ზე გადასვლამ შეიძლება მარშრუტი და რეზოლვერი ძველ გვირაბზე დატოვოს. ორივე მდგომარეობა ცალ-ცალკე წაიკითხეთ, შემდეგ გაასწორეთ არასწორი.
კლიენტი იტყობინება, რომ დაკავშირებულია, სისტემის სალაროს ხატულა ნორმალურად გამოიყურება და არაფერი იტვირთება. დაიწყო ზუსტად მას შემდეგ, რაც Wi-Fi-დან კაბელზე გადახვედით, ან ზუსტად მას შემდეგ, რაც დისტრიბუტივის განახლება დასრულდა. გატყდა არა პროფილი, არამედ მდგომარეობა, რომელიც წინა საბაზო კავშირისთვის იყო აგებული. ბირთვს ჯერ კიდევ აქვს ნაგულისხმევი მარშრუტი, რომელიც გვირაბის მოწყობილობაზე მიუთითებს, რომელსაც არავინ ფლობს, ან რეზოლვერი ჯერ კიდევ ჩამოთვლის სერვერებს იმ ბმულზე, რომელიც გაქრა. ორივე გაუმართაობა მკვდარ ქსელს ჰგავს და ორივე ადგილზე შეიძლება გასწორდეს.
მოძველებული ნაწილები არასწორი იყო ჯერ კიდევ მანამ, სანამ შეამჩნევდით. კაბელის გამორთვამ ისინი უბრალოდ თვალსაჩინო გახადა.
ჰკითხეთ ბირთვს, სად წავა პაკეტი
მარშრუტების სიების კითხვა ძნელია, რადგან ისინი ჩამოთვლიან ყველაფერს, რაც სისტემამ იცის, მათ შორის ჩანაწერებს, რომლებიც აღარ მოქმედებს. მარშრუტის ძიება პასუხობს ერთადერთ კითხვას, რომლის დასმაც ღირს: რომელი მოწყობილობა ატარებს სწორედ ამ პაკეტს ახლა. თუ პასუხი გვირაბის მოწყობილობას ასახელებს, ბირთვი მას გამოიყენებს მაშინაც, როცა მის უკან ცოცხალი კლიენტის პროცესი არ არის, და პაკეტი ინტერფეისში ვარდება, რომელსაც არავინ უვლის. თუ პასუხი Ethernet ადაპტერს ასახელებს, მაშინ როცა კლიენტი ამტკიცებს, რომ დაკავშირებულია, გვირაბი არსებობს, მაგრამ არჩევანი დაკარგა, რაც უსადენოდან სადენოზე გადასვლის ჩვეულებრივი შედეგია.
გაუშვით ძიება ორჯერ, ერთხელ საჯარო მისამართისთვის და ერთხელ შიდა მისამართისთვის, რადგან გაყოფილი გვირაბის პოლიტიკამ შეიძლება ერთი პატიოსნად გაატაროს და მეორე ჩამოაგდოს.
ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40რეზოლვერი მკვდარ ბმულსაც ინახავს
systemd-resolved-ის მქონე ჰოსტზე DNS სერვერები ბმულებს ეკუთვნის და არა ერთ გლობალურ სიას. ჩამოვარდნილი VPN ბმული შეიძლება გარკვეული დროით დარეგისტრირებული დარჩეს თავის სერვერებთან და მაშინ ყოველი ძიება ელოდება მისამართს, რომელიც არასოდეს უპასუხებს. ეს შეყოვნება მკვდარ ქსელად იგრძნობა და ხალხს მარშრუტებისკენ აგზავნის, როცა მარშრუტი რიგზეა.
resolvectl status
resolvectl query intranet.example.comწაიკითხეთ ბლოკები ბმულების მიხედვით და დაადგინეთ, რომელი ბმული ფლობს საკითხავ დომენს. გვირაბი, რომელიც აწეულია, მაგრამ შიდა დომენის მფლობელი არ არის, შიდა სახელებს საჯარო რეზოლვერზე გადასცემს და სიმპტომი მარშრუტიზაციის ხარვეზისგან არ გაირჩევა.
გაასწორეთ რეგისტრაცია და არა /etc/resolv.conf. მიმდინარე Ubuntu-სა და Fedora-ს ინსტალაციებში ეს გზა რეზოლვერის გაშვების მდგომარეობაზე სიმბოლური ბმულია, ამიტომ რედაქტირება ან იგნორირდება, ან შემდეგ ქსელურ მოვლენაზე გადაიწერება.
VPN არასოდეს იწყება თავისით
NetworkManager VPN-ს საბაზო კავშირის ზემოთ აწევს და სწავლობს, რომელს მიჰყვეს, connection.secondaries იმ ბაზაზე. კავშირის პარამეტრების ცნობარი ცხადად ამბობს, რომ ავტომატური დაკავშირება VPN პროფილებისთვის არ არის დანერგილი. ეს არის მთელი მექანიზმი ამ ტიპის ხარვეზის უკან: შეცვალეთ ბაზა და VPN ხელახლა უნდა დაწყვილდეს ან ხელით გააქტიურდეს.
nmcli device status
nmcli connection show --active
nmcli connection up office-vpnროცა აქტიური სია ბაზას VPN-ის გარეშე აჩვენებს, გვირაბი საერთოდ არ არის აქტიური და მარშრუტი არასოდეს ჩაყენებულა, და არა დარჩა მოძველებული. როცა გააქტიურება ჩივის, რომ წყაროს კავშირი არ არსებობს, ბაზა, რომელთანაც ის დაწყვილებული იყო, გაქრა, ამიტომ ჯერ ბაზა ან დაწყვილება გაასწორეთ და შეწყვიტეთ VPN-ის ხელახლა ცდა.
განახლებამ შეიძლება პარამეტრები შეტყობინების გარეშე ჩამოაგდოს
დისტრიბუტივის განახლება ცვლის კლიენტს და ხშირად მის NetworkManager დანამატს, ხოლო შენახული პროფილი ინახავს იმ თვისებების სახელებს, რომლებითაც დაიწერა. ყველაფერი, რასაც ახალი დანამატი აღარ ცნობს, ჩუმად გამოტოვდება. პროფილი კვლავ აქტიურდება და მოწყობილობა კვლავ ჩანს, მაგრამ მარშრუტი, რომელიც ადრე მასთან ერთად მოდიოდა, აღარ მოდის.
ხელით დაწერილი კაუჭებიც ინაცვლებს. სკრიპტი, რომელიც მარშრუტს ძველი თანმიმდევრობის წინასწარმეტყველებად მომენტში აყენებდა, ახლა შეიძლება იმუშაოს ინტერფეისის არსებობამდე ან მას შემდეგ, რაც კლიენტს უკვე ვადა გაუვიდა.
შეადარეთ ცოცხალი პროფილი იმ დანამატს, რომელიც ნამდვილად გაქვთ და არა იმ ქცევას, რომელიც გახსოვთ. თუ გასაღები დოკუმენტაციიდან გაქრა, გადაიტანეთ სამუშაო დისპეტჩერის სკრიპტში ან მხარდაჭერილ ჩამნაცვლებელში, ნაცვლად იმისა, რომ ძველი თვისება აღადგინოთ.
სამი მდგომარეობა, სამი განსხვავებული შეკეთება
გადაწყვიტეთ, რომელ მდგომარეობაში ხართ, სანამ რამეს შეეხებით, რადგან გადატვირთვა ანადგურებს მტკიცებულებებს და ხარვეზი შემდეგ ქსელურ ცვლილებაზე ბრუნდება.
| What the lookup shows | What it means | Repair |
|---|---|---|
| A default route via a device that exists but is unused | Leftover route from an earlier activation | Remove the stale entry, or bounce the profile that installed it |
| A tunnel device with no client process | The client skipped its cleanup | Fix the disconnect path, then clear the leftover device state |
| No tunnel device and no active profile | Missing base connection or broken pairing | Bring up the base, then pair the VPN with it again |
დაასრულეთ ერთი ძიებით საჯარო მისამართისთვის, ერთით შიდა მისამართისთვის და ერთი სახელის მოთხოვნით. თუ მისამართები მუშაობს და სახელი არა, დარჩენილი ხარვეზი დომენის არეალია რეზოლვერში და მარშრუტების ცხრილი არასოდეს ყოფილა პრობლემა.