VPN გამორთულია, მაგრამ მაინც ნელია: შეამოწმეთ ადაპტერის კავშირები

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

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

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

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

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

გააკეთეთ ზუსტი კომპონენტის ინვენტარიზაცია

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

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

Get-NetAdapterBinding -Name 'Ethernet' -AllBindings | Select-Object DisplayName,ComponentID,Enabled
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverVersion,Status
Get-NetAdapterStatistics -Name 'Ethernet'
pnputil /enum-drivers | Select-String -Pattern 'vpn|filter|ndis' -Context 0,2
driverquery /v | Select-String -Pattern 'vpn|filter'

ჩაწერეთ ადაპტერის სახელი, კომპონენტის ID, დრაივერის ვერსია და VPN კლიენტის ვერსია. ამ ოთხი მნიშვნელობის გარეშე შემდეგი შედარება ვარაუდია. მიამაგრეთ ისინი ბილეთს, რათა მოგვიანებით გაშვება ამ ერთს შეედაროს.

შეცვალეთ ერთი დამტკიცებული რამ და გაიმეორეთ

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

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

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

დარჩით მომწოდებლის მხარდაჭერილ გზაზე

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

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

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