Ein Kunde meldete sich heute früh bei uns, das an einem seiner Standorte keinerlei Internetseiten mehr geöffnet werden könnten. Die Standortvernetzung an sich und das Arbeiten darüber (WTS, File, etc.) funktionierte hingegen.
An dem genannten Standort wird eine Securepoint UTM Black Dwarf G3 verwendet. Vom Monitoring hatten wir einerlei Alarm erhalten, auf den ersten Blick sah hier alles gut aus. Beim Versuch über das USC auf die UTM zuzugreifen zeigten sich zu den vom Kunden genannten Schwierigkeiten weitere Ausfallerscheinungen. Man kam gar nicht bis zur PIN-Abfrage für die Websession, hier lief endlos der Verbindungsaufbau. Via VPN konnten wir uns verbinden und kamen auf das Web-Interface. Es zeigte sich das kein Ping und keine DNS-Abfrage funktionierten, daher die UTM erst mal neu gestartet.
Ab hier nahm das Unglück seinen (weiteren) Verlauf. Laut USC war die UTM selbst nach längerem warten getrennt, via VPN kam ebenfalls keine Verbindung mehr zu Stande (Timeout). Interessanterweise wurden im RMM diverse Clients an diesem Standort als Online angezeigt. Daher nutzen wir ein dortiges Notebook als Jumphost, allerdings kamen wir weder auf die Konsole des Notebooks noch konnten wir uns mittels anderer Fernwartung verbinden, einzig eine Remote Shell funktionierte. Von hier aus ging es mittels ssh zur UTM weiter.
In der Zwischenzeit meldete das Monitoring das die Standortvernetzung nun ebenfalls down sei. Es wurde also nach dem Neustart schlimmer, statt besser. Hier kam die Befürchtung auf, die UTM könnte defekt sein. Daher mittels root über ssh die SSD geprüft, diese sah allerdings alles gut aus:
root@<UTM-Name>:14.0.9.2 (Final):~# smartctl -H /dev/sda smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.167-yocto-standard] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED
Das muss allerdings nicht unbedingt etwas bedeuten, denn. bekanntermaßen können die Black Dwarf UTMs der G3-Serie wegen eines Intel CPU-Bugs das Zeitliche segnen. Da aber das Gerät noch (irgendwie) lief, schien das nicht die Ursache zu sein.
Daher mal in das Routing geschaut. Hier fiel auf, das die neue IP-Adresse auf der WAN-Schnittstelle eine völlig andere war, als das was wir bei diesem regionalen Provider bislang gesehen haben. Zu dieser Geschichte gehört das der Kunde eine feste IP-Adresse für den Standort gebucht hat, die letzte Aussage vom Provider allerdings lautete, das dies noch etwas dauern würde und man sich postalisch melden würde.
Jedenfalls schauten wir mal, wem die neue IP “gehört” und wunderten uns, das diese einem anderen regionalen Anbieter, 30 KM entfernt, zuzuordnen war. Nebenbei bemerkt: Es geht hier zum zwei Stadtwerke, möglich das diese den gleichen Backbone-Anbieter oder so verwenden. Zum Testen hatten wir dann mal als root via ssh geschaut, was auf der WAN-Schnittstelle passiert:
tcpdump -i wan0
Parallel dazu versuchten wir uns erneut per VPN zur UTM zu verbinden und erwarteten, das wir diese Versuche sehen würde, dem war allerdings nicht so. Auch Ping-Tests aus dem LAN nach außen sah man nicht. Kurzum: Ping geht nicht, völlig andere öffentliche IP eines anderen Providers, kein funktioniertes Routing, alles andere geht in Folge auch nicht (richtig). Man ist zwar irgendwie online, aber eben nicht so ganz. Das nährte den Verdacht, das beim Provider etwas nicht stimmt.
Daher mit dem Kunden abgesprochen, das dieser mal beim Provider nachfragen sollte, ob Störungen bekannt seien und zusätzlich das Glasfaser-Modem mal neu gestartet werden soll. Der Vollständigkeit halber: Wir sind ein paar Stunden von diesem Standort entfernt, also mal schnell hinfahren und schauen ist da nicht.
Der Kunde Tat wie besprochen. Die erste Rückmeldung vom Provider war zunächst ernüchternd, da alles in Ordnung sei, aber man schaue noch mal nach. Etwas später meldete das Monitoring das der Standort wieder online ist, ebenso die Vernetzung, alle Clients wurden im RMM ebenfalls als Verfügbar angezeigt, salopp ausgedrückt gingen die Lichter an.
Wie sich herausstelle hatte der Provider am Vortag doch schon eine feste öffentlich IP auf den Anschluss gebucht, dann gemerkt das etwas nicht stimmt und wieder zurückgerudert. Ganz rund war das dann offenbar nicht. Nach der Reklamation wurde eine neue feste öffentliche IP vom Provider gebucht und seitdem läuft wieder alles.
Wie hat Dir der Artikel gefallen ?
(3 Stimmen, durchschnittlich 4,33 von 5 Sternen)
Loading...
Du möchtest den Blog unterstützen ?
Neben PayPal.ME gibt es noch weitere Möglichkeiten, lies hier wie du diesen Blog unterstützen kannst.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 15 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Schreibe einen Kommentar