it-swarm.com.de

Kann Ping, aber kein SSH an Openstack VM-Instanz senden

MAAS-JUJU-Openstack-Setup mit mehreren Knoten, d. H. Nova-Cloud-Controller, Nova-Compute und Quanten-/Neutronen-Gateway, befinden sich auf separaten Hosts. In diesem Setup teilen sich MAAS und openstack 10.0.0.0/24 als Verwaltungsnetzwerk, während Quantum charm über eth0 mit dem öffentlichen Netzwerk 10.0.10.0 verbunden ist. Ich kann Instanzen erzeugen und ihnen Floating-IP-Adressen zuweisen. Ich kann auch von und zu einem öffentlichen Netzwerk pingen. Darüber hinaus können sich die beiden cirros-Instanzen, die sich im selben Subnetz befinden, gegenseitig sshen. Ich bin jedoch nicht in der Lage, über den Router-Namespace, d. H. ip netns exec qr-xxxx ssh -i <full path to key> [email protected], oder von außerhalb auf Instanzen zu sshen. Ich habe Schlüsselpaare sowohl über Dashboard als auch über Nova generiert, mit ähnlichen Ergebnissen. Auch versucht chmod 0600 key, ssh-add key ohne Erfolg. Eine Beispielausgabe wird hier gezeigt http://Pastebin.ubuntu.com/7676660/ , bei der möglicherweise eine Zeitüberschreitung auftritt. Wenn Sie eine Verbindung über VNC mit Cirros herstellen, wird unter "/ var/log" Folgendes angezeigt:

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

Ähnliche Protokolle werden beim Senden aus dem öffentlichen Netzwerk beobachtet. Im Falle eines öffentlichen Netzwerkzugriffs zeigt wireshark die wiederholte erneute Übertragung von ssh ACK von der Quelle an die öffentliche Adresse der VM an. ARP-Aufrufe fragen, wem die Quell- oder die IP-Adresse der VM gehört, und senden schließlich VM [FIN, ACK ] und beenden Sie die Verbindung.

Ich habe den Metadatenserver eingerichtet und bin der 2. Methode gefolgt, wie in Cloud-Instanzen in OpenStack können keinen öffentlichen SSH-Schlüssel importieren angegeben. Während des Startvorgangs wird Folgendes angezeigt: http : //Pastebin.ubuntu.com/7676789/ . (Nicht sicher, ob diese signifikant sind: Fehler beim Abrufen von http: // 169.254.169.254/2009-04-04/Benutzerdatenwarnung: Keine ec2-Metadaten für Benutzerdaten.) Um das Testen einzugrenzen, habe ich eine neue erstellt Sicherheitsgruppe, die alle TCP-Bereiche sowohl in Eingangs- als auch in Ausgangsrichtung zulässt. Mir scheint, dass dies kein Firewall- oder Richtlinienproblem ist, da die Verbindung zu Port 22 möglich ist. Ich frage mich, ob während des Startvorgangs falsche Metadaten generiert werden. Irgendwelche und alle Vorschläge werden geschätzt. Prost,

3
Nastooh

In unserer Umgebung mit mehreren Knoten bestand das Problem letztendlich in der Paketfragmentierung. Die Lösung für besteht darin, mtu auf 1700 in Bezug auf die Verwaltungsfunktionen von Rechenknoten und Neutronenknoten zu erhöhen, z. B. ifconfig ethxxx mtu 1700

1
Nastooh

In meiner Openstack-Instanz mit 3 Knoten (ML2 - OpenVSwitch - GRE-Tunnel) musste ich MTU auf 1400 setzen. Die Standard-MTU war 1500. Experimentieren Sie mit verschiedenen MTU-Größen.

1
user3507474

Problem: VM Knoten können nicht an physische Knoten gesendet werden, und physische Knoten können nicht an VM Knoten gesendet werden, aber Ping funktioniert zwischen allen. VMs auf Physical können erfolgreich miteinander sshen.

Lösung:
Ändern Sie den VM Node NIC MTU-Wert von 1500 in 1420.
Jetzt können sich die VM Knoten und die physischen Knoten gegenseitig sshen.

0
Gone Crazy

Ich hatte ein ähnliches Problem mit den Metadaten. Meine Lösung war, eine Datei mit dem Namen dnsmasq-neutron.conf mit dem Inhalt zu erstellen:

dhcp-option-force=26,1400

und zeige es in den /etc/neutron/dhcp_agent.ini mit

dnsmasq_config_file=/etc/neutron/dnsmasq-neutron.conf

Überprüfen Sie auch den auth_region = regionOne innerhalb des /etc/neutron/metadata_agent.ini, in meiner Konfiguration ist dies mit r und in der Metadaten-Standardkonfiguration mit R.