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

წაიკითხეთ ინტერფეისი ხატულამდე

დაიწყეთ ip -details link show dev tun0-ით, როგორც აღწერილია ip-link-ის სახელმძღვანელოში, და შეცვალეთ ჩვეულებრივი სახელი იმ ინტერფეისით, რომელიც რეალურად თქვენს კლიენტს ეკუთვნის. დროშები, ტიპი, MTU და ინტერფეისის იდენტობა სასარგებლო დაკვირვებებია. ვირტუალური ინტერფეისის მდგომარეობის ფორმულირება არ ვალდებულია მოიქცეს როგორც ფიზიკური კაბელის მატარებლის მაჩვენებელი, ამიტომ UP მიიღეთ როგორც განაცხადი ინტერფეისზე და არა გვირაბზე.

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

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

დაამატეთ მთვლელები და მოთხოვნა, რომელმაც ისინი უნდა გამოიყენოს

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

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

წაიკითხეთ ორჯერ, ერთხელ ადრე და ერთხელ შემდეგ, ერთი კადრის ნაცვლად.

მისამართები და მარშრუტები ცალკე ნაბიჯებია

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

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

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

არ წაშალოთ ის, რაც არ იდენტიფიცირეთ

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

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

ეს სიფრთხილე ეხება ip link set down-საც, რომელიც შექცევადი ჩანს და ხშირად არ არის.

რა უნდა დაგიტოვოთ შემოწმებამ

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

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

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

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

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