რატომ ვერ მუშაობს თქვენი სტუმრის VPN VirtualBox NAT-ის მიღმა?

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

იპოვეთ VPN-ის პროცესი, სანამ ქსელს დაადანაშაულებთ

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

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

გარე გაცვლა წყვეტს თავსებადობას

VirtualBox-ის ქსელის სახელმძღვანელო ჩამოთვლის NAT-ის შეზღუდვებს, რომლებიც აქ მნიშვნელოვანია: ის არ გაატარებს TCP-ისა და UDP-ის გარდა სხვა პროტოკოლებს, GRE მითითებულია როგორც მხარდაუჭერელი, ხოლო PPTP მოცემულია როგორც დაზარალებული მაგალითი. PPTP იყენებს TCP კონტროლის გაცვლას და GRE-ს მონაცემებისთვის, ამიტომ კონტროლის კავშირი შეიძლება წარმატებული იყოს, მაშინ როცა მონაცემთა გზა ვერ გადაკვეთს იმავე საზღვარს. ეს ორი განსხვავებული მტკიცებულებაა და მხოლოდ ერთია ტრაფიკის ტარებაზე. TCP პორტ 47-ის დაშვება ქსელური ფარის წესში არ არის იგივე, რაც IP პროტოკოლ 47-ის დაშვება, და ეს ორი მუდმივად ერევა ერთმანეთს.

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

რას ცვლის სინამდვილეში ხიდი

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

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

ორი გვირაბი, ორი მტკიცებულების კვალი

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

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

რომელი პირობა გიშლით ხელს სინამდვილეში

ახლა გადაწყვეტილება სამ კითხვამდე ვიწროვდება სხვადასხვა პასუხით. თუ გარე პროტოკოლი TCP-ისა და UDP-ის გარეთაა, შეზღუდვა NAT-ის რეჟიმია და წინსვლის გზა ხიდი ან დამტკიცებული TCP/UDP ტრანსპორტია. თუ გარე გაცვლა სრულდება, მონაცემთა გზა კი არა, შეზღუდვა იგივეა, რაც მეორე მტკიცებულებაში ჩანს. თუ გვირაბი ადის, რესურსები კი არ პასუხობენ, პრობლემა უკვე გასცდა ჰიპერვიზორს მარშრუტიზაციასა თუ პოლიტიკაში.

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