Опишу свою домашнюю сетку как пример простейших локальных сетей с выходом в Интернет через обычный модем и использованием VMware-2.0.3. Структура сети: 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| +--+ В рабочем положении на 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 интерфейсами. Из сервисов взведены: 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 сервер (до него еще пакет доставить надо и вернуть отклик обратно). 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 не взаимодействует. Машина N3 имеет следующие настройки: Сетевая карта установлена в режиме host-ohly. IP 192.168.63.2 name smart1.home DNS 192.168.63.1 gateway 192.168.63.1 И такую таблицу маршрутизации: C:\WINDOWS>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 не взаимодействует. Напрямую в Интернет эта машина ходить не может, поскольку для ее подсети не указано маскарадное правило. Теперь можно ввести некоторые проверяющие изменения в систему с целью выявления закономерностей и лучшего понимания происходящего. Например. Если привести правила на 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 методом прямого указания пути к ресурсам, хотя и не видят друг друга явно. +--+ eth0 +---+ vmnet1 +--+ |N2|---------|N1 |---------|N3| +--+ +---+ +--+ | ppp0 dinamic IP | Internet Возможно именно такая схема окажется наиболее удобной для большинства пользователей. Так же использование host-only режима в совмещении с маскарадом или без оного (только прокси) существенно повышает защищенность гостевой операционки от внешних атак, поскольку с ней невозможно установить непрошенный контакт. Так же степень защищенности легко настраивается с помощью правил ipchains основной оси. В больших сетях работа с VMware через host-only с маскарадом средствами основной системы так же очень удобна тем, что все гостевые оси на всех машинах могут иметь совершенно идентичные IP адреса и настройки, да и сама vmware так же настраивается одинаково. Таким образом для администратора сети существенно упрощается настройка парка машин, поскольку гостевые оси можно размножать прямым копированием образа виртуального диска между машинами без какой либо последующей донастройки. Минусом подобного подхода являются трудности работы в окружении MSNetwork при попытке браузинга сети а так же при работе с public aplication, использующими Домен сети Microsoft. Это связано с широковещательным характером протокола сетей Microsoft, который несовместим с многосегментной сетью, получающейся в результате такого подхода. (автор статьи пытался побороть эти сложности используя PDC и WINS но после 2'х дней борьбы был вынужден сдаться) Если же есть желание пожертвовать защищенностью ради функциональности, то имеет смысл использовать bridget режим сетевого адаптера для 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 | +--+ +---|N3| | +--+ Итак, изменив тип адаптера с host-only на bridget (автору статьи это стоило снесенных гостевых виндов - умер реестр) мы получаем следующее - виртуальная тачка N3 настраивается точно так же как и N2 поскольку они находятся в одной подсети: IP 192.168.9.3 name smart1.home DNS 192.168.9.1 gateway 192.168.9.1 И такую таблицу маршрутизации: C:\WINDOWS>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.3 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.3 192.168.9.3 1 192.168.9.3 255.255.255.255 127.0.0.1 127.0.0.1 1 192.168.9.255 255.255.255.255 192.168.9.3 192.168.9.3 1 224.0.0.0 224.0.0.0 192.168.9.3 192.168.9.3 1 255.255.255.255 255.255.255.255 192.168.9.3 192.168.9.3 1 Соответственно внутри - с машинами N1 и N2 данная виртуальная ось ведет себя так же как и любая другая физическая тачка в том же сегменте сети, точно так же как и N2, в том числе и все операции в MSNetwork так же выполняются. В плане работы с Интернет получаем в точности ту же картину, что и для машины N2, а аменно. При наличии простого форварда пакетов на N1: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): Chain output (policy ACCEPT): N3 способна общаться только через прокси на N1 и ее же DNS. Причину этого легко понять через ping на любой из внешних хостов с одновременным просмотром вывода # tcpdump -i ppp0 -n Вы увидите, что пакеты уходят, но ответы не возвращаются, поскольку у внешнего хоста нет роутинга на N3, имеющего внутренний адрес. Соответственно при приведении правил N1 к стандартному для моего дома виду: 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): пакеты N3 подпадают под маскарадное правило и отрабатываются точно так же как и для N2. А значит, что с внешними хостами работает все, что только вообще может работать через маскарад, в том числе и ping. Данный режим работы гостевой оси можно смело рекомендовать тем администраторам больших сетей, у которых часть win32 приложений, вытесненных под VMware, используют домен MSNetwork или просто хочется что бы в виндах "все осталось как было раньше". При работе через bridget именно так и будет - все как раньше :-) Из минусов такого подхода можно отметить, что каждая виртуальная ось потребует собственный уникальный IP адрес во внутренней сети, то есть если все машины перевести на Linux и на всех поставить по одной Win под VMware то количество потребных адресов в локальной сети удвоится. Так же, вполне очевидно что при серийном размножении виртуальных осей потребуется ручная доработка в смысле изменения IP адреса и доменного подключения (последнее особенно долго). Все вышеописанные подходы безусловно применимы (и это проверено на практике) не только к гостевой Win95OSR2, но так же и к любым другим осям, которые можно установить на виртуальную машину. (из личного опыта автора Win98 NT4 W2k Linux)