Kein Zugriff über SSH auf 4 Geräte in einem gerouteten Firmennetz mit 40 subnetzen

Ich habe 40 Geräte mit Raspberry Pi units in einem gerouteten Firmennetz mit 40 Subnetzen in Kamerun ausgerollt.
In 36 der 40 Subnetze funktioniert alles einwandfrei (Je ein RPi pro subnetz).

In 4 von den 40 subnetzen wird der Zugriff über SSH (port 22) verweigert: SSH access denied.
Da alle 40 SD Karten der RPi mit dem gleichen Image programmiert sind schließe ich einen Fehler von meiner Seite aus.

Ein ping auf die IP Adressen der 4 fraglichen Geräte wird beantwortet.
Wenn ich einen Ping-Sweep (Advanced IP scanner) mache sehe ich in den 4 betroffenen VLAN-DATA subnetzen nur eine IP Adresse, nämlich die meine. Es kann sich also nicht um einen Adressen Konflikt handeln.
Der Unterschied beim ping-sweep ist dass ich bei den Geräten die erreichbar sind den Apache2 http server sehe der auf allen units läuft, bei den anderen sehe ich in nicht.

Welche Fragen muss ich dem Netzwerk Administrator stellen damit er das Problem löst?
Ich bin fast sicher dass das Problem an den Routereinstellungen der vier Subnetze liegt da ich identische SD Images verwende bei denen nur die statische IP und das gateway angepasst wurden.

Das Problem ist dass die 4 betroffenen Geräte ausgerechnet 900km entfernt sind und ich nicht einfach dort hinfahren kann.

Herzlichen Dank im Voraus.

Gruß Chris

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 521244

Url: https://administrator.de/contentid/521244

Ausgedruckt am: 19.11.2024 um 08:11 Uhr

11 Kommentare

Neuester Kommentar

Wenn man wirklich sicher gehen kann das es keinen Fehler bei den SD Karten der RasPis gibt, dann liegt die Vermutung nahe das es in den VLAN Subnetzen keinen DHCP Server gibt, sprich Endgeräte also keine gültige IP Adresse bekommen.
Wir gehen mal davon aus das deine RasPis ihre IP per DHCP beziehen, richtig ?!
Was denkbar ist ist auch die Möglichkeit das die Layer 3 IP Adresse (Router oder L3 Switch) in diesen betroffenen VLANs fehlt. Das hat dann ebenso zur Folge das ein ggf. eingerichteter DHCP Server nicht funktioniert.
Ausnahme ist allerdings wenn der DHCP Server separat in diesen VLANs rennt.
Leider machst du dazu nur sehr rudimentäre bis keine Aussagen zur Adressierung von Endgeräten in den VLAN Segmenten so das man hier nur im freien Fall raten kann.

Möglich ist auch das der DHCP Server schlicht eine falsche Gateway Adresse in den betroffenen VLAN Segmenten vergibt.
All das führt dazu das die RasPis dann nicht erreichbar sind.

Troubleshooting ist eigentlich relativ einfach. Sage dem dortigen Admin er soll einen Test Laptop in den betreffenden Port dieser VLANs stecken und die Adressvergabe checken.
Je nachdem was für ein OS der Kollege drauf hat ist das das Kommando ipconfig -all (Winblows) oder ifconfig (Linux, MacOS usw.).
Bei den unixoiden OS muss er zusätzlich noch ip route list oder netstat -r -n angeben um das Default Gateway zu checken.
Die Ausgabe dieser Kommandos muss dann zu den diesen VLANs zugeordneten IP Netzen bzw. VLAN IP Adressen und dem Gateway passen.
Mit dem Test Laptop kann er dann die lokale Gateway IP pingen und testweise einen der laufenden RasPis in einem funktionierenden VLAN.
Wenn beides klappt kannst du dir sicher sein das die SD Karte in den betroffenen RasPi's einen an der Waffel hat bzw. die SSH Konfig auf den Geräten.
Pingbar sind die betroffenen Geräte auch nicht, richtig ?!!
Das würde dann die These der fehlerhaften IP Adressierung von oben bestätigen !

Danke.
Aber es handelt sich ausschließlich um statische IP Adressen in allen Subnetzen ohne DHCP.
Und diese Adressen sind pingbar und eindeutig (also kein Adressen Konflikt)

Gruß

OK, dann liegt der Fehler ganz klar am RasPi selber.
Vermutlich oder sehr wahrscheinlich ist dann der SSH Server nicht aktiv.
Das lässt sich aber relativ einfach fixen....
Der Admin dort vor Ort entfernt die SD Karte aus dem RasPi und steckt sie in einen SD Kartenleser und diesen dann in seinen Rechner. Das /boot Verzeichnis auf der Karte ist eine normale FAT32 Partition die in jedem OS einfach zu lesen ist.
Es reicht dann dort eine leere Datei nur mit dem Namen ssh zu erzeugen.
SD Karte zurückstecken in den RasPi, booten, et voila...schon sollte der SSH Server funktionieren.

Halte ich eher für unwahrscheinlich weil es das gleiche Image ist, das 40 mal kopiert wurde und nur die statische IP und der GW angepasst wurden.Ich glaube das muss am Cisco Router liegen der irgendeinen Port sperrt o.ä

Aber mit Cisco Konfiguration kenne ich mich leider nicht aus.

Ich glaube mich zu erinnern, ich habe schon ein SSH auf den Router Gateway gemacht
Der Cisco Router hat seine Anmelde Maske angezeigt. Die Authentifizierung kenne ich allerdings nicht.
D.h. das Subnetz ist nicht für SSH port 22 blockiert.
Ich werde das morgen nochmal überprüfen.

Ich vermute auch eine ACL im Cisco.

Um ganz sicher zu gehen kannst Du den Admin zwei Raspis gegenseitig vertauschen lassen, dann siehst Du ob der Fehler wandert. Die IPs müssten dafür noch angepasst werden.

Das Problem ist dass der Admin, wie ich, hier in Douala sitzt und nur remote Zugriff hat.
Das Personal in 900km Entfernung kann maximal die Units initialisieren durch ein/ausschalten der Stromversorgung.

Moin,

Und diese Adressen sind pingbar und eindeutig (also kein Adressen Konflikt)

Das kannst du doch von ausserhalb des Subnetzes gar nicht feststellen... Das würde sich maximal anhand der MAC sagen lassen (die nur im lokalen Subnetz sichtbar ist).

Also: Pi ausschalten lassen, dann pingen. Kommt eine Antwort => doppelte IP. kommt keine Antwort => ACL am CISCO prüfen.

Der Cisco Router hat seine Anmelde Maske angezeigt. ... D.h. das Subnetz ist nicht für SSH port 22 blockiert.

Das ist doch quatsch. Das ssh im Subnet A geht, bedeutet doch nicht, das es im Subnet B auch gehen muss!

lg,
Slainte

Da hat der TO wohl die Arbeitsweise von Cisco ACLs nicht ganz durchschaut....?
Wäre hilfreich die hier ggf. mal zu posten um ggf. Fehler dort zu entdecken.
Oder eben doch doppelte IP...?!

Das Problem ist gelöst.
Die Leute auf den vier Stationen haben die SD Karten (mit einer neuen SW Version) unter Spannung gewechselt und keinen reboot gemacht. Deshalb waren die units pingbar aber SSH war blockiert.

Danke an alle die Lösungsvorschläge beigetragen haben.