Я установил многоузловую односетевую инфраструктуру OpenStack Folsom (2012.2). Все работает нормально, экземпляры работают нормально на любом вычислительном узле, частная сеть работает как шарм, и все экземпляры доступны через плавающие IP-адреса извне и могут достигать внешнего.
Но при попытке выполнить сетевой запрос от виртуальной машины к самой себе через плавающий IP-адрес происходит сбой.
Ни пинг, ни ssh не работают.
Все группы безопасности открыты.
Ping работает через плавающие IP-адреса от одной виртуальной машины к другой, но по SSH не.
Некоторые данные для одного примера
Записи iptables (относительно 10.1.100.4/10.0.0.13) на контроллере (все службы, включая сеть):
-A nova-network-2.7-OUTPUT -d 10.1.100.4/32 -j DNAT --to-destination 10.0.0.13
-A nova-network-2.7-PREROUTING -d 10.1.100.4/32 -j DNAT --to-destination 10.0.0.13
-A nova-network-2.7-float-snat -s 10.0.0.13/32 -o eth0 -j SNAT --to-source 10.1.100.4
Записи iptables на вычислительном узле:
относительно 10.1.100.4/10.0.0.13:
-A nova-compute-2.7-local -d 10.0.0.13/32 -j nova-compute-2.7-inst-143
относительно nova-compute-2.7-inst-143:
-N nova-compute-2.7-inst-143
-A nova-compute-2.7-inst-143 -m state --state INVALID -j DROP
-A nova-compute-2.7-inst-143 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-provider
-A nova-compute-2.7-inst-143 -s 10.0.0.1/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A nova-compute-2.7-inst-143 -s 10.0.0.0/24 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 22 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m tcp --dport 3389 -j ACCEPT
-A nova-compute-2.7-inst-143 -p tcp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p udp -m multiport --dports 1:65535 -j ACCEPT
-A nova-compute-2.7-inst-143 -p icmp -j ACCEPT
-A nova-compute-2.7-inst-143 -j nova-compute-2.7-sg-fallback
Приветствуются любые предложения по поиску проблемы. Разумеется, предоставлю все необходимые данные для решения проблемы. В настоящее время я не совсем уверен, какие данные помогут.
Хорошо, я нашел проблему:
Все пакеты для плавающих IP-адресов (10.1.100.0/24 в моем случае) DNAT привязаны к месту назначения частной сети (10.0.0.0/24 в моем случае). Пакеты ssh проходят через контроллер и возвращаются обратно в виртуальную машину. Сервер ssh отвечает, но отправляет пакет со своим частным адресом в качестве источника (конечно, другого у него нет). Таким образом, клиент ssh получает пакет от 10.0.0.13 в качестве ответа на запрос к 10.1.100.4, который он игнорирует.
Итак, при отправке пакетов с частных на плавающие IP-адреса не только место назначения должно быть преобразовано через NAT, но и источник. Но это непросто, потому что DNAT находится в PREROUTE, а SNAT - в POSTROUTE. Это можно сделать с помощью модуля отслеживания подключений:
iptables -t nat -A nova-network-2.7-float-snat -s 10.0.0.13/32 -d 10.0.0.0/24 -j SNAT --to-source 10.1.100.4 -m conntrack --ctstate DNAT
Это помогло мне (конечно, для каждого плавающего IP-адреса). Он изменяет каждый пакет от частного к частному, который уже был DNATed (затем он должен перейти на плавающий IP-адрес), чтобы казалось, что он исходит с плавающего IP-адреса.
В моем сценарии ssh теперь происходит следующее:
Это работает также для проверки связи, а также для трафика между различными виртуальными машинами.
Похоже, мне нужно исправить код nova-network и отправить его в проект openstack: - /.
Тило,
Это хорошо отражено в https://bugs.launchpad.net/nova/+bug/1096259, и патчи для nova (https://review.openstack.org/#/c/19139/) на сегодняшний день (7 января 2013 г.).
Полное исправление также связано с ошибкой 1096987 (https://bugs.launchpad.net/nova/+bug/1096987) и 1096985 (https://bugs.launchpad.net/nova/+bug/1096987), чтобы охватить более распространенные сценарии развертывания, когда вы используете либо предопределенный внешний шлюз, либо пользуетесь преимуществами настройки общедоступного сетевого моста nova-network linux / iptables.