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

სამი განსხვავებული რამ, რომელსაც დაკავშირებული ეწოდება

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

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

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

რომელი მრიცხველი ამტკიცებს, რომ პაკეტები გადაადგილდნენ

IPsec-ში IKE ასოციაცია და CHILD ასოციაცია ცალკე ობიექტებია, და მხოლოდ child ატარებს იმ მრიცხველებს, რომლებიც ამ კითხვას პასუხობენ. ჩამოთვალეთ child, დააკვირდით, იზრდება თუ არა პაკეტები ორივე მიმართულებით, და შეადარეთ ეს იმას, რისი გაკეთებაც აპლიკაციას სურს. ნულზე დაყენებული ასოციაცია სხვა დაკვირვებაა, ვიდრე ის, რომელიც იზრდება, სანამ აპლიკაცია კვლავ ფარდება; პირველი ნიშნავს, რომ ტრაფიკი არ ირჩევა, მეორე — რომ ის მოძრაობს და ხარვეზი უფრო შორსაა. წაიკითხეთ მრიცხველები ორჯერ, რამდენიმე წამის შუალედით, რადგან ერთი ნიმუში ტენდენციას ვერ აჩვენებს.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

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

სად ზის ხარვეზი მას შემდეგ, რაც მრიცხველები მოძრაობენ

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

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

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

ჩაწერეთ ტრიგერი, შემდეგ შეცვალეთ ერთი რამ

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

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

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

დაკავშირებული სტატიები