Auf Reddit unter r/sysadmin habe ich diese Tage einen Beitrag entdeckt, in dem jemand frei übersetzt das folgende beklagt:

 

„Als genereller System Administrator muss man über eine Menge Dinge bescheid wissen. Unter anderem Windows, Linux, Mac, AD, Virtualisierung, Routing und Switching, Exchange, Vulnerability Management, Antivirus, Scripts, Datenbanken, und Hardware jeglicher Art. […] Obwohl man Generalist/Universalist ist, wird Expertenwissen erwartet.“

 

Hand aufs Herz, wer erkennt sich da wieder?

Gerade in KMUs ist es leider normal, dass ein zu kleines IT Team zu viele Aufgaben übernehmen muss, und um irgendwie über die Runden zu kommen, ist ein breit gestaffeltes Wissen sinnvoller als bei Randthemen in die Tiefe zu tauchen.

Im Bedarfsfalle kann man sich immer noch externes Wissen dazu holen, wie z.B. Herstellersupport, oder outsourced-DBA.

 

Ich möchte keine Diskussion darüber starten, ob diese Art und Weise die beste ist, aber wenn man dem folgt gibt es zwei Probleme – mindestens.
Zum einen stellt man sich selbst die Frage „Kann ich das noch, oder brauche ich dafür jemand anders?“ und zum anderen bekommt man die Frage gestellt „Warum konntest du das nicht selbst?“

Und selbst wenn man es selbst gelöst hat, sieht man sich vielleicht noch mit „Warum hat das so lange gedauert?“ konfrontiert.

Halt! Stopp! Keine Panik! Hier kommen wir ins Spiel.

 

Werkzeuge für SysAdmins

 

Troubleshooting kann nicht beginnen, bevor das Problem grob lokalisiert wurde. Wenn man auf die eingangs erwähnten Schichten schaut, kann das allein schon einen signifikanten Zeitaufwand darstellen.

Wie wäre es mit so etwas:

 

 

Für mich und manche Leser ist das ein vertrautes Werkzeug, andere sehen das sicher zum ersten Mal. Es gehört zu unserer Orion® Plattform und heißt AppStack.

 

Man sieht automatisch die Abhängigkeit zweier Anwendungen, das Betriebssystem, die Virtualisierungsschicht bis hinunter in den Bereich Storage, immer aktuell.

Ein simples mouse-over zeigt mir den Status der beteiligten Elemente an und in meinem Fall bringt mich die zweite rote Kugel schon ziemlich nahe zum Ziel:

 

 

Natürlich ist es nicht immer so einfach, aber ihr könnt euch vorstellen, wie viel Arbeit einem ein solches Werkzeug abnehmen kann, und wenn man quasi mit der Nase in die Richtung des eigentlichen Problems geschubst wird, hat man in vielen Fällen schon gewonnen.

Bei der Ansicht des Fensters sehe ich aber noch etwas anderes und möchte es mir im Detail ansehen. Die DB berichtet „irgendwas ist rot“:

 

 

Aber was genau bedeutet das? Hier bekommen wir mehr Informationen:

 

 

Ich kann mit meinen Werkzeugen noch tiefer gehen und tatsächlich das Query sehen, dass hier blockiert, auch von wo und von wem es ausgeführt wurde, sowie einige unterstützende Informationen.
Ich weiss aber jetzt schon, dass ich als Generalist entweder den Hersteller der jeweiligen Anwendung oder aber zumindest einen Entwickler brauchen werde.

Definitiv ein Fall der Kategorie Spezialwissen, aber ich kann es dokumentieren, und die mir durch Database Performance Analzyer (DPA)  zur Verfügung stehenden Informationen helfen dem Experten, das Problem schnell zu beseitigen.

 

Ein weiteres Feature der Orion Plattform, in diesem Fall geliefert durch Server & Application Monitor (SAM), ist das automatische Erkennen der Abhängigkeiten von Anwendungen und auch hier hilft ein Blick, um Zusammenhänge zu erkennen.

