Назад | Перейти на главную страницу

Невозможно подключиться к экземпляру через плавающие IP-адреса, неправильно настроен / перенаправлен

У меня возникают проблемы с правильной работой плавающих IP-адресов в моей настройке OpenStack. Похоже, что узел контроллера (под управлением nova-network) не пересылает трафик экземплярам.

У меня есть развертывание Folsom с FlatDHCP, а не с несколькими хостами, работающее на Ubuntu 12.04.

В качестве примера приведем работающий экземпляр с фиксированным IP-адресом 10.40.0.2 и плавающим IP-адресом 10.20.0.3:

$ nova list
+-------+---------+--------+------------------------------+
| ID    | Name    | Status | Networks                     |
+-------+---------+--------+------------------------------+
| 3d292 | quantal | ACTIVE | private=10.40.0.2, 10.20.0.3 |
+-------+---------+--------+------------------------------+

Если я вошел в контроллер, я могу выполнить ping и ssh для экземпляра виртуальной машины с любого из IP-адресов. Однако я не могу выполнить ping или ssh для экземпляра с внешнего компьютера.

Если я попытаюсь выполнить эхо-запрос с машины в другой сети (192.168.3.5), я вижу, что пакеты достигают контроллера на его общедоступном интерфейсе (eth3), но эти пакеты не перенаправляются на подключенный мост (br100) в частный интерфейс:

# tcpdump -i any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
20:33:12.908188 IP 192.168.3.5 > 10.20.0.3: ICMP echo request, id 58378, seq 0, length 64
20:33:13.910759 IP 192.168.3.5 > 10.20.0.3: ICMP echo request, id 58378, seq 1, length 64
20:33:14.910591 IP 192.168.3.5 > 10.20.0.3: ICMP echo request, id 58378, seq 2, length 64

Я настроил nova-network на использование драйвера брандмауэра "no-op", поэтому здесь не должно быть никаких проблем с группой безопасности:

firewall_driver=nova.virt.firewall.NoopFirewallDriver

Я подтвердил, что у меня включена переадресация IP:

$ cat /proc/sys/net/ipv4/ip_forward
1

Я не слишком знаком с iptables, но смотрю правила (см. https://gist.github.com/lorin/5209761), Я не вижу ничего явно неправильного.

Я предполагаю, что это правило действует при подключении контроллера к виртуальной машине:

-A nova-network-OUTPUT -d 10.20.0.3/32 -j DNAT --to-destination 10.40.0.2

И что он попадает в эти правила при движении вперед

-A nova-network-PREROUTING -d 10.20.0.3/32 -j DNAT --to-destination 10.40.0.2
-A nova-network-FORWARD -o br100 -j ACCEPT

На данный момент я не понимаю, почему он не выполняет NAT должным образом и не пересылает пакеты.

Интерфейсы:

eth0: (здесь не участвует)
eth1: подключается к внутренней сети только для виртуальных машин, br100 подключается к ней. Пакеты в конечном итоге должны выходить из этого интерфейса
eth2: (здесь не участвует)
eth3: общедоступный интерфейс. Он имеет IP-адрес контроллера (10.20.0.2), а также плавающий IP-адрес экземпляра (10.20.0.3).

Ниже приведен вывод «ip a» с скрытыми MAC-адресами.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 169.254.169.254/32 scope link lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 10.30.0.131/24 brd 10.30.0.255 scope global eth0
    inet6 ef23::2345:3aff:fe86:50c8/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br100 state UP qlen 1000
    link/ether 11:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff
    inet6 ef23::2345:3aff:fe86:50c9/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 77:88:99:00:11:22 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.131/24 brd 10.10.0.255 scope global eth2
    inet6 ef23::2345:3aff:fe68:b4b6/64 scope link
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 33:44:55:66:77:88 brd ff:ff:ff:ff:ff:ff
    inet 10.20.0.2/24 brd 10.20.0.255 scope global eth3
    inet 10.20.0.3/32 scope global eth3
    inet6 ef23::2345:3aff:fe68:b4b7/64 scope link
       valid_lft forever preferred_lft forever
6: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 54:78:1a:86:50:c9 brd ff:ff:ff:ff:ff:ff
    inet 10.40.0.1/16 brd 10.40.255.255 scope global br100
    inet6 ef23::2345:3aff:fed1:cd55/64 scope link
       valid_lft forever preferred_lft forever

Таблица маршрутизации:

~$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.0.1       0.0.0.0         UG    100    0        0 eth2
10.10.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth2
10.20.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth3
10.30.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.40.0.0       0.0.0.0         255.255.0.0     U     0      0        0 br100

Настройка моста:

# brctl show
bridge name bridge id       STP enabled interfaces
br100       8000.54781a8650c9   no      eth1

Вот несколько сетевых строк из /etc/nova/nova.conf

network_manager=nova.network.manager.FlatDHCPManager
flat_interface=eth1
flat_network_bridge=br100
public_interface=eth3
firewall_driver=nova.virt.firewall.NoopFirewallDriver

В разделе «Интерфейсы есть» вы говорите, что eth2 не задействован, но из выходных данных маршрута похоже, что шлюз настроен для eth2.

Я думаю, вы захотите настроить его на eth3. Я бы проверил, что / etc / network / interfaces настроен так, чтобы отразить это.