VMware и iptables - PullRequest
Новая
       25

VMware и iptables

0 голосов
/ 09 ноября 2008

Есть ли проблема с использованием VMware в Windows для размещения виртуального Linux-бокса с iptables? У меня есть конфигурация, которая, кажется, работает на физическом оборудовании, но нестабильна под VMware.

Я использую VMware для запуска виртуальной машины linux 2.6.24 на хосте Windows 2003 Server. По сути, приложение linux является маршрутизатором NATting, который работает iptables. Правила в таблице nat включают: 

Chain foo_pre
 target     prot opt in  out  source      destination
 LOG        all  --  *   *    0.0.0.0/0   0.0.0.0/0     [options here]
 LOG        all  --  *   *    0.0.0.0/0   10.10.1.33    [options here]
 DNAT       all  --  *   *    0.0.0.0/0   10.10.1.33    tcp dpt:80 to:192.168.0.33:8080

Chain PREROUTING
 target     prot opt in  out  source      destination
 foo_pre    all  --  *   *    0.0.0.0/0   0.0.0.0/0

Я вижу входящие пакеты на 10.10.1.33:80, используя tcpdump, и первый LOG генерирует сообщения, но ни DNAT, ни второй LOG не показывают пакеты, зарегистрированные на их счетчиках пакетов вторая LOG не генерирует сообщений, а tcpdump не показывает пакеты с 192.168.0.33.

Адаптер eth0 находится в сети 10.10.0.0/16 со шлюзом по умолчанию 10.10.1.1; у него есть дополнительный адрес 10.10.1.33/32. /proc/sys/net/ipv4/config/eth0/forwarding установлено на 1.

Является ли VMware виновником или я что-то упустил? Спасибо!

Обновление: мы упростили среду тестирования. Нет никаких правил NAT, просто виртуальная машина Linux, работающая под хостом Win2k3 Server. Тестовые шаги:

  1. ВМ подключена к сетевой карте хоста. Виртуальная машина и хост находятся в одной подсети с тем же шлюзом по умолчанию, что и выше.

  2. ВМ взаимодействует с устройствами как в своей подсети, так и вне ее: ICMP, TCP, UDP. Связь является двунаправленной: не имеет значения, какое оборудование ее инициирует.

  3. Инженер включил и снова включил шлюз по умолчанию, пока ковырялся в системе.

  4. ВМ теперь связывается только с устройствами в своей подсети. Любая попытка установить связь через шлюз с тем же оборудованием , начиная с шага 2 , не позволяет помещать пакеты в провод. tcpdump на eth0 на ВМ показывает исходящие пакеты без ответа; WireShark на хосте показывает ничего на физическом NIC.

  5. Остановка и перезапуск виртуальной машины не меняет ее поведение. Остановка виртуальной машины и замена ее на другую виртуальную машину с соответствующим IP-адресом, и т. Д. не меняет поведение.

  6. Хост Win2k3 продолжает нормально взаимодействовать как в своей подсети, так и вне ее.

Из этого я могу только заключить, что «что-то происходит» между ВМ и хостом: в драйверах VMware или в сетевых стеках хоста. Я снова прочесываю паутину ... трудно представить, что мы первые это заметили.

Обновления по мере их поступления. Спасибо за ваши мысли и обсуждение.

Ответы [ 2 ]

1 голос
/ 11 ноября 2008

Ваша вторая строка журнала пытается сопоставить пакеты, отправленные на 10.10.1.33, но вы изменили адрес назначения на 192.168.0.33 в строке над ней.

Я не уверен, почему вы еще не видите исходящие пакеты в tcpdump. Я предполагаю, что вы запускаете tcpdump на самой виртуальной машине Linux. Виртуальная машина отправляет пакеты на тот же интерфейс, который получает, или есть второй виртуальный адаптер Ethernet? Каким машинам назначены различные IP-адреса (кроме 10.10.1.33).

По поводу обновления: Я полагаю, вы не используете DHCP (люди обычно не беспокоятся при использовании статических IP-адресов). Кроме того, похоже, что шлюз видит одну сетевую карту, используя два IP-адреса. Обычно это должно быть хорошо, но это всегда детали, которые получают вас.

Возможно ли, что шлюз назначит только один IP-адрес сетевой карте и игнорирует трафик от виртуальной машины?

0 голосов
/ 11 ноября 2008

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

...