Auf einem meiner Webserver, dem Namen nach in der Cloud, können meine Benutzer nicht zuverlässig oder nur langsam Einloggen, um mit der Webanwendung zu arbeiten.

Wie man sieht, liegt die Ursache nicht am Webserver, sondern an der Verbindung zum Domain-Controller.

 

 

Ein Mausklick auf die Verbindung zeigt mir Details:

 

 

Ich muss kein Netzwerk-Spezialist sein, um sowohl den Webserver als auch den DC aus der Fehlerkette ausschließen zu können.

Für diejenigen die wissen möchten, wie dieses Feature funktioniert:

Der Orion Agent sitzt auf den Kisten und überprüft, welche internen Prozesse an welchen Ports lauschen, und von wo Daten herkommen bzw. hingehen.

Wenn die andere Maschine ebenfalls überwacht wird, geschieht dort das gleiche und Orion zeigt die Verbindung der Maschinen sowie der Anwendungen an.


Da beide Elemente wahrscheinlich kritisch für das Unternehmen sind, empfiehlt es sich die Verbindung als NetPath anzulegen, leider gibt meine Laborumgebung dieses Beispiel nicht her, also muss ich improvisieren.

Wer mit NetPath noch nicht vertraut ist: NetPath visualisiert die Verbindung von Anwendungen über verschiedene Standorte bis in die Cloud.

Um das Konzept zu verstehen, denkt kurz an Traceroute – aber dann stoppt. Traceroute nutzt entweder ICMP oder UDP was zwar nett, aber irrelevant für die meisten Anwendungen ist, die selbstverständlich über TCP kommunizieren.
Daher bietet NetPath eine TCP basierende „hop-by-hop“ Analyse.

 

Ich öffne einen hybriden Pfad, der meinem obigen Beispiel recht nahekommt:

 

 

Der Pfad selbst sieht so aus:

 

 

Im Produktivbetrieb ist der Pfad lebendig – man kann auf alles Klicken für weitere Informationen, eine Zeitachse benutzen, um Änderungen zu sehen, aber das Problem ist hier schon offensichtlich.
Links ist mein Netz, alles ist Grün, irgendwo in der Mitte lande ich bei meinem ISP und auch dort ist alles okay.
Rechts jedoch, beim Cloud-Anbieter, gibt es Paketverlust zu drei von vier Zielcontainern, die sich dort in der Rotation befinden.

 

Dies ist ein weiterer Fall von „jetzt muss der Hersteller ran“ und wir helfen sogar Kontaktdaten nach einem weiteren Mausklick:

 

 

Ein weitertes Beispiel gebe ich euch noch mit auf den Weg. Wieder muss ich etwas improvisieren.

Nehmen wir an, AppStack zeigt uns Probleme mit einem IIS an.

 

 

Und der darunterliegende Server ist nicht glücklich:

  

 

Schaut nach rechts oben und klickt auf „Perfstack“:

 

 

PerfStack ist ein Werkzeug, um beliebige Daten in Relation zu setzen. Man sieht gerade nur die CPU, die von der vorherigen Seite übernommen wurde.
Auf der rechten Seite ist ein Doppelwinkel:

 

 

Ein Klick öffnet den Knoten:

 

 

Und ein Klick darauf zeigt die Informationen an, die wir von dem Server sammeln:

 

 

Mittels Dragp&Drop kann man nun weitere Informationsschichten in die Grafiken ziehen.

 

 

Das Hinzufügen von Events und Konfigurationsänderungen zeigt mir auf der Zeitachse einen Zusammenhang mit dem Anstieg in der CPU Auslastung an:

 

 

Ich klicke auf die Spalte mit der Konfiguration:

 

 

Interessant. Ich brauche mehr Details:

 

 

Auch als nicht-IIS-Admin sehe ich, dass eine weitere Webseite hinzugefügt worden ist.
Tatsächlich sehe ich rechts oben sogar von wem.

 

