Чому гостьовий VPN не працює за NAT VirtualBox?

Браузер у віртуальній машині працює, а 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. Якщо зовнішній обмін завершується, а шлях даних ні, обмеження те саме, що видно в другому доказі. Якщо тунель піднімається, а ресурси не відповідають, проблема вже минула гіпервізор і перебуває в маршрутизації чи політиці.

Запишіть відповідь поруч із режимом адаптера, інакше наступна людина повторить той самий день. Після будь-якого виправлення перевірте реальний застосунок і розв'язання імен усередині гостя, потім перепідключіться й випробуйте політику відмови. Робоча вебсторінка через тунель доводить лише те, що вебшлях працює, а це менше твердження, ніж здається тієї миті.