Здравствуйте, daks.
Вы писали 3 марта 2005 г., 19:00:22:
> zubator пишет:
>> хай All!
>> Народ простите что сюда пишу, но может что нить сталкивался с проблемой
>> настройки сети между хостовой машиной и гостевой. Посмотрел в инете, но
>> как ничего нормального не нашел (было связанное с настройкой в оффтопе,
>> но как это сделать в линуксе я не понял), может что нить знает статью
>> или не лень написать маленькую заметку про настроку сети можду двумя ОС.
>> Просто охота потренироваться с iptables и все дела. В часности охота nat
>> настроить. Но как я смотрел в vmware есть устройство nat....Короче для
>> меня пока темный лес, если можете то помогите ниформацией.
>> Заранее благодарен.
Вот, может поможет:
Структура сети:
N1 - шлюзовая машина, Linux.
N2 - вторая машина, рабочая станция Win98.
N3 - виртуальная машина под VMware на N1, Win95OSR2.
далее этих виртуальных может быть очень много, столько сколько потянет N1 по
ресурсам. (удавалось запускать одновременно 4 оси - NT4, Win95, Linux, Linux
и на PIII550 128M все это работало с приемлимой производительностью)
Интерфейсы и сети.
192.168.9.2 192.168.9.1
+--+ eth0 +--+
|N2|--------------| |
+--+ |N1| ppp0 dinamic IP
vmnet1 | |--------Internet
+--------| |
| +--+
| 192.168.63.1
|
| 192.168.63.2
+--+
|N3|
+--+
В рабочем положении (при активном ppp соединении с провайдером) на N1 имеем следующие
настройки:
Интерфейсы:
eth0 inet addr:192.168.9.1 Bcast:192.168.9.255 Mask:255.255.255.0
lo inet addr:127.0.0.1 Mask:255.0.0.0
ppp0 inet addr:62.118.144.204 P-t-P:212.30.161.18 Mask:255.255.255.255
vmnet1 inet addr:192.168.63.1 Bcast:192.168.63.255 Mask:255.255.255.0
Таблицу маршрутизации:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
APAS18.mtu.ru * 255.255.255.255 UH 0 0 0 ppp0
192.168.63.0 * 255.255.255.0 U 0 0 0 vmnet1
192.168.9.0 * 255.255.255.0 U 0 0 0 eth0
127.0.0.0 * 255.0.0.0 U 0 0 0 lo
default APAS18.mtu.ru 0.0.0.0 UG 0 0 0 ppp0
/etc/resolv.conf
search home
nameserver 127.0.0.1
/etc/sysconfig/network
NETWORKING=yes
FORWARD_IPV4=yes
HOSTNAME=smart.home
DOMAINNAME=home
GATEWAY=192.168.9.1
И такую простейшую систему правил:
[root@smart cornet]# ipchains -L
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target prot opt source destination ports
MASQ all 192.168.9.0/24 anywhere n/a
Chain output (policy ACCEPT):
Можно было и сложнее, но для домашней сети смысла особого не вижу. .
В данном случае MASQ предназначен для хождения N2 по любым сервисам в Интернет.
С помощью vmware-config.pl была в неавтоматическом режиме сконфигурирована VMware
на работу с bridget и host-only интерфейсами.
Из сервисов на N1 подняты:
1. samba
практически в дефалте, но добавлено
[global]
interfaces = 127.0.0.1 eth0
bind interfaces only = Yes
что бы не светить в Интернет. При этом vmnet1 так же прослушивается Самбой, поскольку
привязан к eth0.
2. named
Так же - почти что кэширующий дефалт, но кроме этого держит домен home, ссылается
на провайдерский DNS и самое главное в named.conf:
listen-on { 127.0.0.1; 192.168.9.1; 192.168.63.1; };
Здесь адрес vmnet1(192.168.63.1) необходимо включить явно, иначе N3 до DNS не
дозвонится напрямую.
При этом сервис vmware должен стартовать раньше named, чего не происходит по
умолчанию.
Если всего этого не сделать, то для гостевых осей придется указывать в качестве
DNS не адрес vmnet1 а
адрес eth0 материнской оси, или какой то другой DNS сервер (до него еще пакет
доставить надо и вернуть отклик обратно).
По этому для чистоты эксперимента и для более полного описания возможностей
конфигурирования взаимодействий
VMware и материнской оси я сделал эти изменения в named.conf
3. squid
То же почти ничего не правил (надо будет баннерщиков порезать), добавил лишь
правила доступа:
acl home src 192.168.9.0/255.255.255.0
acl vmware src 192.168.63.0/255.255.255.0
http_access allow home
http_access allow vmware
Таким образом мы получили практически стандартную конфигурацию сервисов,
в которую внесены только те изменения, которые касаются предмета обсуждения
данной статьи.
Машина N2 имеет следующие настройки:
IP 192.168.9.2
name fiona.home
DNS 192.168.9.1
gateway 192.168.9.1
И такую таблицу маршрутизации:
C:\MUST_DIE>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric
0.0.0.0 0.0.0.0 192.168.9.1 192.168.9.2 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.9.0 255.255.255.0 192.168.9.2 192.168.9.2 1
192.168.9.2 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.9.255 255.255.255.255 192.168.9.2 192.168.9.2 1
224.0.0.0 224.0.0.0 192.168.9.2 192.168.9.2 1
255.255.255.255 255.255.255.255 192.168.9.2 192.168.9.2 1
В браузере для http указан прокси 192.168.9.1:3128
Машина свободно ходит в Интернет через прокси и маскарад (ping ходит), работает
с N1 по всем протоколам,
пингуется с N3 но по samba (а точнее MSNetwork) не взаимодействует.
Машина N3 имеет следующие настройки:
Сетевая карта виртуальной машины установлена в режиме host-ohly.
IP 192.168.63.2
name smart1.home
DNS 192.168.63.1
gateway 192.168.63.1
И такую таблицу маршрутизации:
C:\MUST_DIE>route print
Active Routes:
Network Address Netmask Gateway Address Interface Metric
0.0.0.0 0.0.0.0 192.168.63.1 192.168.63.2 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.63.0 255.255.255.0 192.168.63.2 192.168.63.2 1
192.168.63.2 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.63.255 255.255.255.255 192.168.63.2 192.168.63.2 1
224.0.0.0 224.0.0.0 192.168.63.2 192.168.63.2 1
255.255.255.255 255.255.255.255 192.168.63.2 192.168.63.2 1
В браузере для http указан прокси 192.168.63.1:3128
Машина свободно ходит в Интернет через прокси, работает с N1 по всем протоколам,
пингуется с N3 но по samba (а точнее MSNetwork) не взаимодействует.
Напрямую в Интернет эта машина ходить не может, поскольку для ее подсети не
указано маскарадное правило.
Теперь можно ввести некоторые проверяющие изменения в систему с целью выявления
закономерностей и лучшего понимания происходящего.
Например. Если привести правила на N1 к вот такому виду:
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):
то N2 потеряет пинг на Интернет, но между N2 и N3 пинги все равно ходят.
Это очевидно происходит по тому, что N1 через который проходят пакеты для обеих
машин является default gateway.
В больших сетях, в которых много хостов с VMware
такое положения явно не сохранится поскольку default gateway на всех один и
пингуемому
хосту не известен обратный роутинг до пингующего и он, получив пакет, ответит
на него не туда, куда следовало бы.
Для более полного взаимодействия N3 с окружающим миром достаточно разрешить маскарад
с его адреса на все остальные адреса. Т
о есть привести правила к такому виду:
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
target prot opt source destination ports
MASQ all 192.168.9.0/24 anywhere n/a
MASQ all 192.168.63.0/24 anywhere n/a
Chain output (policy ACCEPT):
Итак, сейчас мы имеем совершенно симметричную схему сети и N2 и N3 абсолютно
равноправны и работают по samba
(а точнее MSNetwork) методом прямого указания пути к ресурсам, хотя и не видят
друг друга явно в браузинге сети.
+--+ eth0 +---+ vmnet1 +--+
|N2|---------|N1 |---------|N3|
+--+ +---+ +--+
|
ppp0 dinamic IP
|
Internet
Возможно именно такая схема окажется наиболее удобной для большинства пользователей.
Так же использование host-only режима в совмещении с маскарадом или без оного
(только прокси) существенно повышает защищенность
гостевой операционки от внешних атак, поскольку с ней невозможно установить
непрошенный контакт. Так же степень защищенности легко
настраивается с помощью правил ipchains или iptables основной оси.
В больших сетях работа с VMware через host-only с маскарадом средствами основной
системы так же очень удобна тем, что все гостевые
оси на всех машинах могут иметь совершенно идентичные IP адреса и настройки,
да и сама VMware так же настраивается одинаково.
Таким образом для администратора сети существенно упрощается настройка парка
машин, поскольку гостевые оси можно размножать
прямым копированием файла виртуального диска между машинами без какой либо последующей
донастройки.
Минусом подобного подхода являются трудности работы в окружении MSNetwork при
попытке браузинга сети а так же при
работе с public aplication, использующими Домен сети Microsoft. Это связано с
широковещательным характером протокола сетей Microsoft,
который несовместим с многосегментной сетью, получающейся в результате такого
подхода. (автор статьи пытался побороть эти сложности используя PDC
и WINS но после 2'х дней борьбы был вынужден сдаться)
Если же есть желание пожертвовать защищенностью ради функциональности, то имеет
смысл использовать bridget
режим сетевого адаптера VMware для N3. В этом случае, интерфейс vmnet1 не используется
вовсе (его можно опустить),
а во внутренней сети появляется своего рода алиас на eth0 с новым адресом из
той же подсети (можно и с другим адресом
из другой подсети, но практическая ценность такого подхода не велика). Машина
N3 оказывается полноправным членом внутренней сети
и мы получаем следующую схему с точки зрения TCP/IP.
| 192.168.9.0/24
|
| 192.168.9.2
| +--+
+---|N2|
| +--+
|
| 192.68.9.2
|eth0+--+ ppp0 dinamic IP
+----|N1|--------Internet
| +--+
|
| 192.168.9.3
|
> Самый Лучший Ман (не потому шо самый полный, а потому шо на русском :-))
> http://gazette.linux.ru.net/rus/articles/iptables-tutorial.html
> А вообще-то это третья ссылка в Гугле :-( Пора учиться искать и не
> сдаваться.
> Успехов...
