как я могу получить доступ к веб-серверу, запущенному на моем гостевом компьютере VMware Fusion с NAT, из остальной подсети? [закрыто]
Мне не разрешено запускать мою гостевую VMWare в режиме моста, и я хочу каким-то образом туннелировать от согласованного порта на внешнем сетевом интерфейсе Mac к веб-серверу, работающему на гостевой системе VMWare fusion.
Я предполагаю, что я могу каким-то образом настроить туннель в ipfw, работающем на Mac, для поддержки этого.
Кто-нибудь может дать мне несколько указателей?
Правовая оговорка я не попробовал это, но это для рабочей станции, но я полагаю, что она должна работать
При выполнении виртуальной машины на компьютере можно хотеть получить доступ к той виртуальной машине от другого компьютера. Давайте использовать пример: Скажите, что у Вас есть виртуальная машина Ubuntu с работой Apache порта 80, и Вы хотите показать другим людям в Вашей сети для доступа к веб-сайту, который Вы размещаете.
Мы собираемся предположить, что виртуальная машина использует NAT и была присвоена IP-адрес 192.168.23.128.
Сначала откройте объект меню "Пуск" Manage Virtual Networks:
Нажмите на вкладку NAT и затем нажмите на Edit. Вы будете видеть диалоговое окно Настроек NAT:
Нажмите кнопку Port Forwarding, и Вы будете видеть это диалоговое окно: 
Теперь мы находимся наконец на экране, который мы можем на самом деле использовать. Мы собираемся использовать порт 8080 на хост-машине. Мы вводим IP-адрес для виртуальной машины человечности и порт 80. Эти порты могли быть любыми портами. 
Мы должны смочь проверить это путем движения в http://localhost:8080 на нашем ПК хоста. Мы можем выделить URL к нашей хост-машине путем замены localhost с IP-адресом главного компьютера.
Править:
При использовании NAT VM находится позади уровня хоста адрес NAT (172.x.y.z), о котором Маршрутизатор интернета ничего не знает. Вы могли передать порт 80 от маршрутизатора до IP Вашего хоста, затем настроить/Library/Application Поддержку/VMware Fusion/vmnet8/nat.conf к порту передачи порта 80 запросов к 172 адресам Вашего VM на порте 80. Это требует выключения Apache на OS X, если бы это работает, потому что это вызвало бы конфликт порта.
Ваша другая опция, должен изменить VM от NAT до соединенного мостом, в этом случае Ваш OS X и Ваш VM Ubuntu были бы на той же подсети с адресом DHCP, розданным Маршрутизатором интернета. Маршрутизатор передал бы трафик непосредственно к VM без любого дополнительного перенаправления портов.
-
1Спасибо - это точно, что я хочу сделать, но я не могу найти эти опции на VMware Fusion. А-ч – Martin 19 October 2010 в 12:15
-
2я попытаюсь изменить nat.conf, как Вы предполагаете и видите, как далеко это получает меня. Еще раз спасибо. – Martin 19 October 2010 в 13:20
Маршрутизаторы NAT будут переписывать исходный кортеж orig-ip: orig-port исходящих UDP-пакетов в nat-ip: nat-port и поддерживать таблица отношений между orig-ip: orig-port и nat-ip: nat-port , поэтому пакеты ответов UDP, прибывающие с nat-ip: nat-port поскольку пункт назначения может быть отображен обратно в пункт назначения orig-ip: orig-port . Для получения подробной информации о том, как реализация NAT может обрабатывать вещи, взгляните на , как отслеживание соединений реализовано в Linux .
Если ваша реализация не позволяет изменять номер порта клиента, это просто не будет гарантированно работает за NAT роутерами. Он может работать для одного клиента, поскольку многие реализации будут пытаться использовать тот же номер порта источника, что и исходный пакет, если он доступен, поэтому nat-port будет равен orig-port для первого клиентского соединения. Но по мере того, как этот порт становится недоступным, последующие попытки неизбежно приведут к состоянию, когда nat-port отличается от orig-port .
Таким образом, основным «ключом», который вам нужно будет различать между разными клиентами, будет исходный UDP-порт клиента. Ваше серверное чат-приложение должно генерировать UDP-пакеты, идущие на тот же порт назначения, из которого он получил клиентский пакет, инициирующий чат-соединение - создавая почти такую же ситуацию, как у вас с установленными сеансами TCP.
последующие попытки неизбежно привели бы к тому, что nat-port отличается от orig-port .Таким образом, основным «ключом», который вам нужно будет различать между разными клиентами, будет исходный UDP-порт клиента. Ваше серверное чат-приложение должно генерировать UDP-пакеты, идущие на тот же порт назначения, из которого он получил клиентский пакет, инициирующий чат-соединение - создавая почти такую же ситуацию, как у вас с установленными сеансами TCP.
последующие попытки неизбежно приведут к тому, что nat-port будет отличаться от orig-port .Таким образом, основным «ключом», который вам нужно будет различать между разными клиентами, будет исходный UDP-порт клиента. Вашему серверному чат-приложению необходимо генерировать UDP-пакеты, идущие на тот же порт назначения, из которого он получил клиентский пакет, инициирующий чат-соединение, создавая примерно такую же ситуацию, как у вас с установленными сеансами TCP.
весь трафик tcp на порт 8080 на вашем хост-компьютере OSX будет немедленно перенаправлен на порт назначения 80 виртуальной машины с IP 172.16.68.188 и сделает вашу виртуальную машину доступной в вашей локальной сети на 192.168.1.72:8080. вы уже используете веб-сервер в OSX, конфликты могут возникнуть на порту 80, поэтому используйте 8080 (как я показал здесь) или другой порт, чтобы избежать проблем.