Ich glaube, ich rufe Rose an, um den Sinn eines Change-Protokolls zu diskutieren.

 

 

Bis dahin, macht’s gut, und stresst euch nicht zu viel.

Hallo Zusammen,

 

Bei den letzten Updates der Netzwerk-Management Module unserer Orion® Plattform haben wir erweiterten Support für Palo Alto Firewalls implementiert, ein Feature, welches seit 2017 auf euren Wunschlisten stand.


Ich muss kurz ausholen: Das Feature selbst heißt „Network Insight für Palo Alto“, und es gibt bereits einige Network Insight sowie App-Insights innerhalb von Orion.
Wir nennen es „Insight,“ wenn wir bei komplexen Themen mehr Unterstützung bringen, als es mit gewöhnlichen Methoden möglich ist.

 

Mit den Insights haben wir es uns zur Aufgabe gemacht, komplizierte Technologien, die im Detail oft Spezialwissen erfordern, für den Allrounder (IT Generalist) zugänglich zu machen.

 

Im Bereich von Network Insight gibt es bereits Support für F5 Loadbalancer, Cisco Nexus sowie ASA.
Für den Support der ASAs haben wir von euch viel Lob erhalten, also lag der Schritt nahe, sich mit einer weiteren Firewall zu befassen.

Und wieder kamt ihr ins Spiel – kein Anbieter wurde von euch so oft vorgeschlagen wie PA.

 

 

Verwalten von Security Policies

 

Die Effektivität einer Firewall wird durch die Policies bzw. Regeln definiert. Idealerweise sichern die Regeln den Netzwerkverkehr ab ohne negativen Einfluss auf die Geschäftsprozesse.
Wenn es jedoch zu Flüchtigkeitsfehlern oder grober Fehlkonfiguration kommt, entstehen Probleme auf verschiedenen Ebenen. Für den Administrator reicht es an dieser Stelle nicht mehr aus, lediglich die Performance der Firewall zu beobachten.
Unglücklicherweise ist das Einpflegen von Regeln keine einmalige Aktion, sondern eine dynamische Angelegenheit.
Die Infrastruktur ändert sich ebenso wie Geschäftsprozesse und Anwendungen, und Regeln müssen ständig angepasst werden.

 

Network Configuration Manager (NCM) stellt die folgenden Features zur Verfügung:

  • Komplette Übersicht über alle Regeln
  • Details zu einzelnen Regeln sowie deren Änderungen
  • Die Benutzung von Regeln über mehrere PA Knoten
  • Das Vergleichen von Ausschnitten der Konfiguration
  • Interface Konfigurationen
  • Information zu Anwendungen, Adressen und Diensten innerhalb von Regeln

 

Nach dem ersten Einlesen der Konfiguration wird NCM automatisch die Regeln sowie die dazugehörigen Elemente anzeigen.
Die im Bild angezeigte Seite erlaubt das schnelle Auffinden von Regeln durch Such- und Filterfunktionen.

 

 

Ein Klick auf eine Regel zeigt Details der Konfiguration inklusive der Objekte und Objektgruppen, die von der Regel betroffen sind.

 

 

Manche Regeln werden über mehrere Firewalls hinweg eingesetzt. Wir zeigen dies automatisch an, um Situationen vorzubeugen, bei denen ein Administrator eine Änderung versehentlich auf allen Geräten gleichzeitig replizieren lässt.
Ebenso lässt sich sofort feststellen, ob eine neue Regel korrekt angewandt worden ist.

 

 

Was bei der Überwachung von jeglichen Konfigurationen wichtig ist, trifft um so mehr zu bei Firewalls; ein Audit über Veränderungen. Compliance erfordert ein Log, und wir zeigen direkt an wann und was verändert wurde.

 

 

 

VPN Tunnel Überwachung

 

