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

გაიარეთ იგივე ხუთი ნაბიჯი, რომელსაც პაკეტები გადიან.

ნაბიჯი 1: დააკვირდით სახელის ძიებას

თუ პროფილი ჰოსტის სახელს იყენებს, პირველი კითხვაა, რას აბრუნებს რეზოლვერი. dig AAAA vpn.example.com მხოლოდ IPv6-ის ქსელში აბრუნებს ნამდვილ AAAA ჩანაწერს, DNS64-დან სინთეზირებულ ჩანაწერს, ან საერთოდ არაფერს. სინთეზირებული პასუხი IPv4 დანიშნულებას თარგმანის პრეფიქსში კოდირებს და მხოლოდ მაშინ შეუძლია IPv6 დანიშნულების გარეშე კლიენტს მასზე მიღწევა. მყარად ჩაწერილი IPv4 მისამართის მქონე პროფილი აქამდე არასდროს აღწევს, რადგან სინთეზირების სახელი არ არსებობს.

ეს ერთი განსხვავება ხსნის «იქ მუშაობს, აქ ვარდება» მოხსენებების უმეტესობას და მის სანახავად ერთი ბრძანება საკმარისია.

ნაბიჯი 2: ნახეთ, რომელ ოჯახს მიმართა კლიენტმა

დააკვირდით სოკეტს და არა პროგრესის ზოლს. კლიენტს, რომელიც მხოლოდ IPv6-ის ჩართულობაზე IPv4 მისამართისკენ IPv4 სოკეტს ხსნის, არსად აქვს მისი გაგზავნა, და ჩავარდნა ვლინდება როგორც დროის ამოწურვა და არა როგორც სახელის შეცდომა. ss -tanp კლიენტის მიერთებისას აჩვენებს დისტანციურ მისამართს და ოჯახს, რომელიც მან სცადა. შეადარეთ ის ip -6 route-ს, რომ დარწმუნდეთ ნაგულისხმევი ნამდვილი IPv6 შემდეგი ნახტომია.

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

ნაბიჯი 3: გამოყავით თარგმანი გვირაბს

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

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

ნაბიჯი 4: გამოსცადეთ იგივე პროფილი სხვა ქსელში

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

მოხსენება, რომ VPN გატეხილია, სამოქმედოდ არ გამოდგება. მოხსენება, რომ ის მხოლოდ IPv6-ის წვდომაზე ვარდება, ხარვეზის მოხსენებაა.

ნაბიჯი 5: გაასწორეთ გზა და არა უსაფრთხოების პარამეტრები

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

რეალური ვარიანტებია კლიენტი, რომელიც მხარს უჭერს ქსელური თარგმანის მოდელს, ან დანიშნულება ხელმისაწვდომი IPv6 მისამართით. მოითხოვეთ ერთ-ერთი მათგანი.

დაკავშირებული სტატიები