მალავს თუ არა VPN მარშრუტის ქეში თქვენს ცვლილებას? შეამოწმეთ სამი რამ

მარშრუტის ქეშის გასუფთავება პირველი ინსტინქტია, როცა ცვლილება არ ამოქმედდება, და თანამედროვე Linux-ზე ეს ფუჭი შრომაა: გლობალური IPv4 მარშრუტის ქეში წლების წინ წაიშალა, ამიტომ ip route show cache არაფერს ბეჭდავს და გასასუფთავებელი არაფერია. მდგომარეობა, რომელიც გატყუებთ, ერთი ფენით ზემოთ ცხოვრობს: socket-ში, NAT-ის ასახვაში, რეზოლვერში ან ქსელის მენეჯერში, რომელმაც ძველი პროფილი ხელახლა გამოიყენა. სამი კითხვა ყოფს ამ შემთხვევებს: მოდის თუ არა არასწორი გზა ახალი ნაკადიდან თუ ძველი კავშირიდან, ქეშავს თუ არა თქვენი პლატფორმა მარშრუტებს საერთოდ, და მდგომარეობა მარშრუტიზაციაშია თუ მის ზემოთ. უპასუხეთ მათ ინტერფეისის გადატვირთვამდე.

შემოწმება პირველი: მოდის ძველი გზა ახალი ნაკადიდან?

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

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

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

შემოწმება მეორე: ინახავს თქვენი პლატფორმა საერთოდ მარშრუტის ქეშს?

Linux-ზე პასუხი არის არა, იმ გაგებით, რასაც უმეტესი სახელმძღვანელო გულისხმობს. გლობალური დანიშნულების ქეში არ არსებობს გადასაგდებად, და არჩეულ მარშრუტს რომ ინახავს socket-ის დონის ჩანაწერი, ის socket-თან ერთად თავისუფლდება. ip-route სახელმძღვანელოს ქეშის ნაწილი ისტორიულ ქცევას აღწერს და არა იმას, რისი გასუფთავებაც მიმდინარე ბირთვზე შეგიძლიათ.

სხვა პლატფორმები განსხვავდება და სწორედ აქ ცდება რჩევების კოპირება. Windows ინახავს დანიშნულების ქეშს, რომლის გასუფთავებაც netsh interface ip delete destinationcache-ით შეგიძლიათ. BSD და macOS დანიშნულების მიხედვით ძიებებს route -n get-ის მეშვეობით აჩვენებს, და მათი ქეშები საკუთარი გრაფიკით იწურება. ბრძანება, რომელიც ერთ-ერთ მათგანზე მუშაობს, Linux-ზე საერთოდ არაფერს აკეთებს, ამიტომ იგივე გამოსწორება მსურველთა ნახევარს წარუმატებლად ეჩვენება.

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

შემოწმება მესამე: მდგომარეობა მარშრუტიზაციაშია თუ მის ზემოთ?

წაიკითხეთ მიმდინარე ძიება სხვა რამის წაკითხვამდე: ip route get დანიშნულებისთვის, შემდეგ იგივე ბრძანება from-ითა და წყაროს მისამართით, შემდეგ ip rule show. თუ ეს სამი ემთხვევა თქვენს განზრახვას, მარშრუტიზაცია არ არის გამოსასწორებელი ფენა, და მოძველებული დაკვირვება სხვა ადგილიდან მოვიდა.

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

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

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

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

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

შენიშვნებში სამი მდგომარეობა ცალ-ცალკე შეინახეთ

შენახული კონფიგურაცია, მიმდინარე ძიება და დაკვირვებული ნაკადი სამი განსხვავებული ფაქტია, და მათი «ქეშში» შერწყმა არის ის, რაც ხარვეზის რეპროდუცირებას ართულებს. ჩაწერეთ მარშრუტის მფლობელი პროფილი ან ერთეული, ip route get-ის გამოსავალი, და რეალური კავშირის წყარო და დანიშნულება.

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