Linux EHOSTUNREACH OpenVPN-ით: რომელი შემდეგი ნახტომი ჩავარდა?

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

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

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

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

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

გამოკვეთილი მიუწვდომელი მარშრუტი პაკეტს ლოკალურად უარყოფს

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

მარშრუტის ტიპები ურთიერთშემცვლელი არ არის. Blackhole პაკეტს გამომგზავნისთვის შეცდომის გარეშე აგდებს, prohibit აბრუნებს EACCES-ს, ხოლო unreachable აბრუნებს EHOSTUNREACH-ს. ამიტომ VPN დამხმარე, რომელიც ხელახალი დაკავშირების დროს ღრმული მარშრუტს აყენებს, შეიძლება host-unreachable შეცდომების აფეთქება გამოიწვიოს, რომლებიც გვირაბის აწევისთანავე ქრება, მაშინ როცა blackhole მარშრუტი სამაგიეროდ ჩუმ დროის ამოწურვებს გამოიწვევდა.

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

მკვდარი მეზობელი Ethernet-ზე იმავე შეცდომას იწვევს

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

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

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

შორეული მოხსენებები და ასინქრონული UDP შეცდომები

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

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

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

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

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

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

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