Может пропинговать, но не может SSH к экземпляру Openstack VM
Имейте многоузловую установку MAAS-JUJU-Openstack, то есть, nova-cloud-controller, nova-compute и квант / нейтронный шлюз находятся на отдельных хостах. В этой конфигурации MAAS и openstack совместно используют 10.0.0.0/24 в качестве своей сети управления, в то время как Quantum Charm подключен через eth0 к публичной сети 10.0.10.0. Я могу порождать экземпляры и назначать им плавающие IP-адреса. Я также могу пинговать и из общедоступной сети. Кроме того, 2 экземпляра Cirros, которые находятся в одной подсети, могут соединяться друг с другом. Однако я не могу подключиться к экземплярам через пространство имен маршрутизатора, т. Е. ip netns exec qr-xxxx ssh -i <full path to key> cirros@privateipaddr или извне. Я сгенерировал пары ключей как через панель инструментов, так и через nova, с похожими результатами. Также пытались chmod 0600 key, ssh-add key безрезультатно. Пример вывода показан здесь http://pastebin.ubuntu.com/7676660/ , который в конечном итоге истекает. Подключение через vnc к Cirros изображению показывает, в сообщениях / var / log, следующее:
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Child connection from GatewayPrivateIp:32818
Jun20 14:29:21 cir3 authpriv.info dropbear[364]: Exit before auth: Timeout before auth
Подобные журналы наблюдаются при ssh-подключении из общедоступной сети. В случае доступа к общедоступной сети wireshark показывает повторную повторную передачу ssh ACK от источника к общему адресу виртуальной машины, при этом ARP-вызовы запрашивают, кому принадлежит IP-адрес источника или виртуальной машины, и, наконец, VM отправляет [FIN, ACK] и закрывает соединение.
Я настроил сервер метаданных и следовал 2-му методу, как отмечено в . Облачные экземпляры в OpenStack не могут импортировать открытый ключ SSH , и во время загрузки я вижу следующее: http://pastebin.ubuntu.com/7676789/. (Не уверен, что они важны: не удалось получить http: // 169.254.169.254 / 2009-04-04 / предупреждение о пользовательских данных: нет метаданных ec2 для пользовательских данных) Чтобы изолировать тестирование, я создал новую группу безопасности это позволяет все диапазоны tcp в обоих направлениях входа и выхода. Сдается мне, что это не проблема брандмауэра или политики, так как возможно подключение к порту 22, мне интересно, генерируются ли неправильные метаданные во время загрузки. Любые и все предложения приветствуются. Ура,
4 ответа
В нашей среде мультиузла проблема закончила тем, что была фрагментацией пакетов. Работа вокруг для должна увеличить mtu до 1700 на зарубках управления и вычислить и нейтронные узлы, например, ifconfig ethxxx mtu 1700
У меня была подобная проблема с метаданными, мое решение было, создают файл, названный dnsmasq-neutron.conf с содержанием:
dhcp-option-force=26,1400
и точка это в /etc/neutron/dhcp_agent.ini использование
dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf
Также проверяет auth_region = regionOne внутренняя часть эти /etc/neutron/metadata_agent.ini в моей конфигурации, которая это с r, и в конфигурации значения по умолчанию метаданных это с R.
В моих 3 узлах экземпляр OpenStack (ML2 - OpenVSwitch - туннель GRE) я должен был установить MTU на 1400. MTU по умолчанию был 1500. Эксперимент с различными размерами MTU.
Проблема: узлы VM, не может ssh к физическим узлам, и физические узлы не могут ssh к узлам VM, но проверять с помощью ping-запросов работы между всеми. VMs на Физической банке ssh успешно друг другу.
Решение:
Измените узел VM NIC значение MTU от 1500 кому: 1420.
Теперь узлы VM и Физические узлы могут ssh друг друга.