Als wir mit der Planung des Network Insights begonnen hatten, haben wir in UX Diskussionen gefragt, wie ihr zur Zeit VPN Tunnel überwacht.
Die häufigste Antwort war „Ich pinge die Gegenstelle.“
Leider ist das nicht wirklich ausreichend. In vielen Konfigurationen hat das andere Ende des Tunnels keine direkte IP Adresse, oder es gibt verschiedene je nach Datenverkehr, also wird meist irgendwas am anderen Ende angepingt.

Das wiederum kann mit der Herausforderung kommen, dass die Gegenstelle aus Sicherheitsgründen nicht auf Ping antwortet.

Oder, noch schlimmer, wenn Pakete plötzlich nicht mehr zurück geliefert werden – das kann oft ein Problem mit der antwortenden Maschine anstatt dem Tunnel sein.
Das ist eine ganze Menge Arbeit, erfordert manuelles Nachforschen, ist nicht präzise und, vor allem, bringt nicht viel. Es zeigt lediglich den Status (up/down) an, aber keinerlei Grund, warum etwas gerade nicht aktiv ist.
Wenn der Tunnel down ist, wo muss sich ansetzen?
Wann hat es zuletzt funktioniert?
Wenn der Tunnel läuft, wieviel Datenverkehr wird gerade generiert?

 

Wenn man bedenkt, dass VPN Tunnel mit WAN Verbindungen gleichzusetzen sind – es werden Standorte verknüpft, oder aber Clouds – wird klar, dass die Tunnel als kritisch anzusehen sind, und Probleme so schnell wie möglich beseitigt werden müssen.

Nachdem Network Insight für Palo Alto aktiviert worden ist, wird Network Performance Monitor (NPM) automatisch die VPN Tunnel erkennen und anzeigen.

Das Site-to-site Element zeigt Details zu jedem Tunnel an:

 

 

Ein paar Dinge sollte man sich genauer anschauen.
Alle Tunnel zeigen Quell- und Ziel-IP. Wenn die Ziel IP bzw. das Gerät schon überwacht wird, vielleicht eine andere PA oder ASA, wird direkt auf den Knoten verlinkt, wie bei der 192.168.100.10 auf dem Screenshot.

Ebenso wird der Name des Tunnels angezeigt, sofern einer vorhanden ist.

Es werden unterschiedliche Informationen für Tunnel je nach Status angezeigt. Wenn ein Tunnel down ist, sieht man Zeit/Datum der Statusänderung. In den meisten Fällen sieht man auch, in welcher Phase der Tunnel gescheitert ist.

Das ist typischerweise die erste Information, die man für das Troubleshooting benötigt.

 

Bei aktiven Tunneln wird Zeit/Datum des Verbindungsaufbaus angezeigt und welche Verschlüsslung in Benutzung ist, inklusive des Hashs.

Die letzten zwei Spalten sind von besonderem Interesse – sie zeigen die Bandbreite an.
Bandbreite kann, durch die Verschlüsslung, ein Problem darstellen. Mit einem Tool zur Datenverkehrsanalyse kann die Bandbreite anhand der beiden kommunizierenden IP Adressen nach der Verschlüsslung identifiziert werden. Das ist ein bisschen Arbeit und zeigt nur die Gesamtanzahl übertragener Pakete bzw. Bytes an. Man hat keine Einsicht in die Anwendungen oder die tatsächlichen Endpunkte.

 

Wenn man sich Flows vor dem Verschlüsseln anschaut, sieht man zwar die direkten Endpunkte, aber das Filtern nach Anwendungen wird schwierig, und letzten Endes weiss man nicht, was genau es durch den Tunnel geschafft hat. Der Overhead durch die Einkapselung wird ignoriert.
Und das Ganze vor dem Hintergrund, dass VPN Tunnel über die WAN Verbindung laufen, was häufig ein sehr hoher Kostenfaktor ist.

 

