Windows Arm-ზე: ნამდვილად ჩაიტვირთება VPN დრაივერი?

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

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

ნაწილი, რომელსაც ემულაცია არ ფარავს

Windows Arm-ზე შეუძლია x86 და x64 აპლიკაციების გაშვება ემულაციის საშუალებით, სანამ ისინი მომხმარებლის რეჟიმში რჩებიან. ბირთვის რეჟიმის კომპონენტები ამ მოპყრობას არ იღებენ: დრაივერი Arm64-ისთვის უნდა იყოს აწყობილი, რომ საერთოდ ჩაიტვირთოს. Microsoft ამ საზღვარს დოკუმენტირებს, და ის ზუსტად იქ არის, სადაც VPN კლიენტები ჩვეულებრივ იმყოფებიან, რადგან ბევრი მათგანი ვირტუალურ ქსელურ ადაპტერს ან ფილტრის დრაივერს აყენებს.

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

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

პირველი პაკეტია. x64 აწყობა და Arm64 აწყობა ორივე 64-ბიტიანი ეწოდება და ურთიერთშემცვლელი არ არის, ამიტომ მხოლოდ Windows 64-ბიტად აღწერილი ჩამოტვირთვა Arm მოწყობილობაზე არაფერს ამტკიცებს. იმ არქიტექტურისთვის მომწოდებლის მიერ მხარდაჭერილი ინსტალატორი ერთადერთი მისაღები საწყისი წერტილია.

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

მესამე კარიბჭე და მისი მხარდაჭერილი კლიენტების ნაკრებია. თუ დამტკიცებულ კლიენტს Arm აწყობა არ აქვს, სხვა კლიენტი მისაღებია მხოლოდ იქ, სადაც კარიბჭის მფლობელი მხარს უჭერს იმ კლიენტის პროტოკოლს, მის აუტენტიფიკაციის მეთოდს და მისი პოლიტიკის ქცევას. Windows-ის ჩაშენებული VPN პროფილი ვერ ჩაანაცვლებს საკუთრების კლიენტს მხოლოდ იმიტომ, რომ ორივე IPsec-ად აღიწერება.

წაიკითხეთ არქიტექტურა მოწყობილობაზე

დაადგინეთ, რა მანქანაა, შემდეგ ნახეთ, რომელი დრაივერები დააინსტალირა პაკეტმა სინამდვილეში. ჩამოთვლას ერთი წუთი სჭირდება და ხელს უშლის კამათს იმაზე, რას ნიშნავს "64-bit".

Get-CimInstance Win32_OperatingSystem | Select-Object OSArchitecture
$env:PROCESSOR_ARCHITECTURE
pnputil /enum-drivers | Select-String -Pattern 'vpn|tap|wintun' -Context 0,3
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverProvider

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

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

დაამტკიცეთ დატვირთვა, და არა შესვლის ეკრანი

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

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

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