ორმაგი დასტის VPN: მისამართების ოჯახს კლიენტი ირჩევს, თქვენ არა
ერთი სახელი, ორი ოჯახი, ორი განსხვავებული გზა. გვირაბი შეიძლება ჯანმრთელი იყოს და მოთხოვნა მაინც ჩავარდეს, რადგან კლიენტმა აირჩია კანდიდატი, რომელიც არასდროს დაგიმარშრუტავთ.
გვირაბი აწეულია, IPv4 საიტები იტვირთება და ერთი ჰოსტის სახელი დროში იწურება. მყისიერი დასკვნაა, რომ VPN გატეხილია ან მონაცემები არასწორია, და ჩვეულებრივ არც ერთი არ არის მართალი. სახელმა დააბრუნა როგორც IPv4, ისე IPv6 მისამართი, აპლიკაციამ ერთი აირჩია, და მხოლოდ ერთ ამ კანდიდატს ჰქონდა სამუშაო გზა. არჩევანი კლიენტმა გააკეთა; გვირაბმა უბრალოდ არ დაფარა ის, რაც მან აირჩია.
არჩევანი დაფარვის დაპირება არ არის
ნაგულისხმევი მისამართის არჩევანი, რომელიც RFC 6724-შია აღწერილი, განსაზღვრავს, რომელ წყარო-დანიშნულების წყვილს ანიჭებს ჰოსტი უპირატესობას, როცა რამდენიმე ხელმისაწვდომია. Happy Eyeballs ზემოდან ამატებს კავშირის სტრატეგიას: იწყებს ცდებს ორივე ოჯახში და ინახავს იმას, რომელიც პირველი პასუხობს, რათა მომხმარებელმა არ დაელოდოს გატეხილი ოჯახის ვადის ამოწურვას.
არც ერთი მექანიზმი არ ქმნის მარშრუტს. თუ თქვენი გვირაბი მხოლოდ IPv4-ს ატარებს, AAAA კანდიდატი მაინც ლეგიტიმური დანიშნულებაა, რომელიც კლიენტს შეუძლია სცადოს, და წარუმატებლობა ნელი ჩატვირთვის სახით ჩნდება და არა შეცდომის, რადგან ბრაუზერი უკან დაბრუნდა. მომხმარებელი ნელი საიტის შესახებ იტყობინება და არა გატეხილის, და მხარდაჭერის ბილეთი ამ ბუნდოვანებას მემკვიდრეობით იღებს. გაამეორეთ ფიქსირებული ოჯახით და ანგარიში კონკრეტული გახდება.
სწორედ ამ უკან დაბრუნების გამო არის სიმპტომი არათანმიმდევრული აპლიკაციებს შორის. ბრაუზერი მალავს დაყოვნებას; ფიქსირებული ოჯახის ბრძანების ხაზის კლიენტი დაუყოვნებლივ გაჩვენებთ ნამდვილ წარუმატებლობას.
იპოვეთ ოჯახი, რომელიც მოთხოვნამ რეალურად გამოიყენა
დაიწყეთ სახელით და არა გვირაბით. ჰკითხეთ ორივე ტიპის ჩანაწერს და ჩაიწერეთ, რა დაბრუნდა:
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.comთუ v4 მოთხოვნა წარმატებულია და v6 მოთხოვნა ჩავარდა, პრობლემა გაამეორეთ გამართვად ფორმაში. თუ ორივე წარმატებულია გარსიდან და ბრაუზერი მაინც ჩავარდა, გვირაბზე ხელის დაჭერამდე შეხედეთ აპლიკაციის საკუთარ გადამწყვეტს ან ქეშირებულ პასუხს.
შეინახეთ ოჯახი და დანიშნულება თქვენს ჩანაწერებში. ბილეთი, რომელიც ამბობს, რომ საიტი VPN-ით არ იტვირთება, ვერავის შეუძლია შეამოწმოს, ხოლო ბილეთი, რომელიც ამბობს, რომ AAAA ჩავარდა და A მუშაობს, კონკრეტულ მარშრუტზე მიუთითებს.
შეამოწმეთ მარშრუტი ამ ოჯახისთვის
ჩავარდნილი ოჯახისთვის ჰკითხეთ ბირთვს, რომელ გზას გამოიყენებდა, და შეადარეთ იგი გვირაბის კონფიგურირებულ მისამართებს. Linux-ზე ip -6 route get დანიშნულებისთვის აჩვენებს ინტერფეისსა და წყაროს, რომლებიც შეირჩეოდა.
შემდეგ შეამოწმეთ თავად გვირაბი. WireGuard თანატოლები ატარებენ დაშვებული IP-ების სიას, და 0.0.0.0/0 ჩანაწერი არაფერს ამბობს IPv6-ზე. თუ თანატოლის სიაში IPv6 პრეფიქსი არ არის, კლიენტს AAAA ტრაფიკის გვირაბში გაგზავნის საფუძველი არ აქვს, და პაკეტი გადის იმ გზით, რასაც ჰოსტი სხვაგვარად გააკეთებდა.
ფაირვოლის წესები და NAT პოლიტიკა იმავე შემოწმებას იმსახურებს თითოეული ოჯახისთვის. IPv4-ისთვის დაწერილი წესი IPv6-ს არც ერთ პლატფორმაზე არ ფარავს, და ეს არის ერთი ოჯახის მუშაობისა და მეორის არმუშაობის ყველაზე გავრცელებული მიზეზი.
ნუ გამორთავთ IPv6-ს ეკრანის სურათის გასამარტივებლად
IPv6-ის სისტემის მასშტაბით გამორთვა სიმპტომს გააქრობს და დაგტოვებთ დიაგნოზის გარეშე. ის ასევე ამტვრევს ნებისმიერ დანიშნულებას, რომელიც მხოლოდ IPv6-ია, და მალავს იმავე შეცდომას შემდეგი აპლიკაციისთვის. თუ მანქანამ ნამდვილად არ უნდა გამოიყენოს IPv6, ეს განზრახ პოლიტიკაა მფლობელთან და ტესტთან ერთად. ინციდენტის დროს მისი გამორთვა არც ერთია.
გადაწყვიტეთ, რა უნდა გააკეთოს კლიენტმა ოჯახთან, და კონფიგურირეთ ეს ცხადად: გაატარეთ იგი გვირაბში, ან დაბლოკეთ მხარდაჭერილი გზით, რათა არჩევანი არასდროს შესთავაზოს მიუწვდომელი კანდიდატი. ორივე ლეგიტიმური დიზაინია. გლობალური გამორთვა არც ერთია, რადგან ის საერთოდ დიზაინი არ არის.
რა ჩავწეროთ ბილეთში
ჩაიწერეთ ოთხი რამ: ჰოსტის სახელი, ჩავარდნილი ოჯახი, ბირთვის მიერ არჩეული მარშრუტი და ოჯახისთვის სპეციფიკური მოთხოვნის შედეგი. ეს ნაკრები საკმარისია, რომ სხვამ გაამეოროს წარუმატებლობა იმის გამოცნობის გარეშე, თუ რომელი ორი გზა გქონდათ მხედველობაში.
RFC 6724 მისამართის არჩევის წესები ხსნის, თუ რატომ ანიჭებდა კლიენტი უპირატესობას იმ კანდიდატს, რომელსაც ანიჭებდა, და RFC 8305 ხსნის რბოლის ქცევას, რომელმაც დაყოვნება დამალა. არც ერთი მათგანი პაკეტს თქვენთვის არ დაამარშრუტებს, და სწორედ ეს ნაწილი უნდა გააკეთოს გვირაბმა.