Туннелирование сетевого подключения к гостю VMWare без сети
Я пытаюсь установить TCP-соединение между клиентским компьютером и гостевой виртуальной машиной, работающей на сервере ESXi. Хитрость в том, что у гостевой виртуальной машины нет настроенной сети (намеренно). Однако сервер ESX находится в сети, поэтому теоретически можно было бы устранить разрыв с помощью программного обеспечения.
Конкретно, я бы хотел со временем создать прямое TCP-соединение из кода Python, запущенного на клиентском компьютере (я хочу создать RPyC-соединение). Однако все, что приводит к туннелированию портов в стиле ssh, будет достаточно прорывным.
Я предполагаю, что возможна некоторая комбинация VMWare Tools, pysphere и малоизвестных сетевых адаптеров. Но пока что мой поиск не дает никакого результата, и мои единственные идеи либо уродливы (что-то вроде туннелирования по файловым операциям), и / или очень подвержены ошибкам (в основном, если мне нужно построить стек TCP, я знаю, что писать много ошибок).
Это для настройки среды тестирования, а не производства; но я предпочитаю стабильность скорости. В настоящее время я не вижу особой необходимости в высокой пропускной способности.
Чтобы подвести итог настройки:
- Клиентский компьютер (Windows/Linux, что бы ни работал) с установленными инструментами vmware
- Сервер ESXi (сеть доступна с клиентского компьютера)
- Гость VMWare, который вообще не имеет сетевых карт, но доступен с помощью инструментов vmware (в моем случае это должна быть Windows, но для полноты картины приветствуется решение Linux)
Любые идеи и предложения по дальнейшему чтению будут отличными. Спасибо тебе интернет, ты самый лучший!
3 ответа
Это немного поздно, но виртуальный последовательный порт может быть вашим другом. Вы можете выбрать последовательный порт на внешнем конце через сеть или локально, в зависимости от ваших возможностей. Тогда у вас может быть материал для ppp или ваш собственный скрипт для взаимодействия. Вы также можете запустить какой-нибудь инструмент для создания отдельного сокета из последовательного канала на гостевой стороне, если вы хотите избежать использования интерфейса ppp, но все же должны туннелировать TCP-соединение для некоторых приложений. Это должно держать вас в безопасности при анализе вредоносного кода, если он не является скайнетом:-) Вы все равно должны делать это с разрешения системного администратора, поскольку вы можете нарушать правила вашей компании, обходя некоторые меры безопасности.
Непонятно, что означает "никаких сетевых карт на гостя". Если я могу предположить, что для гостя не назначены физические сетевые карты, это означает, что здесь. Это простое решение, поскольку для гостевой виртуальной машины может быть предоставлен программный сетевой адаптер vmWare, который будет служить точкой входа в гостевой netstack.
Но если софт NIC также недоступен, мне действительно интересно, как и что может служить точкой входа в гостевую сеть, будь то Linux/Windows. Насколько я понимаю, если это именно то, что вы имели в виду, то вам, возможно, придется внести изменения в гостевую ОС, чтобы использовать другую дверь для доступа к гостевому сетевому стеку и для отправки / утечки pkts из него. Но опять же, когда вы сделаете правильную реализацию этого бэкдора, он станет просто еще одной реализацией soft NIC, который vmware поддерживает по умолчанию. Так почему бы не использовать это?
Если виртуальная машина "намеренно" не настроила сеть, вы не можете подключиться к ней по сети.
Ваш вопрос воплощает противоречие в терминах.