IPv6 გვირაბის პარტნიორის ping ვერ ხერხდება? შეამოწმეთ :: მისამართი

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

სიმპტომი, რომელიც მისამართზე მიუთითებს

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

ყველა-ნულოვანი იდენტიფიკატორი anycast-ადაა დაცული

RFC 4291 ინახავს ყველა-ნულოვან ინტერფეისის იდენტიფიკატორს ქვექსელის როუტერის anycast მისამართად, ამიტომ /64, მაგალითად 2001:db8:4a::/64 არ შეიცავს გამოსადეგ ჰოსტს მისამართზე 2001:db8:4a::. დაცვა თავის ადგილს იმსახურებს: როუტერის განცხადებები და მეზობლების აღმოჩენა ამ ფორმას მისამართებს, და როუტერი პასუხობს იმ პრეფიქსისთვის, რომელსაც ემსახურება. ამ მნიშვნელობის გვირაბის ბოლოსთვის მინიჭება ფოთოლს როუტერის როლს აძლევს და სწორედ ამიტომ არაფერი ბრუნდება. პრეფიქსის ნებისმიერი სხვა იდენტიფიკატორი ჰოსტად მუშაობს, ამიტომ შესწორება ჩვეულებრივ ერთი ციფრია.

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

მიანიჭეთ ჰოსტის მისამართები და დაამარშრუტეთ პრეფიქსი

აირჩიეთ ::1 და ::2 ორი ბოლოსთვის, დაამატეთ ერთი ip -6 addr add 2001:db8:4a::2/64 dev tun0-ით, შემდეგ დაამარშრუტეთ შორეული პრეფიქსი იმის ნაცვლად, რომ სცადოთ მისი მისამართება. მარშრუტი 2001:db8:4a::/64 -ისთვის გვირაბის გავლით შორეულ მხარეს ხდის მისაწვდომს; მხოლოდ მისამართი მხოლოდ ლოკალურ ინტერფეისს აკონფიგურირებს.

სრული გვირაბისთვის არის მესამე ნაბიჯი, ნაგულისხმევი მარშრუტი გლობალური unicast-ისთვის მოწყობილობის გავლით, რაც IPv6-ში ყველაფრის გვირაბში გაგზავნის ეკვივალენტია. თუ გამოტოვებთ, IPv6 აგრძელებს ფიზიკური ბმულის გამოყენებას, სანამ IPv4 გვირაბის შიგნით მოგზაურობს, ამიტომ ჰოსტი ჟონავს ზუსტად იმ ტრაფიკს, რომელიც გეგონათ დაფარული. დაადასტურეთ ip -6 route get 2001:4860:4860::8888 -ით და წაიკითხეთ, რომელ მოწყობილობას ასახელებს, ნაცვლად პასუხის ვარაუდისა.

multicast უარყოფილია მარშრუტიზაციამდე

Android ამოწმებს VpnService.Builder -ის მისამართებსა და მარშრუტებს LinkAddress-ის მეშვეობით, და ეს კონსტრუქტორი multicast-ს პირდაპირ უარყოფს. მიეცით მას multicast პრეფიქსი მარშრუტად და შედეგი იქნება არა მარშრუტი, არამედ ცუდი LinkAddress პარამეტრების წარუმატებლობა, რაც ვალიდაციის პასუხია და არა ქსელის. უარი შეესაბამება გარემოს: წერტილ-წერტილ tun მოწყობილობას არ აქვს ბმულის დონის multicast, ამიტომ მასზე ჯგუფურ მარშრუტს დასაყენებელი მიწოდების მოდელი არ აქვს. ჯგუფურ მისამართებს თავად stack-ი ქმნის და მოიხმარს, და არა ხელით კონფიგურირდება.

IPv6 all-nodes და solicited-node მისამართები იმავე წესის ქვეშ ექცევა. ინტერფეისი მათ ატარებს იმიტომ, რომ stack-მა იქ დადო, და არა იმიტომ, რომ პოლიტიკას ისინი ჰქონდა გულისხმეული.

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

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

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

სამი შემოწმება, სანამ რამეს მიანიჭებთ

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

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