რატომ იცვლება DNS64-ის პასუხები VPN-ის მიერთებისთანავე?

DNS64-ის პასუხები აღწერენ ქსელურ განლაგებას და არა სერვერის თვისებას. გადამწყვეტი IPv4 მისამართიდან IPv6 მისამართს ასინთეზებს, და შედეგი მხოლოდ იქ მუშაობს, სადაც ამ პრეფიქსის ბოლოში თარჯიმანი ზის. VPN შეიტანეთ გზაზე და ეს განლაგება შეიძლება შენარჩუნდეს, შეიცვალოს ან შეწყვიტოს ჭეშმარიტი ყოფნა სამი პირობის მიხედვით.

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

რაზე მიუთითებს სინამდვილეში ასინთეზებული AAAA ჩანაწერი

DNS64 გადამწყვეტი პასუხობს მხოლოდ IPv4-ის მქონე სახელის AAAA მოთხოვნას იმით, რომ IPv4 მისამართს ათავსებს პრეფიქსში, რომლის გამოყენებაზეც ის კონფიგურირებულია, და ამ სამუშაოსთვის ცნობილი პრეფიქსია 64:ff9b::/96, როგორც აღწერილია RFC 6147-ში. ჩანაწერი აპლიკაციისთვის ნებისმიერი სხვა AAAA ჩანაწერივით გამოიყურება, და ეს არის არსი: მხოლოდ IPv6-ის მქონე კლიენტს შეუძლია კავშირის ცდა იმის ცოდნის გარეშე, რომ დანიშნულებას IPv6 არასდროს ჰქონია. შემდეგ ეს კავშირი დამოკიდებულია NAT64 ფუნქციაზე, რომელიც სადღაც გზაზე ორ ოჯახს შორის თარგმნის. ამ თარჯიმნის გარეშე ასინთეზებული მისამართი დამაჯერებლად გამომყურებელი დანიშნულებაა, რომელიც არსად მიდის.

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

სამი პირობა წყვეტს, ჯერ კიდევ მუშაობს თუ არა

პირველი პირობაა, რომელმა გადამწყვეტმა შექმნა ჩანაწერი, რადგან კონფიგურირებული DNS64-ის გარეშე ის ამ სახელისთვის არაფერს აბრუნებს და აპლიკაცია სხვაგვარად ფარსდება. მეორეა, აქვს თუ არა თქვენს მოწყობილობას მარშრუტი ასინთეზებულ პრეფიქსამდე, რადგან პასუხი შეიძლება ძალაში იყოს, სანამ მასთან მიმავალი გზა აკლია. მესამეა, არის თუ არა იმ პრეფიქსის მფლობელი თარჯიმანი იმ გზაზე, რომელსაც გამოიყენებდით, რადგან გვირაბი, რომელიც 64:ff9b::/96-ს სხვაგან მიაქვს, სხვა ფუნქციას ან საერთოდ არაფერს აღწევს. სამივე შეიძლება ძალაში იყოს გვირაბამდე და ჩავარდეს მის შემდეგ, და ამიტომ სიმპტომი უეცარ დეგრადაციას ჰგავს.

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

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

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

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

შეამოწმეთ მოთხოვნა და გზა ცალ-ცალკე

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

dig AAAA ipv4only.example.com +short
dig AAAA ipv4only.example.com | grep -E '^;; SERVER'
ip -6 route get 64:ff9b::c000:0216
curl -6 -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 http://ipv4only.example.com/

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

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