გამოასწორა VPN-მა DNS, თუ უბრალოდ გამოიყენა ქეშირებული პასუხი?

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

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

გვერდის ჩატვირთვა მოთხოვნა არ არის

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

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

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

სანამ დაასკვნით, დათვალეთ ქეშები

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

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

ჩაწერეთ მოვლენა და არა შთაბეჭდილება

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

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

შეადარეთ ორჯერ ერთი და იმავე გზით

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

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

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

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