У мене була точно така ж проблема, і я розглянув її до вирішення, тому я радий детально пояснити проблему та рішення.
Без залучення VPN
Важливо зрозуміти конфігурацію, яка потрібна для того, щоб відповідати вашим вимогам без залучення VPN. Крім того, ця інформація передбачає, що жоден програмний брандмауер не заважає ні хосту, ні гостю.
Без VPN це зазвичай вирішується шляхом створення двох мережевих адаптерів у конфігурації віртуальної машини.
Перший адаптер повинен бути встановлений у NAT
режимі, що дозволяє гостю отримувати доступ до мережевих ресурсів (включаючи Інтернет) через мережевий інтерфейс хоста.
Другий адаптер повинен бути встановлений на Host-only
, що дозволяє двосторонній зв'язок між ведучим та гостем.
Цей адаптер трохи складніший у налаштуванні, ніж перший, оскільки він потребує зміни параметрів глобальної мережі VirtualBox, щоб налаштувати адаптер лише для хоста (зверніть увагу: для цього потрібні права адміністратора).
У VirtualBox перейдіть до File -> Preferences -> Network
. Перейдіть на Host-only Networks
вкладку та натисніть маленьку +
піктограму, щоб додати новий адаптер. Вам буде запропоновано збільшити дозволи VirtualBox.
Заповнення Adapter
вкладки є обов'язковим; це має виглядати приблизно так (ігноруйте адаптер, позначений міткою #2
; використовується для чогось непов'язаного):
Значення на DHCP
вкладці сервера необов’язкові. Якщо ви маєте намір жорстко кодувати IP-адресу цього адаптера в межах мережевої конфігурації гостя, то ці значення зайві. Якщо, з іншого боку, ви маєте намір використовувати DHCP, значення можуть виглядати приблизно так:
Останній крок щодо налаштування VirtualBox - повернутися до мережевої конфігурації VM та додати другий адаптер, який посилається на тільки що створений адаптер:
Тепер у гостьовій операційній системі мережа повинна бути налаштована на використання цих двох мережевих інтерфейсів.
На Debian або Ubuntu GNU / Linux конфігурація настільки ж проста, як і модифікація, /etc/network/interfaces
щоб виглядати так:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp
# The secondary network interface
auto eth1
iface eth1 inet static
address 192.168.56.101
netmask 255.255.255.0
(пурист може /etc/network/interfaces.d
скоріше використовувати каталог, але це не виходить за рамки цього пояснення)
Перезапустіть мережеві послуги гостя або, простіше кажучи, перезавантажте всю гостьову машину, і все повинно «просто працювати».
На цьому етапі потрібно мати змогу зателефонувати на відвідувач VM 192.168.56.101
та отримати відповідь (за умови, що брандмауер програмного забезпечення не заважає).
Аналогічно, потрібно мати можливість пінг-хосту в 10.0.2.2
. Ця IP-адреса, здається, "жорстко закодована" в реалізацію NAT VirtualBox, або, принаймні, вказана через якусь неочевидну конфігураційну директиву, і інформації про її походження є мало. Але, на жаль, "це просто працює".
Враховуючи цю конфігурацію, всі три умови, викладені у вашому запитанні, виконані.
Введіть: VPN
Але, ось руб. Введення VPN викликає проблему зупинки показу (ну, залежно від конкретної VPN та її конфігурації).
Сучасні VPN здатні розділити тунель , який необхідний, щоб згадана конфігурація VirtualBox функціонувала відповідно до ваших трьох вимог. З (доброї) причини безпеки розбиття тунелів часто вимикається, і саме в цьому полягає проблема у вашому випадку (і в моєму).
Коли ви підключаєтесь до VPN, клієнт VPN (клієнт Cisco AnyConnect Secure Mobility Client, 3.1.02026, в моєму випадку) вивчає таблиці маршрутизації хост-комп'ютера, запам'ятовує їх, а потім перекладає їх зі значеннями, які зазвичай надходять із деяких центрально- кероване місцеположення (тобто навіть з правами місцевого адміністратора неможливо змінити налаштування).
Ви можете вивчити таблиці маршрутизації для себе, відкривши command.exe
(у Windows):
C:\>route print
Перед підключенням до VPN таблиця маршрутизації містить важливі записи, які дозволяють цій конфігурації VirtualBox правильно функціонувати. Підключення до VPN призводить до видалення цих записів, що перешкоджає спілкуванню між хостом та гостем.
(Є багато інших записів, які я тут опустив, оскільки вони не мають значення для першопричини такої поведінки.)
Перед підключенням до VPN:
192.168.56.0 255.255.255.0 On-link 192.168.56.1 266
192.168.56.1 255.255.255.255 On-link 192.168.56.1 266
192.168.56.255 255.255.255.255 On-link 192.168.56.1 266
224.0.0.0 240.0.0.0 On-link 192.168.56.1 266
255.255.255.255 255.255.255.255 On-link 192.168.56.1 266
Після підключення до VPN:
192.168.56.1 255.255.255.255 On-link 192.168.56.1 266
224.0.0.0 240.0.0.0 On-link 192.168.56.1 266
255.255.255.255 255.255.255.255 On-link 192.168.56.1 266
Клієнт VPN видаляє такі рядки:
192.168.56.0 255.255.255.0 On-link 192.168.56.1 266
192.168.56.255 255.255.255.255 On-link 192.168.56.1 266
Без цих останніх двох записів хост і гість не можуть спілкуватися, і саме це передбачається поведінка, коли розділене тунелювання вимкнено в конфігурації VPN.
Зазвичай ці дві команди відновлять ці маршрути:
C:\>route ADD 192.168.56.0 MASK 255.255.255.0 192.168.56.1 METRIC 266
C:\>route ADD 192.168.56.255 MASK 255.255.255.255 192.168.56.1 METRIC 266
Але клієнт VPN залишається пильним: він перехоплює спроби змінити таблицю маршрутизації. Мій клієнт, здається, дозволяє другий запис, але не перший. (І може періодично обробляти обидва періоди; я цього не перевіряв.)
Якщо ваша конкретна VPN та супутня конфігурація дозволяють включити розділене тунелювання, воно зазвичай включається так:
Після відключення від VPN, добре сприйняті VPN-клієнти відновлять таблиці маршрутів, які були в наявності до з'єднання. Мій VPN-клієнт, схоже, робить це надійно, що вигідно, оскільки це означає, що гостьовий VM не потрібно перезапускати, коли я підключаюся до VPN або відключаюсь від нього. У таких випадках вторинний адаптер VM скидається, але він автоматично отримує свою IP-адресу автоматично та прозоро, відновлюючи зв’язок між господарем та гостем практично негайно. А ще краще, що кріплення NFS між хостом та гостем (я використовую кріплення CIFS) залишаються з’єднаними через операції з'єднання / відключення VPN.
У тому випадку, коли ваш VPN дозволяє розділити тунелі, це може бути простою справою, щоб увімкнути його, і в цьому випадку я хотів би почути від вас, чи "все просто працює".