имеем хост с Debian lenny и VMWare workstation, гостевая система WinXP SP3

vmnet1 это для host-only

vmnet8 это NAT


устанавливаем тип сетевого адаптера гостевой системы на NAT, смотрим IP адрес:
благополучно пингуем внешний хост и ходим в инет, при этом на хосте нет никаких iptables


после /sbin/route add -net 172.16.16.0/24 gw ип-deb пингуем ... не пингуется
добавляем /sbin/iptables -t nat -A POSTROUTING -s 172.16.16.0 -j MASQUERADE - бессмысленно

ложим гостевую систему, на хосте устанавливаем /sbin/iptables -t nat -A POSTROUTING -s 172.16.76.0/24 -j MASQUERADE, меняем тип сетевого адаптера гостевой системы на host-only, после поднятия настраиваем протокол TCP/IP

и после /sbin/route add -net 172.16.76.0/24 gw ип-deb
пинг с внешнего xen0 хоста проходит, xenU WinXP SP3 благополучно соединяется с WinXP SP3 под VMWare.

это что, VMWare для NAT интерфейса не использует MASQUERADE ?

можно ли в VMWare прописать кто имеет право обращаться гостевым хостам внутрь NAT подсети, кроме как портмаппера ?

Осявы в курсе наверное, что NAT = MASQUERADE@IPTABLES.
Тогда какое отношение может VMWare иметь к нему, а? Ваши личные настройки NAT не имеют отношения к настройкам виртуальных интерфейсов, зачем вообще вам это правило в iptables?

когда я настроил в VMWare виртуальное сетевое устройство c атрибутами Network connection:NAT, то ожидал что:

либо появится новое правило в iptables

либо VMWare как то сделает MASQUERADE при обращении извне к этому устройсву

правило iptables не появилось

трафик виртуальная машина к внешним ресурсам лезет и обратно поток получает, но никто не может подсоединится извне к виртуальной машине. Значит VMWare NAT не совсем MASQUERADE, как это мы привыкли. Как этот MASQUERADE настраивается ?

andrey_anonymousslobodyan_ury, а зачем Вам вообще виртуальный NAT, если Вы хотите ходить на виртуалки извне?
Может, Bridge все-таки больше подходит?

так один адрес на инетную проксю дали

Relic Hunterslobodyan_uryникто не может подсоединится извне к виртуальной машинеNAT позволяет заходить на виртуалку только с хоста.

а то, что я смог соединить через smb 2 виртуальные машины после того, как хостах-хозяинах сделал iptables -t nat ... MASQUERADE, это не NAT ?

ALex_hhaавторЗначит VMWare NAT не совсем MASQUERADE, как это мы привыкли. Как этот MASQUERADE настраивается ?
читать основы tcp/ip

Вот какие советы я люблю - это читать основы :)
существует рекламный свет, просьба о ожидаемом чуде, описание реализации от чародея и реальность, данная в ощущениях. Слету вспоминается анекдот о 17" тенисе. Если б все 4 вещи соответствовали друг другу, никто б никаких лишних слов в форумах не писал.

ALex_hhaавторNAT позволяет заходить на виртуалку только с хоста
вообще то NAT позволяет "видеть" виртуалке локальную сеть.


ALex_hha
автортрафик виртуальная машина к внешним ресурсам лезет и обратно поток получает, но никто не может подсоединится извне к виртуальной машине.
Простая аналогия

Есть шлюз с внешним ip xxx.xxx.xxx.xxx за которым в локальной сети стоит сервер терминалов на Windows 2003. Ты из дома хочешь попасть на сервер терминалов. У себя на машине ты набираешь > mstsc /v:xxx.xxx.xxx.xxx. Как ты думаешь, соединение установится?



Внутрь подсети NAT я не залезу, пока у себя в роуте у себя не напишу, что в подсеть с NAT могу залезть через шлюз xxx.xxx.xxx.xxx, и там нет MASQUERADE, либо DNAT дл яконкретных портов. И шлюз xxx.xxx.xxx.xxx не перекинет пакет на NAT-машину, покаместь в его роуте не прописан, как пакет на NAT-машину попадет - через TAP/TUN интерфейс, или в другой шлюз.

