# 7.9 Ping funktioniert, Anwendung nicht Ein Server antwortet auf einen Ping, die eigentliche Anwendung ist jedoch nicht erreichbar oder funktioniert nicht vollständig. Dieses Fehlerbild entsteht häufig, weil ein erfolgreicher Ping fälschlicherweise als Nachweis für die Funktionsfähigkeit des gesamten Dienstes interpretiert wird. Ping prüft jedoch nur einen begrenzten Teil der Kommunikationskette. --- **7.9.1 Typisches Fehlerbild** Mögliche Meldungen und Beobachtungen: - Der Server antwortet auf `ping`, aber die Webseite öffnet sich nicht. - Die IP-Adresse ist erreichbar, aber die Anwendung meldet einen Timeout. - Der TCP-Port ist erreichbar, aber die Anmeldung schlägt fehl. - Der Dienst funktioniert lokal auf dem Server, jedoch nicht von einem Client. - Die Anwendung funktioniert ohne VPN, aber nicht über den VPN-Tunnel. - Einige Benutzer können zugreifen, andere nicht. - IPv4 funktioniert, IPv6 jedoch nicht. - Der Reverse Proxy antwortet, erreicht aber das Backend nicht. - Die Anwendung zeigt `502 Bad Gateway` oder `503 Service Unavailable`. - Die Startseite funktioniert, ein bestimmter Geschäftsprozess jedoch nicht. - Ein Healthcheck ist erfolgreich, während Benutzerfunktionen fehlschlagen. Die Diagnose muss deshalb über ICMP hinausgehen und den tatsächlichen Anwendungsweg prüfen. --- **7.9.2 Diagnoseziel** Ziel ist es, eindeutig festzustellen: - welches Ziel die Anwendung tatsächlich verwendet; - welche IP-Adresse verwendet wird; - ob IPv4 oder IPv6 verwendet wird; - welches Transportprotokoll erforderlich ist; - welcher Port angesprochen wird; - ob der Zielport erreichbar ist; - ob auf dem Server ein passender Prozess lauscht; - ob der Dienst an der richtigen Adresse gebunden ist; - ob TLS und Zertifikatsprüfung funktionieren; - ob ein Proxy, Reverse Proxy oder Load Balancer beteiligt ist; - ob Authentifizierung und Autorisierung funktionieren; - ob alle Backendabhängigkeiten verfügbar sind; - an welcher Stelle die vollständige Kommunikationskette unterbrochen wird. Ein möglicher Fehlerbereich darf erst dann als Ursache gelten, wenn er durch ein reproduzierbares Prüfergebnis, ein Protokoll oder einen Paketmitschnitt bestätigt wurde. --- **7.9.3 Kommunikationskette der Anwendung** Eine typische Anwendungsverbindung kann mehrere voneinander unabhängige Prüfebenen enthalten: 1. Anwendungskonfiguration 2. Namensauflösung 3. Auswahl von IPv4 oder IPv6 4. lokales Routing 5. VPN oder Proxy 6. Clientfirewall 7. Netzwerkfirewall oder ACL 8. NAT oder Portweiterleitung 9. Load Balancer oder Reverse Proxy 10. TCP- oder UDP-Kommunikation 11. TLS-Handshake 12. Anwendungsprotokoll 13. Authentifizierung 14. Autorisierung 15. Backenddienste 16. vollständiger Benutzerablauf Ein Fehler auf einer späteren Ebene kann auftreten, obwohl alle vorherigen Ebenen funktionieren. Beispiele: - Ping funktioniert, aber TCP 443 wird blockiert. - TCP 443 funktioniert, aber der TLS-Handshake schlägt fehl. - TLS funktioniert, aber der HTTP-Pfad ist falsch. - HTTP funktioniert, aber die Anmeldung wird verweigert. - Die Anmeldung funktioniert, aber die Datenbank ist nicht erreichbar. - Der Healthcheck funktioniert, aber der eigentliche Geschäftsprozess schlägt fehl. --- **7.9.4 Was Ping tatsächlich prüft** Ping verwendet normalerweise ICMP-Echo-Anfragen und ICMP-Echo-Antworten. Ein erfolgreicher Ping bestätigt für den konkreten Testzeitpunkt grundsätzlich: - der verwendete Zielname konnte für diesen Aufruf aufgelöst werden, sofern ein Name angegeben wurde; - eine Zieladresse wurde ausgewählt; - der Client konnte ein ICMP-Echo-Paket absenden; - das Paket erreichte ein antwortendes System; - eine ICMP-Echo-Antwort erreichte den Client; - der ICMP-Hin- und Rückweg funktionierte für diese Paketgröße und diesen Zeitpunkt. Ping kann zusätzlich Hinweise liefern auf: - Antwortzeit; - Paketverlust; - wechselnde Antwortzeiten; - ausgewählte IPv4- oder IPv6-Adresse; - grobe Erreichbarkeit eines Systems. Das antwortende System muss jedoch nicht zwingend der erwartete Anwendungsserver sein. Bei virtuellen IP-Adressen, Load Balancern, Firewalls oder falsch aufgelösten Namen kann ein anderes System antworten. --- **7.9.5 Was Ping nicht beweist** Ein erfolgreicher Ping beweist nicht: - dass ein bestimmter TCP-Port geöffnet ist; - dass ein UDP-Dienst funktioniert; - dass der erwartete Prozess läuft; - dass der Dienst an der richtigen Adresse lauscht; - dass TLS funktioniert; - dass das Zertifikat gültig ist; - dass der richtige virtuelle Host ausgewählt wird; - dass ein Reverse Proxy das Backend erreicht; - dass ein Load Balancer ein gesundes Backend besitzt; - dass ein Proxy die Verbindung zulässt; - dass eine Anmeldung möglich ist; - dass der Benutzer ausreichend berechtigt ist; - dass Datenbank, API oder Verzeichnisdienst verfügbar sind; - dass größere Pakete oder Datenübertragungen funktionieren; - dass die eigentliche Anwendung dieselbe IP-Adresse wie Ping verwendet; - dass der vollständige Benutzerablauf funktioniert. Ebenso beweist ein fehlgeschlagener Ping nicht automatisch, dass der Server oder die Anwendung ausgefallen ist. ICMP kann absichtlich blockiert, begrenzt oder niedriger priorisiert werden, während der eigentliche Anwendungsdienst weiterhin erreichbar ist. --- **7.9.6 Fehlerumfang bestimmen** Vor technischen Änderungen muss der Umfang des Fehlers festgestellt werden. Zu prüfen sind: - Ist nur ein Benutzer betroffen? - Ist nur ein Client betroffen? - Ist nur ein Betriebssystem betroffen? - Ist nur ein Standort oder VLAN betroffen? - Tritt der Fehler nur über VPN auf? - Tritt der Fehler nur bei WLAN oder nur bei LAN auf? - Sind alle Benutzer betroffen? - Funktioniert die Anwendung intern, aber nicht extern? - Funktioniert sie über IPv4, aber nicht über IPv6? - Betrifft der Fehler nur einen bestimmten Funktionsbereich? - Tritt der Fehler dauerhaft oder nur zeitweise auf? - Seit welchem Zeitpunkt besteht der Fehler? - Welche Änderung erfolgte unmittelbar davor? Geeignete Vergleichstests: | Vergleich | Mögliche Eingrenzung | |---|---| | gleicher Benutzer an anderem Client | clientbezogener Fehler | | anderer Benutzer am gleichen Client | benutzerbezogener Fehler | | gleicher Client in anderem Netz | Netzwerkpfad oder standortbezogene Regel | | Zugriff mit und ohne VPN | VPN-Route, DNS, Proxy, Firewall oder MTU | | IPv4 und IPv6 getrennt | adressfamilienbezogener Fehler | | direkter Anwendungstest und Zugriff über Proxy | Proxy- oder Reverse-Proxy-Fehler | | lokaler Test auf dem Server und entfernter Test | Dienstfehler oder externer Netzwerkpfad | | einfacher Endpunkt und vollständiger Benutzerablauf | Backend- oder Anwendungsfehler | Kreuztests dürfen nur kontrolliert durchgeführt werden. Produktive Zugangsdaten oder vertrauliche Daten dürfen nicht ungeschützt in Diagnoseausgaben übernommen werden. --- **7.9.7 Ausgangszustand sichern** Vor einem Neustart oder einer Konfigurationsänderung sollten mindestens folgende Informationen gesichert werden: - genaue Fehlermeldung; - Screenshot oder vollständiger Fehlertext; - Zeitpunkt einschließlich Zeitzone; - betroffener Benutzer; - betroffener Client; - verwendetes Netzwerk; - verwendeter Servername; - verwendete Zieladresse; - Port und Protokoll; - URL oder Ressourcenpfad; - Proxy- und VPN-Zustand; - relevante Clientprotokolle; - relevante Serverprotokolle; - Reverse-Proxy- oder Load-Balancer-Protokolle; - Dienststatus; - Listener und Bindungsadresse; - letzte Änderungen; - Vergleich mit einem funktionierenden Client. Ein vorschneller Neustart kann flüchtige Hinweise beseitigen, beispielsweise: - bestehende Verbindungen; - Fehlerzustände; - temporäre Protokolle; - Speicherauslastung; - Portbelegung; - Prozesszustand; - Warteschlangen; - reproduzierbare Zeitüberschreitungen. Änderungen dürfen erst nach Sicherung des Ausgangszustands erfolgen. --- **7.9.8 Tatsächliches Ziel der Anwendung bestimmen** Vor jedem Port- oder Protokolltest muss geklärt werden, welches Ziel die Anwendung wirklich anspricht. Zu erfassen sind: ```text Anwendung: Benutzerfunktion: Servername: Vollständiger DNS-Name: Verwendete IP-Adresse: IPv4 oder IPv6: Transportprotokoll: Port: Anwendungsprotokoll: URL oder Ressourcenpfad: Proxy: VPN: Load Balancer oder Reverse Proxy: Fehlerzeitpunkt: ``` Die Anwendungskonfiguration kann vom vermuteten Standard abweichen. Mögliche Einflussquellen: - explizit eingetragener Servername; - vollständige URL; - abweichender Port; - Hosts-Datei; - DNS-Suffix; - Suchdomäne; - Service-Discovery; - Umgebungsvariable; - Proxykonfiguration; - PAC-Datei; - Reverse Proxy; - Load Balancer; - lokale Anwendungskonfiguration; - gespeicherte Sitzung oder zwischengespeicherte Adresse; - IPv4- oder IPv6-Verwendung; - mandanten-, standort- oder benutzerabhängige Konfiguration; - Umleitungen innerhalb der Anwendung. Besonders wichtig: - Ein Ping auf den Servernamen kann eine andere Adresse verwenden als die Anwendung. - Ein Proxy kann die eigentliche Verbindung stellvertretend aufbauen. - Ein Load Balancer kann mehrere Backendserver verwenden. - Ein Browser kann einen anderen Resolver oder einen eigenen Proxyweg verwenden. - Eine Anwendung kann eine alte Adresse zwischengespeichert haben. - Ein direkter Aufruf per IP-Adresse verändert bei HTTPS möglicherweise SNI, Hostname und Zertifikatsprüfung. Die im Fehlerzeitpunkt verwendete Zieladresse sollte aus der Anwendung, einem Verbindungsprotokoll oder einem Paketmitschnitt bestätigt werden. --- **7.9.9 Namensauflösung prüfen** Windows: ```powershell Resolve-DnsName -Name -Type A Resolve-DnsName -Name -Type AAAA ``` Linux: ```bash getent ahosts dig A dig AAAA ``` macOS: ```bash dscacheutil -q host -a name dig A dig AAAA ``` Zu vergleichen sind: - die von der Anwendung verwendete Adresse; - die von `ping` angezeigte Adresse; - die von `curl -v` verwendete Adresse; - A- und AAAA-Antworten; - die Antworten verschiedener DNS-Server; - interne und öffentliche DNS-Antworten; - das Verhalten mit und ohne VPN. Ein erfolgreicher Ping auf einen Namen beweist nur, dass für diesen Ping-Aufruf eine Namensauflösung möglich war. Die Antwort kann aus DNS, einer Hosts-Datei oder einem anderen lokalen Namensauflösungsverfahren stammen. DNS-Caches sollten nicht als erste Maßnahme gelöscht werden. Zuerst muss dokumentiert werden, welche Adresse aktuell verwendet wird und warum sie falsch sein könnte. --- **7.9.10 TCP-Port gezielt prüfen** Windows: ```powershell Test-NetConnection ` -ComputerName ` -Port ` -InformationLevel Detailed ``` Wichtige Felder: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` Linux und macOS: ```bash nc -vz ``` Ein erfolgreicher TCP-Test beweist: - der verwendete Name wurde aufgelöst; - der Client konnte die verwendete Adresse erreichen; - der TCP-Verbindungsaufbau zum angegebenen Port wurde abgeschlossen. Er beweist nicht: - dass auf dem Port der erwartete Dienst läuft; - dass TLS funktioniert; - dass die Anwendung eine gültige Antwort liefert; - dass eine Anmeldung möglich ist; - dass der vollständige Geschäftsprozess funktioniert. --- **7.9.11 TCP-Fehler richtig interpretieren** | Ergebnis | Bedeutung | Nächster Nachweis | |---|---|---| | `TcpTestSucceeded : True` | TCP-Verbindungsaufbau war möglich | Anwendungsprotokoll und TLS prüfen | | `Connection refused` | Ziel oder zwischengeschaltetes System hat die Verbindung aktiv abgelehnt | Listener, Port und Serverprotokoll prüfen | | Verbindungs-Timeout | Keine rechtzeitige TCP-Antwort | Firewall, Rückweg, Routing, Überlastung oder falsche Adresse untersuchen | | Name nicht gefunden | Zielname konnte nicht aufgelöst werden | Namensauflösung prüfen | | Verbindung wird sofort getrennt | Dienst lehnt Sitzung ab oder falsches Protokoll wird verwendet | Dienst- und Anwendungsprotokoll prüfen | | Verbindung beginnt, bleibt dann hängen | Anwendung, TLS, Backend, Paketverlust oder Pfad-MTU möglich | Protokolle und Paketverlauf untersuchen | Ein Timeout beweist nicht automatisch eine Firewallblockierung. Auch ein falscher Rückweg, ein überlasteter Dienst, ein fehlerhafter Load Balancer oder eine falsche IP-Adresse können zu einem Timeout führen. --- **7.9.12 Anwendungsprotokoll statt nur Port prüfen** Der Test muss zum tatsächlichen Dienst passen. | Dienst | Geeigneter Funktionstest | |---|---| | HTTP oder HTTPS | `curl -v` mit vollständiger URL | | SSH | `ssh -vvv @` | | DNS | `Resolve-DnsName` oder `dig` gegen den vorgesehenen DNS-Server | | SMB | Zugriff auf die konkrete Freigabe testen | | RDP | kontrollierter Verbindungsversuch mit dem RDP-Client | | Datenbank | nativen Datenbankclient mit einer sicheren Leseabfrage verwenden | | API | vorgesehenen Endpunkt, Methode, Header und Authentifizierung prüfen | | herstellerspezifischer Dienst | Diagnoseclient oder dokumentierten Protokolltest des Herstellers verwenden | Ein erfolgreicher Test auf TCP 3389 beweist beispielsweise nur, dass der Port erreichbar ist. Er beweist noch keine funktionierende RDP-Anmeldung oder Sitzung. `curl` ist für HTTP-, HTTPS- und weitere von curl unterstützte Protokolle geeignet. Ein beliebiger TCP-Dienst darf nicht automatisch mit einer HTTP-Anfrage getestet werden. --- **7.9.13 HTTP und HTTPS prüfen** ```bash curl -v --connect-timeout 5 \ "https://:/" ``` Die Ausgabe wird schrittweise ausgewertet: 1. Welche IP-Adresse wird verwendet? 2. Wird eine TCP-Verbindung aufgebaut? 3. Beginnt der TLS-Handshake? 4. Welches Zertifikat wird präsentiert? 5. Wird die Zertifikatsprüfung erfolgreich abgeschlossen? 6. Welche HTTP-Anfrage wird gesendet? 7. Welcher HTTP-Statuscode wird empfangen? 8. Erfolgt eine Umleitung? 9. Antwortet ein Reverse Proxy oder der erwartete Anwendungsserver? 10. Wird eine Anwendungsfehlermeldung zurückgegeben? Wichtige HTTP-Ergebnisse: | Status | Einordnung | |---|---| | `2xx` | Anfrage wurde auf HTTP-Ebene erfolgreich verarbeitet | | `3xx` | Umleitung; Ziel im `Location`-Header prüfen | | `401` | Anwendung erreicht, Authentifizierung erforderlich oder fehlgeschlagen | | `403` | Anwendung erreicht, Zugriff wird verweigert | | `404` | Dienst antwortet, angeforderter Pfad oder virtuelle Zuordnung fehlt | | `407` | Proxy verlangt eine Authentifizierung | | `5xx` | Server, Gateway oder Backend meldet einen Fehler | Auch eine gültige HTTP-Fehlerantwort beweist, dass bereits mehrere Prüfebenen erfolgreich durchlaufen wurden. Sie beweist jedoch nicht, dass die benötigte Benutzerfunktion arbeitet. --- **7.9.14 Bestimmte IP-Adresse mit richtigem Hostnamen testen** Bei HTTPS sollte nicht einfach die IP-Adresse in die URL eingesetzt werden. Dadurch können sich SNI, Host-Header und Zertifikatsprüfung verändern. Mit curl kann ein Servername kontrolliert einer bestimmten Adresse zugeordnet werden: ```bash curl -v \ --resolve :: \ "https://:/" ``` Damit bleiben der Servername in der URL, der HTTP-Host und die TLS-SNI-Angabe erhalten, während die Verbindung gezielt zur angegebenen IP-Adresse aufgebaut wird. Dieser Test ist hilfreich bei: - mehreren A- oder AAAA-Adressen; - Load Balancern; - geplanten DNS-Änderungen; - einem einzelnen verdächtigen Backend; - dem Vergleich alter und neuer Zieladressen. Das Ergebnis gilt nur für die getestete Kombination aus Name, Adresse, Port und Pfad. --- **7.9.15 TLS kurz prüfen** Für HTTPS oder andere TLS-Dienste: ```bash openssl s_client \ -connect : \ -servername \ -verify_hostname \ -verify_return_error ``` Zu prüfen sind: - wird überhaupt eine TCP-Verbindung aufgebaut? - beginnt der TLS-Handshake? - wird der richtige Servername per SNI verwendet? - stimmt der Zertifikatsname mit dem Servernamen überein? - ist die Zertifikatskette vollständig? - vertraut der verwendete Client der ausstellenden Zertifizierungsstelle? - sind Zertifikat und Zwischenzertifikate gültig? - wird eine gemeinsame TLS-Version beziehungsweise Cipher Suite gefunden? - verlangt der Server ein Clientzertifikat? Die Vertrauensstellung von OpenSSL kann sich vom Zertifikatsspeicher der eigentlichen Anwendung unterscheiden. Ein erfolgreicher OpenSSL-Test beweist deshalb nicht automatisch, dass jeder Client dem Zertifikat vertraut. Zertifikatsprüfungen dürfen nicht dauerhaft mit Optionen wie `-k` oder `--insecure` umgangen werden. Die ausführliche TLS-Diagnose erfolgt auf Seite 7.14. --- **7.9.16 Proxy und anwendungsspezifischen Verbindungsweg prüfen** Eine Anwendung kann einen Proxy verwenden, obwohl ein direkter Porttest erfolgreich ist. Umgekehrt kann ein direkter Test scheitern, während der Zugriff ausschließlich über einen Proxy vorgesehen ist. Windows – WinHTTP-Konfiguration: ```powershell netsh winhttp show proxy ``` Umgebungsvariablen in PowerShell: ```powershell Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|NO)_PROXY$' ``` Linux: ```bash env | grep -iE '^(http|https|no)_proxy=' ``` macOS: ```bash scutil --proxy env | grep -iE '^(http|https|no)_proxy=' ``` Zusätzlich zu prüfen: - eigene Proxyeinstellung der Anwendung; - Browser- oder Benutzerproxy; - PAC-Datei; - Proxy-Bypassliste; - Proxy-Authentifizierung; - Abweichung zwischen WinHTTP und benutzerbezogenen Einstellungen; - unterschiedliche Regeln für interne und externe Namen; - VPN-abhängige Proxykonfiguration. `netsh winhttp show proxy` zeigt nur die WinHTTP-Konfiguration. Daraus darf nicht automatisch auf die Konfiguration jedes Browsers oder jeder Anwendung geschlossen werden. --- **7.9.17 Listener auf dem Server prüfen** Wenn der TCP-Port von außen nicht erreichbar ist, muss geprüft werden, ob der Dienst auf dem Server tatsächlich lauscht. Windows: ```powershell Get-NetTCPConnection ` -LocalPort ` -State Listen | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Zugehörigen Prozess prüfen: ```powershell Get-Process -Id ``` Linux: ```bash sudo ss -lntp ``` macOS: ```bash sudo lsof -nP \ -iTCP: \ -sTCP:LISTEN ``` Zu prüfen sind: - richtiger Port; - erwarteter Prozess; - lokale Bindungsadresse; - IPv4- oder IPv6-Bindung; - Dienststatus; - mehrere konkurrierende Prozesse; - unerwartete Portänderung. Typische Bindungsbefunde: | Bindungsadresse | Bedeutung | |---|---| | `127.0.0.1` | nur lokale IPv4-Verbindungen | | `::1` | nur lokale IPv6-Verbindungen | | konkrete Serveradresse | nur über diese Adresse beziehungsweise Schnittstelle | | `0.0.0.0` | alle lokalen IPv4-Adressen | | `[::]` | alle lokalen IPv6-Adressen; zusätzliches IPv4-Verhalten ist systemabhängig | Ein Dienst, der ausschließlich auf `127.0.0.1` lauscht, kann lokal funktionieren und trotzdem von entfernten Clients nicht erreichbar sein. --- **7.9.18 Lokalen und entfernten Zugriff vergleichen** Auf dem Server kann zunächst ein lokaler Anwendungstest durchgeführt werden: ```bash curl -v \ "http://127.0.0.1:/" ``` Bei einem namensabhängigen HTTPS-Dienst: ```bash curl -v \ --resolve ::127.0.0.1 \ "https://:/" ``` Der lokale Test muss an die tatsächliche Listeneradresse angepasst werden. Ein Dienst, der nur an eine bestimmte Serveradresse gebunden ist, muss über diese Adresse geprüft werden. | Lokaler Test | Entfernter Test | Wahrscheinlicher Bereich | |---|---|---| | schlägt fehl | schlägt fehl | Dienst, Listener, Konfiguration oder Backend | | funktioniert | TCP-Port schlägt fehl | Listenerbindung, Hostfirewall oder Netzwerkpfad | | funktioniert | TCP-Port funktioniert, Protokoll schlägt fehl | TLS, Reverse Proxy, virtueller Host oder Anwendung | | funktioniert | `curl` vom Client funktioniert | Problem im eigentlichen Client oder Benutzerkontext | | funktioniert nur über Loopback | entfernt nicht erreichbar | falsche Listenerbindung wahrscheinlich | | funktioniert über eine Serveradresse | über andere Adresse nicht | Schnittstelle, Routing, DNS oder Firewallregel | Ein lokaler Erfolg beweist nicht, dass die vollständige externe Zugriffskette funktioniert. --- **7.9.19 Firewall, ACL, NAT und Load Balancer prüfen** ICMP und Anwendungsverkehr können durch unterschiedliche Regeln behandelt werden. Zu prüfen sind: - lokale Firewall auf dem Client; - Hostfirewall auf dem Server; - Netzwerkfirewall zwischen den Systemen; - VLAN- oder Segment-ACL; - VPN-Regel; - NAT- oder Portweiterleitung; - Security Group oder Cloud-Firewall; - Load-Balancer-Listener; - Load-Balancer-Healthcheck; - Reverse-Proxy-Route; - Quellnetz- oder benutzerabhängige Regel; - Rückweg vom Server zum Client. Mögliche Konstellationen: - ICMP ist erlaubt, TCP 443 wird verworfen. - TCP 443 erreicht den Load Balancer, aber kein Backend ist gesund. - Der Reverse Proxy besitzt keinen passenden virtuellen Host. - Eine NAT-Regel leitet auf den falschen internen Port weiter. - Eine Firewall erlaubt nur bestimmte Quellnetze. - Der Hinweg funktioniert, der Rückweg verwendet eine falsche Route. - Ein Hostname verweist noch auf eine alte virtuelle IP-Adresse. Firewalls dürfen nicht pauschal deaktiviert werden. Stattdessen müssen Protokoll, Quelladresse, Zieladresse, Port, Richtung und Treffer der konkreten Regel geprüft werden. --- **7.9.20 Authentifizierung und Autorisierung abgrenzen** Wenn eine Anwendung eine Anmeldemaske, einen HTTP-Statuscode oder eine konkrete Berechtigungsfehlermeldung zurückgibt, wurde die Anwendungsebene bereits erreicht. Zu unterscheiden sind: - **Authentifizierung:** Ist die angegebene Identität gültig? - **Autorisierung:** Darf diese Identität die gewünschte Ressource verwenden? - **Anwendungszustand:** Ist Konto, Mandant oder Lizenz in der Anwendung aktiv? - **Verzeichnisdienst:** Kann die Anwendung LDAP, Active Directory oder einen Identitätsanbieter erreichen? - **Sitzung:** Sind Cookie, Token oder Ticket gültig? - **Zeit:** Sind Client, Server und Identitätsdienst ausreichend synchronisiert? Geeignete Kreuztests: | Test | Erkenntnis | |---|---| | anderer Benutzer am selben Client | benutzerbezogener Fehler möglich | | gleicher Benutzer an anderem Client | clientbezogener Fehler möglich | | kontrolliertes Testkonto | Konto- oder Rechteproblem eingrenzen | | anonymer oder öffentlicher Endpunkt | Netzwerk und Anwendung ohne Benutzeranmeldung prüfen | | lokales Anwendungskonto | Abhängigkeit vom Verzeichnisdienst untersuchen | Kontosperren und produktive Benutzerkonten müssen berücksichtigt werden. Die Domänenanmeldung wird ausführlich auf Seite 7.10 behandelt. --- **7.9.21 Anwendungsabhängigkeiten untersuchen** Ein erreichbarer Frontend-Port bedeutet nicht, dass alle Backenddienste funktionieren. Mögliche Abhängigkeiten: - Datenbank; - Verzeichnisdienst; - DNS; - API; - Dateifreigabe; - Objektspeicher; - Nachrichtenwarteschlange; - Cache; - Lizenzserver; - Identitätsanbieter; - externer Cloud-Dienst; - anderer Container oder interner Dienst. Typische Befunde: - Reverse Proxy antwortet mit `502 Bad Gateway`. - Anwendung antwortet mit `503 Service Unavailable`. - Anmeldung bleibt hängen, weil der Identitätsdienst nicht erreichbar ist. - Startseite funktioniert, Datenabfrage schlägt jedoch fehl. - Healthcheck ist erfolgreich, Geschäftsprozess scheitert. - Dienst nimmt TCP-Verbindungen an, besitzt aber keine freien Worker. - Datenträger oder Dateisystem ist voll. - Container ist erreichbar, aber eine interne Abhängigkeit fehlt. Anwendungs-, Proxy- und Backendprotokolle müssen anhand des gleichen Fehlerzeitpunkts korreliert werden. Container-Neustartschleifen werden auf Seite 7.12 und volle Datenträger auf Seite 7.13 ausführlich behandelt. --- **7.9.22 UDP-Dienste korrekt prüfen** UDP besitzt keinen TCP-ähnlichen Verbindungsaufbau. Ein allgemeiner UDP-Porttest kann daher nicht sicher beweisen, dass der Dienst funktioniert. Für UDP muss eine gültige Anfrage des tatsächlichen Anwendungsprotokolls gesendet und die Antwort geprüft werden. DNS-Test unter Windows: ```powershell Resolve-DnsName ` -Name ` -Server ``` DNS-Test unter Linux oder macOS: ```bash dig @ A ``` Ein fehlender UDP-Fehler beweist nicht, dass: - der Port geöffnet ist; - der Dienst läuft; - die Anfrage den Server erreicht hat; - der Server eine gültige Antwort senden kann; - der Rückweg funktioniert. Bei UDP-Diensten sind Anwendungsprotokoll, Serverprotokoll und gegebenenfalls ein kontrollierter Paketmitschnitt besonders wichtig. --- **7.9.23 IPv4 und IPv6 getrennt prüfen** Ein Name kann gleichzeitig A- und AAAA-Einträge besitzen. Ping und Anwendung können unterschiedliche Adressfamilien auswählen. Mit curl getrennt testen: ```bash curl -4 -v \ "https://:/" curl -6 -v \ "https://:/" ``` Zu prüfen sind: - besitzt der Name A- und AAAA-Einträge? - welche Adresse verwendet die fehlerhafte Anwendung? - ist der Dienst an IPv4 und IPv6 gebunden? - besitzen beide Protokolle einen funktionierenden Rückweg? - gelten für IPv4 und IPv6 unterschiedliche Firewallregeln? - funktioniert der Proxy oder Load Balancer mit beiden Adressfamilien? - wird eine veraltete oder nicht erreichbare IPv6-Adresse veröffentlicht? Wenn ausschließlich IPv6 fehlschlägt, muss der IPv6-Pfad oder der AAAA-Eintrag korrigiert werden. IPv6 sollte nicht ohne Ursachenanalyse dauerhaft deaktiviert werden. --- **7.9.24 Paketgröße und Übertragungsverhalten berücksichtigen** Ein kleiner ICMP-Ping kann funktionieren, während größere Anwendungsdaten hängen bleiben. Mögliche Ursachen: - fehlerhafte Path-MTU-Ermittlung; - blockierte erforderliche ICMP-Fehlermeldungen; - Fragmentierungsproblem; - Paketverlust; - fehlerhafter VPN-Tunnel; - Überlastung; - asymmetrischer Pfad; - fehlerhafte Netzwerkhardware. Typische Hinweise: - TCP-Verbindung wird aufgebaut, aber TLS bleibt während des Handshakes hängen. - Kleine Webseiten funktionieren, Downloads brechen ab. - Anwendung funktioniert ohne VPN, aber nicht über den Tunnel. - Wiederholte TCP-Übertragungen sind im Paketmitschnitt sichtbar. - Fehler tritt erst ab einer bestimmten Datenmenge auf. Ein erfolgreicher Standard-Ping darf deshalb nicht als vollständiger Nachweis eines fehlerfreien Datenpfads verwendet werden. --- **7.9.25 Paketmitschnitt kontrolliert einsetzen** Linux oder macOS: ```bash sudo tcpdump -ni \ host and port ``` Alternativ kann Wireshark mit einem passenden Erfassungsfilter verwendet werden. Typische Beobachtungen: | Beobachtung | Einordnung | |---|---| | wiederholte SYN-Pakete ohne Antwort | keine TCP-Antwort; Pfad, Regel oder Ziel prüfen | | SYN wird mit RST beantwortet | Port geschlossen oder Verbindung aktiv abgelehnt | | SYN, SYN-ACK und ACK sichtbar | TCP-Verbindung wurde aufgebaut | | TCP-Verbindung wird danach sofort geschlossen | Dienst oder Protokoll lehnt Verbindung ab | | TLS ClientHello ohne passende Fortsetzung | TLS-Pfad, Server oder Inspektion prüfen | | TLS-Alert | konkrete TLS-Ursache auswerten | | viele Wiederholungen | Paketverlust, Überlastung oder fehlerhafter Pfad möglich | | Antwort verlässt den Server, erreicht Client aber nicht | Rückweg oder zwischengeschaltete Regel prüfen | Ein Paketmitschnitt beweist nur, was an der jeweiligen Erfassungsstelle sichtbar ist. Bei komplexen Pfaden können Mitschnitte auf Client, Server und einem zwischengeschalteten System erforderlich sein. Paketmitschnitte dürfen nur mit entsprechender Berechtigung erstellt und müssen datenschutzgerecht gespeichert werden. --- **7.9.26 Systematischer Diagnoseablauf** 1. **Fehler aufnehmen** Anwendung, Benutzer, Client, Zeitpunkt, Meldung und ursprüngliche Benutzerfunktion dokumentieren. 2. **Umfang bestimmen** Einen Benutzer, einen Client, ein Netz oder alle Benutzer unterscheiden. 3. **Exaktes Ziel bestimmen** Servername, Adresse, Port, Protokoll, Pfad und Verbindungsweg erfassen. 4. **Namensauflösung prüfen** A- und AAAA-Antworten sowie tatsächlich verwendete Adresse vergleichen. 5. **Ping korrekt bewerten** Nur ICMP-Erreichbarkeit als bestätigt betrachten. 6. **Transportprotokoll bestimmen** TCP und UDP unterscheiden. 7. **TCP-Port oder UDP-Anwendung prüfen** Einen zum tatsächlichen Protokoll passenden Test verwenden. 8. **Listener kontrollieren** Port, Prozess und Bindungsadresse auf dem Server prüfen. 9. **Lokalen Anwendungstest durchführen** Dienst auf dem Server über den vorgesehenen Namen, Port und Pfad testen. 10. **Externen Anwendungstest durchführen** Denselben Dienst vom betroffenen Client aus prüfen. 11. **TLS untersuchen** SNI, Zertifikat, Vertrauenskette und Protokollkompatibilität prüfen. 12. **Proxy und VPN berücksichtigen** Tatsächlichen Verbindungsweg der Anwendung nachvollziehen. 13. **Anwendungsantwort auswerten** Statuscode, Protokollmeldung, Umleitung oder Authentifizierungsfehler bestimmen. 14. **Abhängigkeiten prüfen** Datenbank, Identitätsdienst, API, Speicher oder andere Backends untersuchen. 15. **Protokolle korrelieren** Client-, Server-, Proxy- und Anwendungsprotokolle auf denselben Zeitraum begrenzen. 16. **Bei Bedarf Paketverlauf erfassen** SYN, RST, TLS-Alert, Wiederholungen und Rückweg untersuchen. 17. **Hypothese formulieren** Erwartetes Prüfergebnis und möglichen Gegenbeweis festlegen. 18. **Eine kontrollierte Änderung durchführen** Risiko, Rückweg und Erfolgskriterium dokumentieren. 19. **Vollständige Funktion prüfen** Nicht nur Ping oder Port, sondern den ursprünglichen Benutzerablauf testen. 20. **Nachkontrolle durchführen** Protokolle, Überwachung und andere Benutzerfunktionen prüfen. --- **7.9.27 Befundmatrix** | Befund | Mögliche Erklärung | Nächster Nachweis | |---|---|---| | Ping auf IP funktioniert, Name nicht | Namensauflösungsproblem | A-, AAAA-, Hosts- und Resolverdaten prüfen | | Ping auf Name verwendet falsche Adresse | veralteter oder falscher Namenseintrag | autoritative und clientseitige Antwort vergleichen | | Ping funktioniert, TCP-Port hat Timeout | Portverkehr wird verworfen oder Antwort fehlt | Firewall, Routing und Paketverlauf prüfen | | Ping funktioniert, TCP-Port wird abgelehnt | kein Listener oder aktive Ablehnung | Listener und Prozess auf dem Server prüfen | | TCP-Port funktioniert, Verbindung wird sofort geschlossen | falsches Protokoll oder Dienst lehnt Sitzung ab | Dienstprotokoll und Serverlogs prüfen | | TCP funktioniert, TLS schlägt fehl | Zertifikat, SNI, TLS-Version oder Inspektion | `curl -v` oder `openssl s_client` auswerten | | TLS funktioniert, HTTP 401 | Authentifizierung erforderlich oder fehlerhaft | Benutzer-, Token- oder Identitätsanbieter prüfen | | TLS funktioniert, HTTP 403 | fehlende Autorisierung oder Richtlinie | Rollen und Zugriffsrichtlinie prüfen | | HTTP 404 | falscher Pfad oder virtuelle Zuordnung | URL, Host-Header und Proxyroute prüfen | | HTTP 407 | Proxy-Authentifizierung erforderlich | Proxyweg und Benutzerkontext prüfen | | HTTP 502 | Gateway erreicht Backend nicht korrekt | Reverse-Proxy- und Backendprotokolle prüfen | | HTTP 503 | Dienst vorübergehend nicht verfügbar | Healthcheck, Kapazität und Abhängigkeiten prüfen | | lokal funktioniert, entfernt nicht | Bindung, Hostfirewall oder Netzwerkpfad | Listeneradresse und Regeln vergleichen | | `curl` funktioniert, Anwendung nicht | anwendungsspezifische Konfiguration | Proxy, Cache, Zertifikatsspeicher und Benutzerkontext prüfen | | nur ein Client betroffen | lokaler Clientfehler | anderen Client und gleichen Benutzer testen | | nur ein Benutzer betroffen | Konto, Profil, Rechte oder Sitzung | anderes Konto am gleichen Client testen | | nur über VPN betroffen | Route, DNS, MTU oder VPN-Regel | mit und ohne VPN vergleichen | | nur IPv6 betroffen | AAAA-, IPv6-Routing- oder Firewallfehler | `curl -4` und `curl -6` vergleichen | | kleine Anfragen funktionieren | MTU, Paketverlust oder Kapazität möglich | Paketverlauf und größere Übertragung prüfen | | Port erreichbar, Geschäftsprozess scheitert | Backend oder Anwendungslogik fehlerhaft | vollständigen Ablauf und Abhängigkeiten prüfen | --- **7.9.28 Mögliche Ursachen und erforderliche Nachweise** | Mögliche Ursache | Erforderlicher Nachweis | |---|---| | falscher Port | Anwendungskonfiguration und tatsächlicher Listener zeigen unterschiedliche Ports | | Dienst gestoppt | kein Listener vorhanden und Dienststatus beziehungsweise Logs bestätigen den Ausfall | | falsche Listenerbindung | Dienst lauscht nur auf Loopback oder einer anderen Adresse | | Hostfirewall blockiert Port | konkrete Regel oder Protokoll zeigt den verworfenen Verbindungsversuch | | Netzwerkfirewall oder ACL | Trefferprotokoll oder beidseitiger Paketmitschnitt bestätigt die Unterbrechung | | falscher DNS-Eintrag | Anwendung verwendet eine nachweislich falsche oder veraltete Adresse | | fehlerhafter IPv6-Pfad | IPv6-Test scheitert reproduzierbar, IPv4-Test funktioniert | | Proxyfehler | Anwendung verwendet einen fehlerhaften Proxyweg, während direkter Test anders reagiert | | Reverse-Proxy-Fehler | Proxy antwortet, passende Route oder gesundes Backend fehlt | | Load-Balancer-Fehler | virtuelle Adresse ist erreichbar, aber Healthcheck oder Backendzustand ist fehlerhaft | | TLS-Fehler | TLS-Ausgabe zeigt Zertifikats-, SNI- oder Protokollproblem | | fehlende Authentifizierung | Anwendung antwortet mit konkretem Anmelde- oder Tokenfehler | | fehlende Autorisierung | Anmeldung funktioniert, Ressourcenzugriff wird nachvollziehbar verweigert | | ausgefallene Backendabhängigkeit | Frontend antwortet, Serverlogs belegen den Fehler der Abhängigkeit | | Ressourcenengpass | Fehler korreliert mit CPU, Speicher, Worker-, Verbindungs- oder Datenträgerengpass | | Path-MTU- oder Paketverlustproblem | Verbindung beginnt, größere Übertragung scheitert und Paketverlauf bestätigt Wiederholungen oder Größenproblem | | clientseitiger Anwendungsfehler | gleicher Benutzer und Dienst funktionieren mit einem anderen Client | | benutzerbezogener Fehler | anderer Benutzer arbeitet am gleichen Client erfolgreich | --- **7.9.29 Kontrollierte Maßnahmen, Risiko und Rückweg** | Maßnahme | Risiko | Rückweg | |---|---|---| | falschen Servernamen oder Port korrigieren | Verbindung erreicht anderes Ziel | ursprüngliche Konfiguration wiederherstellen | | gestoppten Dienst kontrolliert starten | Dienst kann erneut fehlschlagen oder Last erzeugen | Dienstzustand und Starttyp dokumentieren | | Listenerbindung korrigieren | Dienst wird auf zusätzlichen Netzen erreichbar | vorherige Bindung wiederherstellen | | minimale Firewallfreigabe ergänzen | zusätzliche Erreichbarkeit | konkrete Regel entfernen oder deaktivieren | | falschen DNS-Eintrag korrigieren | Clients wechseln auf neues Ziel | vorherigen Wert und TTL dokumentieren | | Reverse-Proxy-Route korrigieren | andere Anwendungen können betroffen sein | vorherige Proxykonfiguration zurückspielen | | fehlerhaftes Backend aus dem Load Balancer nehmen | geringere Kapazität | Backend nach erfolgreicher Prüfung wieder aufnehmen | | Proxykonfiguration korrigieren | anderer Netzwerkpfad wird verwendet | ursprüngliche Proxywerte wiederherstellen | | Zertifikatskette korrigieren | TLS-Dienst muss eventuell neu geladen werden | vorherige Zertifikatskonfiguration sichern | | Anwendungscache kontrolliert leeren | Sitzungs- oder Anmeldedaten können verloren gehen | Benutzer informieren und Ausgangszustand dokumentieren | | Backenddienst wiederherstellen | abhängige Anwendungen können beeinflusst werden | dienstspezifischen Wiederherstellungsplan verwenden | | Ressource freigeben oder Kapazität erhöhen | Lastverteilung kann sich ändern | vorherige Kapazitäts- oder Ressourcenwerte sichern | Pro Maßnahme sollte möglichst nur eine relevante Variable verändert werden. --- **7.9.30 Verifikation** Nach einer Maßnahme müssen mindestens folgende Prüfungen erfolgen: - Servername wird in die erwartete Adresse aufgelöst; - richtige IPv4- oder IPv6-Adresse wird verwendet; - vorgesehener TCP- oder UDP-Dienst ist erreichbar; - richtiger Prozess lauscht auf dem vorgesehenen Port; - TLS-Handshake und Zertifikatsprüfung funktionieren; - Anwendung liefert die erwartete Protokollantwort; - Anmeldung funktioniert; - benötigte Ressource kann geöffnet werden; - vollständiger ursprünglicher Benutzerablauf funktioniert; - Frontend und Backend arbeiten zusammen; - Test funktioniert aus dem betroffenen Netz; - bei größerem Umfang funktionieren mehrere repräsentative Clients; - keine neuen Fehler erscheinen in Client-, Server- oder Proxyprotokollen; - temporäre Freigaben oder Diagnoseänderungen wurden zurückgenommen; - Firewall und Zertifikatsprüfung sind weiterhin aktiv; - Überwachung prüft nicht nur Ping, sondern auch die Anwendungsfunktion; - keine andere Anwendung wurde durch die Änderung beeinträchtigt. Ein erfolgreicher Ping oder Porttest allein ist keine ausreichende Verifikation. --- **7.9.31 Präventionsmaßnahmen** - Anwendungserreichbarkeit zusätzlich zu ICMP überwachen; - TCP-Port, TLS und einen geeigneten Anwendungsendpunkt prüfen; - kritische Geschäftsprozesse mit synthetischen Funktionstests überwachen; - Servername, Port, Protokoll und Abhängigkeiten dokumentieren; - DNS-Änderungen mit TTL und Rückweg planen; - Zertifikatsablauf und vollständige Zertifikatskette überwachen; - Proxy-, VPN- und Firewallregeln dokumentieren; - Load-Balancer-Healthchecks an die tatsächliche Dienstfunktion anpassen; - Listenerbindungen und Portzuordnungen dokumentieren; - IPv4 und IPv6 getrennt überwachen; - Kapazitätsgrenzen für Worker, Verbindungen, CPU, Speicher und Datenträger überwachen; - Frontend- und Backendprotokolle zeitlich synchronisieren; - Änderungen an DNS, Firewall, Proxy und Anwendung nachvollziehbar protokollieren; - Wiederherstellungs- und Rückfallverfahren testen; - Monitoring nicht auf „Host ist pingbar“ beschränken. --- **7.9.32 Typische Fehler bei der Diagnose** - Einen erfolgreichen Ping mit einer funktionierenden Anwendung gleichsetzen. - Einen Ping als Test eines TCP- oder UDP-Ports interpretieren. - Einen anderen Port als den tatsächlich konfigurierten Port testen. - Die IP-Adresse statt des vorgesehenen HTTPS-Namens aufrufen. - SNI, Host-Header und Zertifikatsnamen ignorieren. - `curl` für einen nicht unterstützten oder nicht HTTP-basierten Dienst verwenden. - Einen allgemeinen UDP-Test als sicheren Funktionsnachweis betrachten. - Einen Timeout automatisch als Firewallfehler einstufen. - `Connection refused` und Timeout gleichsetzen. - Nur einen lokalen Test auf dem Server durchführen. - Nur prüfen, ob der Prozess läuft, statt den Listener zu kontrollieren. - Nur prüfen, ob der Port offen ist, statt das Anwendungsprotokoll zu testen. - Eine HTTP-Antwort automatisch als vollständigen Anwendungserfolg werten. - Einen Healthcheck mit dem eigentlichen Geschäftsprozess gleichsetzen. - Proxy, VPN, Load Balancer oder Reverse Proxy ignorieren. - IPv4 und IPv6 nicht getrennt prüfen. - Firewalls vollständig deaktivieren. - Zertifikatsprüfungen dauerhaft umgehen. - Vor der Protokollsicherung Dienste oder Server neu starten. - Zugangsdaten, Token oder vollständige Debugausgaben ungeschützt weitergeben. - Nach einer Änderung nur erneut pingen und die ursprüngliche Benutzerfunktion nicht testen. --- **7.9.33 Typische Prüfungsfragen** **Warum beweist ein erfolgreicher Ping keine funktionierende Anwendung?** Ping prüft ICMP-Echo-Kommunikation. Die Anwendung kann einen anderen Transportweg, einen bestimmten TCP- oder UDP-Port, TLS, Authentifizierung und weitere Backenddienste benötigen. **Welcher Test sollte nach einem erfolgreichen Ping durchgeführt werden?** Zuerst müssen Zielname, Protokoll und Port der Anwendung bestimmt werden. Anschließend wird der konkrete TCP-Port oder das tatsächliche UDP-Anwendungsprotokoll geprüft. **Was bedeutet „Connection refused“?** Die TCP-Verbindung wurde aktiv abgelehnt. Häufig fehlt ein Listener auf dem Zielport oder eine Komponente lehnt die Verbindung gezielt ab. Der genaue Absender der Ablehnung muss bei Bedarf mit Protokollen oder einem Paketmitschnitt bestimmt werden. **Was bedeutet ein TCP-Timeout?** Der Verbindungsaufbau wurde nicht rechtzeitig abgeschlossen. Mögliche Ursachen sind eine verwerfende Firewallregel, ein falscher Netzwerkpfad, ein fehlender Rückweg, Überlastung oder eine falsche Zieladresse. **Warum sollte ein HTTPS-Dienst nicht nur über seine IP-Adresse getestet werden?** Virtuelle Hosts, TLS-SNI und Zertifikatsprüfung verwenden den Servernamen. Ein Aufruf über die IP-Adresse kann deshalb einen anderen Dienst oder ein anderes Zertifikat erreichen. **Was beweist ein erfolgreicher TCP-Porttest?** Er beweist, dass zum Testzeitpunkt eine TCP-Verbindung zur geprüften Adresse und zum geprüften Port aufgebaut werden konnte. Die Funktion des Anwendungsprotokolls ist damit noch nicht bewiesen. **Was bedeutet ein HTTP-Statuscode 401 oder 403 für die Netzwerkdiagnose?** Die Anwendung wurde erreicht und hat auf HTTP-Ebene geantwortet. Der Fehler liegt anschließend wahrscheinlich bei Authentifizierung, Autorisierung oder einer Anwendungsrichtlinie. **Warum ist ein allgemeiner UDP-Porttest nicht eindeutig?** UDP besitzt keinen verbindlichen Verbindungsaufbau. Ohne gültige Anwendungsanfrage und auswertbare Antwort lässt sich die Dienstfunktion nicht sicher bestätigen. **Was bedeutet es, wenn die Anwendung lokal auf dem Server funktioniert, vom Client aber nicht?** Der Dienst selbst arbeitet grundsätzlich. Danach müssen Listenerbindung, Hostfirewall, Netzwerkpfad, Proxy, Load Balancer und externe Namensauflösung geprüft werden. **Warum kann `curl` funktionieren, obwohl die eigentliche Anwendung fehlschlägt?** Die Anwendung kann einen anderen Proxy, Zertifikatsspeicher, DNS-Cache, Benutzerkontext, Authentifizierungsmechanismus oder zusätzliche Protokollfunktionen verwenden. **Warum reicht ein erfolgreicher Healthcheck nicht immer aus?** Ein Healthcheck kann nur einen einfachen Endpunkt prüfen. Datenbankzugriff, Anmeldung oder der eigentliche Geschäftsprozess können trotzdem fehlschlagen. --- **7.9.34 Checkliste** - [ ] ursprüngliche Benutzerfunktion dokumentiert - [ ] genaue Fehlermeldung und Fehlerzeitpunkt erfasst - [ ] betroffene Benutzer und Clients bestimmt - [ ] vollständiger Servername erfasst - [ ] verwendete Zieladresse bestätigt - [ ] TCP oder UDP bestimmt - [ ] richtiger Port bestimmt - [ ] Protokoll und URL-Pfad bestimmt - [ ] Ping nur als ICMP-Test bewertet - [ ] A- und AAAA-Auflösung geprüft - [ ] tatsächlich verwendete Adresse kontrolliert - [ ] TCP-Port oder UDP-Anwendung geprüft - [ ] Listener und zugehöriger Prozess geprüft - [ ] Bindungsadresse kontrolliert - [ ] lokaler Anwendungstest durchgeführt - [ ] entfernter Anwendungstest durchgeführt - [ ] TLS und Zertifikat geprüft - [ ] Proxy- und VPN-Weg geprüft - [ ] Firewall, ACL und Rückweg berücksichtigt - [ ] Load Balancer oder Reverse Proxy geprüft - [ ] Anwendungsantwort und Statuscode ausgewertet - [ ] Authentifizierung und Autorisierung unterschieden - [ ] Backendabhängigkeiten geprüft - [ ] IPv4 und IPv6 getrennt getestet - [ ] Client-, Server- und Proxyprotokolle korreliert - [ ] Paketmitschnitt nur bei Bedarf und berechtigt erstellt - [ ] Hypothese und Gegenbeweis formuliert - [ ] Risiko und Rückweg vor Änderung dokumentiert - [ ] nur eine kontrollierte Änderung durchgeführt - [ ] vollständiger Benutzerablauf verifiziert - [ ] temporäre Diagnoseänderungen zurückgenommen - [ ] Ergebnis und Präventionsmaßnahme dokumentiert --- **7.9.35 Schnellreferenz** | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Ping | `ping ` | `ping -c 4 ` | `ping -c 4 ` | | Namensauflösung | `Resolve-DnsName ` | `getent ahosts ` | `dscacheutil -q host -a name ` | | A-Eintrag | `Resolve-DnsName -Type A` | `dig A` | `dig A` | | AAAA-Eintrag | `Resolve-DnsName -Type AAAA` | `dig AAAA` | `dig AAAA` | | TCP-Port | `Test-NetConnection -Port ` | `nc -vz ` | `nc -vz ` | | HTTP oder HTTPS | `curl.exe -v ` | `curl -v ` | `curl -v ` | | IPv4 mit curl | `curl.exe -4 -v ` | `curl -4 -v ` | `curl -4 -v ` | | IPv6 mit curl | `curl.exe -6 -v ` | `curl -6 -v ` | `curl -6 -v ` | | bestimmte Ziel-IP | `curl.exe --resolve :: ` | `curl --resolve :: ` | `curl --resolve :: ` | | Listener | `Get-NetTCPConnection -State Listen` | `sudo ss -lntp` | `sudo lsof -nP -iTCP -sTCP:LISTEN` | | WinHTTP-Proxy | `netsh winhttp show proxy` | nicht zutreffend | nicht zutreffend | | Systemproxy | Anwendungseinstellungen prüfen | Anwendung und Umgebungsvariablen prüfen | `scutil --proxy` | | TLS | `openssl s_client` bei installierter OpenSSL-Version | `openssl s_client` | `openssl s_client` | | Paketmitschnitt | Wireshark oder freigegebenes Windows-Werkzeug | `tcpdump` oder Wireshark | `tcpdump` oder Wireshark | --- **7.9.36 Quellen** **Standards und RFCs** - [RFC 792 – Internet Control Message Protocol](https://datatracker.ietf.org/doc/html/rfc792) - [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293) - [RFC 9110 – HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110) - [RFC 8446 – The Transport Layer Security Protocol Version 1.3](https://datatracker.ietf.org/doc/html/rfc8446) - [RFC 1191 – Path MTU Discovery für IPv4](https://datatracker.ietf.org/doc/html/rfc1191) - [RFC 8201 – Path MTU Discovery für IPv6](https://datatracker.ietf.org/doc/html/rfc8201) - [IANA – HTTP Status Code Registry](https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml) **Offizielle Hersteller- und Projektdokumentation** - [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection) - [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname) - [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection) - [Microsoft Learn – netsh winhttp](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-winhttp) - [curl – offizielle Befehlsreferenz](https://curl.se/docs/manpage.html) - [Everything curl – Verbose output](https://everything.curl.dev/usingcurl/verbose.html) - [OpenSSL – openssl s_client](https://docs.openssl.org/3.6/man1/openssl-s_client/) - [OpenBSD – nc(1)](https://man.openbsd.org/nc) **Lokale Befehlsreferenzen** Die genaue Syntax kann von Betriebssystem und installierter Version abhängen. Maßgeblich ist die lokale Befehlsreferenz: ```bash man ping man nc man curl man ss man lsof man tcpdump man dscacheutil man scutil ``` Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.