Network Insight für Palo Alto zeigt die tatsächliche Bandbreite jedes einzelnen Tunnels an. Die Datensätze sind normalisiert und erlauben somit das Erstellen von Berichten für die Kapazität/Auslastung, sowie die Alarmierung für den Fall, dass sich etwas verabschiedet.
Aber wir wären nicht SolarWinds, wenn wir die Daten nicht auch im PerfStack Dashboard der Plattform bereit stellen würden:

 

 

 

GlobalProtect VPN Überwachung

 

Ich stelle eine Behauptung auf:
Wenn jemand ein Problem mit einer Endpunkt-VPN Verbindung hat, ist es meistens jemand aus der Führungsetage.

Würdet ihr zustimmen?

 

Das beim Troubleshooting von Endpunkt-VPNs ist, dass man meisten nicht wirklich viele Daten hat, bis man den Laptop tatsächlich in den Händen hält, und eine Antwort wie „Keine Ahnung was da los ist“ lässt Zweifel an der Kompetenz aufkommen.
Network Insight für Palo Alto überwacht GlobalProtect und erstellt einen Eintrag für jede einzelne Verbindung:

 

 

Dadurch kann man auf einige Probleme schließen. Wenn z.B. der gleiche User permanent Verbindungsprobleme hat, liegen lokale Probleme vor. Vielleicht einfach nur ein falsches Passwort.
Wenn jedoch keiner mehr Verbinden kann, liegt ein Problem mit der Firewall vor oder der Verbindung zum System für die Authentifizierung.

 

 

Datenverkehr nach Regel

 

Sogar Netflow Traffic Analyzer (NTA) trägt zum Network Insight bei. Wir haben Teile von NTA mit NCM integriert, und wenn beide Module vorhanden sind, kann man den Flow anhand einzelnen Policies einsehen.

Das beantwortet viele Fragen, wie z.B. „Wer oder was mag von einer Regeländerung beeinflusst werden?“ aber vereinfacht natürlich auch retrospektives Troubleshooting.

Es gibt verschiedene Wege, um die Daten anzusehen, hier starten wir auf der Detailseite des Knotens und klicken links auf Policies:

 

 

Dort wählen wir eine Regel von der Übersicht aus:

 

 

Und schließlich öffnen sich die Policy-Details:

 

 

Auf der linken Seite sieht man ein paar Daten zur Regel sowie die exakte Konfiguration.
Die Übersicht auf der rechten Seite ist nicht wie üblich nach Knoten oder Interface gefiltert, sondern tatsächlich nach der Policy, die den Datenfluss regelt.
Die angezeigten Endpunkte befinden sich in einer der konfigurierten Firewall-Zonen und die die Konversationen selbst definieren sich über die Application-IDs die in den Regeln gefunden werden.

Das sind wertvolle Informationen für jeden, der Regeln plant oder ändert, da hier grafisch aufbereitet wird, welchen Einfluss eine Änderung auf den Produktiv-Betrieb haben kann.

Für diese Ansicht werden sowohl NCM als auch NTA benötigt und NTA hat NPM als Voraussetzung.

 

 

Da kommt noch was – User Device Tracker

 

In den meisten Fällen benötigt User Device Tracker (UDT) lediglich SNMP Zugangsdaten, um Informationen über Ports und verbundene Endpunkte zu sammeln.

Bei manchen Geräten jedoch werden diese Informationen nicht oder nur limitiert über SNMP bereitgestellt, z.B. Cisco Nexus 5K, 7K und 9K, und Palo Alto! Hier wird die CLI benutzt.

Der CLI Zugriff kann entweder per Gerät oder im Bulk eingerichtet werden.

 

 

Nachdem die Auswahl der Geräte getroffen wurde, werden die Eigenschaften editiert:

 

 

Etwas weiter unten befinden sich die CLI Einstellungen:

 

Es ist wichtig, L3 Polling zu aktivieren:

 

 

Danach wird UDT die Endpunkte anzeigen, hier ein Bild von einem NX-7K:

 

Viel Spass mit dem neuen Network Insight!

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.