ALex_hha
З.Ы.
подсказка, смотреть в сторону DNAT.


в меру своего понимания DNAT - должно быть хоть одно правило со словом DNAT. iptables VMWare не использует.
В DNAT VMWare выставляет отдельные порты. SQL*NET не работает, т.к. после обращения к листенеру динамически распределяются порты обмена между серверным и клиентскими процессами. Corba сервисы тоже нормально работать не могут. Вот с MASQUERADE это хозяйство работает.

andrey_anonymousslobodyan_uryВнутрь подсети NAT я не залезу, пока у себя в роуте у себя не напишу, что в подсеть с NAT могу залезть через шлюз xxx.xxx.xxx.xxx, и там нет MASQUERADE
Уфф...
Прошу пардону, но таки шо Вы понимаете под буквосочетанием MASQUERADE?
И для чего же все-таки Вам NAT?
Как от связан с инетной proxy?

Или, быть может, Вы просто раскажете:
1) Какие сервисы будут жить на виртуалке?
2) Клиенты каких сетей (локальная сеть хоста, крутящего VM? интранет (кроме локалки)? интернет?) должны иметь доступ к этим сервисам?
3) Каким боком тут все-таки вылезла "инетная прокся"?

andrey_anonymousslobodyan_uryВнутрь подсети NAT я не залезу, пока у себя в роуте у себя не напишу, что в подсеть с NAT могу залезть через шлюз xxx.xxx.xxx.xxx, и там нет MASQUERADE
Уфф...
Прошу пардону, но таки шо Вы понимаете под буквосочетанием MASQUERADE?
И для чего же все-таки Вам NAT?
Как от связан с инетной proxy?

Или, быть может, Вы просто раскажете:
1) Какие сервисы будут жить на виртуалке?
2) Клиенты каких сетей (локальная сеть хоста, крутящего VM? интранет (кроме локалки)? интернет?) должны иметь доступ к этим сервисам?
3) Каким боком тут все-таки вылезла "инетная прокся"?

по рабоче-крестьянскому:
1) для доступа в инет на прокси прописан только 1 адрес. Админами сети применяется жесткая политика распределения ip адресов, лишних IP нет. Плюс к тому же хотелось бы в инет ходить с виртуальных хостов, поднятых на хосте-хозяине
2) хотелось чтобы на гостевом хосте можно было б поднять виндовую шару, установить БД ORACLE, FTP сервер, и чтобы доступ к этим ресурсам был не обязательно с хоста-хозяина.

andrey_anonymousЕсли нет требования по доступу к виртуалкам из инета (что "по-честному" без админов все равно не решить), то:
Настраиваем сервисы: host-only adapter, выделяем на него сеть, в которой живет виртуалка.
Сеть из диапазона, не применяемого в конторе - например, если живете в 172.16.x.x, то выделить из 192.168 или 10.
- На хост-системе настраиваем роутинг host-only интерфейс<->real интерфейс
- тем, кто пожелает пользоваться сервисами виртуалки, прописывается статический маршрут к виртуальной подсети через хост-систему.


интересно, какой адрес-источника увидит в пакете инет-прокси при настраивании роутинга host-only интерфейс<->real интерфейс ? 172.16.x.x (из подсети гостевой хост-хозяин ), или 10.1.1.x хозяина ? и что инет-прокси сделает с пакетом, который разрешен только для IP 10.1.1.x хозяина? с таким раскладом инет для гостевого хоста недоступен

andrey_anonymous
Интернет с виртуалок: видится два варианта
1) через вторую проксю, поднятую на хост-системе, т.е. virt->proxy@host->;proxy@net.
2) поднять на хост-системе маскарад, подставляя IP хост-машины для соединений в сторону proxy.

с инета видить виртуалки не требуется. для решения вопроса был поднят маскарад. Исходный вопрос был в том, почему VMWare virtual network не поднимает/использует маскарад, когда указываешь тип виртуального интерфейса - NAT. Зачем надо дополнительно извращаться с настройкой маскарада, почему его VMWare сама не реализует