რატომ ვერ მუშაობს IPv6 მეზობლების აღმოჩენა მარშრუტიზებულ VPN-ში

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

არე კონფიგურაციამდე მოდის

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

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

ხაფანგია ვარაუდი, რომ პრეფიქსი ბმულზეა

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

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

ხიდვა განზრახ ცვლის წესებს

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

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

შეამოწმეთ იმ მისამართით, რომელსაც აპლიკაცია იყენებს

დაადასტურეთ მარშრუტი ip -6 route get-ით, დაათვალიერეთ მეზობლის ჩანაწერი ip -6 neigh-ით, შემდეგ დაადასტურეთ სერვისი მარშრუტიზებულ გზაზე. DNS და დაბრუნების გზა ცალკე შემოწმებებია, და ჯანსაღი მეზობლის ჩანაწერი არც ერთს არ ამტკიცებს.

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

ჩაწერეთ, რომელი დიზაინი გაქვთ

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

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