SoftEther-ის ვირტუალური ადაპტერი ჩნდება, მაგრამ ტრაფიკს არ აგზავნის

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

გამოყავით მოწყობილობა სესიისგან

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

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

შეუსაბამეთ ერთი ადაპტერი ერთ პროფილს

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

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

დაკავშირების შემდეგ წაიკითხეთ რეალური პარამეტრები

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

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

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

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

გაჩერდით ხიდამდე ან წაშლამდე

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

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

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