# 3. Netzwerkfehler systematisch analysieren # 3.0 Netzwerkfehler systematisch eingrenzen Netzwerkstörungen sollten nicht durch zufälliges Ausprobieren einzelner Befehle untersucht werden. Eine zuverlässige Diagnose beginnt beim betroffenen Endgerät und arbeitet sich schrittweise durch die beteiligten Ebenen und Komponenten bis zum Zielsystem vor. Dieses Kapitel behandelt typische Fehler in lokalen Netzwerken, standortübergreifenden Verbindungen und beim Zugriff auf interne oder externe Dienste. > **Grundregel:** Zuerst feststellen, auf welcher Ebene die Kommunikation scheitert. Erst danach wird die konkrete Ursache innerhalb dieser Ebene untersucht. ---
1. Welche Ziele verfolgt dieses Kapitel? Nach diesem Kapitel soll eine Netzwerkstörung strukturiert folgenden Bereichen zugeordnet werden können: - physische Verbindung, - Netzwerkschnittstelle und Treiber, - VLAN und Layer-2-Kommunikation, - IP-Konfiguration und Subnetz, - DHCP, - ARP beziehungsweise IPv6 Neighbor Discovery, - Routing und Standardgateway, - DNS und Namensauflösung, - TCP- und UDP-Ports, - Firewall und Paketfilter, - NAT und Portweiterleitung, - Proxy und Reverse Proxy, - VPN und Tunnel, - WLAN, - Netzwerkperformance, - Paketverlust und Wiederholungen, - MTU und Fragmentierung, - interne oder externe Zielsysteme. Das Ziel ist nicht nur, die Verbindung wiederherzustellen, sondern die tatsächliche Ursache nachvollziehbar zu bestimmen und zu dokumentieren.
2. Welche Seiten enthält das Kapitel? | Seite | Thema | Zentrale Fragestellung | |---:|---|---| | 3.0 | Netzwerkfehler systematisch eingrenzen | Wie wird eine Netzwerkstörung grundsätzlich untersucht? | | 3.1 | Störungsumfang und Kommunikationsweg bestimmen | Wer ist betroffen und welchen Weg nimmt die Verbindung? | | 3.2 | Physische Verbindung und Netzwerkschnittstelle | Bestehen Link, Signal und fehlerfreie Schnittstellenkommunikation? | | 3.3 | IP-Konfiguration und Subnetz prüfen | Besitzt das Endgerät eine gültige und passende Konfiguration? | | 3.4 | DHCP-Fehler analysieren | Warum erhält ein Client keine oder eine falsche IP-Konfiguration? | | 3.5 | ARP und IPv6 Neighbor Discovery | Kann die lokale Zieladresse einer MAC-Adresse zugeordnet werden? | | 3.6 | VLAN- und Layer-2-Fehler | Befinden sich Port und Endgerät im richtigen logischen Netz? | | 3.7 | Standardgateway und Routing | Existiert ein gültiger Weg zum Zielnetz? | | 3.8 | DNS-Fehler analysieren | Ist nur die Namensauflösung oder die gesamte Verbindung gestört? | | 3.9 | Ports und Transportprotokolle prüfen | Ist der benötigte TCP- oder UDP-Dienst erreichbar? | | 3.10 | Firewall und Paketfilter untersuchen | Wo und warum wird Kommunikation zugelassen oder verworfen? | | 3.11 | NAT und Portweiterleitungen | Werden Adressen und Ports korrekt übersetzt? | | 3.12 | Proxy und Reverse Proxy | Scheitert die Verbindung am Proxy, Backend oder Client? | | 3.13 | VPN- und Tunnelprobleme | Sind Tunnel, Routen, DNS und MTU korrekt? | | 3.14 | WLAN-Störungen analysieren | Liegt die Ursache bei Signal, Funkkanal, Authentifizierung oder IP-Konfiguration? | | 3.15 | Paketverlust, Latenz und Jitter | Wo entsteht eine instabile oder langsame Verbindung? | | 3.16 | MTU, MSS und Fragmentierungsprobleme | Sind Pakete für einen Teil des Übertragungsweges zu groß? | | 3.17 | Asymmetrisches Routing | Nehmen Hin- und Rückweg unterschiedliche, problematische Wege? | | 3.18 | Netzwerkfehler mit Wireshark erkennen | Welche Paketsequenz belegt die technische Störung? | | 3.19 | Typische Netzwerkfehler nach Symptomen | Welche Prüfungen passen zu einem konkreten Fehlerbild? | | 3.20 | Befehlsübersicht für Windows, Linux und macOS | Welcher Befehl prüft welche Netzwerkebene? | | 3.21 | Dokumentations- und Eskalationsvorlage | Wie wird die Analyse vollständig übergeben? |
3. Welche Kennzeichnungen werden verwendet? | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Read-only: liest Informationen aus | | `[TEST]` | führt eine aktive Netzwerkprüfung durch | | `[PRIV]` | benötigt möglicherweise Administrator- oder Root-Rechte | | `[FILE]` | erzeugt oder verändert eine Datei | | `[SENS]` | Ausgabe kann vertrauliche Daten enthalten | | `[CHANGE]` | verändert eine Konfiguration oder einen Systemzustand | | `[DISRUPT]` | kann eine bestehende Verbindung oder einen Dienst unterbrechen | **Beispiele** ```powershell [RO] Get-NetIPConfiguration ``` Der Befehl zeigt die vorhandene Windows-Netzwerkkonfiguration an. ```bash [TEST] ping -c 4 192.0.2.1 ``` Der Befehl sendet aktiv ICMP-Echo-Anfragen. ```powershell [PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet' ``` Dieser Befehl startet den Netzwerkadapter neu und unterbricht dabei bestehende Verbindungen. Er darf nicht als erster Diagnoseschritt verwendet werden.
4. Wie wird der Kommunikationsweg dargestellt? Vor der technischen Analyse sollte der erwartete Kommunikationsweg gezeichnet werden. **Beispiel: Zugriff auf eine interne Anwendung** ```text Client → Netzwerkschnittstelle → Access Switch → VLAN → Standardgateway → Firewall → Reverse Proxy → Anwendungsserver → Datenbankserver ``` **Beispiel: Internetzugriff** ```text Client → Switch oder Access Point → lokales Gateway → Firewall → NAT → Internetprovider → externes Zielsystem ``` **Beispiel: VPN-Zugriff** ```text Client → lokales Netzwerk → Internet → VPN-Gateway → VPN-Tunnel → interne Firewall → Zielserver ``` Jede Verbindung besteht aus mehreren möglichen Fehlerstellen. Der Kommunikationsweg verhindert, dass Komponenten untersucht werden, die an der Verbindung überhaupt nicht beteiligt sind.
5. Wie wird eine Netzwerkstörung sinnvoll eingegrenzt? Die Untersuchung sollte vom Allgemeinen zum Spezifischen erfolgen. | Schritt | Fragestellung | |---:|---| | 1 | Was funktioniert konkret nicht? | | 2 | Seit wann besteht die Störung? | | 3 | Wer oder was ist betroffen? | | 4 | Was funktioniert weiterhin? | | 5 | Welche Änderung ging der Störung voraus? | | 6 | Welcher Kommunikationsweg wird erwartet? | | 7 | Auf welcher Ebene liegt der erste Fehler? | | 8 | Ist die Störung reproduzierbar? | | 9 | Welche Messung belegt die Vermutung? | | 10 | Welche einzelne Änderung kann die Hypothese prüfen? | | 11 | Wurde die ursprüngliche Funktion wiederhergestellt? | | 12 | Wurden Ursache, Änderung und Ergebnis dokumentiert? | **Beispiel** ```text Unzureichende Fehlerbeschreibung: „Das Netzwerk funktioniert nicht.“ Bessere Fehlerbeschreibung: „CLIENT-023 kann seit 09:42 Uhr den internen Webserver app.example.intern nicht über TCP 443 erreichen. Andere interne Server sind erreichbar. Weitere Clients im selben VLAN sind nicht betroffen.“ ``` Die zweite Beschreibung grenzt die Störung bereits deutlich ein: - ein Client betroffen, - ein bestimmtes Ziel betroffen, - ein bestimmter Dienst betroffen, - andere Ziele funktionieren, - der Fehler besitzt einen bekannten Startzeitpunkt.
6. Welche Prüfungsreihenfolge ist in der Praxis sinnvoll? | Reihenfolge | Bereich | Beispielprüfung | |---:|---|---| | 1 | Fehlerbild und Umfang | ein Benutzer, mehrere Benutzer oder gesamter Standort? | | 2 | lokale Schnittstelle | Adapter aktiv, Link vorhanden, Fehlerzähler? | | 3 | IP-Konfiguration | Adresse, Präfix, Gateway und DNS korrekt? | | 4 | lokale TCP/IP-Funktion | Loopback und eigene Adresse erreichbar? | | 5 | lokales Netz | Gateway und Nachbarn erreichbar? | | 6 | Routing | existiert eine Route zum Ziel? | | 7 | Namensauflösung | wird der richtige Name zur richtigen Adresse aufgelöst? | | 8 | Transportebene | ist der benötigte TCP- oder UDP-Port erreichbar? | | 9 | Sicherheitskomponenten | blockieren Host-Firewall, Netzwerk-Firewall oder ACL? | | 10 | Anwendungsebene | antwortet der eigentliche Dienst korrekt? | | 11 | Performance | treten Latenz, Paketverlust oder Wiederholungen auf? | | 12 | Paketmitschnitt | welche Paketsequenz belegt den Fehler? | Diese Reihenfolge darf an das konkrete Fehlerbild angepasst werden. Wenn beispielsweise bereits eine falsche IP-Adresse sichtbar ist, muss nicht zuerst ein entfernter Anwendungsserver untersucht werden.
7. Wie helfen OSI- und TCP/IP-Modell bei der Fehleranalyse? | OSI-Schicht | Typische Komponenten | Typische Fehler | |---:|---|---| | 1 – Bitübertragung | Kabel, Funk, Stecker, Transceiver | kein Link, Signalstörung, beschädigtes Kabel | | 2 – Sicherung | Ethernet, MAC, Switch, VLAN | falsches VLAN, Portfehler, Layer-2-Schleife | | 3 – Vermittlung | IPv4, IPv6, Router | falsches Subnetz, fehlende Route, falsches Gateway | | 4 – Transport | TCP, UDP | Port geschlossen, Verbindungsabbruch, Paketverlust | | 5 – Sitzung | Sitzungssteuerung | Sitzung läuft ab oder wird nicht aufgebaut | | 6 – Darstellung | TLS, Kodierung | Zertifikat, Verschlüsselung oder Format inkompatibel | | 7 – Anwendung | DNS, HTTP, SMB, SSH | Dienstfehler, Authentifizierung oder falsche Konfiguration | **Wichtiger Hinweis** Das OSI-Modell ist ein Denk- und Strukturierungsmodell. Reale Protokolle und Anwendungen lassen sich nicht immer vollständig einer einzigen Schicht zuordnen. **Praktische Reihenfolge** ```text Link vorhanden? ↓ gültige IP-Konfiguration? ↓ lokales Gateway erreichbar? ↓ Route zum Ziel vorhanden? ↓ Name korrekt aufgelöst? ↓ Port erreichbar? ↓ Anwendungsprotokoll funktioniert? ```
8. Was bedeutet Bottom-up, Top-down und Divide-and-Conquer? **Bottom-up** Die Untersuchung beginnt auf der untersten Ebene: ```text Kabel → Link → VLAN → IP → Route → Port → Anwendung ``` Geeignet bei: - vollständig fehlender Verbindung, - unbekannter Fehlerstelle, - neu aufgebauter Infrastruktur, - physischen oder lokalen Auffälligkeiten. **Top-down** Die Untersuchung beginnt bei der Anwendung: ```text Anwendung → Port → DNS → Route → IP → Link ``` Geeignet bei: - klarer Anwendungsfehlermeldung, - nur einem betroffenen Dienst, - ansonsten funktionierendem Netzwerk, - bekanntem HTTP-, TLS- oder Authentifizierungsfehler. **Divide-and-Conquer** Die Untersuchung beginnt an einer sinnvollen mittleren Stelle: ```text Kann der Client das Standardgateway erreichen? ``` - Wenn nein: Fehler wahrscheinlich lokal oder im lokalen Netz. - Wenn ja: Untersuchung in Richtung Routing, Firewall und Zielsystem fortsetzen. Diese Methode ist oft besonders effizient, wenn der Kommunikationsweg bekannt ist.
9. Welche Vergleichstests liefern besonders schnell Hinweise? | Vergleich | Aussage | |---|---| | gleicher Client, anderes Ziel | Ist nur ein Ziel betroffen? | | anderer Client, gleiches Ziel | Ist nur ein Client betroffen? | | gleiche Verbindung per IP statt Name | Liegt ein DNS-Problem nahe? | | gleicher Dienst über anderen Port | Ist nur ein Port oder Protokoll betroffen? | | LAN statt WLAN | Liegt die Ursache möglicherweise im Funknetz? | | ohne VPN statt mit VPN | Entsteht das Problem durch Tunnel, Routen oder VPN-DNS? | | funktionierendes Referenzsystem | Welche Konfiguration unterscheidet sich? | | lokaler Zugriff statt entfernter Zugriff | Funktioniert der Dienst grundsätzlich? | | anderer Benutzer am selben Client | Ist das Problem benutzerabhängig? | | gleicher Benutzer an anderem Client | Ist das Problem geräteabhängig? | Ein Vergleich ist besonders aussagekräftig, wenn dabei nur ein relevanter Faktor verändert wird.
10. Welche ersten Prüfungen sind betriebssystemübergreifend möglich? | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Hostname | `[RO] hostname` | `[RO] hostname` | `[RO] hostname` | | lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] ifconfig` | | IP-Konfiguration | `[RO] Get-NetIPConfiguration` | `[RO] ip -brief address` | `[RO] ifconfig` | | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route` | `[RO] netstat -rn` | | ARP-/Nachbartabelle | `[RO] Get-NetNeighbor` | `[RO] ip neigh` | `[RO] arp -an` | | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO] scutil --dns` | | Name auflösen | `[TEST] Resolve-DnsName example.com` | `[TEST] getent hosts example.com` | `[TEST] dscacheutil -q host -a name example.com` | | Gateway testen | `[TEST] Test-Connection GATEWAY -Count 4` | `[TEST] ping -c 4 GATEWAY` | `[TEST] ping -c 4 GATEWAY` | | Route verfolgen | `[TEST] tracert ZIEL` | `[TEST] traceroute ZIEL` | `[TEST] traceroute ZIEL` | | TCP-Port prüfen | `[TEST] Test-NetConnection ZIEL -Port 443` | `[TEST] nc -vz ZIEL 443` | `[TEST] nc -vz ZIEL 443` | | HTTP(S) prüfen | `[TEST] curl -v https://ZIEL/` | `[TEST] curl -v https://ZIEL/` | `[TEST] curl -v https://ZIEL/` | | Verbindungen anzeigen | `[RO] Get-NetTCPConnection` | `[RO] ss -tulpen` | `[RO] netstat -anv` | Die Platzhalter `GATEWAY` und `ZIEL` müssen durch vorher eindeutig bestimmte Adressen oder Namen ersetzt werden.
11. Wie werden Testergebnisse richtig bewertet? | Ergebnis | Sichere Aussage | Nicht automatisch bewiesen | |---|---|---| | Link ist aktiv | physische beziehungsweise logische Linkerkennung besteht | vollständige Netzwerkfunktion | | Ping erfolgreich | ICMP-Antwort kam zurück | Anwendungsport funktioniert | | Ping fehlgeschlagen | keine ICMP-Antwort erhalten | Zielsystem ist ausgeschaltet | | DNS-Auflösung erfolgreich | Name wurde in eine Adresse aufgelöst | Zieladresse ist erreichbar | | TCP-Port erreichbar | TCP-Verbindung konnte aufgebaut werden | Anwendung arbeitet fachlich korrekt | | HTTP 401 | Webdienst antwortet und fordert Authentifizierung | Zugangsdaten sind falsch | | HTTP 403 | Anfrage wurde verstanden und verweigert | Netzwerk-Firewall blockiert | | HTTP 502 | Proxy erhielt keine gültige Backendantwort | Proxy selbst ist zwingend defekt | | Traceroute endet vor dem Ziel | weitere Antworten fehlen | Fehler liegt sicher am letzten sichtbaren Hop | | Keine Pakete im Mitschnitt | am Messpunkt wurde nichts erfasst | Client hat nichts gesendet | Jeder Test beantwortet nur eine begrenzte technische Frage. Die Aussage darf nicht weiter ausgedehnt werden, als das Testergebnis tatsächlich belegt.
12. Welche Störungsumfänge werden unterschieden? | Umfang | Mögliche Untersuchungsrichtung | |---|---| | ein Benutzer | Benutzerprofil, Berechtigung oder individuelle Konfiguration | | ein Endgerät | Adapter, Treiber, IP-Konfiguration oder lokale Firewall | | ein Switchport | Kabel, Port, VLAN oder Port-Security | | ein VLAN | Gateway, DHCP, ACL oder VLAN-Konfiguration | | ein Standort | WAN, Standortfirewall, DNS oder Internetanschluss | | ein Dienst | Serverprozess, Port, Firewall oder Backend | | mehrere Dienste auf einem Server | Server, Betriebssystem oder gemeinsame Ressource | | alle internen Ziele | lokales Routing, Gateway oder Firewall | | nur externe Ziele | NAT, Proxy, Internetzugang oder Provider | | alle Systeme | zentrale Infrastruktur, Stromversorgung oder großflächige Störung | **Hilfreiche Eingrenzungsfragen** ```text Funktioniert derselbe Zugriff von einem anderen Client? ``` ```text Kann der betroffene Client ein anderes Ziel erreichen? ``` ```text Funktioniert der Zugriff über die IP-Adresse? ``` ```text Ist nur ein Port oder sind alle Dienste des Zielsystems betroffen? ``` ```text Tritt der Fehler per LAN und WLAN auf? ``` ```text Tritt der Fehler nur bei aktivem VPN auf? ```
13. Welche Änderungen sind besonders häufig mit Netzwerkstörungen verbunden? - Änderung einer IP-Adresse oder eines Subnetzes, - neuer DHCP-Bereich, - geänderte DNS-Server, - neue Firewall- oder ACL-Regel, - VLAN-Änderung am Switchport, - Firmware- oder Treiberupdate, - neues Zertifikat, - Proxyänderung, - VPN-Client-Update, - Änderung an NAT oder Portweiterleitung, - Routingänderung, - Wechsel des Internetproviders, - neue Sicherheitssoftware, - Änderung an Load Balancer oder Reverse Proxy, - Server- oder Containerupdate, - Änderung von MTU oder Tunnelkonfiguration, - Ablauf eines Zertifikats oder Kennworts, - Wartungsarbeiten am Switch, Router oder Access Point. Die zeitliche Nähe einer Änderung ist ein wichtiger Hinweis, aber noch kein Beweis für die Ursache.
14. Welche Maßnahmen sollten nicht vorschnell durchgeführt werden? | Maßnahme | Risiko | |---|---| | Netzwerkadapter neu starten | bestehende Verbindungen werden unterbrochen | | DHCP-Lease freigeben | Remotezugriff kann verloren gehen | | IP-Adresse ändern | Adresskonflikt oder vollständiger Verbindungsverlust | | Routingtabelle verändern | falsche oder asymmetrische Wege | | DNS-Cache löschen | Beweise und Vergleichszustand verändern sich | | Firewall deaktivieren | erhebliche Sicherheitslücke | | Switchport neu konfigurieren | mehrere Systeme können betroffen sein | | VLAN ändern | Endgerät verliert möglicherweise jede Erreichbarkeit | | Router oder Firewall neu starten | großflächiger Ausfall | | VPN neu installieren | Konfiguration und Protokolle können verloren gehen | | Zertifikatsprüfung abschalten | Sicherheitsmechanismus wird umgangen | | MTU blind reduzieren | Symptom wird möglicherweise nur verdeckt | | Paketfilterregeln löschen | Sicherheits- und Betriebsrisiko | Vor einer Änderung sollten der Ausgangszustand, die Hypothese, die erwartete Wirkung und der Rückweg dokumentiert werden.
15. Wie wird eine Netzwerkhypothese korrekt formuliert? **Ungeeignete Vermutung** ```text „Bestimmt ist die Firewall schuld.“ ``` **Prüfbare Hypothese** ```text Der Client erreicht das Zielsystem auf ICMP-Ebene, aber der TCP-Verbindungsaufbau zu Port 443 erhält keine Antwort. Andere Clients im selben VLAN können den Port erreichen. Deshalb wird eine clientbezogene Filterung oder ein Rückwegproblem vermutet. ``` **Dazugehörige Prüfungen** 1. Quell-IP des betroffenen Clients bestätigen. 2. TCP-Porttest mit Zeitstempel durchführen. 3. Host-Firewall und Sicherheitssoftware prüfen. 4. Firewall-Logs nach Quell- und Zieladresse durchsuchen. 5. Paketmitschnitt am Client und gegebenenfalls am Ziel vergleichen. 6. Funktionierenden Referenzclient gegenüberstellen. Eine Hypothese muss durch Beobachtungen begründet und durch einen konkreten Test widerlegbar sein.
16. Welche Mindestinformationen gehören in ein Netzwerkticket? ```text Ticketnummer: Meldende Person: Betroffener Benutzer: Betroffenes Endgerät: Standort: Verbindungsart: LAN / WLAN / VPN / Mobilfunk Fehlerbeginn: Zeitzone: Letzter funktionierender Zeitpunkt: Fehler reproduzierbar: Ja / Nein Exakte Fehlermeldung: Quellhostname: Quell-IP: Quell-MAC: Quell-VLAN: Quellgateway: Verwendete DNS-Server: Zielhostname: Ziel-IP: Zielport: Transportprotokoll: Anwendungsprotokoll: Betroffene Benutzer oder Geräte: Funktionierende Vergleichssysteme: Weiterhin funktionierende Verbindungen: Kürzliche Änderungen: Erwarteter Kommunikationsweg: 1. 2. 3. 4. Bisherige Prüfungen: - - - Bisherige Änderungen: - - - Arbeitshypothese: Nächster Prüfschritt: Rückweg bei Änderung: ```
17. Wann muss eine Netzwerkstörung eskaliert werden? Eine Eskalation ist sinnvoll oder erforderlich, wenn: - mehrere Benutzer oder Standorte betroffen sind, - ein geschäftskritischer Dienst ausgefallen ist, - ein Sicherheitsvorfall vermutet wird, - unautorisierte Netzwerkänderungen erkennbar sind, - Administratorrechte oder Zuständigkeiten fehlen, - eine Änderung an produktiver Kerninfrastruktur erforderlich wird, - Provider- oder Herstellerunterstützung benötigt wird, - redundante Systeme ebenfalls ausfallen, - die vereinbarte Bearbeitungszeit überschritten wird, - Paketmitschnitte sensible Daten enthalten, - Datenverlust oder Manipulation möglich ist. **Eine gute Eskalation enthält:** - klare Fehlerbeschreibung, - Auswirkung und Priorität, - betroffene Systeme, - Beginn und Zeitzone, - erwarteten Kommunikationsweg, - bereits durchgeführte Prüfungen, - Messergebnisse und Logauszüge, - ausgeschlossene Ursachen, - aktuelle Hypothese, - konkrete Frage an die nächste Stelle, - sichere Kontakt- und Übergabemöglichkeit.
18. Merkschema für die erste Eingrenzung ```text 1. Wer ist betroffen? 2. Was genau funktioniert nicht? 3. Was funktioniert weiterhin? 4. Seit wann besteht der Fehler? 5. Was wurde vorher geändert? 6. Welcher Kommunikationsweg wird erwartet? 7. Besteht ein Link? 8. Ist die IP-Konfiguration gültig? 9. Ist das Gateway erreichbar? 10. Existiert eine Route? 11. Funktioniert die Namensauflösung? 12. Ist der Zielport erreichbar? 13. Antwortet die Anwendung? 14. Wo befindet sich der erste belegte Fehler? 15. Welche Messung bestätigt die Ursache? ``` **Kurzform** ```text Umfang → Link → IP → Gateway → Route → DNS → Port → Anwendung ```
19. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Grundlagen von TCP/IP](https://learn.microsoft.com/troubleshoot/windows-client/networking/tcpip-addressing-and-subnetting) - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Get-NetNeighbor](https://learn.microsoft.com/powershell/module/nettcpip/get-netneighbor) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-neighbour – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [ss – Linux Manual Page](https://man7.org/linux/man-pages/man8/ss.8.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man arp`, `man ping` und `man traceroute` - [Apple Platform Deployment – Network Services](https://support.apple.com/guide/deployment/network-services-dep2d2d2d2d2/web) **Wireshark und tcpdump** - [Wireshark User’s Guide](https://www.wireshark.org/docs/wsug_html/) - [Wireshark Display Filter Reference](https://www.wireshark.org/docs/dfref/) - [tcpdump Manual Page](https://www.tcpdump.org/manpages/tcpdump.1.html) - [pcap-filter Manual Page](https://www.tcpdump.org/manpages/pcap-filter.7.html) > Die genaue Befehlssyntax und die verfügbaren Optionen können von Betriebssystem- und Werkzeugversion abhängen. Vor Änderungen an produktiven Systemen muss zusätzlich die lokale Dokumentation geprüft werden.
# 3.1 Störungsumfang und Kommunikationsweg bestimmen* Bevor einzelne Netzwerkprotokolle, Firewallregeln oder Server untersucht werden, muss der Umfang der Störung bestimmt werden. Dadurch lässt sich erkennen, ob die Ursache wahrscheinlich auf einem Endgerät, in einem Netzsegment, an einer zentralen Komponente oder am Zielsystem liegt. Danach wird der erwartete Kommunikationsweg vom betroffenen Client bis zum Ziel dokumentiert. > **Grundregel:** Erst bestimmen, wer betroffen ist und welchen Weg die Kommunikation nehmen soll. Danach Messungen an den beteiligten Komponenten durchführen. ---
1. Welche Informationen müssen zuerst aufgenommen werden? | Information | Beispiel | |---|---| | Betroffener Benutzer | Max Mustermann | | Betroffenes Gerät | `CLIENT-023` | | Standort | Berlin | | Verbindungsart | LAN | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | Letzter funktionierender Zeitpunkt | `2026-07-31 09:35 CEST` | | Zielanwendung | interne Webanwendung | | Zielname | `app.example.intern` | | Ziel-IP-Adresse | `192.0.2.20` | | Zielport | TCP 443 | | Exakte Fehlermeldung | Verbindung wegen Zeitüberschreitung fehlgeschlagen | | Reproduzierbarkeit | bei jedem Aufruf | | Betroffene Benutzer | nur ein Benutzer bekannt | | Kürzliche Änderung | VPN-Client wurde aktualisiert | **Ungeeignete Fehlerbeschreibung** ```text „Das Internet funktioniert nicht.“ ``` **Geeignete Fehlerbeschreibung** ```text CLIENT-023 kann seit 09:42 Uhr die interne Anwendung https://app.example.intern nicht öffnen. Der Browser meldet nach ungefähr 30 Sekunden eine Zeitüberschreitung. Andere Internetseiten sind erreichbar. CLIENT-024 kann die interne Anwendung weiterhin öffnen. ``` Diese Beschreibung grenzt den Fehler bereits auf einen Client beziehungsweise dessen Kommunikationsweg ein.
2. Welche Fragen sollten der meldenden Person gestellt werden? 1. Was wollten Sie genau durchführen? 2. Welche Anwendung oder Adresse haben Sie verwendet? 3. Welche Fehlermeldung wird vollständig angezeigt? 4. Seit wann tritt der Fehler auf? 5. Hat die Funktion vorher auf demselben Gerät funktioniert? 6. Tritt der Fehler bei jedem Versuch auf? 7. Sind weitere Benutzer betroffen? 8. Funktionieren andere interne Anwendungen? 9. Funktionieren externe Internetseiten? 10. Besteht die Verbindung über LAN, WLAN oder VPN? 11. Wurde der Arbeitsplatz oder Standort gewechselt? 12. Wurde kurz vorher etwas aktualisiert oder verändert? 13. Funktioniert der Zugriff von einem anderen Gerät? 14. Funktioniert der Zugriff mit einem anderen Benutzerkonto? 15. Welche Auswirkung hat die Störung auf die Arbeit? **Wichtig** Die Fragen sollten möglichst konkrete und überprüfbare Antworten erzeugen. ```text Ungenau: „Ist das Netzwerk langsam?“ Besser: „Wie lange dauert der Aufruf normalerweise und wie lange dauert er jetzt?“ ```
3. Wie wird der Störungsumfang bestimmt? | Prüffrage | Wenn ja | Wenn nein | |---|---|---| | Ist nur ein Benutzer betroffen? | Benutzerkonto, Profil und Berechtigungen prüfen | Umfang auf Geräte oder Gruppen erweitern | | Ist nur ein Endgerät betroffen? | lokale Konfiguration, Adapter und Host-Firewall prüfen | gemeinsame Infrastruktur untersuchen | | Ist nur ein Switchport betroffen? | Kabel, Port, VLAN und Port-Security prüfen | Switch oder VLAN weiter untersuchen | | Ist nur ein VLAN betroffen? | Gateway, DHCP, ACL und VLAN-Konfiguration prüfen | übergeordnete Komponenten untersuchen | | Ist nur ein Standort betroffen? | Standortverbindung, Firewall und lokales DNS prüfen | zentrale oder externe Ursache möglich | | Ist nur ein Zielsystem betroffen? | Zielserver, Dienst, Port und Firewall prüfen | gemeinsamer Netzwerkpfad möglich | | Ist nur ein bestimmter Port betroffen? | Dienst, Firewall und Transportprotokoll prüfen | grundlegende Erreichbarkeit untersuchen | | Sind alle externen Ziele betroffen? | Internetzugang, NAT, Proxy oder Provider prüfen | zielbezogene Störung möglich | | Sind alle internen Ziele betroffen? | lokales Gateway, Routing oder zentrale Firewall prüfen | einzelner Dienst oder Pfad betroffen | | Sind alle Systeme betroffen? | zentrale Infrastruktur oder großflächige Störung prüfen | Fehler weiter eingrenzen | **Mögliche Umfangsebenen** ```text Benutzer → Gerät → Switchport → Access Switch → VLAN → Standort → Unternehmensnetz → Dienst → externer Anbieter ``` Je höher die gemeinsame betroffene Ebene liegt, desto wahrscheinlicher ist eine gemeinsame technische Ursache.
4. Welche Vergleichstests sind besonders aussagekräftig? | Test | Gleichbleibender Faktor | Veränderter Faktor | Mögliche Aussage | |---|---|---|---| | anderer Benutzer am selben Client | Gerät und Netzwerkpfad | Benutzerkonto | Benutzer- oder Berechtigungsproblem | | gleicher Benutzer an anderem Client | Benutzer und Ziel | Endgerät | gerätebezogenes Problem | | anderer Client am selben Anschluss | Switchport und Pfad | Endgerät | Endgerät oder Kabel eingrenzen | | gleicher Client an anderem Anschluss | Client | Port und möglicherweise VLAN | Switchport oder Verkabelung | | LAN statt WLAN | Client und Ziel | Zugangsnetz | WLAN-spezifisches Problem | | WLAN statt LAN | Client und Ziel | Zugangsnetz | LAN-Port, Kabel oder VLAN | | IP-Adresse statt DNS-Name | Client und Zielsystem | Namensauflösung | DNS-Problem möglich | | anderes Ziel im selben Netz | Client und lokaler Pfad | Zielsystem | zielbezogene Störung | | gleiches Ziel über anderen Port | Client und Ziel | Dienst beziehungsweise Port | port- oder dienstbezogen | | ohne VPN statt mit VPN | Client und Ziel | Tunnel, Routen und VPN-DNS | VPN-spezifisches Problem | > Bei einem Vergleichstest sollte möglichst nur ein relevanter Faktor verändert werden. Werden gleichzeitig Benutzer, Gerät, Netzwerk und Standort gewechselt, ist das Ergebnis kaum eindeutig zuzuordnen.
5. Wie wird bestimmt, was weiterhin funktioniert? Die funktionierenden Bereiche sind für die Eingrenzung genauso wichtig wie der eigentliche Fehler. **Beispiel** ```text Funktioniert: - Anmeldung am Client - Zugriff auf andere interne Webanwendungen - Zugriff auf externe Internetseiten - DNS-Auflösung des betroffenen Zielnamens - Ping zum Standardgateway Funktioniert nicht: - TCP-Verbindung zu app.example.intern auf Port 443 ``` Daraus kann zunächst abgeleitet werden: - der Client ist grundsätzlich betriebsbereit, - die Netzwerkschnittstelle funktioniert zumindest teilweise, - eine gültige IP-Kommunikation ist vorhanden, - DNS funktioniert für den geprüften Namen, - der Fehler betrifft möglicherweise den Zielport, den Dienst oder den spezifischen Kommunikationspfad. **Negativtest und Positivtest** | Testart | Beispiel | |---|---| | Negativtest | betroffene Anwendung funktioniert nicht | | Positivtest | andere Anwendung im selben Zielnetz funktioniert | | Referenztest | anderer Client erreicht dieselbe Anwendung | Eine belastbare Eingrenzung verwendet möglichst alle drei Testarten.
6. Wie wird das Quellsystem eindeutig identifiziert? Die Bezeichnung „mein Computer“ reicht für eine technische Analyse nicht aus. Zu erfassen sind: - Hostname, - Betriebssystem, - Benutzerkonto, - Netzwerkschnittstelle, - IP-Adresse und Präfix, - MAC-Adresse, - Standardgateway, - DNS-Server, - Verbindungsart, - gegebenenfalls VLAN, VPN oder Proxy. **Windows** ```powershell [RO] hostname ``` ```powershell [RO] Get-ComputerInfo | Select-Object CsName, WindowsProductName, WindowsVersion, OsBuildNumber ``` ```powershell [RO] Get-NetIPConfiguration ``` ```powershell [RO] Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, LinkSpeed, MacAddress, ifIndex ``` **Linux** ```bash [RO] hostnamectl ``` ```bash [RO] ip -brief address ``` ```bash [RO] ip route ``` ```bash [RO] ip -brief link ``` **macOS** ```bash [RO] scutil --get ComputerName ``` ```bash [RO] sw_vers ``` ```bash [RO] ifconfig ``` ```bash [RO] netstat -rn ``` ```bash [RO] networksetup -listallhardwareports ``` Die erfasste IP-Adresse muss der tatsächlich für die Zielverbindung verwendeten Schnittstelle zugeordnet werden. Ein System kann gleichzeitig LAN, WLAN, VPN, virtuelle Adapter und Containerinterfaces besitzen.
7. Wie wird das Zielsystem eindeutig bestimmt? Ein Dienstname oder eine URL muss in seine technischen Bestandteile zerlegt werden. **Beispiel-URL** ```text https://app.example.intern:8443/login ``` | Bestandteil | Wert | |---|---| | Schema beziehungsweise Protokoll | HTTPS | | Hostname | `app.example.intern` | | expliziter Port | TCP 8443 | | Pfad | `/login` | | erwartetes Zielsystem | Reverse Proxy oder Webserver | | möglicher Backenddienst | Anwendungsserver | | mögliche weitere Abhängigkeit | Datenbank oder Identitätsanbieter | Zu erfassen sind: - vollständige URL oder Freigabe, - Hostname, - aufgelöste IP-Adresse beziehungsweise Adressen, - Transportprotokoll, - Port, - erwarteter Server oder Load Balancer, - Anwendungspfad, - möglicherweise verwendeter Proxy, - mögliche Backendabhängigkeiten. **Windows** ```powershell [RO] Resolve-DnsName app.example.intern ``` ```powershell [TEST] Test-NetConnection app.example.intern -Port 443 ``` **Linux** ```bash [RO] getent ahosts app.example.intern ``` ```bash [TEST] nc -vz app.example.intern 443 ``` **macOS** ```bash [RO] dscacheutil -q host -a name app.example.intern ``` ```bash [TEST] nc -vz app.example.intern 443 ``` Ein Hostname kann mehrere IPv4- und IPv6-Adressen zurückgeben. Es muss dokumentiert werden, welche Adresse der Client beim fehlerhaften Versuch tatsächlich verwendet.
8. Wie wird der erwartete Kommunikationsweg gezeichnet? **Direkter Zugriff im lokalen Netz** ```text CLIENT-023 192.0.2.10/24 │ ├─ Access Switch SW-01 │ VLAN 20 │ └─ SERVER-01 192.0.2.20/24 TCP 443 ``` Da Quelle und Ziel im selben IPv4-Subnetz liegen, ist normalerweise kein Router für die direkte Kommunikation erforderlich. **Zugriff in ein anderes internes Netz** ```text CLIENT-023 192.0.2.10/24 │ ├─ Access Switch SW-01 │ VLAN 20 │ ├─ Standardgateway │ 192.0.2.1 │ ├─ Core Router oder Firewall │ ├─ Server-VLAN 40 │ └─ APP-01 198.51.100.20/24 TCP 443 ``` **Zugriff über Reverse Proxy** ```text Browser → DNS-Auflösung → Reverse Proxy TCP 443 → TLS-Verarbeitung → Backend TCP 8080 → Anwendung → Datenbank ``` **Zugriff über VPN** ```text Client → lokales Gateway → Internet → VPN-Gateway → verschlüsselter Tunnel → interne Route → interne Firewall → Zielserver ``` Zu jeder Verbindung sollte bekannt sein: - welche Komponente als Nächstes angesprochen wird, - welche Adresse sie besitzt, - welches Protokoll und welcher Port verwendet werden, - ob Adressen übersetzt werden, - ob Daten verschlüsselt oder getunnelt werden, - welche Komponente den Rückweg bestimmt.
9. Wie wird geprüft, welchen Weg das Betriebssystem verwenden möchte? **Windows – Route zu einem Ziel untersuchen** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Routingtabelle anzeigen: ```powershell [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ``` Pfad verfolgen: ```cmd [TEST] tracert -d 198.51.100.20 ``` **Linux – ausgewählte Route anzeigen** ```bash [RO] ip route get 198.51.100.20 ``` Beispielausgabe: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10 ``` | Feld | Bedeutung | |---|---| | `via 192.0.2.1` | nächster Router | | `dev eth0` | verwendete Schnittstelle | | `src 192.0.2.10` | ausgewählte Quelladresse | Pfad verfolgen: ```bash [TEST] traceroute -n 198.51.100.20 ``` **macOS – ausgewählte Route anzeigen** ```bash [RO] route -n get 198.51.100.20 ``` Pfad verfolgen: ```bash [TEST] traceroute -n 198.51.100.20 ``` > Traceroute zeigt nur antwortende Zwischenstationen. Firewalls und Router können die verwendeten Diagnosepakete verwerfen oder nicht beantworten. Ein Sternchen beweist daher nicht, dass genau dieser Hop den eigentlichen Anwendungsverkehr blockiert.
10. Wie wird bei mehreren Netzwerkschnittstellen die verwendete Schnittstelle bestimmt? Ein Client kann gleichzeitig besitzen: - Ethernet, - WLAN, - VPN, - Mobilfunk, - virtuelle Hypervisoradapter, - Containerbridges, - Loopback, - Tunnelinterfaces. Das Betriebssystem wählt den Weg anhand der Routingtabelle, der Präfixlänge und der Metrik. **Windows** Ausgewählte Route: ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Schnittstellenmetriken: ```powershell [RO] Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Select-Object ifIndex, InterfaceAlias, AddressFamily, ConnectionState, InterfaceMetric ``` **Linux** ```bash [RO] ip route get 198.51.100.20 ``` Richtlinienregeln anzeigen: ```bash [RO] ip rule show ``` Alle wichtigen Routingtabellen anzeigen: ```bash [RO] ip route show table all ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` Netzwerkdienstreihenfolge grafisch prüfen: ```text Systemeinstellungen → Netzwerk → Aktionsmenü → Reihenfolge der Dienste festlegen ``` Die sichtbare Dienstreihenfolge allein ersetzt nicht die Prüfung der tatsächlich ausgewählten Route.
11. Wie werden lokale und entfernte Ziele unterschieden? Das Endgerät entscheidet anhand von IP-Adresse und Präfix beziehungsweise Subnetzmaske, ob das Ziel lokal erreichbar sein sollte. **Lokales Ziel** ```text Quelle: 192.0.2.10/24 Ziel: 192.0.2.20 ``` Beide Adressen gehören zum Netz: ```text 192.0.2.0/24 ``` Der Client versucht normalerweise, die MAC-Adresse des Zielsystems direkt zu ermitteln. **Entferntes Ziel** ```text Quelle: 192.0.2.10/24 Ziel: 198.51.100.20 ``` Das Ziel liegt außerhalb des lokalen Netzes. Der Client sendet das Paket normalerweise an einen Router beziehungsweise das passende Next Hop. **Bedeutung für die Fehleranalyse** | Zieltyp | Erste technische Untersuchung | |---|---| | lokal | VLAN, ARP beziehungsweise Neighbor Discovery, Switchport | | entfernt | Standardgateway, Route, Firewall und Rückweg | | unklar | lokale IP-Konfiguration und Präfix zuerst prüfen | Eine falsche Subnetzmaske kann dazu führen, dass ein Client ein entferntes Ziel fälschlich für lokal hält oder ein lokales Ziel unnötig an das Gateway sendet.
12. Wie wird bestimmt, ob IPv4 oder IPv6 verwendet wird? Ein Hostname kann IPv4- und IPv6-Adressen besitzen. **Windows** ```powershell [RO] Resolve-DnsName app.example.intern -Type A ``` ```powershell [RO] Resolve-DnsName app.example.intern -Type AAAA ``` Bestehende TCP-Verbindung prüfen: ```powershell [RO] Get-NetTCPConnection | Where-Object RemotePort -eq 443 | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess ``` **Linux** ```bash [RO] getent ahosts app.example.intern ``` IPv4 gezielt testen: ```bash [TEST] curl -4 -I https://app.example.intern/ ``` IPv6 gezielt testen: ```bash [TEST] curl -6 -I https://app.example.intern/ ``` **macOS** ```bash [RO] dscacheutil -q host -a name app.example.intern ``` ```bash [TEST] curl -4 -I https://app.example.intern/ ``` ```bash [TEST] curl -6 -I https://app.example.intern/ ``` Wenn IPv4 funktioniert und IPv6 nicht, bedeutet das nicht automatisch, dass IPv6 deaktiviert werden sollte. Stattdessen müssen IPv6-Adresse, Präfix, Router, DNS, Firewall und Rückweg untersucht werden.
13. Wie wird ein Dienst hinter Load Balancer oder Reverse Proxy berücksichtigt? Der im DNS eingetragene Endpunkt ist möglicherweise nicht der eigentliche Anwendungsserver. ```text Client → DNS → virtuelle IP-Adresse → Load Balancer oder Reverse Proxy → Backend 1 → Backend 2 → Backend 3 ``` Zu dokumentieren sind: - DNS-Name, - aufgelöste virtuelle IP-Adresse, - Load-Balancer- beziehungsweise Proxyname, - Frontend-Port, - Backendpool, - Backendadressen, - Backendports, - Health-Check, - TLS-Terminierung, - verwendete Host-Header, - Sitzungsbindung, - mögliche Quelladressübersetzung. **Mögliche Fehlerbilder** | Beobachtung | Untersuchungsrichtung | |---|---| | jeder zweite Aufruf schlägt fehl | einzelnes Backend möglicherweise fehlerhaft | | direkter Backendzugriff funktioniert | Proxy- oder Frontendkonfiguration prüfen | | Proxy antwortet mit 502 | Backendverbindung oder Antwort ungültig | | Proxy antwortet mit 504 | Backend antwortet nicht rechtzeitig | | Zertifikat passt nicht | SNI, Hostname oder TLS-Terminierung prüfen | | nur ein Benutzer betroffen | Sitzung, Cookie oder bestimmtes Backend prüfen | | DNS liefert mehrere Adressen | jede Zieladresse getrennt testen | Ein erfolgreicher Test gegen ein einzelnes Backend beweist nicht, dass der vollständige produktive Weg über den Load Balancer funktioniert.
14. Wie wird ein Proxy im Kommunikationsweg erkannt? **Windows – WinHTTP-Proxy** ```cmd [RO] netsh winhttp show proxy ``` Benutzerbezogene Windows-Proxyeinstellungen: ```powershell [RO] Get-ItemProperty ` 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' | Select-Object ProxyEnable, ProxyServer, AutoConfigURL ``` **Linux** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **macOS** ```bash [RO] scutil --proxy ``` Proxykonfiguration eines bestimmten Netzwerkdienstes: ```bash [RO] networksetup -getwebproxy "Wi-Fi" ``` ```bash [RO] networksetup -getsecurewebproxy "Wi-Fi" ``` **Zu beachten** - Anwendungen können eigene Proxyeinstellungen verwenden. - Umgebungsvariablen können benutzer- oder prozessbezogen sein. - PAC-Dateien können das Ziel dynamisch unterschiedlichen Proxys zuordnen. - WinHTTP- und Benutzer-Proxyeinstellungen können voneinander abweichen. - Ein Browser kann Richtlinien oder eigene Mechanismen verwenden. - `NO_PROXY` beziehungsweise Bypasslisten beeinflussen den tatsächlichen Weg. Ein Proxy muss daher als eigene Komponente in den Kommunikationsweg aufgenommen werden.
15. Wie wird eine Störungsmatrix erstellt? Eine Störungsmatrix macht Muster sichtbar. | Test | CLIENT-023 | CLIENT-024 | CLIENT-025 | |---|---:|---:|---:| | Gateway erreichbar | Ja | Ja | Ja | | DNS-Auflösung | Ja | Ja | Ja | | Ziel-IP erreichbar | Ja | Ja | Ja | | TCP 443 erreichbar | Nein | Ja | Ja | | Anwendung funktioniert | Nein | Ja | Ja | | Internetzugriff | Ja | Ja | Ja | | VLAN | 20 | 20 | 30 | | Betriebssystem | Windows | Windows | Linux | **Erste Einordnung** Da nur `CLIENT-023` betroffen ist und andere Clients denselben Zielport erreichen, sind folgende Bereiche wahrscheinlicher: - lokale Host-Firewall, - Sicherheitssoftware, - falsche lokale Route, - VPN- oder Proxykonfiguration, - clientbezogene Netzwerkzugriffsregel, - fehlerhafte Quelladresszuordnung. Eine allgemeine Störung des Zielservers ist anhand dieser Matrix weniger wahrscheinlich, aber noch nicht vollständig ausgeschlossen.
16. Wie wird eine Zeitlinie der Störung erstellt? | Zeitpunkt | Ereignis | |---|---| | 09:30 | VPN-Client-Update abgeschlossen | | 09:35 | letzter erfolgreicher Anwendungszugriff | | 09:40 | Client wurde neu gestartet | | 09:42 | erster fehlgeschlagener Zugriff | | 09:45 | Fehler im Ticket gemeldet | | 09:50 | anderer Client erfolgreich getestet | | 09:55 | DNS-Auflösung erfolgreich geprüft | | 10:00 | TCP-Porttest schlägt fehl | **Auswertung** Die zeitliche Nähe zwischen VPN-Update und Störung erzeugt eine prüfbare Hypothese. Sie beweist jedoch noch nicht, dass das Update die Ursache ist. Zu prüfen wären beispielsweise: - neue virtuelle Schnittstelle, - geänderte Routingtabelle, - geänderte DNS-Server, - aktivierter Always-on-Tunnel, - neue lokale Filterregeln, - veränderte Proxykonfiguration.
17. Welche typischen Fehlschlüsse müssen vermieden werden? | Beobachtung | Unzulässiger Schluss | Richtige Einordnung | |---|---|---| | ein Benutzer meldet den Fehler | nur ein Benutzer ist betroffen | Umfang aktiv prüfen | | Ping funktioniert | Anwendung funktioniert | nur ICMP-Erreichbarkeit bestätigt | | Ping funktioniert nicht | Host ist offline | ICMP kann blockiert sein | | DNS liefert eine Adresse | DNS ist vollständig korrekt | Adresse und verwendete Antwort prüfen | | Port 443 ist erreichbar | Webanwendung ist fehlerfrei | nur TCP-Verbindungsaufbau bestätigt | | Traceroute zeigt Sterne | dort liegt der Fehler | Hop antwortet möglicherweise nur nicht | | anderer Client funktioniert | Zielserver ist fehlerfrei | clientspezifischer oder intermittierender Fehler möglich | | direkter Backendtest funktioniert | gesamter Dienstpfad funktioniert | Proxy, Load Balancer und DNS fehlen im Test | | Fehler trat nach Update auf | Update ist die Ursache | zeitlicher Zusammenhang ist nur ein Hinweis | | nur WLAN betroffen | Access Point ist defekt | Funk, Authentifizierung, VLAN und Client prüfen | | hohe Latenz an einem Hop | dieser Router verursacht Verzögerung | Antwortpriorisierung kann abweichen |
18. Welche Informationen werden an die nächste Diagnosephase übergeben? Nach der ersten Eingrenzung sollten folgende Ergebnisse vorliegen: ```text Störungsumfang: Nur CLIENT-023 betroffen. Quelle: CLIENT-023 192.0.2.10/24 LAN VLAN 20 Ziel: app.example.intern 198.51.100.20 TCP 443 Erwarteter Weg: CLIENT-023 → SW-01 → Gateway 192.0.2.1 → FW-01 → Reverse Proxy → APP-01 Funktioniert: - Link vorhanden - gültige IP-Adresse - Gateway erreichbar - DNS-Auflösung erfolgreich - andere interne und externe Ziele erreichbar Funktioniert nicht: - TCP-Verbindung zum Zielport 443 Vergleich: CLIENT-024 im selben VLAN erreicht das Ziel. Änderung: VPN-Client wurde kurz vorher aktualisiert. Arbeitshypothese: Lokale Route, VPN-Filter oder Host-Firewall auf CLIENT-023. Nächste Diagnosephase: Physische Schnittstelle, IP-Konfiguration und ausgewählte Route des Clients vollständig prüfen. ``` Damit beginnt die nächste Seite: ```text 3.2 Physische Verbindung und Netzwerkschnittstelle prüfen ```
19. Dokumentationsvorlage ```text Ticketnummer: Bearbeitungsbeginn: Bearbeitende Person: Priorität: Fehlerbeschreibung: Exakte Fehlermeldung: Fehlerbeginn: Letzter funktionierender Zeitpunkt: Zeitzone: Reproduzierbar: Ja / Nein BETROFFENER UMFANG Benutzer: Endgeräte: Switchports: VLANs: Standorte: Dienste: Zielsysteme: Nicht betroffen: QUELLE Hostname: Betriebssystem: Benutzer: Verbindungsart: Schnittstelle: MAC-Adresse: IPv4-Adresse und Präfix: IPv6-Adresse und Präfix: Standardgateway: DNS-Server: VLAN: VPN: Proxy: ZIEL Dienstname: URL oder Freigabe: Hostname: IPv4-Adresse: IPv6-Adresse: Transportprotokoll: Port: Anwendungsprotokoll: Load Balancer: Reverse Proxy: Backend: Weitere Abhängigkeiten: ERWARTETER KOMMUNIKATIONSWEG 1. 2. 3. 4. 5. 6. VERGLEICHSTESTS Gleicher Client, anderes Ziel: Anderer Client, gleiches Ziel: IP-Adresse statt Name: LAN statt WLAN: Ohne VPN: Anderer Benutzer: Referenzsystem: FUNKTIONIERT WEITERHIN - - - FUNKTIONIERT NICHT - - - ZEITLINIE Zeitpunkt: Ereignis: Zeitpunkt: Ereignis: Kürzliche Änderungen: Arbeitshypothese: Begründung: Nächster Prüfschritt: Eskalation erforderlich: Ja / Nein ```
20. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetTCPConnection](https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [netsh winhttp](https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-winhttp) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [getent – Linux Manual Page](https://man7.org/linux/man-pages/man1/getent.1.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man scutil` und `man networksetup` - [Apple Platform Deployment – Network Services](https://support.apple.com/guide/deployment/network-services-dep2d2d2d2d2/web) > Der erwartete Kommunikationsweg muss anhand der tatsächlich eingesetzten Netzwerkarchitektur dokumentiert werden. Beispieladressen und Komponentennamen dürfen nicht ungeprüft auf eine produktive Umgebung übertragen werden.
# 3.2 Physische Verbindung und Netzwerkschnittstelle prüfen Auf der untersten Netzwerkebene wird geprüft, ob zwischen Endgerät und nächster Netzwerkkomponente eine technisch funktionsfähige Verbindung besteht. Dazu gehören Kabel, Stecker, Transceiver, Switchport, WLAN-Signal, Netzwerkkarte, Treiber, Linkstatus, Geschwindigkeit, Duplexmodus und Fehlerzähler. > **Grundregel:** Ein angezeigter Link beweist nur, dass die beteiligten Schnittstellen eine physische beziehungsweise logische Verbindung erkannt haben. Er beweist nicht, dass VLAN, IP-Konfiguration, Routing oder Anwendungen funktionieren. ---
1. Welche Komponenten gehören zur physischen Verbindung? **Kupfer-Ethernet** ```text Endgerät → Netzwerkkarte → RJ45-Stecker → Patchkabel → Netzwerkdose → Gebäudeverkabelung → Patchpanel → Patchkabel → Switchport ``` **Glasfaserverbindung** ```text Gerät → Netzwerkkarte → Transceiver → Glasfaserkabel → Patchfeld → Glasfaserstrecke → Transceiver → Switchport ``` **WLAN-Verbindung** ```text Client → WLAN-Adapter → Funkverbindung → Access Point → Ethernet-Uplink → Switchport ``` Jede Komponente kann vollständig ausfallen oder die Verbindung nur zeitweise beeinträchtigen.
2. Welche Symptome sprechen für einen Fehler auf Layer 1 oder am Netzwerkadapter? - kein Linkstatus, - Adapter wird vom Betriebssystem nicht erkannt, - Verbindung wechselt zwischen aktiv und getrennt, - ausgehandelte Geschwindigkeit ist unerwartet niedrig, - Halbduplex statt Vollduplex, - steigende CRC-, Frame- oder Carrier-Fehler, - steigende Paketverluste direkt an der Schnittstelle, - Verbindung bricht bei Bewegung des Kabels ab, - Switchport meldet häufige Link-Up- und Link-Down-Ereignisse, - Transceiver wird nicht erkannt, - Schnittstelle wird durch Energiesparfunktionen deaktiviert, - Treiber startet wiederholt neu, - nur dieser Switchport oder dieses Kabel ist betroffen, - Datendurchsatz ist deutlich geringer als bei einer Vergleichsverbindung. Einzelne ältere Fehlerzähler beweisen keine aktuelle Störung. Entscheidend ist, ob die Zähler während des Fehlerzeitraums weiter ansteigen.
3. Welche Sichtprüfung sollte zuerst durchgeführt werden? | Prüfung | Fragestellung | |---|---| | Kabel | Ist es geknickt, beschädigt, gequetscht oder ungewöhnlich gespannt? | | Stecker | Sitzt der Stecker vollständig und rastet er ein? | | Netzwerkdose | Ist die richtige und dokumentierte Dose verbunden? | | Patchpanel | Ist die Zuordnung zum Switchport korrekt? | | Switchport | Leuchtet beziehungsweise blinkt die Linkanzeige? | | Netzwerkkarte | Wird ein Link angezeigt? | | Transceiver | Sitzt das Modul vollständig im Steckplatz? | | Glasfaser | Stimmen Fasertyp und Transceivertyp überein? | | Dockingstation | Ist sie mit Strom versorgt und korrekt verbunden? | | USB-Adapter | Wird er vom Betriebssystem erkannt? | | Access Point | Ist der Client tatsächlich mit dem erwarteten AP verbunden? | **Sicherheitsregeln bei Glasfaser** - Niemals direkt in einen Glasfaseranschluss oder Transceiver sehen. - Schutzkappen nicht unnötig entfernen. - Steckerflächen nicht berühren. - Reinigungs- und Prüfverfahren des Herstellers beachten. - Transceiver nicht während einer unklaren produktiven Verbindung entfernen. ```text [CHANGE][DISRUPT] Das Entfernen eines Kabels oder Transceivers unterbricht die Verbindung. ```
4. Was bedeuten Linkstatus, administrativer Status und Betriebsstatus? | Zustand | Bedeutung | |---|---| | administrativ aktiviert | Schnittstelle darf grundsätzlich verwendet werden | | administrativ deaktiviert | Schnittstelle wurde durch Konfiguration abgeschaltet | | Link erkannt | physische beziehungsweise logische Gegenstelle wurde erkannt | | betriebsbereit | Betriebssystem bewertet die Schnittstelle als verwendbar | | verbunden | kann zusätzlich eine höhere logische Verbindung bezeichnen | | getrennt | kein nutzbarer Link oder Dienst | | unbekannt | Treiber oder Betriebssystem liefert keine eindeutige Information | **Linux-Beispiel** ```text ``` | Kennzeichnung | Bedeutung | |---|---| | `UP` | Schnittstelle ist administrativ aktiviert | | `LOWER_UP` | untere Ebene meldet einen aktiven Link | | `RUNNING` | Schnittstelle wird als betriebsbereit gemeldet | Eine Schnittstelle kann administrativ `UP` sein, obwohl kein Kabel angeschlossen und kein physischer Link vorhanden ist.
5. Wie wird der Adapterstatus unter Windows geprüft? **Alle sichtbaren Netzwerkadapter** ```powershell [RO] Get-NetAdapter | Sort-Object Name | Format-Table Name, InterfaceDescription, ifIndex, Status, LinkSpeed, MacAddress ``` **Auch ausgeblendete Adapter anzeigen** ```powershell [RO] Get-NetAdapter -IncludeHidden | Sort-Object Name | Format-Table Name, InterfaceDescription, ifIndex, Status, LinkSpeed, MacAddress ``` **Bestimmten Adapter vollständig anzeigen** ```powershell [RO] Get-NetAdapter -Name 'Ethernet' | Format-List * ``` **Physische Adapter anzeigen** ```powershell [RO] Get-NetAdapter -Physical | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Grafische Adapterübersicht öffnen** ```cmd [RO] ncpa.cpl ``` **Wichtige Felder** | Feld | Bedeutung | |---|---| | `Name` | logischer Windows-Adaptername | | `InterfaceDescription` | Hersteller- oder Treiberbezeichnung | | `ifIndex` | Schnittstellenindex | | `Status` | aktueller Adapterstatus | | `LinkSpeed` | gemeldete Verbindungsgeschwindigkeit | | `MacAddress` | Hardwareadresse des Adapters | Virtuelle Adapter, VPN-Adapter und Hypervisorinterfaces müssen von der tatsächlich verwendeten physischen Schnittstelle unterschieden werden.
6. Wie werden Windows-Adapterstatistiken untersucht? **Grundlegende Statistiken** ```powershell [RO] Get-NetAdapterStatistics ``` **Bestimmten Adapter vollständig anzeigen** ```powershell [RO] Get-NetAdapterStatistics -Name 'Ethernet' | Format-List * ``` **Kompakte Übersicht** ```powershell [RO] Get-NetAdapterStatistics -Name 'Ethernet' | Select-Object Name, ReceivedBytes, ReceivedUnicastPackets, ReceivedDiscardedPackets, ReceivedPacketErrors, SentBytes, SentUnicastPackets, OutboundDiscardedPackets, OutboundPacketErrors ``` **Zähler zu zwei Zeitpunkten vergleichen** ```powershell [RO] $Vorher = Get-NetAdapterStatistics -Name 'Ethernet' Start-Sleep -Seconds 30 $Nachher = Get-NetAdapterStatistics -Name 'Ethernet' [PSCustomObject]@{ ZeitraumSekunden = 30 EmpfangeneBytes = $Nachher.ReceivedBytes - $Vorher.ReceivedBytes GesendeteBytes = $Nachher.SentBytes - $Vorher.SentBytes Empfangsfehler = $Nachher.ReceivedPacketErrors - $Vorher.ReceivedPacketErrors Sendefehler = $Nachher.OutboundPacketErrors - $Vorher.OutboundPacketErrors Empfangsverwerfungen = $Nachher.ReceivedDiscardedPackets - $Vorher.ReceivedDiscardedPackets Sendeverwerfungen = $Nachher.OutboundDiscardedPackets - $Vorher.OutboundDiscardedPackets } ``` `Start-Sleep` verändert keine Netzwerkkonfiguration, verlängert aber die Ausführung der Messung. Die Zähler werden nur gelesen. **Bewertung** | Zähler | Mögliche Bedeutung | |---|---| | `ReceivedPacketErrors` steigt | fehlerhafte empfangene Pakete oder Frames | | `OutboundPacketErrors` steigt | Fehler beim Senden | | `ReceivedDiscardedPackets` steigt | Pakete wurden trotz möglicher Fehlerfreiheit verworfen | | `OutboundDiscardedPackets` steigt | ausgehende Pakete wurden verworfen | | Bytes steigen nicht | möglicherweise keine Aktivität oder falscher Adapter | Die genaue Herkunft einzelner Zähler hängt vom Netzwerktreiber und Adapter ab.
7. Wie werden Windows-Treiber und erweiterte Adaptereigenschaften geprüft? **Treiberinformationen des Adapters** ```powershell [RO] Get-NetAdapter -Name 'Ethernet' | Select-Object Name, InterfaceDescription, DriverInformation, DriverFileName, DriverVersion, DriverDate ``` Falls die Treiberdetails in der Ausgabe des eingesetzten Systems nicht vollständig bereitgestellt werden: ```powershell [RO] Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceClass -eq 'NET' | Select-Object DeviceName, Manufacturer, DriverProviderName, DriverVersion, DriverDate, IsSigned ``` **Erweiterte Eigenschaften anzeigen** ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' ``` **Energiespareinstellungen anzeigen** ```powershell [RO] Get-NetAdapterPowerManagement -Name 'Ethernet' ``` **Hardwarestatus über den Geräte-Manager** ```cmd [RO] devmgmt.msc ``` Zu prüfen sind: - Warnsymbol am Gerät, - Gerätestatus, - Treiberversion, - Treiberdatum, - Hersteller, - Energieverwaltung, - Ereignisse des Geräts. Erweiterte Eigenschaften besitzen je nach Hersteller, Treiber und Sprache unterschiedliche Namen. Werte dürfen nicht anhand fremder Beispiele ungeprüft verändert werden. ```text [CHANGE][DISRUPT] Änderungen an Geschwindigkeit, Duplex, Offloading, Puffern oder Energieverwaltung können die Verbindung unterbrechen oder die Leistung verschlechtern. ```
8. Wie wird der Linkstatus unter Linux geprüft? **Kurzübersicht aller Schnittstellen** ```bash [RO] ip -brief link ``` **Bestimmte Schnittstelle** ```bash [RO] ip link show dev eth0 ``` **Linkstatus aus sysfs** ```bash [RO] cat /sys/class/net/eth0/operstate ``` ```bash [RO] cat /sys/class/net/eth0/carrier ``` Typische Ausgabe von `carrier`: | Wert | Bedeutung | |---:|---| | `1` | Link beziehungsweise Carrier erkannt | | `0` | kein Carrier erkannt | Der Zugriff kann abhängig von Treiber, Interfacezustand und Berechtigungen fehlschlagen. **Schnittstellenereignisse live beobachten** ```bash [RO] ip monitor link ``` Beenden mit: ```text Strg+C ``` Damit können Link-Up-, Link-Down- und andere Schnittstellenänderungen während der Fehlerreproduktion beobachtet werden.
9. Wie werden Geschwindigkeit, Duplex und Autonegotiation unter Linux geprüft? Falls `ethtool` installiert ist: ```bash [RO][PRIV] sudo ethtool eth0 ``` Typische relevante Felder: ```text Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Link detected: yes ``` | Feld | Bedeutung | |---|---| | `Supported link modes` | vom Adapter unterstützte Modi | | `Advertised link modes` | der Gegenstelle angebotene Modi | | `Link partner advertised link modes` | von der Gegenstelle angebotene Modi | | `Speed` | ausgehandelte Geschwindigkeit | | `Duplex` | Halb- oder Vollduplex | | `Auto-negotiation` | automatische Aushandlung aktiv oder inaktiv | | `Port` | physischer Medientyp | | `Link detected` | Link erkannt | **Treiber- und Firmwareinformationen** ```bash [RO][PRIV] sudo ethtool -i eth0 ``` **Treiberstatistiken** ```bash [RO][PRIV] sudo ethtool -S eth0 ``` **Pause-Frame-Einstellungen anzeigen** ```bash [RO][PRIV] sudo ethtool -a eth0 ``` **Energy Efficient Ethernet anzeigen** ```bash [RO][PRIV] sudo ethtool --show-eee eth0 ``` Nicht jeder Treiber unterstützt alle Abfragen. Eine Meldung wie `Operation not supported` kann bedeuten, dass Adapter oder Treiber die entsprechende Funktion nicht bereitstellen.
10. Wie werden Linux-Schnittstellenfehler und Verwerfungen geprüft? **Standardstatistiken anzeigen** ```bash [RO] ip -s link show dev eth0 ``` Detailliertere Standardstatistiken: ```bash [RO] ip -s -s link show dev eth0 ``` Beispielstruktur: ```text RX: bytes packets errors dropped missed mcast TX: bytes packets errors dropped carrier collsns ``` **Zähler aus sysfs** ```bash [RO] grep . /sys/class/net/eth0/statistics/* ``` Ausgewählte Zähler: ```bash [RO] for Datei in \ rx_packets rx_bytes rx_errors rx_dropped \ tx_packets tx_bytes tx_errors tx_dropped \ collisions; do printf '%-20s ' "$Datei" cat "/sys/class/net/eth0/statistics/$Datei" done ``` **Zweimal messen** ```bash [RO] ip -s link show dev eth0 ``` Fehler reproduzieren oder einen definierten Zeitraum abwarten: ```bash [RO] ip -s link show dev eth0 ``` Nur wenn sich ein Fehlerzähler im relevanten Zeitraum erhöht, besteht ein zeitlicher Zusammenhang zur aktuellen Störung.
11. Wie werden Link- und Treibermeldungen unter Linux gesucht? **Kernelmeldungen des aktuellen Starts** ```bash [RO][PRIV] sudo journalctl -k -b ``` Nach typischen Netzwerkmeldungen suchen: ```bash [RO][PRIV] sudo journalctl -k -b | grep -Ei 'link.*(up|down)|carrier|duplex|firmware|eth|network|reset|timeout' ``` **Meldungen einer bestimmten Schnittstelle** ```bash [RO][PRIV] sudo journalctl -k -b | grep -F 'eth0' ``` **NetworkManager-Protokoll** ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager ``` **systemd-networkd-Protokoll** ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd ``` Je nach Distribution und Netzwerkkonfiguration wird nur einer dieser Dienste verwendet. Die tatsächliche Netzwerkverwaltung muss auf dem System bestimmt werden. Typische Hinweise: - `Link is Down`, - `Link is Up`, - `NIC Link is Down`, - Firmware konnte nicht geladen werden, - Adapter wurde zurückgesetzt, - Übertragung ist abgelaufen, - Verbindung wurde neu ausgehandelt.
12. Wie wird der Schnittstellenstatus unter macOS geprüft? **Hardwareports und Gerätenamen zuordnen** ```bash [RO] networksetup -listallhardwareports ``` Beispiel: ```text Hardware Port: Ethernet Device: en0 Ethernet Address: 00:11:22:33:44:55 ``` **Alle Schnittstellen anzeigen** ```bash [RO] ifconfig ``` **Bestimmte Schnittstelle anzeigen** ```bash [RO] ifconfig en0 ``` Wichtige Felder: | Feld | Bedeutung | |---|---| | `status: active` | Link beziehungsweise Dienst ist aktiv | | `status: inactive` | kein aktiver Link | | `ether` | MAC-Adresse | | `media` | aktuelles Medium und ausgehandelter Modus | | `mtu` | Maximum Transmission Unit | | `RX`/`TX`-Informationen | abhängig von Befehl und Ausgabe | **Status eines Netzwerkdienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` Der Dienstname muss vorher mit folgendem Befehl ermittelt werden: ```bash [RO] networksetup -listallnetworkservices ``` **Medienstatus** ```bash [RO] networksetup -getMedia "Ethernet" ``` Die Verfügbarkeit und Ausgabe von `-getMedia` hängen vom Adapter, Treiber und Netzwerkdienst ab.
13. Wie werden Schnittstellenzähler unter macOS geprüft? **Interfaceübersicht mit Zählern** ```bash [RO] netstat -ib ``` Nur eine bestimmte Schnittstelle: ```bash [RO] netstat -ib -I en0 ``` Regelmäßig aktualisierte Anzeige: ```bash [RO] netstat -w 1 -I en0 ``` Beenden mit: ```text Strg+C ``` Je nach macOS-Version enthält die Ausgabe unter anderem: - eingehende Pakete, - eingehende Fehler, - eingehende Bytes, - ausgehende Pakete, - ausgehende Fehler, - ausgehende Bytes, - Kollisionen, - Drops. **Systembericht zur Netzwerkkonfiguration** ```bash [RO][SENS] system_profiler SPNetworkDataType ``` Der Systembericht kann interne Netzwerk-, Geräte- und Dienstinformationen enthalten und sollte bei einer Weitergabe entsprechend behandelt werden.
14. Wie werden Geschwindigkeit und Duplex richtig bewertet? **Beispiel einer erwarteten Verbindung** ```text Endgerät: Gigabit-Ethernet Switchport: Gigabit-Ethernet Kabel: für Gigabit geeignet Erwartung: 1000 Mbit/s, Full Duplex Gemessen: 100 Mbit/s, Full Duplex ``` Mögliche Ursachen: - beschädigtes oder unvollständig aufgelegtes Kabel, - nicht geeignete Verkabelung, - Switchport auf 100 Mbit/s begrenzt, - USB-Adapter unterstützt nur Fast Ethernet, - Dockingstation oder Zwischenadapter begrenzt die Geschwindigkeit, - manuell erzwungene Einstellung, - Aushandlungsproblem. **Duplex-Mismatch** Ein Duplex-Mismatch kann entstehen, wenn eine Seite fest auf Vollduplex gestellt ist, während die andere Seite anders konfiguriert ist oder keine passende Aushandlung erfolgt. Mögliche Symptome: - geringer Durchsatz, - Kollisionen beziehungsweise Late Collisions, - Framefehler, - gute Leistung in eine Richtung und schlechte in die andere, - stark schwankende Antwortzeiten. **Empfehlung** Bei modernen Ethernetverbindungen sollte Autonegotiation normalerweise auf beiden Seiten konsistent verwendet werden. Eine manuelle Einstellung darf nur entsprechend Herstellerdokumentation und abgestimmt auf beiden Seiten vorgenommen werden. ```text [CHANGE][DISRUPT] Geschwindigkeit und Duplex nicht einseitig und nicht ohne dokumentierten Rückweg verändern. ```
15. Wie werden Fehlerzähler richtig interpretiert? | Zähler | Mögliche technische Bedeutung | |---|---| | RX Errors | allgemeine Empfangsfehler | | TX Errors | allgemeine Sendefehler | | CRC Errors | Frame-Prüfsumme stimmt nicht | | Frame Errors | ungültige Frameausrichtung oder Rahmenfehler | | Length Errors | unerwartete Frame- beziehungsweise Paketlänge | | Dropped/Discards | Paket wurde verworfen | | Overruns | Puffer oder Verarbeitung konnte Daten nicht rechtzeitig übernehmen | | Missed | Adapter oder Treiber konnte Pakete nicht übernehmen | | Carrier Errors | Trägersignalproblem beim Senden | | Collisions | Kollisionen im Halbduplexbetrieb | | Late Collisions | verspätete Kollisionen, häufig Hinweis auf Duplex- oder Segmentproblem | | FEC Corrected | Fehler wurden durch Forward Error Correction korrigiert | | FEC Uncorrectable | Fehler konnten durch FEC nicht korrigiert werden | | Link Down Events | Anzahl erkannter Linkabbrüche | **Wichtige Einschränkungen** - Nicht jeder Treiber stellt alle Zähler bereit. - Gleichnamige Zähler können je nach Hersteller unterschiedlich detailliert sein. - Ein Gesamtwert seit dem letzten Neustart enthält möglicherweise alte Ereignisse. - Zähler können bei Neustart, Treiberneustart oder Gerätewechsel zurückgesetzt werden. - `Dropped` bedeutet nicht automatisch einen physischen Kabeldefekt. - Software, Pufferknappheit und Überlastung können ebenfalls Verwerfungen erzeugen. **Geeignete Messung** ```text 1. Ausgangswerte notieren. 2. Fehler reproduzieren. 3. Zähler erneut erfassen. 4. Differenz berechnen. 5. Gegenseite im selben Zeitraum prüfen. ```
16. Warum müssen beide Seiten einer Ethernetverbindung geprüft werden? Eine Verbindung besitzt zwei Enden: ```text Client-NIC ←→ Switchport ``` Ein Client kann beispielsweise nur Empfangsfehler melden, während der Switch Sendefehler oder Linkabbrüche protokolliert. Auf beiden Seiten sollten geprüft werden: | Client | Switch | |---|---| | Linkstatus | Portstatus | | Geschwindigkeit | ausgehandelte Geschwindigkeit | | Duplex | ausgehandelter Duplexmodus | | RX-Fehler | TX-Fehler | | TX-Fehler | RX-Fehler | | Drops | Discards | | Treibermeldungen | Port- und Systemlogs | | MAC-Adresse | gelernte MAC-Adresse | | Verbindungszeitpunkt | letzte Linkänderung | | Adaptermodell | Port- und Transceivertyp | Die konkreten Switchbefehle unterscheiden sich je nach Hersteller und Betriebssystem. Sie dürfen nicht aus Beispielen anderer Plattformen übernommen werden.
17. Wie wird ein Kabel- oder Portfehler durch einen Vergleichstest eingegrenzt? **Ausgangslage** ```text CLIENT-023 verliert wiederholt den Link. ``` **Kontrollierter Vergleich** | Test | Geänderter Faktor | Ergebnisinterpretation | |---|---|---| | bekannt funktionierendes Patchkabel | Patchkabel | Fehler verschwindet: ursprüngliches Kabel verdächtig | | anderer freigegebener Switchport | Switchport und möglicherweise Konfiguration | Fehler verschwindet: Port oder Portkonfiguration prüfen | | anderer Client am selben Kabel | Endgerät | Fehler bleibt: Kabel, Dose oder Port wahrscheinlicher | | gleicher Client an anderer Dose | Gebäudestrecke und Port | Fehler verschwindet: ursprüngliche Strecke prüfen | | USB-Adapter statt interner NIC | Netzwerkadapter | Fehler verschwindet: interne NIC oder Treiber prüfen | **Wichtig** - Der Ersatz muss für Geschwindigkeit und Medientyp geeignet sein. - Ein anderer Switchport kann einem anderen VLAN zugeordnet sein. - Ein Portwechsel muss genehmigt und dokumentiert werden. - Kabel und Ports dürfen nicht wahllos aus produktiven Verbindungen entfernt werden. - Nach dem Test muss der vorgesehene Zustand wiederhergestellt werden. ```text [CHANGE][DISRUPT] Kabel- und Portwechsel unterbrechen bestehende Verbindungen. ```
18. Wie werden Dockingstationen und USB-Netzwerkadapter untersucht? Zusätzliche mögliche Fehlerstellen: ```text Notebook → USB-C- beziehungsweise Thunderbolt-Port → Dockingstation → interner Netzwerkadapter → RJ45-Port → Netzwerkkabel ``` Zu prüfen sind: - Stromversorgung der Dockingstation, - verwendeter Notebookanschluss, - USB-C- oder Thunderbolt-Verbindung, - Firmware der Dockingstation, - Treiber des integrierten Netzwerkadapters, - Linkgeschwindigkeit, - Energiesparzustand, - Verhalten nach Standby, - Vergleich ohne Dockingstation, - Vergleich mit einem freigegebenen Ersatzadapter. **Typische Symptome** - Adapter verschwindet nach dem Aufwachen, - Link wird erkannt, aber regelmäßig neu ausgehandelt, - Geschwindigkeit ist auf 100 Mbit/s begrenzt, - MAC-Adresse ändert sich, - Verbindung bricht bei hoher Last ab, - mehrere Geräte an der Dockingstation fallen gleichzeitig aus. Ein Treiber- oder Firmwareupdate sollte nur nach Prüfung von Modell, Hardwareversion, Herstellerdokumentation, Freigabe und Rückweg erfolgen.
19. Wie werden Energieverwaltung und Ruhezustand als Ursache geprüft? Mögliche Hinweise: - Fehler tritt nach Standby oder Ruhezustand auf, - Link ist nach dem Aufwachen vorhanden, aber keine Kommunikation möglich, - Adapter verschwindet zeitweise, - Verbindung funktioniert nach Adapterneustart wieder, - Dockingstation muss neu verbunden werden, - Ereignisprotokoll zeigt Treiber- oder Energieereignisse. **Windows-Einstellungen nur anzeigen** ```powershell [RO] Get-NetAdapterPowerManagement -Name 'Ethernet' ``` **Windows-Ereignisse des Netzwerkadapters suchen** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.ProviderName -match 'NDIS|Kernel-PnP|Netwtw|e1d|e2f|Network' } | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message ``` Providernamen unterscheiden sich je nach Adapter und Treiber. Der Filter ist deshalb nur eine erste Suche. **Linux** ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'suspend|resume|link.*(up|down)|network|firmware' ``` **macOS** ```bash [RO] pmset -g log | grep -Ei 'sleep|wake' ``` Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, solange der Zusammenhang nicht belegt ist.
20. Warum sollten Offloading-Funktionen nicht vorschnell deaktiviert werden? Netzwerkadapter können bestimmte Aufgaben in Hardware oder Treiber ausführen: - Checksum Offload, - Large Send Offload, - Receive Segment Coalescing, - Receive Side Scaling, - VLAN-Offload, - IPsec-Offload, - Generic Segmentation Offload, - Generic Receive Offload. Diese Funktionen können CPU-Last reduzieren und den Durchsatz erhöhen. Gleichzeitig können sie die Darstellung in einem lokalen Paketmitschnitt beeinflussen. Beispielsweise kann Wireshark auf dem sendenden Host scheinbar ungültige Prüfsummen anzeigen, obwohl die korrekte Prüfsumme erst später vom Netzwerkadapter berechnet wird. ```text Angezeigter Checksum-Fehler im lokalen Mitschnitt ≠ automatisch beschädigtes Paket im Netzwerk ``` Vor einer Änderung müssen geprüft werden: - Herstellerdokumentation, - Treiberversion, - bekannte Fehler, - Vergleichsmessung an einem externen Messpunkt, - Auswirkung auf Produktion, - Rückweg. ```text [CHANGE][DISRUPT] Offloading-Funktionen nicht pauschal als „Problemlösung“ deaktivieren. ```
21. Wann ist ein Adapterneustart sinnvoll und welches Risiko besteht? Ein Adapterneustart kann einen vorübergehend fehlerhaften Treiber- oder Gerätezustand beheben. Er beseitigt aber möglicherweise nur das Symptom und zerstört den ursprünglichen Diagnosezustand. **Vorher erfassen** - Adapterstatus, - IP-Konfiguration, - Routingtabelle, - Fehlerzähler, - Treiberversion, - Ereignisprotokolle, - laufende Verbindungen, - Zeitpunkt des letzten Linkwechsels. **Windows** ```powershell [PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet' ``` **Linux** ```bash [PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 down ``` ```bash [PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 up ``` **macOS** ```bash [PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down ``` ```bash [PRIV][CHANGE][DISRUPT] sudo ifconfig en0 up ``` > Bei einer Remoteverbindung kann der Administrator durch das Deaktivieren der verwendeten Schnittstelle den eigenen Zugriff verlieren. Ein Adapterneustart darf remote nur mit gesichertem alternativem Zugangsweg durchgeführt werden.
22. Welche systematische Prüfungsreihenfolge ist sinnvoll? | Schritt | Prüfung | |---:|---| | 1 | betroffene Schnittstelle eindeutig bestimmen | | 2 | Kabel, Stecker, Adapter und Linkanzeige kontrollieren | | 3 | administrativen und operativen Status abfragen | | 4 | ausgehandelte Geschwindigkeit und Duplex prüfen | | 5 | Ausgangswerte der Fehlerzähler dokumentieren | | 6 | Fehler reproduzieren oder definierten Zeitraum beobachten | | 7 | Fehlerzähler erneut abfragen und Differenzen bestimmen | | 8 | Treiber-, Kernel- und Switchprotokolle vergleichen | | 9 | Gegenstelle beziehungsweise Switchport prüfen | | 10 | bekannt funktionierendes Kabel oder Vergleichsgerät verwenden | | 11 | erst danach eine kontrollierte Änderung durchführen | | 12 | ursprüngliches Fehlerbild erneut testen | | 13 | Ergebnis und Rückweg dokumentieren | **Merksatz** ```text Ansehen → Status lesen → Zähler vergleichen → Gegenseite prüfen → kontrolliert tauschen → erneut messen ```
23. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] networksetup -listallhardwareports` | | physische Adapter | `[RO] Get-NetAdapter -Physical` | abhängig vom Gerätetyp | über Hardwareportzuordnung | | Adapterdetails | `[RO] Get-NetAdapter -Name 'Ethernet' \| Format-List *` | `[RO] ip link show dev eth0` | `[RO] ifconfig en0` | | Linkstatus | Feld `Status` | `[RO] cat /sys/class/net/eth0/carrier` | Feld `status` in `ifconfig en0` | | Geschwindigkeit | Feld `LinkSpeed` | `[RO][PRIV] sudo ethtool eth0` | `[RO] networksetup -getMedia "Ethernet"` | | Duplex | Adapterdetails beziehungsweise erweiterte Eigenschaften | `[RO][PRIV] sudo ethtool eth0` | Medienausgabe des Adapters | | Fehlerzähler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s -s link show dev eth0` | `[RO] netstat -ib -I en0` | | Treiberinformationen | `[RO] Get-NetAdapter \| Select Name,DriverInformation,DriverVersion` | `[RO][PRIV] sudo ethtool -i eth0` | `[RO][SENS] system_profiler SPNetworkDataType` | | Treiberstatistiken | `[RO] Get-NetAdapterStatistics -Name 'Ethernet' \| Format-List *` | `[RO][PRIV] sudo ethtool -S eth0` | abhängig vom Adaptertreiber | | erweiterte Eigenschaften | `[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'` | `[RO][PRIV] sudo ethtool eth0` | abhängig vom Adapter | | Energieverwaltung | `[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'` | Treiber- und Systemkonfiguration prüfen | `[RO] pmset -g` | | Linkereignisse | Windows-Systemprotokoll | `[RO] ip monitor link` | `[RO] log stream --style compact` | | Kernel-/Treiberlogs | `Get-WinEvent -LogName System` | `[RO][PRIV] sudo journalctl -k -b` | `[RO] log show --last 1h --style compact` | | Adapter neu starten | `[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'` | `[PRIV][CHANGE][DISRUPT] sudo ip link set eth0 down/up` | `[PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down/up` | Die Beispielnamen `Ethernet`, `eth0` und `en0` müssen durch die zuvor eindeutig ermittelte Schnittstelle ersetzt werden.
24. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffenes Gerät: Betriebssystem: Standort: Verbindungsart: SCHNITTSTELLE Adaptername: Schnittstellenindex: Adaptermodell: MAC-Adresse: Treiberanbieter: Treiberversion: Treiberdatum: Firmwareversion: Administrativer Status: Operativer Status: Link erkannt: Ja / Nein Geschwindigkeit: Duplex: Autonegotiation: MTU: Energy Efficient Ethernet: Energieverwaltung: PHYSISCHE STRECKE Endgeräteport: Adapter oder Dockingstation: Patchkabel: Netzwerkdose: Patchpanel: Switch: Switchport: VLAN: Transceivertyp: Fasertyp: Linkanzeige Client: Linkanzeige Switch: ZÄHLER VORHER Zeitpunkt: RX-Pakete: RX-Bytes: RX-Fehler: RX-Drops: CRC-Fehler: Framefehler: TX-Pakete: TX-Bytes: TX-Fehler: TX-Drops: Kollisionen: Link-Down-Ereignisse: ZÄHLER NACHHER Zeitpunkt: RX-Pakete: RX-Bytes: RX-Fehler: RX-Drops: CRC-Fehler: Framefehler: TX-Pakete: TX-Bytes: TX-Fehler: TX-Drops: Kollisionen: Link-Down-Ereignisse: DIFFERENZ UND BEWERTUNG - - - VERGLEICHSTEST Getauschte Komponente: Ausgangszustand dokumentiert: Erwartetes Ergebnis: Tatsächliches Ergebnis: Ursprünglicher Zustand wiederhergestellt: TREIBER- UND SWITCHMELDUNGEN - - - Arbeitshypothese: Beleg: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
25. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/get-netadapter) - [Get-NetAdapterStatistics](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterstatistics) - [Get-NetAdapterAdvancedProperty](https://learn.microsoft.com/powershell/module/netadapter/get-netadapteradvancedproperty) - [Get-NetAdapterPowerManagement](https://learn.microsoft.com/powershell/module/netadapter/get-netadapterpowermanagement) - [Restart-NetAdapter](https://learn.microsoft.com/powershell/module/netadapter/restart-netadapter) - [Erweiterte NIC-Eigenschaften](https://learn.microsoft.com/windows-server/networking/technologies/hpn/hpn-nic-advanced-properties) **Linux** - [Linux Interface Statistics – Kernel-Dokumentation](https://www.kernel.org/doc/html/latest/networking/statistics.html) - [ethtool-Netlink – Kernel-Dokumentation](https://docs.kernel.org/networking/ethtool-netlink.html) - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - Lokale Befehlsreferenz: `man ethtool` **Apple** - [Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-mchlp2291/mac) - [Netzwerkumgebungen auf dem Mac verwenden](https://support.apple.com/105129) - Lokale Befehlsreferenzen: `man ifconfig`, `man netstat`, `man networksetup`, `man system_profiler` und `man pmset` > Verfügbare Statistiken und Eigenschaften hängen vom Betriebssystem, Adapter, Treiber, Transceiver und Hersteller ab. Nicht angezeigte Zähler dürfen nicht als Wert null interpretiert werden.
# 3.3 IP-Konfiguration und Subnetz prüfen Nachdem die physische Verbindung und der Netzwerkadapter geprüft wurden, wird die logische IP-Konfiguration untersucht. Ein aktiver Link reicht nicht aus: Das Endgerät benötigt eine zum Netzwerk passende IPv4- oder IPv6-Adresse, eine korrekte Präfixlänge, geeignete Routen sowie gegebenenfalls ein Standardgateway und DNS-Server. > **Grundregel:** Die angezeigte IP-Konfiguration muss mit der vorgesehenen Netzwerkdokumentation verglichen werden. Eine formal gültige Adresse kann trotzdem für den konkreten Standort oder das zugewiesene VLAN falsch sein. ---
1. Welche Angaben gehören zu einer vollständigen IP-Konfiguration? **IPv4** - IPv4-Adresse, - Präfixlänge beziehungsweise Subnetzmaske, - Netzwerkadresse, - Broadcastadresse, - Standardgateway, - DNS-Server, - DHCP aktiviert oder statisch, - DHCP-Server, - Leasebeginn und Leaseende, - Schnittstelle, - Schnittstellenmetrik, - zusätzliche Routen. **IPv6** - globale oder organisationsinterne IPv6-Adresse, - Link-Local-Adresse, - Präfixlänge, - Standardrouter, - DNS-Server, - Adressquelle, - Gültigkeits- und Bevorzugungsdauer, - temporäre Adressen, - Schnittstellenindex beziehungsweise Scope-ID, - zusätzliche Routen. **Beispieldokumentation** ```text Schnittstelle: Ethernet MAC-Adresse: 00-11-22-33-44-55 VLAN: 20 IPv4-Adresse: 192.0.2.23 Präfixlänge: /24 Subnetzmaske: 255.255.255.0 Netzwerkadresse: 192.0.2.0 Broadcastadresse: 192.0.2.255 Standardgateway: 192.0.2.1 DNS-Server: 192.0.2.53, 192.0.2.54 Adressquelle: DHCP ```
2. Welche Symptome sprechen für eine fehlerhafte IP-Konfiguration? - Adresse aus einem unerwarteten Subnetz, - IPv4-Adresse aus `169.254.0.0/16`, - fehlende IPv4-Adresse, - doppelt vergebene IP-Adresse, - falsche Subnetzmaske oder Präfixlänge, - fehlendes oder falsches Standardgateway, - mehrere unerwartete Standardrouten, - falsche DNS-Server, - statische Adresse statt DHCP, - DHCP-Adresse statt vorgesehener statischer Adresse, - alte Konfiguration nach Standort- oder VLAN-Wechsel, - Gateway liegt nicht im direkt erreichbaren Subnetz, - falsche Quelladresse wird für das Ziel ausgewählt, - nur IPv4 oder nur IPv6 funktioniert, - virtuelle Schnittstelle besitzt eine günstigere Route, - VPN-Adapter übernimmt unerwartet den Datenverkehr.
3. Wie wird die IP-Konfiguration unter Windows angezeigt? **Kompakte PowerShell-Übersicht** ```powershell [RO] Get-NetIPConfiguration ``` **Vollständige klassische Ausgabe** ```cmd [RO][SENS] ipconfig /all ``` Die Ausgabe kann Hostname, MAC-Adressen, DNS-Suffixe, DHCP-Server und interne Netzwerkadressen enthalten. **Nur aktive Adapter mit IPv4-Konfiguration** ```powershell [RO] Get-NetIPConfiguration | Where-Object NetAdapter.Status -eq 'Up' | Select-Object InterfaceAlias, InterfaceIndex, IPv4Address, IPv4DefaultGateway, DNSServer ``` **Alle IP-Adressen anzeigen** ```powershell [RO] Get-NetIPAddress | Sort-Object InterfaceIndex, AddressFamily, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin, AddressState ``` **Nur IPv4-Adressen** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, AddressState ``` **Nur IPv6-Adressen** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv6 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, AddressState ``` **Standardrouten anzeigen** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric | Format-Table InterfaceAlias, ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ``` IPv6-Standardrouten: ```powershell [RO] Get-NetRoute -DestinationPrefix '::/0' | Sort-Object RouteMetric | Format-Table InterfaceAlias, ifIndex, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric ```
4. Wie wird die IP-Konfiguration unter Linux angezeigt? **Kompakte Adressübersicht** ```bash [RO] ip -brief address ``` **Ausführliche Adressübersicht** ```bash [RO] ip address show ``` **Bestimmte Schnittstelle** ```bash [RO] ip address show dev eth0 ``` **Nur IPv4** ```bash [RO] ip -4 address show ``` **Nur IPv6** ```bash [RO] ip -6 address show ``` **IPv4-Routingtabelle** ```bash [RO] ip -4 route ``` **IPv6-Routingtabelle** ```bash [RO] ip -6 route ``` **Route und ausgewählte Quelladresse zu einem Ziel** ```bash [RO] ip route get 198.51.100.20 ``` IPv6: ```bash [RO] ip -6 route get 2001:db8:20::20 ``` **NetworkManager-Verbindungen** Falls NetworkManager verwendet wird: ```bash [RO] nmcli connection show ``` Aktive Verbindungen: ```bash [RO] nmcli connection show --active ``` Geräteinformationen: ```bash [RO] nmcli device show ``` **systemd-networkd** Falls systemd-networkd verwendet wird: ```bash [RO] networkctl status ``` ```bash [RO] networkctl status eth0 ``` Nicht jede Linux-Installation verwendet NetworkManager oder systemd-networkd. Zuerst muss bestimmt werden, welche Komponente die Netzwerkkonfiguration verwaltet.
5. Wie wird die IP-Konfiguration unter macOS angezeigt? **Hardwareports und Gerätenamen** ```bash [RO] networksetup -listallhardwareports ``` **Alle Schnittstellen** ```bash [RO] ifconfig ``` **Bestimmte Schnittstelle** ```bash [RO] ifconfig en0 ``` **IPv4-Konfiguration eines Netzwerkdienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` Der tatsächliche Dienstname muss vorher ermittelt werden: ```bash [RO] networksetup -listallnetworkservices ``` **IPv4-Konfigurationsmethode** ```bash [RO] networksetup -getinfo "Wi-Fi" ``` **DNS-Konfiguration** ```bash [RO][SENS] scutil --dns ``` **IPv4-Routingtabelle** ```bash [RO] netstat -rn -f inet ``` **IPv6-Routingtabelle** ```bash [RO] netstat -rn -f inet6 ``` **Ausgewählte Route zu einem IPv4-Ziel** ```bash [RO] route -n get 198.51.100.20 ``` **Ausgewählte Route zu einem IPv6-Ziel** ```bash [RO] route -n get -inet6 2001:db8:20::20 ``` Die Dienstbezeichnung `Ethernet` oder `Wi-Fi` darf nicht ungeprüft übernommen werden. Sie kann auf einem konkreten Mac anders benannt sein.
6. Wie wird eine IPv4-Adresse einem Subnetz zugeordnet? **Beispiel** ```text IPv4-Adresse: 192.0.2.23 Präfix: /24 Subnetzmaske: 255.255.255.0 ``` Daraus ergibt sich: | Bestandteil | Wert | |---|---| | Netzwerkadresse | `192.0.2.0` | | erster typischer Host | `192.0.2.1` | | letzter typischer Host | `192.0.2.254` | | Broadcastadresse | `192.0.2.255` | | Gesamtzahl Adressen | 256 | | klassisch nutzbare Hostadressen | 254 | **Vergleich zweier Ziele** ```text Client: 192.0.2.23/24 Ziel A: 192.0.2.80 Ziel B: 198.51.100.20 ``` - Ziel A liegt im selben `/24`-Subnetz. - Ziel B liegt außerhalb dieses Subnetzes. - Ziel A wird normalerweise direkt über Layer 2 angesprochen. - Ziel B benötigt normalerweise eine passende Route beziehungsweise ein Gateway. **Wichtig** Die erste und letzte Adresse eines Subnetzes werden bei klassischer IPv4-Subnetznutzung als Netzwerk- und Broadcastadresse verwendet. Sonderfälle wie `/31` für Punkt-zu-Punkt-Verbindungen und `/32` für einzelne Hostrouten müssen gesondert betrachtet werden.
7. Wie werden Präfixlänge und Subnetzmaske umgerechnet? | Präfix | Subnetzmaske | Adressen insgesamt | klassisch nutzbare Hosts | |---:|---|---:|---:| | `/16` | `255.255.0.0` | 65.536 | 65.534 | | `/17` | `255.255.128.0` | 32.768 | 32.766 | | `/18` | `255.255.192.0` | 16.384 | 16.382 | | `/19` | `255.255.224.0` | 8.192 | 8.190 | | `/20` | `255.255.240.0` | 4.096 | 4.094 | | `/21` | `255.255.248.0` | 2.048 | 2.046 | | `/22` | `255.255.252.0` | 1.024 | 1.022 | | `/23` | `255.255.254.0` | 512 | 510 | | `/24` | `255.255.255.0` | 256 | 254 | | `/25` | `255.255.255.128` | 128 | 126 | | `/26` | `255.255.255.192` | 64 | 62 | | `/27` | `255.255.255.224` | 32 | 30 | | `/28` | `255.255.255.240` | 16 | 14 | | `/29` | `255.255.255.248` | 8 | 6 | | `/30` | `255.255.255.252` | 4 | 2 | | `/31` | `255.255.255.254` | 2 | Sonderfall für Punkt-zu-Punkt | | `/32` | `255.255.255.255` | 1 | einzelne Hostadresse | **Berechnung der Gesamtzahl** ```text 2 hoch (32 − Präfixlänge) ``` Beispiel `/27`: ```text 2 hoch (32 − 27) = 2 hoch 5 = 32 Adressen ``` Für gewöhnliche IPv4-Subnetze werden Netzwerk- und Broadcastadresse abgezogen: ```text 32 − 2 = 30 klassische Hostadressen ```
8. Wie wird eine falsche Subnetzmaske erkannt? **Vorgesehene Konfiguration** ```text Client: 192.0.2.130/25 Gateway: 192.0.2.129 ``` Das vorgesehene Subnetz lautet: ```text 192.0.2.128/25 ``` Adressbereich: ```text 192.0.2.128 bis 192.0.2.255 ``` **Fehlerhafte Konfiguration** ```text Client: 192.0.2.130/24 ``` Der Client hält nun den gesamten Bereich `192.0.2.0/24` für lokal. Ein Ziel wie `192.0.2.50` wird deshalb direkt per ARP gesucht, obwohl es nach der vorgesehenen Netzplanung in einem anderen Subnetz liegen kann. **Mögliche Symptome** - einzelne Ziele sind nicht erreichbar, - Gateway funktioniert, andere Subnetze jedoch nicht erwartungsgemäß, - ARP-Anfragen erscheinen für eigentlich entfernte Ziele, - Kommunikation funktioniert nur in eine Richtung, - ein Client verhält sich anders als Vergleichsclients, - Routing auf dem Client wirkt korrekt, die lokale Subnetzentscheidung ist aber falsch. Die Präfixlänge muss mit DHCP-Konfiguration, VLAN-Plan und Referenzsystemen verglichen werden.
9. Was bedeutet eine IPv4-Adresse aus 169.254.0.0/16? Windows und andere Betriebssysteme können eine IPv4-Link-Local-Adresse aus folgendem Bereich verwenden: ```text 169.254.0.0/16 ``` Unter Windows wird dies häufig als APIPA bezeichnet. Beispiel: ```text 169.254.73.22/16 ``` Das ist ein Hinweis darauf, dass keine reguläre IPv4-Konfiguration vorliegt beziehungsweise keine gewünschte DHCP-Konfiguration bezogen werden konnte. Die Adresse ermöglicht nur eingeschränkte lokale Kommunikation mit kompatibel konfigurierten Geräten im selben Link-Local-Bereich. **Mögliche Ursachen** - DHCP-Server nicht erreichbar, - falsches VLAN, - Switchport nicht korrekt konfiguriert, - DHCP-Relay fehlt oder funktioniert nicht, - DHCP-Bereich erschöpft, - DHCP-Verkehr wird gefiltert, - Netzwerkkabel wurde erst nach dem Start verbunden, - DHCP-Clientdienst arbeitet nicht, - Adapter oder Treiber ist fehlerhaft. **Windows-Prüfung** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Where-Object IPAddress -Like '169.254.*' ``` **Linux-Prüfung** ```bash [RO] ip -4 address show | grep '169\.254\.' ``` **macOS-Prüfung** ```bash [RO] ifconfig | grep '169\.254\.' ``` Eine Link-Local-Adresse sollte nicht durch eine willkürlich gewählte statische Adresse ersetzt werden. Zuerst muss die vorgesehene Adressvergabe geklärt werden.
10. Welche besonderen IPv4-Adressbereiche müssen erkannt werden? | Bereich | Zweck | |---|---| | `0.0.0.0` | nicht spezifizierte IPv4-Adresse | | `0.0.0.0/0` | Standardroute beziehungsweise alle IPv4-Ziele | | `127.0.0.0/8` | Loopback | | `169.254.0.0/16` | IPv4 Link-Local | | `10.0.0.0/8` | privater IPv4-Adressraum | | `172.16.0.0/12` | privater IPv4-Adressraum | | `192.168.0.0/16` | privater IPv4-Adressraum | | `100.64.0.0/10` | Shared Address Space, häufig für Carrier-Grade NAT | | `224.0.0.0/4` | Multicast | | `255.255.255.255` | Limited Broadcast | Die in diesem Buch verwendeten Bereiche `192.0.2.0/24`, `198.51.100.0/24` und `203.0.113.0/24` sind für Dokumentationsbeispiele vorgesehen und sollten nicht als produktive Adressplanung übernommen werden.
11. Wie werden Standardgateway und lokale Erreichbarkeit geprüft? Zuerst muss das konfigurierte Gateway ausgelesen werden. Es darf nicht angenommen werden, dass es immer auf `.1` endet. **Windows** ```powershell [RO] Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address, IPv4DefaultGateway ``` Gateway testen: ```powershell [TEST] Test-Connection 192.0.2.1 -Count 4 ``` **Linux** ```bash [RO] ip route show default ``` Gateway testen: ```bash [TEST] ping -c 4 192.0.2.1 ``` **macOS** ```bash [RO] route -n get default ``` Gateway testen: ```bash [TEST] ping -c 4 192.0.2.1 ``` **Interpretation** | Ergebnis | Aussage | |---|---| | Gateway antwortet | ICMP-Kommunikation zum Gateway funktioniert | | Gateway antwortet nicht | keine ICMP-Antwort; Ursache noch offen | | Nachbartabelle enthält Gateway | Layer-2-Zuordnung wurde ermittelt | | keine Nachbarzuordnung | VLAN-, ARP-, NDP- oder Linkproblem möglich | | andere Clients erreichen Gateway | clientbezogene Ursache wahrscheinlicher | | Gateway blockiert ICMP | Ping ist als Nachweis ungeeignet | Ein fehlgeschlagener Ping beweist nicht, dass das Gateway vollständig unerreichbar ist. Manche Gateways beantworten ICMP nicht oder nur eingeschränkt.
12. Wie wird erkannt, welche Quelladresse für ein Ziel verwendet wird? Bei mehreren Adressen und Schnittstellen ist nicht automatisch die erwartete Quelladresse aktiv. **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Die Ausgabe zeigt unter anderem: - verwendete Schnittstelle, - Next Hop, - ausgewählte lokale IP-Adresse, - passende Route. **Linux** ```bash [RO] ip route get 198.51.100.20 ``` Beispiel: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23 ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` Zu kontrollieren sind: | Feld | Prüffrage | |---|---| | Interface | Wird der erwartete Adapter verwendet? | | Source | Wird die richtige Quelladresse gewählt? | | Gateway | Wird der erwartete Router verwendet? | | Route | Ist das Ziel als lokal, spezifisch oder über Default geroutet? | | Metrik | Gibt es eine bevorzugte konkurrierende Route? | Eine unerwartete Quelladresse kann zu Firewall-, Rückweg-, NAT- oder Berechtigungsproblemen führen.
13. Wie werden mehrere Standardgateways bewertet? Mehrere Standardrouten können beabsichtigt sein, beispielsweise bei: - mehreren Internetanbindungen, - VPN, - Redundanz, - Policy-Based Routing, - getrennten Netzwerkdiensten, - virtuellen Umgebungen. Sie können aber auch zu unerwarteten Wegen führen. **Windows** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric, InterfaceMetric ``` **Linux** ```bash [RO] ip route show default ``` ```bash [RO] ip rule show ``` **macOS** ```bash [RO] netstat -rn -f inet | grep '^default' ``` **Zu prüfen** - welche Standardroute bevorzugt wird, - welche Schnittstelle zu dieser Route gehört, - ob ein VPN eine neue Route angelegt hat, - ob der Rückweg zur verwendeten Quelladresse passt, - ob die Metrik beabsichtigt ist, - ob eine spezifischere Route die Standardroute übersteuert. ```text Längstes passendes Präfix hat grundsätzlich Vorrang vor einer weniger spezifischen Route. Die Metrik entscheidet erst zwischen geeigneten konkurrierenden Routen nach den Regeln des jeweiligen Betriebssystems. ```
14. Wie werden IPv6-Adressen unterschieden? | IPv6-Typ | Typischer Bereich beziehungsweise Merkmal | Zweck | |---|---|---| | Unspecified | `::` | keine bestimmte Adresse | | Loopback | `::1` | lokaler Host | | Link-Local | `fe80::/10` | Kommunikation auf dem lokalen Link | | Unique Local | `fc00::/7` | interne IPv6-Adressierung | | Global Unicast | typischerweise aus `2000::/3` | global routbare Kommunikation | | Multicast | `ff00::/8` | Gruppenkommunikation | **Link-Local-Adresse** Beispiel: ```text fe80::1234:5678:9abc:def0%12 ``` Die Scope-ID `%12` beziehungsweise ein Interfacebezug ist erforderlich, weil derselbe Link-Local-Bereich auf mehreren Schnittstellen existieren kann. **Windows** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv6 | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, AddressState, PrefixOrigin, SuffixOrigin ``` **Linux** ```bash [RO] ip -6 address show ``` **macOS** ```bash [RO] ifconfig | grep -E '^[a-z0-9]+:|inet6' ``` Eine vorhandene Link-Local-Adresse beweist nicht, dass globales oder standortübergreifendes IPv6-Routing funktioniert.
15. Was bedeuten bevorzugte, veraltete und vorläufige Adresszustände? Eine IP-Adresse kann vorhanden sein, aber noch nicht vollständig verwendbar sein. **Windows-Feld `AddressState`** | Zustand | Bedeutung | |---|---| | `Tentative` | Prüfung auf Adresskonflikt noch nicht abgeschlossen | | `Duplicate` | doppelte Adresse erkannt | | `Deprecated` | Adresse soll nicht mehr für neue Verbindungen bevorzugt werden | | `Preferred` | Adresse kann normal verwendet werden | | `Invalid` | Adresse ist nicht gültig | **Linux-Ausgabe kann unter anderem zeigen** | Kennzeichnung | Bedeutung | |---|---| | `tentative` | Duplicate Address Detection läuft | | `dadfailed` | Duplicate Address Detection ist fehlgeschlagen | | `deprecated` | Adresse wird für neue Verbindungen nicht bevorzugt | | `temporary` | temporäre IPv6-Adresse | | `dynamic` | dynamisch zugewiesen | **Prüfung unter Linux** ```bash [RO] ip address show ``` Eine Adresse im Zustand `Duplicate` oder `dadfailed` darf nicht als normal funktionsfähig betrachtet werden.
16. Wie wird ein IP-Adresskonflikt erkannt? Mögliche Symptome: - Warnmeldung über doppelte IP-Adresse, - Verbindung funktioniert wechselweise, - ARP-Eintrag ändert seine MAC-Adresse, - ein anderes Gerät ist unter der eigenen Adresse erreichbar, - Verbindungen brechen sporadisch ab, - Switch lernt dieselbe IP-Zuordnung über wechselnde MAC-Adressen, - Windows meldet `Duplicate`, - IPv6 Duplicate Address Detection schlägt fehl. **Windows** ```powershell [RO] Get-NetIPAddress | Where-Object AddressState -ne 'Preferred' | Format-Table InterfaceAlias, IPAddress, AddressFamily, AddressState ``` Systemereignisse untersuchen: ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.Message -match 'duplicate|conflict|Adressenkonflikt' } | Select-Object TimeCreated, Id, ProviderName, Message ``` **Linux** ```bash [RO] ip address show | grep -E 'tentative|dadfailed|deprecated' ``` Kernel- und Netzwerkprotokolle: ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'duplicate|conflict|dadfailed' ``` **macOS** ```bash [RO] log show --last 1h --style compact \ --predicate 'eventMessage CONTAINS[c] "duplicate" OR eventMessage CONTAINS[c] "conflict"' ``` **Wichtig** Das absichtliche Senden von ARP-Probes mit zusätzlichen Werkzeugen ist ein aktiver Test und kann Sicherheitsüberwachung auslösen. Solche Werkzeuge dürfen nur im autorisierten Netz eingesetzt werden. Bei einem bestätigten Konflikt müssen DHCP-Leases, statische Zuweisungen, Reservierungen, Dokumentation und die MAC-Adressen beider Geräte geprüft werden.
17. Wie werden DNS-Server innerhalb der IP-Konfiguration geprüft? An dieser Stelle wird nur geprüft, **welche DNS-Server konfiguriert sind**. Die eigentliche DNS-Fehleranalyse erfolgt auf Seite 3.8. **Windows** ```powershell [RO] Get-DnsClientServerAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ServerAddresses ``` **Linux mit systemd-resolved** ```bash [RO] resolvectl status ``` Klassische Resolverdatei: ```bash [RO] cat /etc/resolv.conf ``` Die Datei `/etc/resolv.conf` kann automatisch generiert oder ein symbolischer Link sein: ```bash [RO] ls -l /etc/resolv.conf ``` **macOS** ```bash [RO][SENS] scutil --dns ``` Dienstbezogene DNS-Server: ```bash [RO] networksetup -getdnsservers "Wi-Fi" ``` **Zu prüfen** - gehören die Server zur vorgesehenen Umgebung? - sind interne und externe Resolver korrekt getrennt? - hat ein VPN andere DNS-Server eingetragen? - existieren schnittstellen- oder domänenspezifische Resolver? - wird eine lokale Filterlösung verwendet? - ist die Reihenfolge beabsichtigt? Ein Eintrag in der Konfiguration beweist noch nicht, dass der DNS-Server erreichbar ist oder korrekte Antworten liefert.
18. Wie wird DHCP von statischer Adressierung unterschieden? **Windows** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, Dhcp, ConnectionState ``` Adressursprung: ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin ``` Vollständige Leaseinformationen: ```cmd [RO][SENS] ipconfig /all ``` **Linux mit NetworkManager** ```bash [RO] nmcli device show ``` Verbindungsprofil: ```bash [RO][SENS] nmcli connection show ``` Die genaue Verbindung kann anschließend gezielt abgefragt werden: ```bash [RO][SENS] nmcli connection show "VERBINDUNGSNAME" ``` **macOS** ```bash [RO] networksetup -getinfo "Ethernet" ``` **Mögliche Zustände** | Zustand | Bewertung | |---|---| | DHCP vorgesehen und DHCP aktiv | grundsätzlich passend | | DHCP vorgesehen, aber statische Adresse | Fehlkonfiguration möglich | | statische Adresse vorgesehen, aber DHCP aktiv | falsche Adresse möglich | | DHCP-Adresse aus falschem Subnetz | falsches VLAN oder falscher DHCP-Server möglich | | DHCP-Lease abgelaufen | Erneuerung und DHCP-Erreichbarkeit prüfen | | Link-Local-Adresse | reguläre DHCP-Konfiguration vermutlich nicht erhalten | Die detaillierte DHCP-Analyse folgt auf Seite 3.4.
19. Welche lokalen Tests sind nach der Konfigurationsprüfung sinnvoll? Die Adressen müssen durch die tatsächlichen Werte des untersuchten Systems ersetzt werden. | Reihenfolge | Test | Aussage | |---:|---|---| | 1 | Loopback testen | lokaler TCP/IP-Stack reagiert | | 2 | eigene Adresse testen | eigene konfigurierte Adresse reagiert lokal | | 3 | Gateway testen | Kommunikation bis zum lokalen Router | | 4 | Ziel im selben Subnetz testen | lokale Layer-2-Kommunikation | | 5 | entferntes Ziel per IP testen | Routing grundsätzlich möglich | | 6 | Ziel per Name testen | Namensauflösung zusätzlich beteiligt | **Windows** ```powershell [TEST] Test-Connection 127.0.0.1 -Count 4 ``` ```powershell [TEST] Test-Connection 192.0.2.23 -Count 4 ``` ```powershell [TEST] Test-Connection 192.0.2.1 -Count 4 ``` **Linux und macOS** ```bash [TEST] ping -c 4 127.0.0.1 ``` ```bash [TEST] ping -c 4 192.0.2.23 ``` ```bash [TEST] ping -c 4 192.0.2.1 ``` **IPv6-Loopback** Windows: ```powershell [TEST] Test-Connection ::1 -Count 4 ``` Linux und macOS: ```bash [TEST] ping -c 4 ::1 ``` Ein erfolgreicher Test zur eigenen IP-Adresse durchläuft nicht zwangsläufig den vollständigen physischen Netzwerkweg.
20. Warum sollten IP-Einstellungen nicht vorschnell verändert werden? Mögliche Risiken: - Verlust des Remotezugriffs, - doppelter IP-Adresskonflikt, - falsches VLAN wird verdeckt, - DHCP-Fehler bleibt unentdeckt, - bestehende Verbindungen brechen ab, - falsche DNS- oder Gatewaywerte werden eingetragen, - ursprünglicher Diagnosezustand geht verloren, - statische Serverkonfiguration wird überschrieben. **Vor jeder Änderung sichern** **Windows** ```powershell [RO][FILE][SENS] Get-NetIPConfiguration | Format-List * | Out-File 'C:\Temp\NetIPConfiguration-vorher.txt' ``` ```powershell [RO][FILE][SENS] Get-NetIPAddress | Format-List * | Out-File 'C:\Temp\NetIPAddress-vorher.txt' ``` ```powershell [RO][FILE][SENS] Get-NetRoute | Format-Table -AutoSize | Out-File 'C:\Temp\NetRoute-vorher.txt' -Width 300 ``` **Linux** ```bash [RO][FILE][SENS] ip address show > /tmp/ip-address-vorher.txt ``` ```bash [RO][FILE][SENS] ip route show table all > /tmp/ip-route-vorher.txt ``` **macOS** ```bash [RO][FILE][SENS] ifconfig > /tmp/ifconfig-vorher.txt ``` ```bash [RO][FILE][SENS] netstat -rn > /tmp/netstat-route-vorher.txt ``` Die verwendeten Speicherorte müssen zur betrieblichen Umgebung und deren Datenschutzvorgaben passen.
21. Welche eingreifenden Befehle existieren und warum sind sie riskant? **Windows – DHCP-Lease freigeben** ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release ``` Lease erneut anfordern: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew ``` **Linux mit NetworkManager – Verbindung neu aktivieren** ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME" ``` ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME" ``` **macOS – DHCP-Lease erneuern** ```bash [PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP ``` Der macOS-Befehl setzt die betreffende Schnittstelle auf DHCP und ist deshalb nicht für ein System geeignet, das statisch konfiguriert sein soll. > Diese Befehle dürfen erst verwendet werden, nachdem die vorhandene Konfiguration, der vorgesehene Adressierungsmodus und ein Rückweg dokumentiert wurden. Bei einer Remoteverbindung kann der eigene Zugriff sofort verloren gehen.
22. Wie wird eine Referenzkonfiguration verglichen? Ein funktionierendes Vergleichssystem sollte möglichst folgende Merkmale teilen: - gleicher Standort, - gleiches VLAN, - gleiche Verbindungsart, - gleiche Geräteklasse, - gleiche Betriebssystemversion, - gleiche Netzwerkrolle. **Vergleichstabelle** | Eigenschaft | Betroffener Client | Referenzclient | Bewertung | |---|---|---|---| | VLAN | 20 | 20 | gleich | | IPv4-Adresse | `192.0.2.23` | `192.0.2.24` | plausibel | | Präfix | `/24` | `/24` | gleich | | Gateway | `192.0.2.1` | `192.0.2.1` | gleich | | DNS 1 | `192.0.2.53` | `192.0.2.53` | gleich | | DNS 2 | fehlt | `192.0.2.54` | Abweichung | | DHCP | aktiv | aktiv | gleich | | IPv6 | nur Link-Local | globale Adresse | Abweichung | | Standardroute | Ethernet | Ethernet | gleich | | VPN-Route | vorhanden | nicht vorhanden | relevante Abweichung | Eine Abweichung ist zunächst ein Untersuchungshinweis. Sie ist erst dann eine belegte Ursache, wenn sie zum Fehlerbild passt und durch einen kontrollierten Test bestätigt wird.
23. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | IP-Adresse ist vorhanden | Konfiguration ist korrekt | Subnetz, Gateway und Adressquelle vergleichen | | Adresse beginnt mit `192.168` | Adresse gehört zum richtigen Netz | privater Bereich umfasst viele unterschiedliche Netze | | Gateway endet auf `.1` | Gateway ist automatisch korrekt | vorgesehenes Gateway dokumentiert prüfen | | `169.254.x.x` ist vorhanden | Netzwerkkarte ist defekt | reguläre IPv4-Konfiguration fehlt vermutlich | | Ping zur eigenen IP funktioniert | Netzwerkkabel funktioniert | Test kann lokal beantwortet werden | | Gateway antwortet nicht | Gateway ist ausgefallen | ICMP kann blockiert sein | | mehrere Adressen vorhanden | zwingend Fehlkonfiguration | bei IPv6 und mehreren Interfaces normal möglich | | IPv6 ist vorhanden | IPv6-Internet funktioniert | Link-Local-Adresse reicht dafür nicht | | DNS-Server ist eingetragen | DNS funktioniert | Erreichbarkeit und Antwort separat prüfen | | DHCP ist aktiviert | korrekte Lease wurde empfangen | Leasewerte und DHCP-Server prüfen | | `/24` sieht üblich aus | Präfix ist korrekt | Netzplan und Referenzsystem vergleichen | | eine Default Route existiert | richtiger Weg wird verwendet | spezifischere Routen und Metriken prüfen |
24. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | tatsächlich verwendete Schnittstelle bestimmen | | 2 | vollständige IPv4- und IPv6-Konfiguration erfassen | | 3 | Adressquelle DHCP, statisch, SLAAC oder andere bestimmen | | 4 | Adresse und Präfix mit dem Netzplan vergleichen | | 5 | Netzwerk- und Broadcastadresse bei IPv4 bestimmen | | 6 | Gateway und DNS-Server vergleichen | | 7 | Adresszustand auf Duplicate, Tentative oder Deprecated prüfen | | 8 | Standardrouten und spezifische Routen untersuchen | | 9 | ausgewählte Route und Quelladresse zum Ziel prüfen | | 10 | Loopback, eigene Adresse und Gateway kontrolliert testen | | 11 | mit funktionierendem Referenzclient vergleichen | | 12 | erst danach DHCP, ARP/NDP oder Routing vertieft untersuchen | | 13 | Änderungen nur mit Sicherung und Rückweg durchführen | | 14 | Ergebnis dokumentieren | **Merksatz** ```text Schnittstelle → Adresse → Präfix → Gateway → DNS → Route → Quelladresse → Vergleich ```
25. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | vollständige Konfiguration | `[RO][SENS] ipconfig /all` | `[RO] ip address show` | `[RO] ifconfig` | | kompakte Übersicht | `[RO] Get-NetIPConfiguration` | `[RO] ip -brief address` | `[RO] networksetup -getinfo "DIENST"` | | IPv4-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address` | `[RO] ifconfig` | | IPv6-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv6` | `[RO] ip -6 address` | `[RO] ifconfig` | | IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route` | `[RO] netstat -rn -f inet6` | | Standardroute IPv4 | `[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0'` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zu Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL-IP` | `[RO] ip route get ZIEL-IP` | `[RO] route -n get ZIEL-IP` | | DNS-Server | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | DHCP-Status | `[RO] Get-NetIPInterface -AddressFamily IPv4` | `[RO] nmcli device show` | `[RO] networksetup -getinfo "DIENST"` | | Loopback testen | `[TEST] Test-Connection 127.0.0.1 -Count 4` | `[TEST] ping -c 4 127.0.0.1` | `[TEST] ping -c 4 127.0.0.1` | | Gateway testen | `[TEST] Test-Connection GATEWAY -Count 4` | `[TEST] ping -c 4 GATEWAY` | `[TEST] ping -c 4 GATEWAY` | | Lease freigeben | `[PRIV][CHANGE][DISRUPT] ipconfig /release` | abhängig vom Netzwerkmanager | nicht direkt gleichwertig | | Lease erneuern | `[PRIV][CHANGE][DISRUPT] ipconfig /renew` | abhängig vom Netzwerkmanager | `[PRIV][CHANGE][DISRUPT] sudo ipconfig set INTERFACE DHCP` | Die Platzhalter `DIENST`, `INTERFACE`, `GATEWAY` und `ZIEL-IP` müssen durch zuvor eindeutig ermittelte Werte ersetzt werden.
26. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffenes Gerät: Betriebssystem: Benutzer: Standort: VLAN: Verbindungsart: SCHNITTSTELLE Schnittstellenname: Schnittstellenindex: MAC-Adresse: Status: Linkgeschwindigkeit: MTU: IPV4 IPv4-Adresse: Präfixlänge: Subnetzmaske: Netzwerkadresse: Broadcastadresse: Adresszustand: Adressquelle: DHCP aktiviert: DHCP-Server: Leasebeginn: Leaseende: Standardgateway: DNS-Server: Ausgewählte Quelladresse zum Ziel: Ausgewählte Route: Next Hop: IPV6 Link-Local-Adresse: Globale beziehungsweise interne IPv6-Adresse: Präfixlänge: Adresszustand: Adressquelle: Standardrouter: DNS-Server: Ausgewählte Quelladresse zum Ziel: Ausgewählte Route: Next Hop: LOKALE TESTS Loopback IPv4: Loopback IPv6: Eigene IPv4-Adresse: Eigene IPv6-Adresse: IPv4-Gateway: IPv6-Router: Ziel im lokalen Subnetz: Entferntes Ziel per IP: REFERENZVERGLEICH Referenzgerät: Gleiches VLAN: IPv4-Präfix: Gateway: DNS-Server: Adressquelle: Relevante Abweichungen: AUFFÄLLIGKEITEN - - - Arbeitshypothese: Nächster Prüfschritt: Gesicherter Ausgangszustand: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
27. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration) - [Get-NetIPAddress](https://learn.microsoft.com/powershell/module/nettcpip/get-netipaddress) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-DnsClientServerAddress](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientserveraddress) - [TCP/IP-Adressierung und Subnetting](https://learn.microsoft.com/troubleshoot/windows-client/networking/tcpip-addressing-and-subnetting) **Linux** - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [NetworkManager nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [systemd networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man scutil`, `man networksetup` und `man ipconfig` - [Ändern der TCP/IP-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-tcp-ip-settings-mac-mh14129/mac) - [Ändern der DNS-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac) **Standards** - [RFC 1918 – Private Address Space](https://www.rfc-editor.org/rfc/rfc1918) - [RFC 3927 – IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927) - [RFC 4291 – IPv6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291) - [RFC 6164 – IPv6 Prefix Length for Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc6164) - [RFC 3021 – IPv4 /31 Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc3021) - [RFC 5737 – IPv4 Documentation Address Blocks](https://www.rfc-editor.org/rfc/rfc5737) > Adressen, Präfixe, Gateways und DNS-Server müssen immer mit der tatsächlichen Netzwerkdokumentation verglichen werden. Die Beispielwerte auf dieser Seite sind keine Vorgabe für produktive Netze.
# 3.4 DHCP-Fehler analysieren DHCP stellt Clients automatisch Netzwerkparameter zur Verfügung. Dazu gehören typischerweise IP-Adresse, Präfix beziehungsweise Subnetzmaske, Standardgateway, DNS-Server, DNS-Suchdomäne und Lease-Dauer. Eine erfolgreiche DHCP-Zuweisung beweist jedoch nicht automatisch, dass alle übermittelten Parameter korrekt sind. Ein Client kann eine technisch gültige Adresse aus dem falschen Subnetz oder von einem nicht vorgesehenen DHCP-Server erhalten. > **Grundregel:** Zuerst die vorhandene Lease und deren Herkunft dokumentieren. Erst danach darf eine Freigabe oder Erneuerung durchgeführt werden. ---
1. Welche Symptome sprechen für ein DHCP-Problem? - IPv4-Adresse aus `169.254.0.0/16`, - keine reguläre IPv4-Adresse, - Adresse aus einem falschen Subnetz, - falsches Standardgateway, - falsche DNS-Server, - fehlende DHCP-Optionen, - Lease kann nicht erneuert werden, - Verbindung funktioniert erst nach langer Wartezeit, - neue Geräte erhalten keine Adresse, - bestehende Geräte funktionieren noch, - Fehler betrifft nur ein VLAN, - Fehler betrifft nur einen Standort, - ein Client erhält wechselnde Konfigurationen, - DHCP-Adresskonflikt wird gemeldet, - Lease-Dauer ist ungewöhnlich kurz, - nicht autorisierter DHCP-Server antwortet, - DHCP funktioniert über LAN, aber nicht über WLAN, - DHCP funktioniert im Server-VLAN, aber nicht über den Relay-Agenten.
2. Welche Informationen müssen vor einer Veränderung erfasst werden? | Information | Beispiel | |---|---| | Clienthostname | `CLIENT-023` | | MAC-Adresse | `00-11-22-33-44-55` | | Schnittstelle | Ethernet | | VLAN | 20 | | aktuelle IPv4-Adresse | `192.0.2.23` | | Präfix beziehungsweise Maske | `/24` beziehungsweise `255.255.255.0` | | Standardgateway | `192.0.2.1` | | DNS-Server | `192.0.2.53`, `192.0.2.54` | | DHCP aktiviert | Ja | | DHCP-Server | `192.0.2.10` | | Lease erhalten | `2026-07-31 08:00 CEST` | | Lease läuft ab | `2026-08-01 08:00 CEST` | | erwarteter DHCP-Bereich | `192.0.2.20–192.0.2.200` | | Fehlerbeginn | `2026-07-31 09:42 CEST` | Vor einer Lease-Erneuerung sollten zusätzlich gespeichert werden: - vollständige IP-Konfiguration, - Routingtabelle, - DNS-Konfiguration, - DHCP-Clientprotokolle, - relevante Netzwerkereignisse, - Vergleichsdaten eines funktionierenden Clients.
3. Wie funktioniert DHCPv4 grundsätzlich? Der klassische erstmalige DHCPv4-Ablauf wird häufig als DORA bezeichnet: ```text Client DHCP-Server │ │ │──── DHCPDISCOVER ────────────────────────>│ │<─── DHCPOFFER ────────────────────────────│ │──── DHCPREQUEST ─────────────────────────>│ │<─── DHCPACK ──────────────────────────────│ │ │ ``` | Nachricht | Absender | Bedeutung | |---|---|---| | `DHCPDISCOVER` | Client | sucht verfügbare DHCP-Server | | `DHCPOFFER` | Server | bietet Adresse und Parameter an | | `DHCPREQUEST` | Client | fordert ein bestimmtes Angebot an | | `DHCPACK` | Server | bestätigt die Lease | | `DHCPNAK` | Server | lehnt angeforderte Konfiguration ab | | `DHCPDECLINE` | Client | meldet angebotene Adresse als problematisch | | `DHCPRELEASE` | Client | gibt eine Lease frei | | `DHCPINFORM` | Client | fordert Optionen an, ohne eine neue Adresse zu beziehen | DHCPv4 verwendet grundsätzlich: | Richtung | UDP-Port | |---|---:| | Server | 67 | | Client | 68 | Die erste Kommunikation erfolgt häufig per Broadcast, weil der Client zunächst noch keine reguläre IPv4-Adresse und keinen bekannten DHCP-Server besitzt.
4. Wie wird eine bestehende DHCP-Konfiguration unter Windows geprüft? **Vollständige Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` Zu prüfen sind insbesondere: ```text DHCP aktiviert IPv4-Adresse Subnetzmaske Lease erhalten Lease läuft ab Standardgateway DHCP-Server DNS-Server Verbindungsspezifisches DNS-Suffix ``` **DHCP-Status der Schnittstellen** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, Dhcp, ConnectionState, InterfaceMetric ``` **Adressursprung** ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, InterfaceIndex, IPAddress, PrefixLength, PrefixOrigin, SuffixOrigin, AddressState ``` **Konfiguration sichern** ```powershell [RO][FILE][SENS] ipconfig /all | Out-File 'C:\Temp\ipconfig-vor-dhcp-test.txt' ``` ```powershell [RO][FILE][SENS] Get-NetIPConfiguration | Format-List * | Out-File 'C:\Temp\netipconfig-vor-dhcp-test.txt' ``` Die Verzeichnisse müssen vorhanden und für Diagnoseinformationen freigegeben sein.
5. Wie werden DHCP-Clientereignisse unter Windows gelesen? **Verfügbare DHCP-bezogene Protokolle suchen** ```powershell [RO] Get-WinEvent -ListLog '*DHCP*' | Select-Object LogName, IsEnabled, RecordCount ``` Je nach Windows-Version und aktivierten Kanälen können unter anderem DHCP-Client-Protokolle unter folgendem Bereich vorhanden sein: ```text Anwendungs- und Dienstprotokolle → Microsoft → Windows → Dhcp-Client ``` **Aktivierte DHCP-Protokolle auslesen** ```powershell [RO] Get-WinEvent -ListLog '*DHCP*' | Where-Object { $_.IsEnabled -and $_.RecordCount -gt 0 } | ForEach-Object { Get-WinEvent -LogName $_.LogName -MaxEvents 50 -ErrorAction SilentlyContinue } | Sort-Object TimeCreated -Descending | Select-Object TimeCreated, LogName, Id, LevelDisplayName, ProviderName, Message ``` **Systemprotokoll nach DHCP-Meldungen durchsuchen** ```powershell [RO] Get-WinEvent -LogName System -MaxEvents 1000 | Where-Object { $_.ProviderName -Match 'Dhcp' -or $_.Message -Match 'DHCP' } | Sort-Object TimeCreated -Descending | Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message ``` Protokollname, Provider und Ereignis-ID können sich zwischen Windows-Versionen unterscheiden. Deshalb sollte zuerst mit `Get-WinEvent -ListLog '*DHCP*'` geprüft werden, welche Kanäle tatsächlich vorhanden sind.
6. Wie wird eine bestehende DHCP-Konfiguration unter Linux geprüft? **Grundlegende IP-Konfiguration** ```bash [RO] ip -4 address ``` ```bash [RO] ip -4 route ``` **Mit NetworkManager** Gerätestatus: ```bash [RO] nmcli device status ``` Ausführliche Gerätedaten: ```bash [RO][SENS] nmcli device show eth0 ``` Aktive Verbindungen: ```bash [RO] nmcli connection show --active ``` Verbindungsprofil: ```bash [RO][SENS] nmcli connection show "VERBINDUNGSNAME" ``` Zu prüfen sind insbesondere Eigenschaften wie: - IPv4-Konfigurationsmethode, - aktuelle IPv4-Adresse, - Gateway, - DNS-Server, - DHCP-Server beziehungsweise DHCP-Optionen, - Domänen- und Suchinformationen. Die tatsächlich verfügbaren Felder hängen von NetworkManager-Version und Backend ab. **Mit systemd-networkd** ```bash [RO] networkctl status eth0 ``` ```bash [RO] networkctl status --all ``` **Lease-Dateien** Speicherort und Format von Lease-Dateien hängen von Distribution und Netzwerkmanager ab. Es sollte nicht von einem festen Pfad ausgegangen werden. Vorhandene Dateien können gesucht werden, ohne sie zu verändern: ```bash [RO][PRIV][SENS] sudo find /run /var/lib \ -maxdepth 4 \ -type f \ \( -iname '*lease*' -o -iname '*dhcp*' \) \ 2>/dev/null ``` Gefundene Dateien dürfen nicht gelöscht oder verändert werden, bevor Netzwerkmanager und Zweck eindeutig bestimmt wurden.
7. Wie werden DHCP-Clientprotokolle unter Linux geprüft? **NetworkManager** ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager ``` Nach DHCP-Meldungen filtern: ```bash [RO][PRIV] sudo journalctl -b -u NetworkManager | grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout' ``` **systemd-networkd** ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd ``` Nach DHCP-Meldungen filtern: ```bash [RO][PRIV] sudo journalctl -b -u systemd-networkd | grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout' ``` **Allgemeine Protokollsuche** ```bash [RO][PRIV] sudo journalctl -b | grep -Ei 'dhcp|lease|dhclient|NetworkManager|systemd-networkd' ``` **Kernelmeldungen zur Schnittstelle** ```bash [RO][PRIV] sudo journalctl -k -b | grep -E 'eth0|link.*(up|down)|carrier' ``` Vor der Interpretation muss bekannt sein, welcher Dienst die Schnittstelle verwaltet. Meldungen eines installierten, aber nicht verwendeten DHCP-Clients sind möglicherweise irrelevant.
8. Wie wird eine bestehende DHCP-Konfiguration unter macOS geprüft? **Netzwerkdienste auflisten** ```bash [RO] networksetup -listallnetworkservices ``` **Hardwareports zuordnen** ```bash [RO] networksetup -listallhardwareports ``` **Konfiguration eines Dienstes** ```bash [RO] networksetup -getinfo "Ethernet" ``` **DHCP-Paketinformationen einer Schnittstelle** ```bash [RO][SENS] ipconfig getpacket en0 ``` Diese Ausgabe kann unter anderem enthalten: - angebotene IPv4-Adresse, - Subnetzmaske, - Router, - DHCP-Serverkennung, - Lease-Dauer, - DNS-Server, - Domainnamen, - weitere DHCP-Optionen. **Nur die aktuelle IPv4-Adresse** ```bash [RO] ipconfig getifaddr en0 ``` **DNS-Konfiguration** ```bash [RO][SENS] scutil --dns ``` **Systemprotokolle nach DHCP durchsuchen** ```bash [RO] log show \ --last 1h \ --style compact \ --predicate 'process == "bootp" OR eventMessage CONTAINS[c] "DHCP"' ``` Je nach macOS-Version können Prozessname, Subsystem und verfügbare Meldungen abweichen. Eine leere Ausgabe beweist nicht, dass kein DHCP-Vorgang stattgefunden hat.
9. Wie wird geprüft, ob der Client überhaupt DHCP verwendet? Ein Client kann eine statische Adresse besitzen und deshalb keine reguläre DHCP-Lease anfordern. **Windows** ```powershell [RO] Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias, Dhcp, ConnectionState ``` **Linux mit NetworkManager** ```bash [RO] nmcli connection show "VERBINDUNGSNAME" | grep -E '^ipv4\.method' ``` Typische Werte: | Wert | Bedeutung | |---|---| | `auto` | automatische IPv4-Konfiguration, typischerweise DHCP | | `manual` | statische Konfiguration | | `disabled` | IPv4 deaktiviert | | `shared` | geteilte Verbindung mit eigener Adressbereitstellung | **macOS** ```bash [RO] networksetup -getinfo "Ethernet" ``` Die Ausgabe zeigt die verwendete Konfigurationsmethode. **Prüffragen** - Soll diese Schnittstelle DHCP verwenden? - Ist möglicherweise ein altes statisches Profil aktiv? - Verwaltet eine zusätzliche Software die Konfiguration? - Ist ein VPN- oder MDM-Profil beteiligt? - Wird die richtige physische oder virtuelle Schnittstelle untersucht?
10. Wie wird eine DHCPv4-Störung anhand der Nachrichten eingegrenzt? | Sichtbare Nachrichten | Mögliche Untersuchungsrichtung | |---|---| | kein `DHCPDISCOVER` | DHCP-Client, Schnittstelle oder Capture-Punkt prüfen | | `DISCOVER`, aber kein `OFFER` | VLAN, Relay, Filter, Server oder Bereich prüfen | | mehrere `OFFER` | mehrere DHCP-Server vorhanden; Berechtigung prüfen | | `OFFER`, aber kein `REQUEST` | Clientzustand oder nicht gewähltes Angebot prüfen | | `REQUEST`, aber kein `ACK` | Server, Relay, Filter oder Adressprüfung untersuchen | | `REQUEST` gefolgt von `NAK` | angeforderte Adresse ist für Server nicht gültig | | `ACK` mit falschen Optionen | Scope-, Policy- oder Optionskonfiguration prüfen | | wiederholte DORA-Sequenzen | Lease wird nicht übernommen oder Verbindung bricht ab | | `DECLINE` | Client vermutet Adresskonflikt | | Lease funktioniert nur im Server-VLAN | DHCP-Relay oder Routing prüfen | Die Interpretation muss anhand von Transaktions-ID, Client-MAC beziehungsweise Client-Identifier und Zeitstempel erfolgen. Gleichzeitige DHCP-Vorgänge anderer Clients dürfen nicht verwechselt werden.
11. Wie wird DHCP-Verkehr sicher mit Wireshark oder TShark geprüft? **Wireshark-Display-Filter für DHCPv4** ```text dhcp ``` Je nach Wireshark-Version wird auch weiterhin der ältere Protokollname `bootp` in Feldern oder Filtern verwendet. Der folgende Filter ist deshalb ebenfalls verbreitet: ```text bootp ``` **Nur DHCPv4-Ports** ```text udp.port == 67 || udp.port == 68 ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "udp port 67 or udp port 68" ``` **Zeitlich begrenzte Aufnahme mit dumpcap** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "udp port 67 or udp port 68" \ -a duration:60 \ -w dhcp-test.pcapng ``` **DHCP-Nachrichtentypen aus einer Datei anzeigen** ```bash [RO][SENS] tshark \ -r dhcp-test.pcapng \ -Y "bootp" \ -T fields \ -e frame.time \ -e eth.src \ -e ip.src \ -e ip.dst \ -e bootp.option.dhcp ``` Feldnamen können sich zwischen Wireshark-Versionen ändern. Die lokal verfügbaren Felder sollten geprüft werden: ```bash [RO] tshark -G fields | grep -Ei 'dhcp|bootp' ``` Ein Paketmitschnitt darf nur mit Freigabe und unter Beachtung der Regeln aus Seite 2.14 erstellt werden.
12. Wie wird ein fehlendes DHCPOFFER untersucht? Wenn der Client `DHCPDISCOVER` sendet, aber kein Angebot erhält, wird der Kommunikationsweg geprüft: ```text Client → Switchport → Client-VLAN → DHCP-Relay oder direktes Broadcastsegment → Netzwerkpfad → DHCP-Server ``` **Prüffragen** 1. Ist der Client im richtigen VLAN? 2. Wird das `DHCPDISCOVER` am Client gesendet? 3. Wird es am Switch beziehungsweise Relay empfangen? 4. Ist für dieses VLAN ein DHCP-Relay konfiguriert? 5. Verwendet das Relay die richtige Serveradresse? 6. Ist der DHCP-Server vom Relay aus erreichbar? 7. Ist UDP 67/68 auf dem Weg erlaubt? 8. Existiert ein aktiver DHCP-Bereich für das Clientnetz? 9. Besitzt der Bereich noch freie Adressen? 10. Ist der Serverdienst aktiv? 11. Wird die Anfrage durch eine Policy abgelehnt? 12. Enthält die Relay-Anfrage die erwarteten Informationen? 13. Wird ein Angebot zurückgesendet? 14. Erreicht das Angebot wieder den Client? Wenn nur ein Client betroffen ist, während andere Clients am selben Anschlussbereich neue Leases erhalten, ist ein vollständiger Ausfall des DHCP-Servers weniger wahrscheinlich.
13. Welche Aufgabe hat ein DHCP-Relay? IPv4-Broadcasts werden normalerweise nicht durch Router weitergeleitet. Befindet sich der DHCP-Server in einem anderen Netz, nimmt ein DHCP-Relay die Clientanfrage entgegen und leitet sie an den Server weiter. ```text Client-VLAN 20 192.0.2.0/24 │ ├─ DHCPDISCOVER als Broadcast │ └─ Gateway/DHCP-Relay │ └─ Weiterleitung zum DHCP-Server 198.51.100.10 ``` Der Server muss anhand der Relayinformationen erkennen können, für welches Clientnetz eine Adresse vergeben werden soll. **Typische Relay-Probleme** - Relay fehlt auf dem VLAN-Interface, - falsche DHCP-Serveradresse, - neues VLAN wurde nicht ergänzt, - Route zum DHCP-Server fehlt, - Rückroute zum Relay fehlt, - Firewall blockiert DHCP-Verkehr, - falsche Relay- beziehungsweise Gatewayadresse, - Policy behandelt Relayinformationen falsch, - redundante Relays verhalten sich unterschiedlich. **Typisches Muster** ```text DHCP funktioniert im selben Netz wie der Server, aber nicht in einem entfernten VLAN. ``` Dies ist ein starker Hinweis auf Relay, Routing, Firewall oder fehlenden Scope für das entfernte Netz.
14. Wie wird ein erschöpfter DHCP-Bereich erkannt? Mögliche Symptome: - bestehende Clients funktionieren weiterhin, - neue Clients erhalten keine Adresse, - nach Ablauf alter Leases können weitere Geräte ausfallen, - Server meldet keine verfügbaren Adressen, - freie Adressen liegen nahe null, - viele veraltete oder ungewöhnlich lange Leases, - Adressen sind durch Reservierungen belegt, - Bereich ist zu klein für die tatsächliche Gerätezahl. **Zu prüfen** | Bereich | Prüffrage | |---|---| | Adresspool | Wie viele Adressen enthält er? | | aktive Leases | Wie viele Adressen sind vergeben? | | freie Adressen | Wie viele können noch vergeben werden? | | Ausschlüsse | Welche Adressen sind ausgeschlossen? | | Reservierungen | Welche Adressen sind fest zugeordnet? | | Lease-Dauer | Passt sie zur Nutzung des Netzes? | | veraltete Einträge | Sind Leases nicht mehr aktiver Geräte vorhanden? | | Konflikterkennung | Wurden Adressen als problematisch markiert? | Eine Vergrößerung des Bereichs ist eine Netzwerkänderung. Präfix, Gateway, VLAN, Routing, Ausschlüsse und mögliche Überschneidungen müssen vorher geprüft werden.
15. Wie wird ein nicht autorisierter DHCP-Server erkannt? Ein nicht vorgesehener DHCP-Server kann Clients falsche Netzwerkparameter liefern. Mögliche Hinweise: - verschiedene Clients erhalten unterschiedliche Gateways, - DNS-Server weichen voneinander ab, - Lease stammt von einer unbekannten Serveradresse, - mehrere `DHCPOFFER` werden sichtbar, - Fehler betrifft nur einen Switchbereich, - Clients erhalten Adressen aus einem fremden Subnetz, - Internetzugriff funktioniert, interne Dienste jedoch nicht. **Prüfung mit einem Paketmitschnitt** ```text DHCPDISCOVER ← DHCPOFFER von Server A ← DHCPOFFER von Server B ``` Zu dokumentieren sind: - Server-Identifier, - Quell-IP-Adresse, - Quell-MAC-Adresse, - angebotene IP-Adresse, - Gateway, - DNS-Server, - Lease-Dauer, - Switchport der Server-MAC-Adresse. **Wichtig** Mehrere DHCP-Server können absichtlich zur Redundanz eingesetzt werden. Mehrere Angebote sind deshalb nicht automatisch ein Sicherheitsvorfall. Die Server müssen mit der vorgesehenen Architektur verglichen werden. Ein tatsächlich unbekannter DHCP-Server ist umgehend an Netzwerk- und Informationssicherheitsverantwortliche zu eskalieren.
16. Wie werden falsche DHCP-Optionen erkannt? Eine Lease kann erfolgreich bestätigt werden und trotzdem falsche Parameter enthalten. Typische DHCP-Optionen: | Option | Zweck | |---:|---| | 1 | Subnetzmaske | | 3 | Router beziehungsweise Standardgateway | | 6 | DNS-Server | | 15 | Domainname | | 42 | NTP-Server | | 51 | Lease-Dauer | | 54 | DHCP-Server-Identifier | | 58 | Renewal Time T1 | | 59 | Rebinding Time T2 | | 66 | TFTP- beziehungsweise Servername, abhängig vom Einsatz | | 67 | Bootdateiname | | 119 | Domain Search List | | 121 | Classless Static Routes | Nicht jede Option wird in jeder Umgebung verwendet. **Typische Fehler** - falsche Subnetzmaske, - Gateway aus einem anderen Netz, - veralteter DNS-Server, - falsches DNS-Suffix, - fehlerhafte statische Route, - falscher Zeitserver, - falsche Bootinformationen, - Scope-Option wird durch Server-, Policy- oder Reservierungsoption überschrieben. Die wirksame Option kann aus mehreren Konfigurationsebenen stammen. Deshalb muss die tatsächlich an den Client übertragene DHCP-Antwort geprüft werden.
17. Wie funktionieren Verlängerung und Rebinding einer Lease? Eine DHCP-Lease besitzt eine begrenzte Gültigkeitsdauer. Vereinfacht: ```text Leasebeginn │ ├─ T1: Client versucht Erneuerung beim bisherigen Server │ ├─ T2: Client versucht Erneuerung über weitere erreichbare Server │ └─ Leaseende: Adresse darf nicht unbegrenzt weiterverwendet werden ``` Typische Standardbeziehungen, sofern der Server nichts anderes vorgibt: ```text T1 ungefähr 50 % der Lease-Dauer T2 ungefähr 87,5 % der Lease-Dauer ``` Die tatsächlich übertragenen Werte sind entscheidend. **Mögliche Fehlerbilder** | Situation | Auswirkung | |---|---| | Erstanfrage funktioniert, Verlängerung nicht | bestehende Verbindung kann bis zum Leaseende bestehen | | Server zeitweise nicht erreichbar | Client versucht weitere Erneuerungen | | DHCPNAK bei Erneuerung | Client muss Konfiguration verwerfen und neu anfordern | | Netzwerkwechsel | alte Adresse passt möglicherweise nicht zum neuen VLAN | | sehr kurze Lease | häufige DHCP-Kommunikation und höhere Serverlast | | sehr lange Lease | Änderungen werden langsamer wirksam |
18. Wann dürfen Lease-Freigabe und -Erneuerung durchgeführt werden? Erst nachdem der Ausgangszustand dokumentiert wurde und geklärt ist, dass die Schnittstelle DHCP verwenden soll. **Windows** Lease freigeben: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release ``` Lease erneuern: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew ``` Nur einen benannten Adapter ansprechen: ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /release "Ethernet" ``` ```cmd [PRIV][CHANGE][DISRUPT] ipconfig /renew "Ethernet" ``` Die Behandlung von Platzhaltern und Adapternamen sollte auf dem konkreten Windows-System mit `ipconfig /?` geprüft werden. **Linux mit NetworkManager** Verbindung erneut aktivieren: ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME" ``` ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME" ``` Abhängig von NetworkManager-Version und Profil kann auch eine erneute Anwendung vorhandener Einstellungen möglich sein: ```bash [PRIV][CHANGE][DISRUPT] sudo nmcli device reapply eth0 ``` Dies erzwingt nicht in jedem Fall einen vollständigen neuen DHCP-DORA-Ablauf. **macOS** DHCP-Konfiguration auf einer Schnittstelle anfordern: ```bash [PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP ``` Dieser Befehl setzt die Schnittstelle auf DHCP und darf nicht verwendet werden, wenn eine statische Konfiguration vorgesehen ist. > Bei Remotezugriff kann die Freigabe einer Lease die eigene Administrationsverbindung sofort beenden.
19. Warum sollte dhclient nicht ungeprüft parallel gestartet werden? Der Befehl `dhclient` ist nicht auf jeder Linux-Installation vorhanden. Außerdem kann die Schnittstelle bereits durch NetworkManager, systemd-networkd oder einen anderen Netzwerkdienst verwaltet werden. Ein zusätzlich gestarteter DHCP-Client kann: - mit dem bestehenden Netzwerkmanager konkurrieren, - eine vorhandene Lease verändern, - Routen und DNS-Einstellungen überschreiben, - die Remoteverbindung unterbrechen, - Diagnoseergebnisse verfälschen. Vor einer Verwendung muss geprüft werden: ```bash [RO] ps -ef | grep -E '[d]hclient|[N]etworkManager|[s]ystemd-networkd' ``` ```bash [RO] systemctl --type=service --state=running | grep -Ei 'network|dhcp' ``` `dhclient` sollte nur verwendet werden, wenn er tatsächlich der vorgesehene DHCP-Client dieser Schnittstelle ist und seine lokale Dokumentation geprüft wurde.
20. Wie unterscheidet sich DHCPv6 von DHCPv4? DHCPv6 ist kein direkter identischer Ersatz für DHCPv4. IPv6-Clients können Konfigurationen unter anderem erhalten durch: - Router Advertisements, - Stateless Address Autoconfiguration, - zustandsbehaftetes DHCPv6, - zustandsloses DHCPv6, - statische Konfiguration. DHCPv6 verwendet: | Richtung | UDP-Port | |---|---:| | Client | 546 | | Server | 547 | Vereinfachter DHCPv6-Ablauf: ```text Client DHCPv6-Server │ │ │──── SOLICIT ─────────────────────────────>│ │<─── ADVERTISE ────────────────────────────│ │──── REQUEST ─────────────────────────────>│ │<─── REPLY ────────────────────────────────│ ``` Typische Nachrichten: - `SOLICIT`, - `ADVERTISE`, - `REQUEST`, - `REPLY`, - `RENEW`, - `REBIND`, - `RELEASE`, - `INFORMATION-REQUEST`. **Wireshark-Filter** ```text dhcpv6 ``` Capture-Filter: ```text udp port 546 or udp port 547 ``` > Das IPv6-Standardgateway wird üblicherweise über Router Advertisements und nicht als klassische DHCPv6-Gatewayoption bezogen. Deshalb müssen DHCPv6 und Neighbor Discovery beziehungsweise Router Advertisements gemeinsam betrachtet werden.
21. Wie wird zwischen Client-, Netz- und Serverproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur ein Client betroffen | Clientzustand, Profil, Adapter oder MAC-bezogene Policy | | alle Clients an einem Port betroffen | Port, VLAN oder lokale Infrastruktur | | alle neuen Clients eines VLANs betroffen | Relay, Scope oder Filter | | alle VLANs betroffen | DHCP-Dienst oder zentrale Infrastruktur | | bestehende Leases funktionieren | Bereich erschöpft oder Neuanfrage gestört | | DISCOVER verlässt Client nicht | Client oder Schnittstelle | | DISCOVER sichtbar, aber nicht am Relay | VLAN- oder Switchingpfad | | DISCOVER erreicht Server, kein OFFER | Server, Scope oder Policy | | OFFER verlässt Server, erreicht Client nicht | Rückweg, Relay oder Filter | | ACK erreicht Client, Konfiguration fehlt | Client übernimmt Lease nicht | | ACK enthält falsche Werte | Server-, Scope-, Policy- oder Reservierungsoption | | mehrere OFFER von unbekannten Servern | möglicher Rogue-DHCP-Server | Diese Zuordnung bildet eine Arbeitshypothese und muss durch Logs, Paketmitschnitte und Vergleichstests bestätigt werden.
22. Welche Serverprüfungen sind erforderlich? Die konkreten Befehle hängen vom DHCP-Serverprodukt ab. Unabhängig vom Produkt sollten folgende Punkte geprüft werden: 1. Läuft der DHCP-Dienst? 2. Ist der Server autorisiert beziehungsweise betrieblich freigegeben? 3. Ist der richtige Bereich aktiv? 4. Passt der Bereich zum Clientnetz? 5. Sind freie Adressen vorhanden? 6. Stimmen Präfix und Subnetzmaske? 7. Stimmen Gateway- und DNS-Optionen? 8. Existiert eine Reservierung für den Client? 9. Gibt es Ausschlussbereiche? 10. Wurde die Adresse als Konflikt markiert? 11. Greift eine Policy oder Geräteklassifizierung? 12. Sind Failover- beziehungsweise Redundanzpartner synchron? 13. Erreichen Anfragen den Server? 14. Verlässt die Antwort den Server? 15. Sind Relayinformationen korrekt? 16. Enthalten Serverlogs einen Ablehnungsgrund? **Wichtig** Die Oberfläche eines DHCP-Servers zeigt möglicherweise einen freien Bereich, während Policies, Reservierungen oder Failoverzustände die tatsächliche Vergabe beeinflussen. Die Serverprotokolle und die reale DHCP-Antwort sind deshalb ebenfalls zu prüfen.
23. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | `169.254.x.x` vorhanden | Netzwerkkarte ist defekt | reguläre DHCP-Konfiguration wurde vermutlich nicht bezogen | | DHCP aktiviert | Lease ist korrekt | Server, Adresse und Optionen prüfen | | DHCPOFFER sichtbar | DHCP funktioniert vollständig | REQUEST und ACK müssen folgen | | DHCPACK sichtbar | Netzwerk funktioniert | übertragene Optionen können falsch sein | | mehrere Angebote | Angriff liegt vor | redundante Server können beabsichtigt sein | | bestehende Clients funktionieren | DHCP-Server ist gesund | nur Verlängerung oder freie Adressen können betroffen sein | | Ping zum DHCP-Server scheitert | DHCP muss scheitern | Relay und ICMP-Regeln getrennt bewerten | | Server befindet sich in anderem Netz | DHCP kann nicht funktionieren | Relay kann Broadcasts weiterleiten | | Lease wurde erneuert | Ursache wurde behoben | Fehler kann nur vorübergehend verdeckt sein | | statische Adresse funktioniert | DHCP-Fehler ist bewiesen | VLAN, Routing und Adresskonflikte bleiben möglich | | keine DHCP-Logs vorhanden | keine Anfrage wurde gesendet | falscher Logkanal oder fehlende Protokollierung möglich | | DNS funktioniert nicht | DHCP ist vollständig ausgefallen | möglicherweise nur Option 6 fehlerhaft |
24. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | betroffene Schnittstelle und VLAN bestimmen | | 2 | vorhandene Lease vollständig sichern | | 3 | DHCP-Server, Leasezeiten und Optionen dokumentieren | | 4 | mit funktionierendem Client im selben VLAN vergleichen | | 5 | DHCP-Clientprotokolle untersuchen | | 6 | Verfügbarkeit freier Adressen serverseitig prüfen | | 7 | bei Bedarf autorisierten Paketmitschnitt vorbereiten | | 8 | DHCP-Vorgang kontrolliert reproduzieren | | 9 | DORA-Sequenz und Server-Identifier auswerten | | 10 | Relay-, Routing- und Firewallpfad kontrollieren | | 11 | Serverlogs und Scope-Konfiguration prüfen | | 12 | falsche oder fehlende Optionen bestimmen | | 13 | nur eine begründete Änderung durchführen | | 14 | neue Lease mit Ausgangswert vergleichen | | 15 | Gateway, DNS und Zielverbindung testen | | 16 | Ursache und Änderung dokumentieren | **Merksatz** ```text Lease lesen → Clientlog prüfen → DORA verfolgen → Relay prüfen → Server und Scope prüfen → kontrolliert erneuern ```
25. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | vollständige Konfiguration | `[RO][SENS] ipconfig /all` | `[RO] ip address show` | `[RO] ifconfig` | | DHCP-Status | `[RO] Get-NetIPInterface -AddressFamily IPv4` | `[RO] nmcli device show` | `[RO] networksetup -getinfo "DIENST"` | | Adressursprung | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] nmcli connection show "NAME"` | `[RO] networksetup -getinfo "DIENST"` | | DHCP-Paketdaten | in `ipconfig /all` teilweise sichtbar | abhängig vom Netzwerkmanager | `[RO][SENS] ipconfig getpacket en0` | | Clientlogs | `[RO] Get-WinEvent -ListLog '*DHCP*'` | `[RO][PRIV] sudo journalctl -b -u NetworkManager` | `[RO] log show --last 1h --predicate 'eventMessage CONTAINS[c] "DHCP"'` | | NetworkManager-Status | nicht zutreffend | `[RO] nmcli device status` | nicht zutreffend | | networkd-Status | nicht zutreffend | `[RO] networkctl status` | nicht zutreffend | | DHCPv4-Capture | `dumpcap -f "udp port 67 or udp port 68"` | gleicher Befehl | gleicher Befehl | | DHCPv6-Capture | `dumpcap -f "udp port 546 or udp port 547"` | gleicher Befehl | gleicher Befehl | | Lease freigeben | `[PRIV][CHANGE][DISRUPT] ipconfig /release` | abhängig vom Netzwerkmanager | kein direkt gleichwertiger allgemeiner Lesebefehl | | Lease erneuern | `[PRIV][CHANGE][DISRUPT] ipconfig /renew` | Verbindung kontrolliert neu aktivieren | `[PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP` | Die Platzhalter `DIENST`, `NAME`, `INTERFACE` und `en0` müssen durch die tatsächlich ermittelten Bezeichnungen ersetzt werden.
26. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Benutzer: Standort: Schnittstelle: MAC-Adresse: Switch: Switchport: VLAN: VORHANDENE KONFIGURATION DHCP aktiviert: IPv4-Adresse: Präfix/Subnetzmaske: Adresszustand: Standardgateway: DNS-Server: DNS-Suchdomäne: DHCP-Server: Lease erhalten: T1: T2: Lease läuft ab: Weitere DHCP-Optionen: ERWARTETE KONFIGURATION DHCP-Bereich: Präfix/Subnetzmaske: Standardgateway: DNS-Server: DHCP-Server: Lease-Dauer: Weitere Optionen: VERGLEICHSCLIENT Hostname: Gleiches VLAN: DHCP-Server: IPv4-Adresse: Präfix: Gateway: DNS-Server: Lease erfolgreich: Relevante Abweichungen: CLIENTPROTOKOLL Zeitpunkt: Meldung: Provider/Dienst: Ereignis-ID: PAKETABLAUF DHCPDISCOVER sichtbar: Ja / Nein DHCPOFFER sichtbar: Ja / Nein Anzahl anbietender Server: DHCPREQUEST sichtbar: Ja / Nein DHCPACK sichtbar: Ja / Nein DHCPNAK sichtbar: Ja / Nein DHCPDECLINE sichtbar: Ja / Nein Transaktions-ID: Client-Identifier: Server-Identifier: Angebotene Adresse: Übertragene Optionen: RELAY Relay erforderlich: Relayadresse: Anfrage erreicht Relay: Anfrage erreicht Server: Antwort erreicht Relay: Antwort erreicht Client: SERVER Dienststatus: Scope aktiv: Freie Adressen: Ausschlüsse: Reservierungen: Konflikte: Policy: Failoverstatus: Serverlog: Arbeitshypothese: Begründung: Gesicherter Ausgangszustand: Durchgeführter Test: Durchgeführte Änderung: Rückweg: Neue Lease: Abschlussprüfung: Ermittelte Ursache: ```
27. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [DHCP – technische Übersicht](https://learn.microsoft.com/windows-server/networking/technologies/dhcp/dhcp-top) - [DHCP-Bereitstellung und -Verwaltung](https://learn.microsoft.com/windows-server/networking/technologies/dhcp/quickstart-install-configure-dhcp-server) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [Get-NetIPAddress](https://learn.microsoft.com/powershell/module/nettcpip/get-netipaddress) - [Get-WinEvent](https://learn.microsoft.com/powershell/module/microsoft.powershell.diagnostics/get-winevent) - [ipconfig](https://learn.microsoft.com/windows-server/administration/windows-commands/ipconfig) **Linux** - [NetworkManager nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html) - [systemd-networkd](https://www.freedesktop.org/software/systemd/man/latest/systemd-networkd.service.html) - [networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html) - [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html) **Apple** - Lokale Befehlsreferenzen: `man ipconfig`, `man networksetup`, `man scutil` und `man log` - [Ändern der TCP/IP-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-tcp-ip-settings-mac-mh14129/mac) **Wireshark** - [Wireshark DHCP Display Filter Reference](https://www.wireshark.org/docs/dfref/b/bootp.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 2131 – Dynamic Host Configuration Protocol](https://www.rfc-editor.org/rfc/rfc2131) - [RFC 2132 – DHCP Options](https://www.rfc-editor.org/rfc/rfc2132) - [RFC 3046 – DHCP Relay Agent Information Option](https://www.rfc-editor.org/rfc/rfc3046) - [RFC 8415 – DHCP for IPv6](https://www.rfc-editor.org/rfc/rfc8415) > DHCP-Serverbefehle und Verwaltungsoberflächen unterscheiden sich je nach Hersteller und Produkt. Änderungen an Scopes, Relays, Optionen oder Failoverkonfigurationen dürfen nur anhand der Dokumentation des tatsächlich eingesetzten Systems vorgenommen werden.
# 3.5 ARP und IPv6 Neighbor Discovery analysieren Damit ein Endgerät ein IP-Paket innerhalb eines lokalen Ethernetnetzes übertragen kann, benötigt es die zugehörige MAC-Adresse des nächsten direkten Kommunikationspartners. Bei IPv4 übernimmt diese Zuordnung das Address Resolution Protocol, kurz ARP. IPv6 verwendet dafür Neighbor Discovery, kurz NDP beziehungsweise ND, auf Basis von ICMPv6. > **Grundregel:** Für ein Ziel im lokalen Subnetz wird die MAC-Adresse des Zielsystems benötigt. Für ein Ziel in einem entfernten Subnetz wird normalerweise die MAC-Adresse des nächsten Routers benötigt – nicht die MAC-Adresse des entfernten Zielsystems. ---
1. Welche Aufgabe erfüllt ARP? ARP ordnet eine lokale IPv4-Adresse einer MAC-Adresse zu. **Beispiel im selben Subnetz** ```text CLIENT-023 IPv4: 192.0.2.23/24 MAC: 00-11-22-33-44-55 SERVER-01 IPv4: 192.0.2.80/24 MAC: AA-BB-CC-DD-EE-FF ``` Der Client kennt zunächst nur die IPv4-Adresse des Servers und sendet eine ARP-Anfrage: ```text Wer hat 192.0.2.80? Antwort bitte an 192.0.2.23. ``` Die Anfrage wird als Ethernet-Broadcast gesendet: ```text FF:FF:FF:FF:FF:FF ``` Der Server antwortet normalerweise per Unicast: ```text 192.0.2.80 befindet sich unter AA:BB:CC:DD:EE:FF. ``` Der Client kann die Zuordnung anschließend vorübergehend in seiner Nachbartabelle speichern.
2. Welche MAC-Adresse wird bei einem entfernten IPv4-Ziel aufgelöst? **Ausgangslage** ```text Client: 192.0.2.23/24 Gateway: 192.0.2.1 Ziel: 198.51.100.20 ``` Das Ziel liegt nicht im lokalen Subnetz `192.0.2.0/24`. Der Client ermittelt daher normalerweise nicht die MAC-Adresse von `198.51.100.20`, sondern die MAC-Adresse des nächsten Routers: ```text ARP-Anfrage: Wer hat 192.0.2.1? ``` Anschließend entsteht vereinfacht folgender Frame: ```text Ethernet-Ziel-MAC: MAC-Adresse des Gateways IP-Zieladresse: 198.51.100.20 ``` | Ebene | Ziel | |---|---| | Ethernet | nächster Router | | IPv4 | entferntes Zielsystem | Die Ethernetadressen können sich an jedem gerouteten Abschnitt ändern. Die IP-Zieladresse bleibt ohne NAT normalerweise bis zum Ziel bestehen.
3. Welche Symptome sprechen für ein ARP- oder Neighbor-Discovery-Problem? - Gateway ist trotz korrekter IP-Konfiguration nicht erreichbar, - Ziel im selben Subnetz ist nicht erreichbar, - Nachbareintrag bleibt unvollständig, - dieselbe IP-Adresse erscheint mit wechselnden MAC-Adressen, - Verbindung funktioniert nur sporadisch, - IP-Adresskonflikt wird gemeldet, - ARP-Anfragen werden gesendet, aber nicht beantwortet, - Neighbor Solicitation wird nicht beantwortet, - IPv6-Adresse bleibt im Zustand `tentative`, - IPv6 Duplicate Address Detection schlägt fehl, - falscher statischer Nachbareintrag ist vorhanden, - Proxy ARP oder Proxy NDP antwortet unerwartet, - Switchport befindet sich im falschen VLAN, - WLAN-Client-Isolation verhindert direkte Kommunikation, - Security-Funktion blockiert ARP- oder NDP-Nachrichten, - virtuelle Maschinen oder Container verwenden unerwartete Nachbareinträge.
4. Wie wird entschieden, ob ARP für das Ziel oder für das Gateway verwendet wird? Zuerst wird die ausgewählte Route geprüft. **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` **Linux** ```bash [RO] ip route get 198.51.100.20 ``` **macOS** ```bash [RO] route -n get 198.51.100.20 ``` **Bewertung** | Routenergebnis | Aufzulösender direkter Nachbar | |---|---| | Ziel gilt als direkt verbunden | Ziel-IP-Adresse | | Route enthält ein Gateway beziehungsweise Next Hop | Gateway-Adresse | | Route verwendet Tunnelinterface | Verhalten abhängig vom Tunnel | | Route fehlt | keine reguläre Weiterleitung möglich | | Ziel wird fälschlich als lokal behandelt | möglicherweise falsches Präfix | Eine falsche Subnetzmaske kann dazu führen, dass ein Client ARP-Anfragen für ein eigentlich entferntes Ziel sendet.
5. Wie wird die IPv4-Nachbartabelle unter Windows angezeigt? **PowerShell** ```powershell [RO] Get-NetNeighbor -AddressFamily IPv4 ``` **Übersichtliche Darstellung** ```powershell [RO] Get-NetNeighbor -AddressFamily IPv4 | Sort-Object InterfaceIndex, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, LinkLayerAddress, State, PolicyStore ``` **Ein bestimmter Nachbar** ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress '192.0.2.1' ``` **Klassischer Befehl** ```cmd [RO] arp -a ``` Bestimmte IP-Adresse suchen: ```cmd [RO] arp -a 192.0.2.1 ``` Die PowerShell-Ausgabe zeigt zusätzlich den Zustand des Eintrags. `arp -a` unterscheidet hauptsächlich zwischen dynamischen und statischen Einträgen.
6. Welche Neighbor-Zustände zeigt Windows? Mögliche Zustände von `Get-NetNeighbor`: | Zustand | Bedeutung | |---|---| | `Unreachable` | Nachbar gilt als nicht erreichbar | | `Incomplete` | Auflösung wurde begonnen, aber noch nicht abgeschlossen | | `Probe` | Erreichbarkeit wird aktiv geprüft | | `Delay` | Prüfung wird kurz verzögert | | `Stale` | Eintrag ist vorhanden, wurde aber länger nicht bestätigt | | `Reachable` | Nachbar wurde kürzlich als erreichbar bestätigt | | `Permanent` | statischer beziehungsweise dauerhafter Eintrag | | `Unknown` | Zustand konnte nicht eindeutig bestimmt werden | Ein Eintrag im Zustand `Stale` ist nicht automatisch fehlerhaft. Er kann bei der nächsten Verwendung erneut geprüft werden. Ein dauerhaft `Incomplete` bleibender Eintrag deutet darauf hin, dass die Adressauflösung nicht erfolgreich abgeschlossen wird.
7. Wie wird die IPv4-Nachbartabelle unter Linux angezeigt? **Alle IPv4-Nachbarn** ```bash [RO] ip -4 neighbour show ``` Kurzform: ```bash [RO] ip -4 neigh ``` **Bestimmte Schnittstelle** ```bash [RO] ip -4 neighbour show dev eth0 ``` **Bestimmte IP-Adresse** ```bash [RO] ip -4 neighbour show 192.0.2.1 ``` **Änderungen live beobachten** ```bash [RO] ip monitor neigh ``` Beenden mit: ```text Strg+C ``` **Klassischer ARP-Befehl** ```bash [RO] arp -an ``` Der ältere Befehl `arp` ist nicht auf jeder Linux-Installation standardmäßig vorhanden. Für moderne Systeme ist `ip neighbour` vorzuziehen.
8. Welche Neighbor-Zustände zeigt Linux? | Zustand | Bedeutung | |---|---| | `INCOMPLETE` | Adressauflösung läuft, aber MAC-Adresse fehlt | | `REACHABLE` | Nachbar wurde kürzlich als erreichbar bestätigt | | `STALE` | Eintrag ist bekannt, Bestätigung ist aber älter | | `DELAY` | Erreichbarkeitsprüfung wird verzögert | | `PROBE` | Nachbar wird aktiv geprüft | | `FAILED` | Auflösung beziehungsweise Erreichbarkeitsprüfung ist fehlgeschlagen | | `NOARP` | für diesen Eintrag wird keine normale Nachbarauflösung durchgeführt | | `PERMANENT` | statischer, dauerhafter Eintrag | **Beispiel** ```text 192.0.2.1 dev eth0 lladdr 00:11:22:33:44:01 REACHABLE ``` | Bestandteil | Bedeutung | |---|---| | `192.0.2.1` | IPv4-Adresse des Nachbarn | | `dev eth0` | verwendete Schnittstelle | | `lladdr` | Link-Layer-Adresse folgt | | `00:11:22:33:44:01` | MAC-Adresse | | `REACHABLE` | aktueller Zustand | **Fehlgeschlagener Eintrag** ```text 192.0.2.80 dev eth0 FAILED ``` Dies bedeutet, dass die Nachbarauflösung beziehungsweise Erreichbarkeitsprüfung fehlgeschlagen ist. Die genaue Ursache kann weiterhin bei VLAN, Zielgerät, Switch, WLAN-Isolation oder Filterung liegen.
9. Wie wird die IPv4-Nachbartabelle unter macOS angezeigt? **Alle ARP-Einträge** ```bash [RO] arp -an ``` **Bestimmte IP-Adresse** ```bash [RO] arp -n 192.0.2.1 ``` **Routingtabelle mit Link-Layer-Einträgen** ```bash [RO] netstat -rn -f inet ``` Beispiel eines vollständigen Eintrags: ```text ? (192.0.2.1) at 00:11:22:33:44:01 on en0 ifscope [ethernet] ``` Beispiel eines unvollständigen Eintrags: ```text ? (192.0.2.80) at (incomplete) on en0 ifscope [ethernet] ``` Ein unvollständiger Eintrag bedeutet, dass keine verwendbare MAC-Adresse ermittelt wurde.
10. Wie wird ein Nachbareintrag kontrolliert erzeugt? Wenn noch kein Eintrag vorhanden ist, kann eine normale Kommunikation zum direkten Nachbarn die Auflösung auslösen. **Windows** ```powershell [TEST] Test-Connection 192.0.2.1 -Count 1 ``` Danach: ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress '192.0.2.1' ``` **Linux** ```bash [TEST] ping -c 1 192.0.2.1 ``` Danach: ```bash [RO] ip neighbour show 192.0.2.1 ``` **macOS** ```bash [TEST] ping -c 1 192.0.2.1 ``` Danach: ```bash [RO] arp -n 192.0.2.1 ``` Auch wenn das Ziel ICMP nicht beantwortet, kann durch die lokale Zustellung ein ARP-Eintrag entstehen. Voraussetzung ist, dass das Betriebssystem das Ziel als direkten Nachbarn behandelt.
11. Wie wird ARP mit arping aktiv geprüft? `arping` sendet aktive ARP-Anfragen auf einer lokalen Ethernetverbindung. Das Werkzeug ist nicht unter jedem Betriebssystem standardmäßig vorhanden. **Linux-Beispiel** ```bash [TEST][PRIV] sudo arping \ -I eth0 \ -c 4 \ 192.0.2.1 ``` | Option | Bedeutung | |---|---| | `-I eth0` | Schnittstelle | | `-c 4` | vier Anfragen | | Zieladresse | direkt zu prüfende lokale IPv4-Adresse | **Einsatzmöglichkeiten** - direkte lokale Erreichbarkeit prüfen, - Antwort-MAC-Adresse bestimmen, - erkennen, ob mehrere Geräte antworten, - ARP unabhängig von ICMP testen. **Einschränkungen** - funktioniert nur für direkt erreichbare IPv4-Nachbarn, - prüft kein geroutetes entferntes Ziel, - kann Sicherheitsüberwachung auslösen, - verschiedene `arping`-Implementierungen besitzen unterschiedliche Optionen, - eine Antwort beweist nicht die Funktion höherer Protokolle. Vor der Verwendung muss die lokale Syntax geprüft werden: ```bash [RO] arping --help ``` oder: ```bash [RO] man arping ```
12. Wie wird ARP mit Wireshark oder TShark untersucht? **Wireshark-Display-Filter** ```text arp ``` Nur Anfragen: ```text arp.opcode == 1 ``` Nur Antworten: ```text arp.opcode == 2 ``` Bestimmte IPv4-Adresse: ```text arp.src.proto_ipv4 == 192.0.2.1 || arp.dst.proto_ipv4 == 192.0.2.1 ``` **Capture-Filter** ```text arp ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "arp" ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "arp" \ -a duration:30 \ -w arp-diagnose.pcapng ``` **ARP-Felder anzeigen** ```bash [RO][SENS] tshark \ -r arp-diagnose.pcapng \ -Y "arp" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e arp.opcode \ -e arp.src.proto_ipv4 \ -e arp.src.hw_mac \ -e arp.dst.proto_ipv4 \ -e arp.dst.hw_mac ``` Die lokal verfügbaren Feldnamen können geprüft werden: ```bash [RO] tshark -G fields | grep -E $'\tarp\.' ```
13. Wie wird eine erfolglose ARP-Auflösung im Paketmitschnitt erkannt? Typisches Muster: ```text Client → Broadcast: Who has 192.0.2.80? Client → Broadcast: Who has 192.0.2.80? Client → Broadcast: Who has 192.0.2.80? Keine Antwort ``` Mögliche Ursachen: - Zielsystem ist ausgeschaltet, - Ziel besitzt eine andere IP-Adresse, - Ziel befindet sich nicht im selben VLAN, - Client befindet sich im falschen VLAN, - Switchport ist falsch konfiguriert, - WLAN-Client-Isolation ist aktiv, - Layer-2-Sicherheitsmechanismus blockiert den Verkehr, - falsche Subnetzmaske lässt ein entferntes Ziel lokal erscheinen, - virtuelle Bridge oder Netzwerkschnittstelle ist falsch verbunden, - Ziel antwortet aufgrund eines lokalen Netzwerkproblems nicht. **Wichtiger Gegencheck** Wenn der Client ARP für eine entfernte Zieladresse sendet, muss zuerst Präfix und Route geprüft werden. Die Ursache liegt dann möglicherweise nicht bei ARP, sondern in einer falschen Subnetzkonfiguration.
14. Was ist Gratuitous ARP? Gratuitous ARP ist eine ARP-Nachricht, bei der ein Gerät eine eigene IPv4-/MAC-Zuordnung ohne vorherige normale Anfrage bekannt gibt oder prüft. Mögliche Zwecke: - Erkennung eines Adresskonflikts, - Aktualisierung von Nachbartabellen, - Übernahme einer virtuellen IP-Adresse, - Hochverfügbarkeits-Failover, - Mitteilung nach einem MAC- oder Portwechsel, - Aktualisierung von Switch- und Hostinformationen. **Typisches Szenario** ```text Firewall A besitzt virtuelle IP 192.0.2.1. Firewall A fällt aus. Firewall B übernimmt 192.0.2.1. Firewall B sendet Gratuitous ARP mit ihrer MAC-Adresse. ``` Clients sollen dadurch die neue Zuordnung lernen. Viele Gratuitous-ARP-Nachrichten sind nicht automatisch schädlich. Sie müssen im Zusammenhang mit Hochverfügbarkeit, Clusterbetrieb, Virtualisierung und Adresskonflikten bewertet werden.
15. Was ist Proxy ARP? Beim Proxy ARP antwortet ein Gerät auf eine ARP-Anfrage für eine andere IPv4-Adresse mit seiner eigenen MAC-Adresse. Vereinfacht: ```text Client fragt: Wer hat 192.0.2.80? Router antwortet: 192.0.2.80 befindet sich unter meiner MAC-Adresse. ``` Der Router übernimmt anschließend die Weiterleitung zum eigentlichen Ziel. Proxy ARP kann bewusst eingesetzt werden, beispielsweise für bestimmte Netzdesigns oder Übergangslösungen. Es kann aber auch Fehlkonfigurationen verbergen. **Hinweise auf Proxy ARP** - mehrere IP-Adressen werden derselben Router-MAC zugeordnet, - ein vermeintlich lokales Ziel wird über einen Router erreicht, - Kommunikation funktioniert trotz ungewöhnlicher Subnetzkonfiguration, - Paketmitschnitt zeigt Antworten eines Routers für fremde IP-Adressen. Proxy ARP darf nicht ohne Prüfung der Netzwerkarchitektur als Angriff oder Fehlfunktion bewertet werden.
16. Welche Aufgabe erfüllt IPv6 Neighbor Discovery? IPv6 verwendet kein ARP. Neighbor Discovery arbeitet mit ICMPv6 und übernimmt mehrere Funktionen: - Auflösung von IPv6-Adresse zu MAC-Adresse, - Erreichbarkeitsprüfung von Nachbarn, - Routererkennung, - Präfixinformationen, - Duplicate Address Detection, - Weiterleitung auf einen besseren Router, - teilweise automatische Adresskonfiguration. Wichtige ICMPv6-Nachrichten: | Typ | Nachricht | Aufgabe | |---:|---|---| | 133 | Router Solicitation | Client fordert Routerinformationen an | | 134 | Router Advertisement | Router teilt Präfixe und Parameter mit | | 135 | Neighbor Solicitation | Nachbarauflösung oder Erreichbarkeitsprüfung | | 136 | Neighbor Advertisement | Antwort beziehungsweise Ankündigung eines Nachbarn | | 137 | Redirect | Router weist auf einen besseren nächsten Hop hin | NDP verwendet Multicast statt des aus IPv4 bekannten Broadcasts.
17. Wie funktioniert die IPv6-Nachbarauflösung? Vereinfachter Ablauf: ```text Client IPv6-Nachbar │ │ │──── Neighbor Solicitation ───────────────>│ │<─── Neighbor Advertisement ───────────────│ │ │ ``` Die Neighbor Solicitation wird normalerweise an eine zur Zieladresse gehörende Solicited-Node-Multicast-Adresse gesendet. **Wichtiger Unterschied zu ARP** | IPv4 | IPv6 | |---|---| | ARP | ICMPv6 Neighbor Discovery | | Ethernet-Broadcast | IPv6-Multicast | | separate ARP-Nachricht | Teil von ICMPv6 | | ARP-Tabelle | IPv6-Nachbartabelle | ICMPv6 darf nicht pauschal blockiert werden. Viele ICMPv6-Nachrichten sind für die grundlegende IPv6-Funktion erforderlich.
18. Wie wird die IPv6-Nachbartabelle unter Windows angezeigt? ```powershell [RO] Get-NetNeighbor -AddressFamily IPv6 ``` Übersicht: ```powershell [RO] Get-NetNeighbor -AddressFamily IPv6 | Sort-Object InterfaceIndex, IPAddress | Format-Table InterfaceAlias, InterfaceIndex, IPAddress, LinkLayerAddress, State ``` Bestimmte Link-Local-Adresse: ```powershell [RO] Get-NetNeighbor ` -InterfaceAlias 'Ethernet' ` -IPAddress 'fe80::1' ``` Bei Link-Local-Adressen ist die Schnittstelle beziehungsweise Scope-ID entscheidend, da `fe80::/10` auf mehreren Interfaces verwendet werden kann. **Alternative klassische Anzeige** ```cmd [RO] netsh interface ipv6 show neighbors ```
19. Wie wird die IPv6-Nachbartabelle unter Linux angezeigt? **Alle IPv6-Nachbarn** ```bash [RO] ip -6 neighbour show ``` **Bestimmte Schnittstelle** ```bash [RO] ip -6 neighbour show dev eth0 ``` **Bestimmte Adresse** ```bash [RO] ip -6 neighbour show 2001:db8:20::20 ``` **Änderungen beobachten** ```bash [RO] ip monitor neigh ``` **Router und Standardroute** ```bash [RO] ip -6 route show default ``` **IPv6-Adressen und deren Zustand** ```bash [RO] ip -6 address show dev eth0 ``` Auf folgende Zustände achten: ```text tentative dadfailed deprecated ``` `dadfailed` weist darauf hin, dass Duplicate Address Detection für diese Adresse fehlgeschlagen ist.
20. Wie wird die IPv6-Nachbartabelle unter macOS angezeigt? **IPv6-Nachbartabelle** ```bash [RO] ndp -an ``` **Bestimmten Nachbarn anzeigen** ```bash [RO] ndp -n fe80::1%en0 ``` Die Schnittstellenangabe `%en0` ist bei Link-Local-Adressen häufig erforderlich. **IPv6-Routingtabelle** ```bash [RO] netstat -rn -f inet6 ``` **IPv6-Konfiguration einer Schnittstelle** ```bash [RO] ifconfig en0 ``` Zu prüfen sind: - Link-Local-Adresse, - globale beziehungsweise interne IPv6-Adressen, - Präfixlängen, - Adresszustände, - Standardrouter, - Nachbareinträge und deren MAC-Adressen.
21. Wie wird IPv6 Neighbor Discovery mit Wireshark untersucht? **Alle Neighbor-Discovery-Nachrichten** ```text icmpv6.type >= 133 && icmpv6.type <= 137 ``` **Router Solicitation** ```text icmpv6.type == 133 ``` **Router Advertisement** ```text icmpv6.type == 134 ``` **Neighbor Solicitation** ```text icmpv6.type == 135 ``` **Neighbor Advertisement** ```text icmpv6.type == 136 ``` **Redirect** ```text icmpv6.type == 137 ``` **Bestimmte IPv6-Adresse** ```text ipv6.addr == 2001:db8:20::20 ``` **Capture-Filter für relevante ICMPv6-Nachrichten** ```text icmp6 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "icmp6" \ -a duration:30 \ -w ipv6-nd.pcapng ``` **TShark-Auswertung** ```bash [RO][SENS] tshark \ -r ipv6-nd.pcapng \ -Y "icmpv6.type >= 133 && icmpv6.type <= 137" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e ipv6.src \ -e ipv6.dst \ -e icmpv6.type ```
22. Was ist Duplicate Address Detection bei IPv6? Bevor eine neue IPv6-Adresse regulär verwendet wird, prüft der Host normalerweise, ob sie bereits auf dem lokalen Link verwendet wird. Vereinfacht: ```text Neuer Host → Neighbor Solicitation für die eigene geplante Adresse → keine widersprechende Antwort: Adresse kann verwendet werden ``` Antwortet ein anderes Gerät, kann die Adresse als doppelt erkannt werden. **Mögliche Zustände** | Zustand | Bedeutung | |---|---| | `tentative` | Prüfung läuft | | `preferred` | Adresse kann normal verwendet werden | | `deprecated` | Adresse wird nicht mehr für neue Verbindungen bevorzugt | | `dadfailed` beziehungsweise `Duplicate` | Konflikt erkannt | **Mögliche Ursachen eines DAD-Fehlers** - tatsächlich doppelte statische IPv6-Adresse, - fehlerhafte virtuelle Netzwerkkonfiguration, - Loop oder reflektierte Pakete, - fehlerhaftes Proxy-NDP-Verhalten, - duplizierte virtuelle Maschine mit identischer Konfiguration, - Sicherheitsgerät beantwortet Anfragen unerwartet. Ein DAD-Fehler darf nicht durch dauerhaftes Abschalten der Konflikterkennung verdeckt werden.
23. Wie werden Router Advertisements in die Diagnose einbezogen? Router Advertisements können unter anderem mitteilen: - verfügbare Router, - Präfixinformationen, - Präfixlänge, - Gültigkeitsdauer, - bevorzugte Dauer, - ob SLAAC verwendet werden kann, - Hinweise auf DHCPv6, - MTU, - Routeninformationen, - weitere IPv6-Parameter. **Typische Fehlerbilder** - Client erhält nur Link-Local-Adresse, - IPv6-Standardroute fehlt, - falsches Präfix wird angekündigt, - nicht autorisierter Router sendet Advertisements, - mehrere Router kündigen widersprüchliche Informationen an, - Router Advertisement erreicht bestimmte VLANs nicht, - ICMPv6 wird gefiltert, - Präfix ist abgelaufen oder falsch konfiguriert. **Windows-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv6 ``` **Linux** ```bash [RO] ip -6 route ``` **macOS** ```bash [RO] netstat -rn -f inet6 ``` Ein vorhandener DHCPv6-Server ersetzt nicht automatisch die Router Advertisements für die Standardrouterinformation.
24. Warum dürfen Nachbartabellen nicht vorschnell geleert werden? Das Leeren einer Nachbartabelle: - verändert den Diagnosezustand, - entfernt möglicherweise den Beleg einer falschen Zuordnung, - erzwingt neue ARP- oder NDP-Auflösungen, - kann Verbindungen kurzfristig unterbrechen, - behebt eine falsche Zuordnung möglicherweise nur vorübergehend, - beseitigt nicht die eigentliche Ursache. Vorher sollten gespeichert werden: **Windows** ```powershell [RO][FILE][SENS] Get-NetNeighbor | Export-Csv 'C:\Temp\nachbartabelle-vorher.csv' ` -NoTypeInformation ` -Encoding UTF8 ``` **Linux** ```bash [RO][FILE][SENS] ip neighbour show \ > /tmp/nachbartabelle-vorher.txt ``` **macOS** ```bash [RO][FILE][SENS] arp -an \ > /tmp/arp-vorher.txt ``` ```bash [RO][FILE][SENS] ndp -an \ > /tmp/ndp-vorher.txt ``` Die Speicherorte müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen.
25. Welche eingreifenden Befehle existieren? **Windows – IPv4-Nachbartabelle leeren** ```cmd [PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache ``` **Linux – dynamische IPv4-Nachbarn einer Schnittstelle leeren** ```bash [PRIV][CHANGE][DISRUPT] sudo ip -4 neighbour flush dev eth0 ``` **Linux – IPv6-Nachbarn einer Schnittstelle leeren** ```bash [PRIV][CHANGE][DISRUPT] sudo ip -6 neighbour flush dev eth0 ``` **macOS – einzelnen ARP-Eintrag entfernen** ```bash [PRIV][CHANGE][DISRUPT] sudo arp -d 192.0.2.1 ``` **macOS – einzelnen IPv6-Nachbareintrag entfernen** ```bash [PRIV][CHANGE][DISRUPT] sudo ndp -d fe80::1%en0 ``` > Diese Befehle sind keine ersten Diagnoseschritte. Bei Remotezugriff kann insbesondere das Entfernen des Gatewayeintrags die aktive Verbindung kurzfristig beeinträchtigen. Syntax und unterstützte Optionen müssen lokal mit der jeweiligen Hilfeseite geprüft werden.
26. Wie werden statische Nachbareinträge bewertet? Statische Einträge können bewusst eingerichtet sein, beispielsweise für: - besondere Appliances, - Hochverfügbarkeitslösungen, - Sicherheitskonzepte, - Testumgebungen, - feste Nachbarzuordnungen. Sie können jedoch veraltet sein, wenn: - Netzwerkkarte ersetzt wurde, - virtuelle Maschine verschoben wurde, - Failover stattgefunden hat, - Gerät eine neue MAC-Adresse verwendet, - Netzwerkarchitektur geändert wurde. **Windows** ```powershell [RO] Get-NetNeighbor | Where-Object State -eq 'Permanent' ``` **Linux** ```bash [RO] ip neighbour show nud permanent ``` **macOS** ```bash [RO] arp -an ``` Statische Einträge dürfen nicht gelöscht werden, bevor Eigentümer, Zweck, Konfigurationsquelle und Rückweg geklärt sind.
27. Wie werden ARP-Spoofing und Neighbor-Discovery-Manipulation erkannt? Mögliche Hinweise: - Gateway-IP wechselt unerwartet zwischen MAC-Adressen, - eine fremde MAC-Adresse beansprucht viele IP-Adressen, - unerwartete Gratuitous-ARP-Nachrichten, - nicht autorisierte Router Advertisements, - mehrere Geräte antworten auf dieselbe Adresse, - Verbindung wird über ein unbekanntes Gerät umgeleitet, - Zertifikatswarnungen treten gleichzeitig auf, - Netzwerküberwachung meldet Dynamic-ARP-Inspection- oder RA-Guard-Verstöße. **Sicheres Vorgehen** 1. aktuelle Nachbartabelle sichern, 2. Zeitpunkt dokumentieren, 3. Switch-MAC-Tabelle und Portzuordnung prüfen, 4. DHCP- und Netzwerkdokumentation vergleichen, 5. Paketmitschnitt nur mit Freigabe erstellen, 6. Hochverfügbarkeits- und Proxyfunktionen ausschließen, 7. Informationssicherheit einbeziehen, 8. verdächtiges Gerät nicht unkoordiniert verändern. Eine gemeinsame MAC-Adresse für mehrere IP-Adressen ist nicht automatisch ein Angriff. Router, Load Balancer, Firewalls, Proxy ARP und Cluster können dieses Muster beabsichtigt erzeugen.
28. Wie wird zwischen Client-, VLAN- und Zielproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur ein Client erhält keine ARP-Antwort | Client, Port oder lokale Sicherheitsregel | | mehrere Clients im VLAN betroffen | VLAN, Switch oder Zielsystem | | andere VLANs erreichen das Ziel | betroffenes VLAN oder Gatewayinterface | | ARP-Anfrage verlässt Client nicht | Clientstack oder Schnittstelle | | Anfrage sichtbar, Antwort fehlt | Ziel, VLAN-Pfad oder Filter | | Antwort erreicht Switch, aber nicht Client | Port, WLAN oder Sicherheitsfunktion | | falsche MAC antwortet | Proxy, Konflikt oder Manipulation | | Gateway wird aufgelöst, Ziel nicht erreichbar | Problem liegt wahrscheinlich nach Layer 2 | | Ziel wird fälschlich per ARP gesucht | falsches Präfix oder falsche Route | | IPv6 NS ohne NA | Ziel, VLAN, Filter oder NDP-Konfiguration | | nur IPv6 betroffen | ICMPv6, RA, NDP oder IPv6-VLAN-Pfad |
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | ARP-Tabelle ist leer | Netzwerk ist defekt | möglicherweise wurde noch kein lokaler Nachbar angesprochen | | Eintrag ist `Stale` | Ziel ist nicht erreichbar | Eintrag wird bei Nutzung erneut geprüft | | Eintrag ist `Incomplete` | Ziel ist ausgeschaltet | VLAN, Präfix und Filter bleiben mögliche Ursachen | | entfernte Ziel-IP fehlt in ARP | Fehler liegt vor | nur der lokale Next Hop wird benötigt | | viele IPs haben dieselbe MAC | Angriff | Router, Proxy ARP oder Cluster möglich | | MAC-Adresse wechselt | Angriff | Failover oder Gerätewechsel möglich | | Ping funktioniert nicht | ARP funktioniert nicht | Nachbartabelle getrennt prüfen | | ARP funktioniert | Anwendung funktioniert | nur lokale Adressauflösung bestätigt | | IPv6 hat keine ARP-Tabelle | IPv6 benötigt keine Auflösung | IPv6 verwendet NDP | | ICMPv6 wird blockiert | nur Ping ist betroffen | zentrale IPv6-Funktionen können ausfallen | | Nachbartabelle wurde geleert und es funktioniert | Ursache wurde behoben | Problem kann nur vorübergehend verdeckt sein | | Gratuitous ARP sichtbar | Manipulation | Konfliktprüfung oder Failover möglich |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | IP-Adresse und Präfix des Clients bestätigen | | 2 | ausgewählte Route zum Ziel bestimmen | | 3 | direkt aufzulösenden Nachbarn identifizieren | | 4 | vorhandene Nachbartabelle unverändert sichern | | 5 | Zustand und MAC-Adresse des Eintrags prüfen | | 6 | mit funktionierendem Referenzclient vergleichen | | 7 | normale Kommunikation zum direkten Nachbarn auslösen | | 8 | Nachbartabelle erneut prüfen | | 9 | bei Bedarf ARP beziehungsweise NDP kontrolliert mitschneiden | | 10 | Anfrage und Antwort auf Client- und Netzseite verfolgen | | 11 | Switchport, VLAN und MAC-Zuordnung prüfen | | 12 | Proxy-, Cluster- und Hochverfügbarkeitsfunktionen berücksichtigen | | 13 | Konflikt oder Manipulationsverdacht eskalieren | | 14 | Tabelle nur nach Beweissicherung gezielt verändern | | 15 | ursprüngliches Fehlerbild erneut testen | | 16 | Ursache und Ergebnis dokumentieren | **Merksatz** ```text Route bestimmen → direkten Nachbarn bestimmen → Tabelle prüfen → Anfrage verfolgen → Antwort verfolgen ```
31. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Nachbarn | `[RO] Get-NetNeighbor -AddressFamily IPv4` | `[RO] ip -4 neighbour` | `[RO] arp -an` | | IPv6-Nachbarn | `[RO] Get-NetNeighbor -AddressFamily IPv6` | `[RO] ip -6 neighbour` | `[RO] ndp -an` | | einzelner IPv4-Nachbar | `[RO] Get-NetNeighbor -IPAddress ZIEL` | `[RO] ip neighbour show ZIEL` | `[RO] arp -n ZIEL` | | einzelne IPv6-Adresse | `[RO] Get-NetNeighbor -IPAddress ZIEL` | `[RO] ip -6 neighbour show ZIEL` | `[RO] ndp -n ZIEL%INTERFACE` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip route get ZIEL` | `[RO] route -n get ZIEL` | | Nachbaränderungen live | PowerShell wiederholt abfragen | `[RO] ip monitor neigh` | wiederholt `arp` beziehungsweise `ndp` | | ARP aktiv testen | normales `Test-Connection` | `[TEST][PRIV] sudo arping -I INTERFACE -c 4 ZIEL` | abhängig von installiertem Werkzeug | | ARP mitschneiden | `[TEST][PRIV][SENS] tshark -i INTERFACE -f "arp"` | gleicher Befehl | gleicher Befehl | | NDP mitschneiden | `[TEST][PRIV][SENS] tshark -i INTERFACE -f "icmp6"` | gleicher Befehl | gleicher Befehl | | ARP-Cache leeren | `[PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache` | `[PRIV][CHANGE][DISRUPT] sudo ip -4 neigh flush dev INTERFACE` | `[PRIV][CHANGE][DISRUPT] sudo arp -d ZIEL` | | IPv6-Nachbarn leeren | nur gezielt nach lokaler Dokumentation | `[PRIV][CHANGE][DISRUPT] sudo ip -6 neigh flush dev INTERFACE` | `[PRIV][CHANGE][DISRUPT] sudo ndp -d ZIEL%INTERFACE` | Die Platzhalter `ZIEL` und `INTERFACE` müssen durch vorher eindeutig bestimmte Werte ersetzt werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Betriebssystem: Schnittstelle: MAC-Adresse: VLAN: IP-KONFIGURATION Client-IPv4: IPv4-Präfix: Client-IPv6: IPv6-Präfix: Standardgateway IPv4: Standardrouter IPv6: ZIEL Zielname: Ziel-IPv4: Ziel-IPv6: Ziel laut Präfix lokal: Ja / Nein Ausgewählte Route: Ausgewählte Quelladresse: Next Hop: Direkt aufzulösender Nachbar: NACHBARTABELLE VOR DEM TEST IPv4-Nachbar: MAC-Adresse: Schnittstelle: Zustand: Dynamisch oder statisch: IPv6-Nachbar: MAC-Adresse: Schnittstelle: Zustand: Dynamisch oder statisch: AKTIVER TEST Verwendeter Test: Startzeit: Endzeit: Anfragen gesendet: Antworten empfangen: PAKETMITSCHNITT ARP Request sichtbar: ARP Reply sichtbar: Neighbor Solicitation sichtbar: Neighbor Advertisement sichtbar: Router Advertisement sichtbar: Quell-MAC: Antwort-MAC: Mehrere Antworten: Gratuitous ARP: Proxy ARP vermutet: DAD fehlgeschlagen: NETZWERKSEITE Switch: Switchport: Port-VLAN: Gelernte Client-MAC: Gelernte Ziel-MAC: MAC wechselt zwischen Ports: Port-Security-Ereignisse: ARP-/NDP-Schutzereignisse: REFERENZCLIENT Hostname: Gleiches VLAN: Nachbar-IP: Nachbar-MAC: Nachbarzustand: Relevante Abweichungen: Arbeitshypothese: Begründung: Originaltabelle gesichert: Durchgeführte Änderung: Rückweg: Abschlussprüfung: Ermittelte Ursache: Sicherheitseskalation erforderlich: Ja / Nein ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetNeighbor](https://learn.microsoft.com/powershell/module/nettcpip/get-netneighbor) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [netsh interface](https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-interface) - [IPv6 Neighbor Discovery](https://learn.microsoft.com/windows-server/networking/technologies/ipv6/ipv6-top) **Linux** - [ip-neighbour – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-neighbour.8.html) - [ip-monitor – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-monitor.8.html) - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - Lokale Befehlsreferenz: `man arping` **Apple** - Lokale Befehlsreferenzen: `man arp`, `man ndp`, `man route`, `man netstat` und `man ifconfig` **Wireshark** - [ARP Display Filter Reference](https://www.wireshark.org/docs/dfref/a/arp.html) - [ICMPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmpv6.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 826 – Address Resolution Protocol](https://www.rfc-editor.org/rfc/rfc826) - [RFC 5227 – IPv4 Address Conflict Detection](https://www.rfc-editor.org/rfc/rfc5227) - [RFC 4861 – Neighbor Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc4861) - [RFC 4862 – IPv6 Stateless Address Autoconfiguration](https://www.rfc-editor.org/rfc/rfc4862) - [RFC 6980 – Security Implications of IPv6 Fragmentation with NDP](https://www.rfc-editor.org/rfc/rfc6980) > Nachbarzustände, Zeitlimits und verfügbare Diagnosefelder hängen vom Betriebssystem, Treiber und Netzwerkdesign ab. Eine fehlende Antwort muss immer zusammen mit Route, Präfix, VLAN und tatsächlichem Messpunkt bewertet werden.
# 3.6 VLAN- und Layer-2-Fehler analysieren Virtual LANs teilen eine physische Switchinfrastruktur in getrennte logische Layer-2-Netze. Geräte in unterschiedlichen VLANs können nicht allein über Switching miteinander kommunizieren. Für die Kommunikation zwischen VLANs ist normalerweise ein Router oder eine Layer-3-Switch-Funktion erforderlich. VLAN-Fehler können dazu führen, dass ein Endgerät zwar einen aktiven Link besitzt, aber keine passende DHCP-Adresse erhält, sein Gateway nicht erreicht oder im falschen logischen Netz landet. > **Grundregel:** Linkstatus und VLAN-Zugehörigkeit sind getrennte Eigenschaften. Ein Switchport kann physisch aktiv und gleichzeitig logisch dem falschen VLAN zugeordnet sein. ---
1. Welche Aufgaben erfüllt ein VLAN? Ein VLAN bildet eine eigene Layer-2-Broadcast-Domain. ```text Physischer Switch ├─ VLAN 10 – Verwaltung ├─ VLAN 20 – Clients ├─ VLAN 30 – VoIP ├─ VLAN 40 – Server └─ VLAN 50 – Gäste ``` Innerhalb eines VLANs werden unter anderem folgende Nachrichten verteilt: - Ethernet-Broadcasts, - ARP-Anfragen, - bestimmte IPv4-Broadcasts, - relevante IPv6-Multicasts, - DHCP-Broadcasts vor einem Relay. Ein Router trennt normalerweise die Broadcast-Domains und vermittelt bei Bedarf zwischen den VLANs. **Beispiel** ```text CLIENT-023 in VLAN 20 192.0.2.23/24 SERVER-01 in VLAN 40 198.51.100.20/24 ``` Die Kommunikation benötigt: ```text VLAN 20 → Gateway für VLAN 20 → Layer-3-Routing und mögliche Firewallregeln → Gateway beziehungsweise Interface für VLAN 40 → VLAN 40 ```
2. Was ist der Unterschied zwischen Access-Port und Trunk? | Porttyp | Typischer Einsatz | Verhalten | |---|---|---| | Access-Port | normales Endgerät | gehört normalerweise zu einem ungetaggten VLAN | | Trunk | Verbindung zwischen Switches, Routern, Servern oder Access Points | transportiert mehrere VLANs | | Hybrid-/General-Port | herstellerabhängige Mischform | kombiniert getaggte und ungetaggte VLANs | | Routed Port | Layer-3-Verbindung | arbeitet nicht als gewöhnlicher Switchport | **Access-Port** ```text Client │ ungetaggter Ethernetframe ▼ Switchport als Access-Port in VLAN 20 ``` Der Client muss normalerweise keine VLAN-ID kennen. Der Switch ordnet eingehende ungetaggte Frames dem konfigurierten Access-VLAN zu. **Trunk** ```text Switch A │ VLAN 10 getaggt │ VLAN 20 getaggt │ VLAN 40 getaggt ▼ Switch B ``` Die VLAN-Zugehörigkeit wird bei IEEE 802.1Q über einen VLAN-Tag im Ethernetframe transportiert.
3. Welche Informationen enthält ein IEEE-802.1Q-Tag? Ein 802.1Q-Tag enthält unter anderem: | Feld | Bedeutung | |---|---| | PCP | Prioritätsinformation nach IEEE 802.1p | | DEI | Drop Eligible Indicator | | VLAN ID | VLAN-Kennung | Die VLAN-ID besitzt 12 Bit. Dadurch sind Werte von 0 bis 4095 darstellbar. Die Randwerte sind reserviert beziehungsweise besitzen Sonderbedeutungen; für reguläre VLAN-Zuordnungen werden typischerweise VLAN-IDs 1 bis 4094 verwendet. **Vereinfachter Ethernetframe** ```text Ohne VLAN-Tag: Ziel-MAC Quell-MAC EtherType Nutzdaten FCS ``` ```text Mit 802.1Q-Tag: Ziel-MAC Quell-MAC 802.1Q-Tag EtherType Nutzdaten FCS ``` Der zusätzliche Tag vergrößert den Ethernetframe um vier Byte. Geräte und Netzwerkpfade müssen entsprechend kompatibel sein.
4. Welche Symptome sprechen für einen VLAN-Fehler? - Client erhält keine DHCP-Adresse, - Client erhält eine Adresse aus dem falschen Subnetz, - Gateway ist nicht erreichbar, - nur Geräte an einem Switchport sind betroffen, - ein Gerät funktioniert an einem anderen Port, - gleiche SSID führt an verschiedenen Access Points in unterschiedliche Netze, - Voice-Telefon funktioniert, angeschlossener PC jedoch nicht, - bestimmte VLANs funktionieren über einen Uplink nicht, - Server ist lokal erreichbar, aber nicht über andere Switches, - ungetaggter Verkehr funktioniert, getaggter Verkehr nicht, - virtuelle Maschine befindet sich im falschen Netz, - Container- oder Hypervisorbridge transportiert das VLAN nicht, - VLAN funktioniert nur in eine Richtung, - nach einer Switchänderung fallen mehrere Geräte eines VLANs aus, - Spanning Tree blockiert den erwarteten Pfad, - Port-Security verhindert den Verkehr, - MAC-Adresse wird an einem unerwarteten Port gelernt, - Native-VLAN-Konfiguration unterscheidet sich zwischen zwei Seiten.
5. Welche Informationen müssen vor einer VLAN-Analyse bekannt sein? | Information | Beispiel | |---|---| | Clienthostname | `CLIENT-023` | | Client-MAC-Adresse | `00-11-22-33-44-55` | | Switch | `SW-ACCESS-01` | | Switchport | Port 17 | | vorgesehene VLAN-ID | 20 | | Portmodus | Access | | erwartetes Subnetz | `192.0.2.0/24` | | erwartetes Gateway | `192.0.2.1` | | erwarteter DHCP-Server beziehungsweise Relay | dokumentierte Infrastruktur | | nächster Uplink | `SW-CORE-01` | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | letzte Änderung | Portkonfiguration wurde angepasst | Bei einem Trunk zusätzlich: - erlaubte VLANs, - ungetaggtes beziehungsweise natives VLAN, - Tagging auf beiden Seiten, - LAG- beziehungsweise Port-Channel-Zugehörigkeit, - Spanning-Tree-Zustand je VLAN, - Uplinkpfad zum Ziel.
6. Wie wird ein Access-Port systematisch geprüft? Auf der Switchseite sollten mindestens folgende Eigenschaften geprüft werden: | Eigenschaft | Prüffrage | |---|---| | administrativer Status | Ist der Port aktiviert? | | operativer Status | Besteht ein Link? | | Portmodus | Ist der Port tatsächlich als Access-Port vorgesehen? | | Access-VLAN | Ist das richtige VLAN zugeordnet? | | Voice-VLAN | Existiert eine zusätzliche Telefonzuordnung? | | MAC-Tabelle | Wird die erwartete MAC-Adresse gelernt? | | Port-Security | Ist die Client-MAC zugelassen? | | Authentifizierung | Ist 802.1X beziehungsweise MAB erfolgreich? | | Spanning Tree | Ist der Port forwarding oder blockiert? | | Fehlerzähler | Steigen CRC-, Drop- oder andere Fehler? | | Beschreibung | Passt die Dokumentation zum angeschlossenen Gerät? | **Erwartetes Muster** ```text Switchport: Port 17 Modus: Access Access-VLAN: 20 MAC-Adresse: 00:11:22:33:44:55 Spanning Tree: Forwarding Port-Security: kein Verstoß ``` Wenn die MAC-Adresse des Clients an diesem Port nicht gelernt wird, müssen Link, Kabel, Clientaktivität, Authentifizierung und Portzustand geprüft werden.
7. Wie wird ein Trunk systematisch geprüft? **Prüfpunkte auf beiden Seiten** | Eigenschaft | Seite A | Seite B | |---|---|---| | Portmodus | Trunk | Trunk | | erlaubte VLANs | identische beziehungsweise kompatible Liste | identische beziehungsweise kompatible Liste | | natives VLAN | abgestimmt | abgestimmt | | Tagging | abgestimmt | abgestimmt | | Linkaggregation | gleiche logische Verbindung | gleiche logische Verbindung | | Geschwindigkeit und Duplex | kompatibel | kompatibel | | Spanning Tree | erwarteter Zustand | erwarteter Zustand | **Typischer Fehler** ```text Switch A erlaubt: VLAN 10, 20, 40 Switch B erlaubt: VLAN 10, 40 ``` Auswirkung: ```text VLAN 20 funktioniert nicht über diesen Trunk. VLAN 10 und VLAN 40 funktionieren weiterhin. ``` Dadurch kann der Eindruck entstehen, der Uplink sei grundsätzlich in Ordnung, obwohl nur ein bestimmtes VLAN fehlt.
8. Was ist ein Native-VLAN- oder ungetaggtes VLAN? Auf manchen Trunks wird ein definiertes VLAN ungetaggt übertragen. Die genaue Bezeichnung und das Verhalten sind hersteller- und konfigurationsabhängig. **Fehlkonfiguration** ```text Switch A: ungetaggtes VLAN 10 Switch B: ungetaggtes VLAN 20 ``` Ein ungetaggter Frame wird dann auf beiden Seiten unterschiedlichen VLANs zugeordnet. Mögliche Auswirkungen: - Geräte landen im falschen Netz, - Managementzugriff verhält sich unerwartet, - DHCP-Antworten stammen aus dem falschen Bereich, - Verkehr wird zwischen unerwarteten Broadcast-Domains übergeben, - Sicherheitsgrenzen werden verletzt. **Wichtig** Die Begriffe `native`, `untagged`, `PVID`, `default VLAN` und `access VLAN` werden von Herstellern nicht immer identisch verwendet. Die Dokumentation des konkret eingesetzten Switches muss geprüft werden.
9. Was ist die PVID? PVID steht für Port VLAN Identifier. Sie bestimmt bei vielen Switchplattformen, welchem VLAN ein ungetaggt eingehender Frame zugeordnet wird. Vereinfacht: ```text Untagged Frame trifft auf Port mit PVID 20 → Switch ordnet den Frame VLAN 20 zu ``` Die PVID ist nicht automatisch dasselbe wie die vollständige Liste aus getaggten und ungetaggten VLAN-Mitgliedschaften. Bei einer Prüfung müssen deshalb getrennt betrachtet werden: - VLAN-Mitgliedschaft des Ports, - getaggt oder ungetaggt, - PVID, - zulässige VLAN-Liste, - Verhalten ausgehender Frames.
10. Wie wird die lokale VLAN-Konfiguration unter Windows geprüft? Normale Endgeräte an Access-Ports besitzen häufig keine lokale VLAN-Konfiguration. Die VLAN-Zuordnung erfolgt dann ausschließlich am Switch. **Adapter und erweiterte Eigenschaften anzeigen** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' ``` Nach VLAN-bezogenen Eigenschaften suchen: ```powershell [RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet' | Where-Object { $_.DisplayName -Match 'VLAN|Priority' -or $_.RegistryKeyword -Match 'VLAN|Priority' } | Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue ``` **Wichtige Einschränkung** Bezeichnungen und Verfügbarkeit hängen vom Netzwerktreiber ab. Ein fehlendes VLAN-Feld bedeutet nicht automatisch, dass keine VLAN-Nutzung möglich ist. **Hyper-V-Adapter anzeigen** Falls Hyper-V installiert und der Administrator dafür zuständig ist: ```powershell [RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS ``` VLAN-Konfiguration virtueller Maschinen: ```powershell [RO][PRIV] Get-VM | Get-VMNetworkAdapter | Get-VMNetworkAdapterVlan ``` Die Hyper-V-Cmdlets sind nur verfügbar, wenn die entsprechenden Hyper-V-Komponenten installiert sind.
11. Wie wird die VLAN-Konfiguration unter Linux geprüft? **Detaillierte Linkinformationen** ```bash [RO] ip -d link show ``` **Bestimmte Schnittstelle** ```bash [RO] ip -d link show dev eth0.20 ``` Beispiel einer VLAN-Schnittstelle: ```text eth0.20@eth0 vlan protocol 802.1Q id 20 ``` | Bestandteil | Bedeutung | |---|---| | `eth0.20` | Name der logischen VLAN-Schnittstelle | | `@eth0` | zugrunde liegende Schnittstelle | | `802.1Q` | VLAN-Tagging-Protokoll | | `id 20` | VLAN-ID 20 | **VLAN-Schnittstellen übersichtlich suchen** ```bash [RO] ip -d -o link show | grep -i 'vlan' ``` **Linux-Bridge-VLANs** Falls Linux Bridging mit VLAN-Filtering verwendet wird: ```bash [RO][PRIV] sudo bridge vlan show ``` Detaillierte Bridge-Links: ```bash [RO][PRIV] sudo bridge -d link show ``` Forwarding-Datenbank beziehungsweise MAC-Tabelle: ```bash [RO][PRIV] sudo bridge fdb show ``` **NetworkManager-Verbindungen** ```bash [RO] nmcli connection show ``` Nur VLAN-Verbindungen: ```bash [RO] nmcli -f NAME,TYPE,DEVICE connection show | grep -i vlan ``` Vollständiges Profil: ```bash [RO][SENS] nmcli connection show "VLAN-VERBINDUNGSNAME" ```
12. Wie wird die VLAN-Konfiguration unter macOS geprüft? **Alle Schnittstellen** ```bash [RO] ifconfig ``` **VLAN-Schnittstellen suchen** ```bash [RO] ifconfig -a | grep -E '^[[:alnum:]].*:|vlan:' ``` Eine VLAN-Schnittstelle kann abhängig von Konfiguration und macOS-Version beispielsweise als `vlan0` erscheinen. **Netzwerkdienste** ```bash [RO] networksetup -listallnetworkservices ``` **Hardwareports** ```bash [RO] networksetup -listallhardwareports ``` Die grafische VLAN-Verwaltung und ihre Verfügbarkeit hängen von macOS-Version, Adapter und Treiber ab. Nicht jeder USB- oder Thunderbolt-Ethernetadapter unterstützt VLAN-Konfigurationen in gleicher Weise. Ein Mac an einem gewöhnlichen Access-Port benötigt normalerweise keine lokale VLAN-ID.
13. Wie wird geprüft, ob der Client im erwarteten VLAN gelandet ist? Der Client sieht die VLAN-ID an einem gewöhnlichen Access-Port normalerweise nicht direkt. Deshalb werden mehrere Informationen kombiniert. | Prüfung | Erwartetes Ergebnis | |---|---| | Switchportkonfiguration | vorgesehenes Access-VLAN | | erhaltene DHCP-Adresse | Subnetz des vorgesehenen VLANs | | Standardgateway | Gateway des vorgesehenen VLANs | | DNS-Server | passende Infrastruktur | | sichtbare Nachbarn | Geräte des erwarteten Netzes | | Switch-MAC-Tabelle | Client-MAC am erwarteten Port und VLAN | | Vergleichsclient | passende Konfiguration am gleichen Standort | **Beispiel** Vorgesehen: ```text VLAN 20 Subnetz 192.0.2.0/24 Gateway 192.0.2.1 ``` Tatsächlich: ```text Clientadresse 198.51.100.45/24 Gateway 198.51.100.1 ``` Dies ist ein starker Hinweis auf: - falsches Access-VLAN, - falsche SSID-zu-VLAN-Zuordnung, - fehlerhafte dynamische VLAN-Zuweisung, - nicht vorgesehenen DHCP-Server, - falsches Netzwerkprofil.
14. Wie wird die MAC-Adresstabelle zur VLAN-Diagnose verwendet? Ein Switch lernt Quell-MAC-Adressen eingehender Frames und ordnet sie normalerweise einem Port und VLAN zu. **Zu prüfende Zuordnung** ```text MAC-Adresse: 00:11:22:33:44:55 VLAN: 20 Port: 17 ``` **Mögliche Auffälligkeiten** | Beobachtung | Mögliche Ursache | |---|---| | MAC nicht gelernt | kein Verkehr, Linkproblem, Authentifizierung oder Port blockiert | | MAC im falschen VLAN | Port- oder Taggingfehler | | MAC am falschen Port | Dokumentationsfehler, Umstecken oder Layer-2-Schleife | | MAC wechselt schnell zwischen Ports | Schleife, redundanter Pfad oder Fehlverkabelung | | viele MACs an Clientport | Switch, Bridge, Hypervisor oder unerlaubtes Gerät angeschlossen | | nur Telefon-MAC sichtbar | PC-Port des Telefons oder Daten-VLAN prüfen | | MAC erscheint hinter Uplink | Client befindet sich an nachgelagertem Switch | Die konkreten Befehle zur MAC-Tabelle sind herstellerabhängig. Suchkriterium sollte die zuvor eindeutig ermittelte Client-MAC-Adresse sein.
15. Wie werden Voice-VLAN und angeschlossener PC berücksichtigt? Ein IP-Telefon kann zwei logische Verbindungen bereitstellen: ```text Switchport → Voice-VLAN für Telefon → Data-VLAN für PC hinter dem Telefon ``` Mögliche Fehlerbilder: - Telefon funktioniert, PC erhält keine Adresse, - PC funktioniert, Telefon registriert sich nicht, - beide Geräte erhalten Adressen aus demselben falschen VLAN, - Telefon kündigt dem PC falsche Parameter an, - Voice-VLAN wird nicht über den Trunk transportiert, - Datenport des Telefons ist deaktiviert, - 802.1X- oder MAB-Reihenfolge ist fehlerhaft. Zu prüfen sind: - Access-/Data-VLAN, - Voice-VLAN, - Erkennungsmechanismus des Telefons, - MAC-Adressen beider Geräte, - Authentifizierungsstatus, - DHCP-Bereiche beider VLANs, - Uplink- und Trunkfreigabe.
16. Wie beeinflussen 802.1X und dynamische VLAN-Zuweisung die Diagnose? Bei portbasierter Netzwerkzugangskontrolle kann ein Gerät abhängig von seiner Authentifizierung einem VLAN zugewiesen werden. Vereinfachter Ablauf: ```text Client → Switch oder Access Point → Authentifizierungsdienst → Zugelassenes VLAN ``` Mögliche Ergebnisse: - vorgesehenes Produktions-VLAN, - Gast-VLAN, - Quarantäne-VLAN, - Authentifizierungsfehler, - eingeschränkter Netzwerkzugriff, - MAC-basierte Ersatzauthentifizierung. **Typische Symptome** - korrekte Zugangsdaten, aber falsches VLAN, - Gerät erhält eine Quarantäneadresse, - Verbindung funktioniert erst nach erneuter Anmeldung, - Zertifikat oder Gerätekonto wird abgelehnt, - Telefon und PC werden unterschiedlich behandelt, - Switchport ist aktiv, aber normaler Datenverkehr wird blockiert. **Zu erfassen** - Authentifizierungsmethode, - Benutzer- oder Geräteidentität, - Ergebnis, - zugewiesenes VLAN, - Zeitstempel, - Switchport, - Richtlinie, - Authentifizierungsserver. Das manuelle Setzen eines festen VLANs kann die eigentliche Authentifizierungsstörung verdecken und Sicherheitsrichtlinien umgehen.
17. Wie beeinflusst Spanning Tree die Layer-2-Kommunikation? Spanning Tree verhindert Layer-2-Schleifen, indem redundante Pfade kontrolliert blockiert werden. Mögliche Portzustände beziehungsweise Rollen unterscheiden sich je nach verwendeter STP-Variante und Hersteller. Für die Diagnose ist entscheidend, ob der erwartete Port Nutzdaten weiterleitet. **Mögliche Symptome** - VLAN ist über einen bestimmten Uplink nicht erreichbar, - Verbindung funktioniert nach Verzögerung, - MAC-Adressen wechseln zwischen Ports, - Broadcastlast steigt stark, - Switch-CPU steigt, - Ports werden wiederholt blockiert und freigegeben, - Topology Changes treten häufig auf, - nur einzelne VLANs sind betroffen. **Wichtige Prüfung** ```text Ist der Port für das betroffene VLAN im Zustand Forwarding? ``` Ein physisch aktiver Port kann durch Spanning Tree logisch blockiert sein. **Warnung** ```text [CHANGE][DISRUPT] Spanning Tree darf nicht als schnelle Fehlerbehebung deaktiviert werden. Dadurch können Layer-2-Schleifen und großflächige Netzwerkausfälle entstehen. ```
18. Was ist eine Layer-2-Schleife und wie wird sie erkannt? Ethernetframes besitzen auf Layer 2 kein mit IP-TTL direkt vergleichbares allgemeines Feld, das eine Schleife zuverlässig beendet. Eine Schleife kann deshalb zu einem Broadcast Storm führen. **Mögliche Symptome** - Netzwerk wird plötzlich extrem langsam, - sehr hohe Broadcast- und Multicastrate, - Switch-CPU ist stark ausgelastet, - MAC-Adressen springen zwischen Ports, - mehrere Switchports blinken dauerhaft stark, - DHCP und ARP funktionieren unzuverlässig, - Managementzugriff auf Switches bricht ab, - Spanning-Tree-Topology-Changes treten wiederholt auf. **Sicheres Vorgehen** 1. Netzwerkverantwortliche und Incident-Prozess aktivieren. 2. betroffene Switches und VLANs bestimmen, 3. STP-Ereignisse und MAC-Flapping prüfen, 4. letzte Verkabelungs- und Portänderungen kontrollieren, 5. Schleifenpfad anhand der Topologie eingrenzen, 6. nur koordiniert einen eindeutig bestimmten Port isolieren, 7. Stabilisierung und Ursache dokumentieren. Ein wahlloses Entfernen von Uplinks kann Redundanz und weitere Standorte beeinträchtigen.
19. Wie wirken Port-Security und MAC-Limits? Port-Security kann die Anzahl oder Identität zugelassener MAC-Adressen begrenzen. Mögliche Reaktionen bei einem Verstoß: - Frames verwerfen, - unbekannte MAC-Adressen blockieren, - Ereignis protokollieren, - Port in einen Fehler- oder Shutdownzustand versetzen, - Alarm an das Monitoring senden. **Typische Ursachen eines Verstoßes** - Endgerät wurde ersetzt, - Dockingstation verwendet andere MAC-Adresse, - IP-Telefon und PC erzeugen zwei MAC-Adressen, - Hypervisor oder Bridge sendet mehrere MAC-Adressen, - kleiner Switch wurde unerlaubt angeschlossen, - zufällige beziehungsweise private MAC-Adresse wird verwendet, - konfigurierte Sticky-MAC ist veraltet. **Zu prüfen** - erlaubte Anzahl MAC-Adressen, - aktuell gelernte MAC-Adressen, - fest konfigurierte oder dynamisch gelernte Einträge, - Verstoßzähler, - Reaktionsmodus, - Portstatus, - Endgerätetyp. Port-Security darf nicht einfach deaktiviert werden, ohne Sicherheitszweck und Richtlinie zu prüfen.
20. Wie werden private oder zufällige MAC-Adressen berücksichtigt? Moderne Betriebssysteme können bei WLAN-Verbindungen private beziehungsweise zufällige MAC-Adressen verwenden. Abhängig von Plattform und Konfiguration kann dies auch die Wiedererkennung eines Geräts beeinflussen. Mögliche Auswirkungen: - DHCP-Reservierung greift nicht, - MAC-basierte Authentifizierung schlägt fehl, - Gerät erscheint als neuer Client, - Port- oder WLAN-Richtlinie greift nicht, - Inventarisierung stimmt nicht, - mehrere Leases werden erzeugt. **Prüfung** Die aktuell verwendete MAC-Adresse muss mit folgenden Stellen verglichen werden: - Betriebssystem, - Switch oder Access Point, - DHCP-Lease, - Netzwerkzugangskontrolle, - Inventarsystem. Eine private MAC-Adresse ist nicht automatisch eine Fehlfunktion. Ihre Verwendung kann beabsichtigter Datenschutzstandard oder durch eine Richtlinie gesteuert sein.
21. Wie werden VLAN-Tags mit Wireshark geprüft? **Wireshark-Display-Filter für VLAN-Tags** ```text vlan ``` Bestimmte VLAN-ID: ```text vlan.id == 20 ``` Mehrere VLAN-IDs: ```text vlan.id == 20 || vlan.id == 40 ``` Nur DHCP in VLAN 20: ```text vlan.id == 20 && (udp.port == 67 || udp.port == 68) ``` **Capture-Filter** ```text vlan ``` Bestimmtes VLAN: ```text vlan 20 ``` Bestimmtes VLAN und Host: ```text vlan 20 and host 192.0.2.23 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "vlan 20" \ -a duration:30 \ -w vlan20.pcapng ``` **TShark-Auswertung** ```bash [RO][SENS] tshark \ -r vlan20.pcapng \ -Y "vlan" \ -T fields \ -e frame.time \ -e eth.src \ -e eth.dst \ -e vlan.id \ -e vlan.priority ``` Lokal verfügbare VLAN-Felder: ```bash [RO] tshark -G fields | grep -E $'\tvlan\.' ```
22. Warum ist ein VLAN-Tag im Clientmitschnitt möglicherweise nicht sichtbar? Mögliche Gründe: 1. Der Client befindet sich an einem Access-Port und empfängt ungetaggte Frames. 2. Der Netzwerkadapter entfernt VLAN-Tags in Hardware. 3. Der Treiber übergibt Tags nicht an das Capture-Werkzeug. 4. Offloading beeinflusst die lokale Darstellung. 5. Es wurde auf der falschen Schnittstelle mitgeschnitten. 6. Der Tag befindet sich nur auf einem anderen Abschnitt des Netzwerkweges. 7. Eine virtuelle Bridge oder ein Hypervisor verarbeitet den Tag vor der Aufzeichnung. ```text Kein sichtbarer VLAN-Tag im lokalen Mitschnitt ≠ kein VLAN im Netzwerk ``` Für die Prüfung eines Trunks ist ein geeigneter Messpunkt am Trunk beziehungsweise ein korrekt konfigurierter Mirror-Port erforderlich. Eine solche Aufzeichnung muss autorisiert und datenschutzgerecht durchgeführt werden.
23. Wie werden virtuelle Maschinen und Hypervisor-VLANs berücksichtigt? Mögliche Modelle: **VLAN-Zuordnung am virtuellen Switch** ```text VM sendet ungetaggt → virtueller Switch ordnet VLAN 40 zu → physischer Uplink überträgt VLAN 40 getaggt ``` **VLAN-Zuordnung in der VM** ```text VM erzeugt 802.1Q-Tag → virtueller Switch reicht Tag durch → physischer Trunk transportiert VLAN ``` **Mögliche Fehler** - falsche VLAN-ID am virtuellen Adapter, - physischer Uplink erlaubt VLAN nicht, - virtueller Switch entfernt oder erwartet Tags, - VM und Hypervisor taggen gleichzeitig, - Portgruppe gehört zum falschen VLAN, - Teaming- oder Bond-Uplink ist inkonsistent, - Migration verschiebt VM auf Host ohne passende Trunkfreigabe. Zu prüfen sind: - virtuelle Netzwerkkarte, - Portgruppe beziehungsweise virtueller Switchport, - virtueller Switch, - physischer Uplink, - Switch-Trunk, - erlaubte VLANs auf allen beteiligten Pfaden.
24. Wie werden Linux-Bridge und Container-VLANs berücksichtigt? Vereinfachter Pfad: ```text Container oder VM → virtuelle Schnittstelle → Linux-Bridge → VLAN-Filterung → physische Schnittstelle → Switch-Trunk ``` **Bridge-Übersicht** ```bash [RO][PRIV] sudo bridge link show ``` **VLAN-Zuordnungen** ```bash [RO][PRIV] sudo bridge vlan show ``` **MAC-Tabelle der Bridge** ```bash [RO][PRIV] sudo bridge fdb show ``` **Detaillierte Links** ```bash [RO] ip -d link show ``` Mögliche Fehler: - VLAN-Filtering ist anders konfiguriert als erwartet, - VLAN fehlt am Bridgeport, - PVID ist falsch, - VLAN ist ungetaggt statt getaggt, - physischer Uplink transportiert das VLAN nicht, - Container-MAC wird nicht korrekt gelernt, - Firewall- beziehungsweise Bridge-Filter verwirft Frames. Docker-Standardbridges verwenden nicht automatisch dieselbe VLAN-Struktur wie ein physischer Switch. Das konkrete Container- und Hostnetz muss separat dokumentiert werden.
25. Wie werden VLANs über mehrere Switches verfolgt? **Beispielpfad** ```text CLIENT-023 → SW-ACCESS-01 Port 17 → VLAN 20 → Uplink 1 → SW-DISTRIBUTION-01 → Port-Channel 10 → SW-CORE-01 → Gateway VLAN 20 ``` Für jeden Abschnitt wird geprüft: | Abschnitt | Prüfung | |---|---| | Clientport | Access-VLAN und Client-MAC | | erster Switch | MAC wird im richtigen VLAN gelernt | | Uplink | VLAN 20 ist erlaubt | | nächster Switch | VLAN existiert und ist aktiv | | Linkaggregation | alle Mitglieder sind konsistent | | Spanning Tree | erwarteter Pfad ist forwarding | | Gateway | VLAN-Interface ist aktiv | | Rückweg | führt zurück in dasselbe Client-VLAN | **Methode** Die Client-MAC-Adresse wird vom Access-Port in Richtung Core verfolgt. Die Gateway-MAC-Adresse wird in Gegenrichtung geprüft.
26. Was ist bei Link Aggregation und Port-Channels zu beachten? Mehrere physische Links können zu einer logischen Verbindung gebündelt werden. Mögliche Fehler: - ein Mitglied besitzt andere VLAN-Einstellungen, - nur einige Mitglieder transportieren das betroffene VLAN, - LACP-Zustand ist fehlerhaft, - ein Link ist physisch aktiv, aber nicht im Bundle, - Lastverteilung führt nur bestimmte Verbindungen über den fehlerhaften Link, - native beziehungsweise ungetaggte VLANs unterscheiden sich, - Spanning Tree sieht eine unerwartete Topologie. **Typisches Symptom** ```text Einige Verbindungen funktionieren, andere nicht. Der Fehler hängt von Quell- und Zieladresse oder Sitzung ab. ``` Dies kann auftreten, wenn die Hash-basierte Lastverteilung bestimmte Datenströme über ein fehlerhaftes Mitglied leitet. Auf allen Mitgliedern müssen relevante Konfigurationen konsistent sein. Änderungen dürfen nur über die vorgesehene logische Port-Channel-Konfiguration erfolgen.
27. Wie wird zwischen VLAN-, DHCP- und Routingproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | keine DHCP-Adresse, ARP ebenfalls ohne Antwort | VLAN oder Layer 2 möglich | | DHCP-Adresse aus falschem Subnetz | falsches VLAN oder Rogue-DHCP möglich | | korrekte Adresse, Gateway-MAC nicht auflösbar | VLAN, Gatewayinterface oder Layer 2 | | Gateway erreichbar, anderes VLAN nicht | Routing oder Firewall | | Geräte im selben VLAN kommunizieren | lokales Layer 2 grundsätzlich aktiv | | nur ein Trunkabschnitt betroffen | erlaubte VLANs oder Tagging | | nur neue Clients betroffen | DHCP oder Zugangskontrolle | | nur ein Port betroffen | Access-VLAN, Port-Security oder Verkabelung | | alle Ports eines VLANs betroffen | VLAN, Gateway, STP oder Uplink | | VLAN lokal verfügbar, über Uplink nicht | Trunk oder Spanning Tree | | Ziel wird im falschen Subnetz gesucht | Clientpräfix oder DHCP-Option | Ein Fehler kann mehrere Ebenen gleichzeitig betreffen. Beispielsweise kann ein falsches Access-VLAN zu einer falschen DHCP-Konfiguration führen.
28. Welche eingreifenden Änderungen dürfen nicht vorschnell erfolgen? | Änderung | Risiko | |---|---| | Access-VLAN ändern | Client verliert Verbindung oder landet im falschen Sicherheitsbereich | | Trunk-VLAN hinzufügen | unerwartete Netze werden erweitert | | Trunk-VLAN entfernen | gesamtes VLAN fällt über den Uplink aus | | natives VLAN ändern | ungetaggter Verkehr wird falsch zugeordnet | | Port auf Trunk umstellen | Endgerät kann Tags erhalten oder Sicherheitsgrenze verändert sich | | Port-Security deaktivieren | Zugriffsschutz wird aufgehoben | | 802.1X umgehen | Sicherheitsrichtlinie wird umgangen | | Spanning Tree deaktivieren | Layer-2-Schleife und Broadcast Storm möglich | | Port-Channel verändern | mehrere Verbindungen können ausfallen | | VLAN auf Hypervisor ändern | VM- oder Managementzugriff kann ausfallen | | VLAN-Interface löschen | IP-Kommunikation dieses Netzes fällt aus | Vor jeder Änderung müssen dokumentiert werden: - Ausgangskonfiguration, - betroffener Port, - abhängige Geräte, - vorgesehener Sollzustand, - erwartete Wirkung, - Rückweg, - Wartungs- und Kommunikationsplan.
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Link ist aktiv | VLAN ist korrekt | Link und VLAN sind getrennte Zustände | | Client sieht keinen VLAN-Tag | kein VLAN vorhanden | Access-Port liefert gewöhnlich ungetaggte Frames | | DHCP funktioniert | VLAN ist korrekt | DHCP kann aus falschem VLAN stammen | | Ping im VLAN funktioniert | Trunk ist vollständig korrekt | andere VLANs können fehlen | | VLAN 20 funktioniert lokal | VLAN 20 funktioniert überall | Uplinkpfad separat prüfen | | MAC fehlt in Tabelle | Gerät ist ausgeschaltet | Authentifizierung, Port oder fehlende Aktivität möglich | | MAC wechselt den Port | Angriff | Schleife, Redundanz oder legitime Migration möglich | | STP blockiert Port | STP ist defekt | Blockierung kann notwendiger Schleifenschutz sein | | mehrere MACs am Port | unerlaubter Switch | Telefon, Hypervisor oder Bridge möglich | | gleiche VLAN-ID | gleiches Layer-2-Netz | getrennte Switchdomänen können dieselbe ID verwenden | | Portwechsel behebt Fehler | Switchport ist defekt | anderer Port kann anderes VLAN oder Policy besitzen | | VLAN hinzufügen behebt Fehler | Änderung war korrekt | Sicherheits- und Architekturprüfung bleibt erforderlich |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | Client, MAC-Adresse, Switch und Port bestimmen | | 2 | vorgesehenes VLAN und Subnetz aus Dokumentation ermitteln | | 3 | aktuelle Clientadresse mit dem vorgesehenen VLAN vergleichen | | 4 | Portmodus, Access-VLAN, PVID und Voice-VLAN prüfen | | 5 | Authentifizierungs- und Port-Security-Status prüfen | | 6 | Client-MAC in der Switchtabelle suchen | | 7 | Gateway-MAC und lokale Kommunikation prüfen | | 8 | betroffenen VLAN-Pfad über alle Uplinks verfolgen | | 9 | erlaubte und getaggte VLANs auf beiden Seiten vergleichen | | 10 | Spanning-Tree-Zustand je betroffenem VLAN prüfen | | 11 | Linkaggregation und Mitgliedsports vergleichen | | 12 | virtuelle Switches und Bridges einbeziehen | | 13 | bei Bedarf autorisierten Mitschnitt am geeigneten Messpunkt erstellen | | 14 | Hypothese mit einer einzelnen kontrollierten Änderung testen | | 15 | DHCP, Gateway und Zielverbindung erneut prüfen | | 16 | ursprüngliche Konfiguration beziehungsweise Rückweg dokumentieren | **Merksatz** ```text Client-MAC → Access-Port → VLAN → Uplink → Trunk → Spanning Tree → Gateway ```
31. Kompakte Befehlsübersicht | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapter anzeigen | `[RO] Get-NetAdapter` | `[RO] ip -brief link` | `[RO] ifconfig` | | VLAN-Eigenschaften der NIC | `[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'` | `[RO] ip -d link show` | `[RO] ifconfig -a` | | VLAN-Schnittstellen suchen | treiberabhängig | `[RO] ip -d -o link show \| grep -i vlan` | `[RO] ifconfig -a \| grep -E '^[[:alnum:]].*:|vlan:'` | | Hyper-V-VLANs | `[RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS` | nicht zutreffend | nicht zutreffend | | VM-VLANs | `[RO][PRIV] Get-VM \| Get-VMNetworkAdapter \| Get-VMNetworkAdapterVlan` | hypervisorabhängig | hypervisorabhängig | | Linux-Bridge-VLANs | nicht zutreffend | `[RO][PRIV] sudo bridge vlan show` | nicht standardmäßig gleichwertig | | Linux-Bridge-MAC-Tabelle | nicht zutreffend | `[RO][PRIV] sudo bridge fdb show` | nicht standardmäßig gleichwertig | | VLAN-Tags anzeigen | `[RO][SENS] tshark -r DATEI -Y "vlan"` | gleicher Befehl | gleicher Befehl | | VLAN 20 mitschneiden | `[TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "vlan 20" -a duration:30 -w vlan20.pcapng` | gleicher Befehl | gleicher Befehl | | DHCP in VLAN 20 anzeigen | `[RO][SENS] tshark -r DATEI -Y "vlan.id == 20 && (udp.port == 67 \|\| udp.port == 68)"` | gleicher Befehl | gleicher Befehl | Switchbefehle sind hersteller- und betriebssystemspezifisch. Für produktive Switches müssen ausschließlich die offiziellen Befehle der tatsächlich eingesetzten Plattform verwendet werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Standort: Betroffener Client: Client-MAC: Client-IP: Erwartetes Subnetz: Erwartetes Gateway: Erwartete VLAN-ID: ACCESS-PORT Switch: Switchmodell: Switch-Betriebssystem: Switchport: Portbeschreibung: Administrativer Status: Operativer Status: Portmodus: Access-/Data-VLAN: Voice-VLAN: PVID: Getaggte VLANs: Ungetaggte VLANs: 802.1X-Status: Dynamisch zugewiesenes VLAN: Port-Security-Status: Erlaubte MAC-Anzahl: Gelernte MAC-Adressen: Verstoßzähler: STP-Zustand: Fehlerzähler: UPLINKPFAD Switch 1: Ausgangsport: Erlaubte VLANs: Natives/ungetaggtes VLAN: Port-Channel: STP-Zustand: Switch 2: Eingangsport: Erlaubte VLANs: Natives/ungetaggtes VLAN: Port-Channel: STP-Zustand: Weitere Switches: - GATEWAY Gatewaygerät: VLAN-Interface: Interfacezustand: Gateway-IP: Gateway-MAC: Routing aktiv: Firewall beteiligt: CLIENTPRÜFUNG Erhaltene IPv4-Adresse: Präfix: DHCP-Server: Standardgateway: DNS-Server: Gateway-MAC aufgelöst: Gateway erreichbar: Referenzclient: Relevante Abweichungen: VIRTUELLE INFRASTRUKTUR Hypervisor: Virtueller Switch: Portgruppe: VM-VLAN: Physischer Uplink: Bridge-VLAN: PVID: Getaggt/ungetaggt: PAKETMITSCHNITT Messpunkt: Sichtbare VLAN-ID: Erwartete VLAN-ID: DHCP sichtbar: ARP sichtbar: Unbeabsichtigter Fremdverkehr: Capture-Datei: Hash: Arbeitshypothese: Begründung: Gesicherte Ausgangskonfiguration: Geplante Änderung: Freigabe: Rückweg: Tatsächliches Ergebnis: Abschlussprüfung: Ermittelte Ursache: ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetAdapterAdvancedProperty](https://learn.microsoft.com/powershell/module/netadapter/get-netadapteradvancedproperty) - [Get-VMNetworkAdapterVlan](https://learn.microsoft.com/powershell/module/hyper-v/get-vmnetworkadaptervlan) - [Hyper-V Virtual Switch](https://learn.microsoft.com/windows-server/virtualization/hyper-v-virtual-switch/hyper-v-virtual-switch) - [Hyper-V-Netzwerkvirtualisierung](https://learn.microsoft.com/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server) **Linux** - [ip-link – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-link.8.html) - [bridge – Linux Manual Page](https://man7.org/linux/man-pages/man8/bridge.8.html) - [Linux Bridge VLAN Filtering](https://docs.kernel.org/networking/bridge.html) - [NetworkManager nm-settings](https://networkmanager.dev/docs/api/latest/nm-settings-nmcli.html) **Apple** - Lokale Befehlsreferenzen: `man ifconfig` und `man networksetup` - [Netzwerkstatus auf dem Mac prüfen](https://support.apple.com/guide/mac-help/check-the-status-of-your-network-mchlp2291/mac) **Wireshark** - [IEEE 802.1Q VLAN Display Filter Reference](https://www.wireshark.org/docs/dfref/v/vlan.html) - [Wireshark Capture Filters](https://www.wireshark.org/docs/wsug_html_chunked/ChCapCaptureFilterSection.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [IEEE 802.1Q – Bridges and Bridged Networks](https://standards.ieee.org/ieee/802.1Q/6844/) > VLAN-Begriffe und Konfigurationsmodelle unterscheiden sich zwischen Switchherstellern. Insbesondere die Bedeutung von Access, Trunk, Tagged, Untagged, Native VLAN und PVID muss anhand der offiziellen Dokumentation des konkret eingesetzten Geräts geprüft werden.
# 3.7 Standardgateway und Routing analysieren Routing bestimmt, über welchen Netzwerkpfad ein IP-Paket sein Ziel erreicht. Liegt das Ziel nicht im direkt angeschlossenen Subnetz, benötigt der Client eine passende Route zu einem Router beziehungsweise Next Hop. Das Standardgateway wird verwendet, wenn keine spezifischere Route zum Ziel vorhanden ist. Eine vorhandene Standardroute beweist jedoch nicht, dass sie korrekt ist oder dass der vollständige Hin- und Rückweg funktioniert. > **Grundregel:** Nicht nur prüfen, ob eine Route vorhanden ist. Es muss geprüft werden, welche Route für das konkrete Ziel tatsächlich ausgewählt wird und ob ein passender Rückweg existiert. ---
1. Welche Aufgaben erfüllt ein Router? Ein Router verbindet unterschiedliche IP-Netze. **Beispiel** ```text Clientnetz: 192.0.2.0/24 Servernetz: 198.51.100.0/24 ``` Kommunikationsweg: ```text CLIENT-023 192.0.2.23/24 │ ├─ Standardgateway 192.0.2.1 │ ├─ Router oder Firewall │ └─ SERVER-01 198.51.100.20/24 ``` Der Client erkennt anhand seines Präfixes, dass `198.51.100.20` nicht im lokalen Subnetz liegt. Er übergibt das Paket deshalb an einen Router. Der Router: 1. liest die Ziel-IP-Adresse, 2. sucht die passendste Route, 3. bestimmt Ausgangsschnittstelle und nächsten Hop, 4. verringert bei IPv4 die TTL beziehungsweise bei IPv6 den Hop Limit, 5. leitet das Paket weiter oder verwirft es.
2. Wann wird das Standardgateway verwendet? Die IPv4-Standardroute lautet: ```text 0.0.0.0/0 ``` Die IPv6-Standardroute lautet: ```text ::/0 ``` Sie passen grundsätzlich auf jedes Ziel der jeweiligen Adressfamilie. Spezifischere Routen werden jedoch bevorzugt. **Beispielroutingtabelle** | Zielpräfix | Next Hop | Bedeutung | |---|---|---| | `192.0.2.0/24` | direkt verbunden | lokales Clientnetz | | `198.51.100.0/24` | `192.0.2.254` | spezifische Route zum Servernetz | | `0.0.0.0/0` | `192.0.2.1` | Standardroute | Für das Ziel `198.51.100.20` wird die spezifische `/24`-Route verwendet und nicht die Standardroute.
3. Was bedeutet Longest Prefix Match? Wenn mehrere Routen zu einem Ziel passen, wird grundsätzlich die Route mit dem längsten passenden Präfix bevorzugt. **Beispiel** | Route | Passt auf `198.51.100.20`? | Präfixlänge | |---|---:|---:| | `0.0.0.0/0` | Ja | 0 | | `198.51.0.0/16` | Ja | 16 | | `198.51.100.0/24` | Ja | 24 | | `198.51.100.20/32` | Ja | 32 | Ausgewählt wird: ```text 198.51.100.20/32 ``` Reihenfolge: ```text Hostroute /32 vor Netzroute /24 vor gröberer Netzroute /16 vor Standardroute /0 ``` Eine Route mit niedrigerer Metrik gewinnt nicht gegen eine passendere Route mit längerem Präfix. Die Metrik wird für konkurrierende, in der Auswahl gleich geeignete Routen relevant.
4. Welche Bestandteile besitzt ein Routingtabelleneintrag? | Bestandteil | Bedeutung | |---|---| | Zielpräfix | Netz oder Host, für den die Route gilt | | Präfixlänge | Genauigkeit der Route | | Next Hop | nächster Router | | Ausgangsschnittstelle | verwendeter Adapter | | Quelladresse | für das Ziel ausgewählte lokale Adresse | | Metrik | Kosten beziehungsweise Priorität | | Protokoll oder Ursprung | statisch, verbunden, DHCP oder Routingprotokoll | | Gültigkeitsdauer | bei dynamischen Einträgen möglicherweise begrenzt | | Routingtabelle | bei Policy Routing eine bestimmte Tabelle | **Beispiel** ```text 198.51.100.0/24 via 192.0.2.254 dev eth0 metric 100 ``` | Feld | Wert | |---|---| | Ziel | `198.51.100.0/24` | | Next Hop | `192.0.2.254` | | Schnittstelle | `eth0` | | Metrik | `100` |
5. Welche Symptome sprechen für einen Routingfehler? - lokale Ziele sind erreichbar, entfernte Ziele jedoch nicht, - Standardgateway fehlt, - falsches Gateway ist eingetragen, - nur ein bestimmtes Zielnetz ist nicht erreichbar, - VPN übernimmt unerwartet die Standardroute, - Zugriff funktioniert nur ohne VPN, - Hinweg funktioniert, Rückweg fehlt, - Traceroute zeigt eine Schleife, - Pakete erreichen die falsche Firewall, - Verbindung funktioniert nur in eine Richtung, - mehrere Standardrouten konkurrieren, - Route zeigt auf eine falsche Schnittstelle, - falsche Quelladresse wird ausgewählt, - ein neues Subnetz ist noch nicht überall bekannt, - Route wurde zusammengefasst und enthält ein nicht erreichbares Teilnetz, - dynamische Route wurde zurückgezogen, - Routingtabelle unterscheidet sich zwischen redundanten Routern, - IPv4 funktioniert, IPv6 jedoch nicht.
6. Wie wird die Routingtabelle unter Windows angezeigt? **IPv4-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, InterfaceAlias, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric, Protocol, State ``` **IPv6-Routen** ```powershell [RO] Get-NetRoute -AddressFamily IPv6 | Sort-Object DestinationPrefix, RouteMetric | Format-Table ifIndex, InterfaceAlias, DestinationPrefix, NextHop, RouteMetric, InterfaceMetric, Protocol, State ``` **Klassische Gesamtausgabe** ```cmd [RO] route print ``` Nur IPv4: ```cmd [RO] route print -4 ``` Nur IPv6: ```cmd [RO] route print -6 ``` **Standardrouten** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table InterfaceAlias, ifIndex, NextHop, RouteMetric, InterfaceMetric, Protocol ``` IPv6: ```powershell [RO] Get-NetRoute -DestinationPrefix '::/0' ```
7. Wie wird unter Windows die tatsächlich ausgewählte Route geprüft? ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.20 ``` Die Ausgabe enthält typischerweise: - passende Route, - Ausgangsschnittstelle, - Next Hop, - lokale Quelladresse. **Zusätzliche Schnittstelleninformationen** ```powershell [RO] Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table ifIndex, InterfaceAlias, AddressFamily, ConnectionState, InterfaceMetric, AutomaticMetric ``` **Konkrete Zielprüfung** ```powershell [TEST] Test-NetConnection 198.51.100.20 -InformationLevel Detailed ``` Mit Traceroute: ```powershell [TEST] Test-NetConnection 198.51.100.20 ` -TraceRoute ` -InformationLevel Detailed ``` `Test-NetConnection -TraceRoute` prüft den Pfad mit den von Windows dafür vorgesehenen Diagnosemechanismen. Ein nicht antwortender Hop beweist nicht automatisch einen Weiterleitungsfehler.
8. Wie wird die Routingtabelle unter Linux angezeigt? **IPv4-Hauptroutingtabelle** ```bash [RO] ip -4 route show ``` **IPv6-Hauptroutingtabelle** ```bash [RO] ip -6 route show ``` **Alle Routingtabellen** ```bash [RO] ip route show table all ``` IPv6: ```bash [RO] ip -6 route show table all ``` **Standardroute** ```bash [RO] ip route show default ``` IPv6: ```bash [RO] ip -6 route show default ``` **Detaillierte Routen** ```bash [RO] ip -details route show ``` **Routingregeln** ```bash [RO] ip rule show ``` Policy Routing kann dazu führen, dass eine andere Tabelle verwendet wird als die gewöhnliche `main`-Tabelle.
9. Wie wird unter Linux die tatsächlich ausgewählte Route geprüft? ```bash [RO] ip route get 198.51.100.20 ``` Beispiel: ```text 198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23 uid 1000 ``` | Feld | Bedeutung | |---|---| | Ziel | `198.51.100.20` | | `via` | nächster Router | | `dev` | Ausgangsschnittstelle | | `src` | ausgewählte Quelladresse | | `uid` | bei entsprechender Ausgabe berücksichtigte Benutzer-ID | **Route mit bestimmter Quelladresse prüfen** ```bash [RO] ip route get 198.51.100.20 from 192.0.2.23 ``` **IPv6** ```bash [RO] ip -6 route get 2001:db8:20::20 ``` Bei Policy Routing kann die Routenauswahl von folgenden Merkmalen abhängen: - Quelladresse, - Zieladresse, - Eingangsinterface, - Firewallmarkierung, - Benutzerkennung, - Routingtabelle, - Priorität der Regel.
10. Wie wird die Routingtabelle unter macOS angezeigt? **IPv4-Routen** ```bash [RO] netstat -rn -f inet ``` **IPv6-Routen** ```bash [RO] netstat -rn -f inet6 ``` **IPv4-Standardroute** ```bash [RO] route -n get default ``` **Ausgewählte Route zu einem IPv4-Ziel** ```bash [RO] route -n get 198.51.100.20 ``` **Ausgewählte Route zu einem IPv6-Ziel** ```bash [RO] route -n get -inet6 2001:db8:20::20 ``` Typische Felder: | Feld | Bedeutung | |---|---| | `destination` | Ziel | | `gateway` | Next Hop | | `interface` | Ausgangsschnittstelle | | `flags` | Routeneigenschaften | | `recvpipe`/`sendpipe` | interne Routinginformationen | | `mtu` | routenbezogene MTU, falls vorhanden | VPN-Verbindungen erscheinen unter macOS häufig über Tunnelinterfaces wie `utun0`, `utun1` oder weitere nummerierte Varianten.
11. Wie werden mehrere Standardrouten bewertet? Mehrere Standardrouten können beabsichtigt sein: - LAN und WLAN gleichzeitig, - VPN-Full-Tunnel, - redundante Router, - mehrere Internetanschlüsse, - virtuelle Adapter, - Mobilfunk-Fallback. **Windows** ```powershell [RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object RouteMetric, InterfaceMetric | Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetric, Protocol ``` **Linux** ```bash [RO] ip route show default ``` ```bash [RO] ip rule show ``` **macOS** ```bash [RO] netstat -rn -f inet | grep '^default' ``` **Prüffragen** 1. Welche Route gehört zur aktiven Schnittstelle? 2. Welche Route besitzt die wirksame Priorität? 3. Gibt es spezifischere VPN-Routen? 4. Welche Quelladresse wird ausgewählt? 5. Passt der Rückweg zu dieser Quelladresse? 6. Ist eine Route nur ein verbliebener Eintrag eines getrennten Adapters? 7. Wird IPv4 anders als IPv6 geroutet? Die numerische Metrik ist nicht zwischen verschiedenen Betriebssystemen direkt vergleichbar.
12. Wie beeinflussen Schnittstellen- und Routenmetrik die Auswahl unter Windows? Windows berücksichtigt unter anderem: - Präfixlänge, - Routenmetrik, - Schnittstellenmetrik. Vereinfacht kann bei gleich spezifischen Routen eine Kombination aus Routen- und Schnittstellenmetrik die bevorzugte Route beeinflussen. **Schnittstellenmetriken** ```powershell [RO] Get-NetIPInterface | Format-Table InterfaceAlias, AddressFamily, AutomaticMetric, InterfaceMetric, ConnectionState ``` **Routenmetriken** ```powershell [RO] Get-NetRoute | Format-Table DestinationPrefix, NextHop, InterfaceAlias, RouteMetric, InterfaceMetric ``` Eine aktivierte automatische Metrik lässt Windows den Wert anhand der Schnittstelleneigenschaften bestimmen. ```text [CHANGE][DISRUPT] Metriken nicht verändern, nur weil eine numerische Reihenfolge unerwartet aussieht. Zuerst die tatsächlich gewählte Route mit Find-NetRoute prüfen. ```
13. Was ist eine Hostroute? Eine Hostroute gilt nur für eine einzelne Zieladresse. **IPv4** ```text 198.51.100.20/32 ``` **IPv6** ```text 2001:db8:20::20/128 ``` Beispiel: ```text 198.51.100.20/32 via 192.0.2.254 0.0.0.0/0 via 192.0.2.1 ``` Nur das Ziel `198.51.100.20` wird über `192.0.2.254` geleitet. Andere Ziele verwenden weiterhin die Standardroute. **Mögliche Fehler** - alte Hostroute zeigt auf nicht mehr vorhandenen Router, - VPN legt eine Hostroute zum VPN-Gateway an, - Sicherheitssoftware installiert spezifische Routen, - statische Testkonfiguration wurde nicht entfernt, - Route gilt nur für IPv4, während die Anwendung IPv6 verwendet.
14. Was ist Policy-Based Routing? Bei gewöhnlichem Routing wird hauptsächlich die Zieladresse betrachtet. Policy-Based Routing kann zusätzliche Kriterien verwenden: - Quellnetz, - eingehende Schnittstelle, - Benutzer oder Anwendung, - DSCP beziehungsweise Traffic-Klasse, - Firewallmarkierung, - Dienst oder Port, - Mandant oder VRF. **Linux-Regeln anzeigen** ```bash [RO] ip rule show ``` Beispielstruktur: ```text 0: from all lookup local 100: from 192.0.2.0/24 lookup firma-a 32766: from all lookup main 32767: from all lookup default ``` Tabelle anzeigen: ```bash [RO] ip route show table firma-a ``` Falls die Tabelle nur eine Nummer besitzt: ```bash [RO] ip route show table 100 ``` Eine korrekte Route in der `main`-Tabelle beweist bei Policy Routing nicht, dass sie für den konkreten Datenstrom verwendet wird.
15. Was ist eine VRF und warum ist sie für die Diagnose wichtig? Eine Virtual Routing and Forwarding Instance stellt eine getrennte Routingdomäne bereit. Vereinfacht: ```text Router ├─ VRF FIRMA-A │ └─ eigene Routingtabelle └─ VRF FIRMA-B └─ eigene Routingtabelle ``` Dieselben IP-Netze können in getrennten VRFs vorkommen, ohne direkt miteinander verbunden zu sein. **Mögliche Fehler** - Schnittstelle befindet sich in falscher VRF, - Route existiert nur in einer anderen VRF, - Firewall prüft falschen Kontext, - Managementzugriff verwendet eine getrennte VRF, - Ping ohne VRF-Angabe testet den falschen Pfad, - Rückroute wurde in falscher Tabelle eingetragen. Linux-VRFs anzeigen, falls verwendet: ```bash [RO] ip -d link show type vrf ``` Routen einer Tabelle: ```bash [RO] ip route show table TABELLENNAME ``` Befehle auf Routern und Firewalls sind herstellerabhängig und müssen im korrekten Routingkontext ausgeführt werden.
16. Wie wird ein fehlender Rückweg erkannt? Für eine funktionierende Kommunikation werden Hin- und Rückweg benötigt. ```text Hinweg: CLIENT-023 → Router A → SERVER-01 Rückweg: SERVER-01 → Router B → CLIENT-023 ``` Ein Rückweg darf anders verlaufen, muss aber: - zur Quelladresse führen, - von Firewalls zugelassen werden, - bei zustandsbehafteten Komponenten zur Sitzung passen, - notwendige NAT-Zustände berücksichtigen. **Typische Symptome eines fehlenden Rückwegs** - SYN verlässt Client, aber keine Antwort kommt zurück, - Anfrage erreicht Server, Antwort verlässt Server, - Antwort kommt an falscher Schnittstelle an, - nur Verbindungen aus einer Richtung funktionieren, - lokale Serverzugriffe funktionieren, entfernte nicht, - Ping vom Client zum Server schlägt fehl, vom Server zum Client ebenfalls, - Firewall meldet ungültigen oder fehlenden Sitzungszustand. **Prüfung** 1. Clientroute zum Server prüfen. 2. Serverroute zur Clientadresse prüfen. 3. Zwischenrouter und Firewalls prüfen. 4. NAT-Zustände berücksichtigen. 5. Paketmitschnitt an mindestens zwei geeigneten Messpunkten vergleichen.
17. Was ist asymmetrisches Routing? Beim asymmetrischen Routing nehmen Hin- und Rückweg unterschiedliche Pfade. ```text Hinweg: Client → Firewall A → Server Rückweg: Server → Firewall B → Client ``` Asymmetrisches Routing ist nicht grundsätzlich fehlerhaft. Es kann jedoch problematisch sein für: - zustandsbehaftete Firewalls, - NAT, - Intrusion-Prevention-Systeme, - Load Balancer, - Pfadmessungen, - MTU-Erkennung, - Paketmitschnitte an nur einer Stelle. **Typische Hinweise** - Firewall A sieht nur Clientpakete, - Firewall B sieht nur Serverantworten, - zustandslose Tests funktionieren, TCP jedoch nicht, - einzelne Verbindungen funktionieren abhängig von Lastverteilung, - Traceroute in Gegenrichtung zeigt anderen Pfad, - Failover führte zu unterschiedlichen Routingtabellen. Die ausführliche Analyse asymmetrischer Wege wird auf Seite 3.17 behandelt.
18. Wie wird der Netzwerkpfad mit tracert oder traceroute untersucht? **Windows** Ohne Namensauflösung: ```cmd [TEST] tracert -d 198.51.100.20 ``` Mit Zielname: ```cmd [TEST] tracert app.example.intern ``` **Linux** ```bash [TEST] traceroute -n 198.51.100.20 ``` **macOS** ```bash [TEST] traceroute -n 198.51.100.20 ``` **Prinzip** Traceroute sendet Pakete mit schrittweise erhöhtem TTL- beziehungsweise Hop-Limit-Wert. ```text TTL 1 → erster Router TTL 2 → zweiter Router TTL 3 → dritter Router ``` Ein Router, an dem der Wert abläuft, kann eine ICMP-Time-Exceeded-Nachricht zurücksenden. **Wichtig** - Router können Diagnosepakete nicht beantworten. - ICMP-Antworten können prioritätsreduziert behandelt werden. - Traceroute-Protokoll und Anwendungsprotokoll können unterschiedlich geroutet oder gefiltert werden. - Der sichtbare Pfad zeigt nur die antwortenden Hops. - Der Rückweg der ICMP-Antwort kann anders verlaufen. - Ein Sternchen beweist keinen Paketverlust des eigentlichen Anwendungsverkehrs.
19. Wie werden Sternchen in einer Traceroute interpretiert? Beispiel: ```text 1 192.0.2.1 1 ms 2 203.0.113.1 5 ms 3 * * * 4 198.51.100.20 12 ms ``` Da Hop 4 antwortet, hat Hop 3 den Verkehr offenbar weitergeleitet. Hop 3 beantwortet nur die Diagnoseanfrage nicht. **Mögliche Gründe für Sternchen** - Router sendet keine TTL-Exceeded-Antwort, - Antwort wird gefiltert, - Rate-Limit für ICMP, - Rückweg der Antwort fehlt, - Gerät priorisiert Weiterleitung höher als Managementantworten, - tatsächlicher Paketverlust. **Erst wenn alle nachfolgenden Hops ebenfalls fehlen**, kann ab dieser Stelle ein Problem vermutet werden. Selbst dann muss geprüft werden, ob das Ziel oder eine Firewall Diagnoseverkehr absichtlich blockiert.
20. Wie wird eine Routing-Schleife erkannt? Eine Routing-Schleife entsteht, wenn Router Pakete wiederholt gegenseitig weiterleiten. Beispiel: ```text Router A → Router B → Router A → Router B ``` Mögliche Traceroute-Ausgabe: ```text 5 192.0.2.1 6 192.0.2.2 7 192.0.2.1 8 192.0.2.2 9 192.0.2.1 ``` **Mögliche Ursachen** - widersprüchliche statische Routen, - fehlerhafte Default Routes, - Routingprotokollproblem, - fehlerhafte Routenumverteilung, - Zusammenfassungsroute ohne passende Detailroute, - Failoverzustand, - falsches Policy Routing, - Tunnelrouting. Die TTL beziehungsweise der Hop Limit verhindert, dass ein einzelnes Paket unbegrenzt zirkuliert. Die Schleife kann trotzdem fortlaufend neue Verbindungen beeinträchtigen.
21. Wie werden Paketverlust und Latenz entlang des Pfades bewertet? **Windows PathPing** ```cmd [TEST] pathping -n 198.51.100.20 ``` PathPing kombiniert eine Pfadermittlung mit längerfristigen Messungen zu den Hops. Die Ausführung kann mehrere Minuten dauern. **Linux und macOS mit MTR** Falls `mtr` installiert und freigegeben ist: ```bash [TEST] mtr -n -r -c 20 198.51.100.20 ``` | Option | Bedeutung | |---|---| | `-n` | keine Namensauflösung | | `-r` | Bericht erzeugen | | `-c 20` | 20 Messzyklen | **Interpretationsregel** ```text Paketverlust an einem Zwischenhop, aber kein Verlust an nachfolgenden Hops → wahrscheinlich nur reduzierte Antwortpriorität dieses Hops. ``` ```text Paketverlust beginnt an einem Hop und setzt sich bis zum Ziel fort → möglicher Verlust ab diesem Pfadabschnitt. ``` Auch dieses Muster ist nur ein Hinweis. Das verwendete Diagnoseprotokoll kann anders behandelt werden als die eigentliche Anwendung.
22. Wie wird ein bestimmter TCP-Dienst entlang des Pfades berücksichtigt? Ein erfolgreicher Traceroute beweist nicht, dass ein bestimmter Port zugelassen ist. **Windows** ```powershell [TEST] Test-NetConnection 198.51.100.20 ` -Port 443 ` -InformationLevel Detailed ``` **Linux** ```bash [TEST] nc -vz -w 5 198.51.100.20 443 ``` **macOS** ```bash [TEST] nc -vz -w 5 198.51.100.20 443 ``` Je nach `nc`-Implementierung können Optionen und Ausgabe abweichen. Lokale Hilfe prüfen: ```bash [RO] nc -h ``` **Bewertung** | Test | Erfolgreich | Fehlgeschlagen | |---|---|---| | Routingprüfung | IP-Pfad grundsätzlich vorhanden | Route, Filter oder Ziel offen | | TCP-Porttest | TCP-Verbindungsaufbau möglich | Filter, Dienst, Rückweg oder Routing offen | | Anwendungstest | Protokollantwort erhalten | Anwendung, Authentifizierung oder Backend offen |
23. Wie wird eine Route mit einem Paketmitschnitt bestätigt? Auf einem Ethernetclient zeigt die Ziel-MAC-Adresse, an welchen direkten Nachbarn das Paket übergeben wird. **Entferntes Ziel** ```text IP-Ziel: 198.51.100.20 Ethernet-Ziel: MAC-Adresse des Gateways ``` **Lokales Ziel** ```text IP-Ziel: 192.0.2.80 Ethernet-Ziel: MAC-Adresse des Zielsystems ``` **Wireshark-Filter** Bestimmtes Ziel: ```text ip.dst == 198.51.100.20 ``` IPv6: ```text ipv6.dst == 2001:db8:20::20 ``` TTL anzeigen beziehungsweise filtern: ```text ip.ttl ``` IPv6 Hop Limit: ```text ipv6.hlim ``` ICMP Time Exceeded: ```text icmp.type == 11 ``` ICMPv6 Time Exceeded: ```text icmpv6.type == 3 ``` Ein lokaler Mitschnitt zeigt nur den Verkehr am ausgewählten Interface. Er beweist nicht, wie nachfolgende Router das Paket weiterleiten.
24. Wie beeinflussen VPN-Verbindungen die Routingtabelle? Ein VPN kann folgende Routen installieren: - neue Standardroute, - spezifische Routen zu internen Netzen, - Hostroute zum VPN-Gateway, - ausgeschlossene lokale Routen, - IPv4- und IPv6-Routen, - richtlinienbasierte Routen. **Full Tunnel** ```text 0.0.0.0/0 → VPN ``` Der gesamte IPv4-Verkehr soll durch den Tunnel geführt werden. **Split Tunnel** ```text 10.0.0.0/8 → VPN 0.0.0.0/0 → lokales Gateway ``` Nur bestimmte Netze werden über das VPN erreicht. **Typische Fehler** - internes Netz fehlt in der Split-Tunnel-Liste, - lokales und entferntes Netz überschneiden sich, - VPN-Route ist spezifischer als lokale Route, - IPv6 wird nicht durch den Tunnel geführt, - Rückroute zum VPN-Adresspool fehlt, - Tunnelinterface bleibt nach Trennung bestehen, - Metriken und Policies wählen falschen Weg. **Vergleich** ```text Routingtabelle vor VPN-Verbindung Routingtabelle nach VPN-Verbindung ``` Dabei dürfen sensible interne Routen nur geschützt dokumentiert werden.
25. Wie werden überlappende Netze erkannt? **Beispiel** Lokales Heimnetz: ```text 192.168.1.0/24 ``` Entferntes Firmennetz über VPN: ```text 192.168.1.0/24 ``` Der Client kann nicht allein anhand der Zieladresse unterscheiden, ob `192.168.1.50` lokal oder über das VPN erreicht werden soll. Mögliche Auswirkungen: - internes Ziel wird im lokalen Netz gesucht, - ARP-Anfragen werden statt VPN-Verkehr erzeugt, - spezifische Hostrouten sind erforderlich, - nur einige Ziele funktionieren, - DNS liefert eine korrekte, aber lokal überlappende Adresse. **Prüfung** **Windows** ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` **Linux** ```bash [RO] ip route get 192.168.1.50 ``` **macOS** ```bash [RO] route -n get 192.168.1.50 ``` Die nachhaltige Lösung erfordert eine abgestimmte Adressplanung oder ein vorgesehenes VPN-/NAT-Konzept. Willkürliche Hostrouten sind häufig nur eine begrenzte Übergangslösung.
26. Wie werden dynamische Routingprotokolle berücksichtigt? Router können Routen dynamisch austauschen, beispielsweise über: - OSPF, - IS-IS, - BGP, - RIP, - herstellerspezifische Verfahren. Zu prüfen sind: - Nachbarschaftsstatus, - empfangene Routen, - angekündigte Routen, - bestes Pfadattribut, - letzte Zustandsänderung, - zurückgezogene Route, - Filter und Route Maps, - Routenumverteilung, - Zusammenfassungen, - gleiche Sicht auf redundanten Routern. **Typische Symptome** - Route fehlt nur auf einem Router, - Pfad ändert sich wiederholt, - nach Failover ist ein Netz nicht erreichbar, - spezifische Route wurde durch Zusammenfassung ersetzt, - Rückroute wird nicht angekündigt, - eine Route wird durch Policy gefiltert. Die konkreten Befehle sind router- und herstellerabhängig. Sie müssen anhand der offiziellen Dokumentation der eingesetzten Plattform ausgewählt werden.
27. Warum dürfen statische Routen nicht vorschnell hinzugefügt werden? Eine zusätzliche statische Route kann ein Symptom kurzfristig umgehen, aber: - dynamischen Routingfehler verdecken, - asymmetrischen Verkehr erzeugen, - falschen Router verwenden, - Sicherheitskontrollen umgehen, - nach einem Failover nicht mehr funktionieren, - zu einer Schleife führen, - nur auf einem einzelnen System gelten, - später vergessen werden. **Vorher dokumentieren** - aktuelle Routingtabelle, - vorgesehene Architektur, - Zielpräfix, - Next Hop, - Schnittstelle, - Metrik, - Persistenz, - Rückroute, - Firewall- und NAT-Auswirkungen, - Rückweg zur Entfernung der Route.
28. Welche eingreifenden Routingbefehle existieren? Die folgenden Beispiele verändern die Routingtabelle und sind keine regulären ersten Diagnoseschritte. **Windows – temporäre Route** ```powershell [PRIV][CHANGE][DISRUPT] New-NetRoute ` -DestinationPrefix '198.51.100.0/24' ` -InterfaceAlias 'Ethernet' ` -NextHop '192.0.2.254' ` -RouteMetric 10 ` -PolicyStore ActiveStore ``` Route entfernen: ```powershell [PRIV][CHANGE][DISRUPT] Remove-NetRoute ` -DestinationPrefix '198.51.100.0/24' ` -InterfaceAlias 'Ethernet' ` -NextHop '192.0.2.254' ``` **Linux – Route hinzufügen** ```bash [PRIV][CHANGE][DISRUPT] sudo ip route add \ 198.51.100.0/24 \ via 192.0.2.254 \ dev eth0 ``` Route entfernen: ```bash [PRIV][CHANGE][DISRUPT] sudo ip route del \ 198.51.100.0/24 \ via 192.0.2.254 \ dev eth0 ``` **macOS – temporäre Route hinzufügen** ```bash [PRIV][CHANGE][DISRUPT] sudo route -n add \ -net 198.51.100.0/24 \ 192.0.2.254 ``` Route entfernen: ```bash [PRIV][CHANGE][DISRUPT] sudo route -n delete \ -net 198.51.100.0/24 \ 192.0.2.254 ``` > Vor der Ausführung müssen Interface, Next Hop, Präfix und Rückweg geprüft werden. Eine falsche Route kann den Remotezugriff sofort unterbrechen. Temporäre Betriebssystemrouten sind außerdem nicht automatisch nach einem Neustart persistent.
29. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Standardroute vorhanden | Routing funktioniert | Next Hop und Rückweg prüfen | | Gateway antwortet auf Ping | alle Ziele sind erreichbar | nur ICMP zum Gateway bestätigt | | Traceroute zeigt Sterne | dort liegt der Fehler | Hop antwortet möglicherweise nur nicht | | hohe Zeit an einem Hop | dieser Hop bremst den Verkehr | Antwortpriorisierung kann abweichen | | Verlust an Zwischenhop | dort gehen Nutzdaten verloren | nachfolgende Hops vergleichen | | Zielroute ist sichtbar | sie wird verwendet | konkrete Auswahl zum Ziel prüfen | | niedrigste Metrik gewinnt immer | Route ist bevorzugt | längstes passendes Präfix zuerst | | Hinweg funktioniert | Verbindung muss funktionieren | Rückweg kann fehlen | | asymmetrischer Pfad | zwingend Fehlkonfiguration | kann beabsichtigt, aber für Stateful-Systeme problematisch sein | | Route hinzufügen behebt Zugriff | Ursache ist gelöst | ursprünglicher Routingfehler kann verdeckt sein | | VPN verbunden | interne Routen sind korrekt | konkrete Zielroute prüfen | | Ping über IP funktioniert | DNS und Anwendung funktionieren | nur IP-/ICMP-Test bestätigt |
30. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | Quell- und Zieladresse eindeutig bestimmen | | 2 | Präfix des Clients prüfen | | 3 | feststellen, ob das Ziel lokal oder entfernt ist | | 4 | aktuelle Routingtabelle unverändert sichern | | 5 | ausgewählte Route zum konkreten Ziel bestimmen | | 6 | Ausgangsschnittstelle, Quelladresse und Next Hop prüfen | | 7 | direkten Next Hop über ARP beziehungsweise NDP kontrollieren | | 8 | Ziel per IP und passendem Dienst testen | | 9 | Pfad mit Traceroute oder vergleichbarem Werkzeug untersuchen | | 10 | Router- und Firewallrouting entlang des Pfades prüfen | | 11 | Rückroute vom Ziel zur tatsächlichen Quelladresse kontrollieren | | 12 | VPN, Policy Routing, VRF und NAT berücksichtigen | | 13 | Routingtabellen redundanter Systeme vergleichen | | 14 | Hypothese mit Mitschnitt oder gezieltem Test bestätigen | | 15 | Änderungen nur mit Freigabe und Rückweg durchführen | | 16 | Funktion und Nebenwirkungen abschließend prüfen | **Merksatz** ```text Ziel bestimmen → Longest Prefix Match → Quelladresse → Interface → Next Hop → Hinweg → Rückweg ```
31. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route` | `[RO] netstat -rn -f inet6` | | klassische Gesamtausgabe | `[RO] route print` | `[RO] ip route show table all` | `[RO] netstat -rn` | | IPv4-Standardroute | `[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0'` | `[RO] ip route show default` | `[RO] route -n get default` | | IPv6-Standardroute | `[RO] Get-NetRoute -DestinationPrefix '::/0'` | `[RO] ip -6 route show default` | `[RO] netstat -rn -f inet6` | | Route zu IPv4-Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip route get ZIEL` | `[RO] route -n get ZIEL` | | Route zu IPv6-Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL` | `[RO] ip -6 route get ZIEL` | `[RO] route -n get -inet6 ZIEL` | | Routingregeln | Windows-Routingauswahl prüfen | `[RO] ip rule show` | Systemroutingtabelle prüfen | | Schnittstellenmetrik | `[RO] Get-NetIPInterface` | Routingmetriken in `ip route` | Routenflags und Dienstreihenfolge | | Pfad ohne DNS | `[TEST] tracert -d ZIEL` | `[TEST] traceroute -n ZIEL` | `[TEST] traceroute -n ZIEL` | | längere Pfadmessung | `[TEST] pathping -n ZIEL` | `[TEST] mtr -n -r -c 20 ZIEL` | `[TEST] mtr -n -r -c 20 ZIEL` | | TCP-Port prüfen | `[TEST] Test-NetConnection ZIEL -Port 443` | `[TEST] nc -vz -w 5 ZIEL 443` | `[TEST] nc -vz -w 5 ZIEL 443` | | Route hinzufügen | `[PRIV][CHANGE][DISRUPT] New-NetRoute …` | `[PRIV][CHANGE][DISRUPT] sudo ip route add …` | `[PRIV][CHANGE][DISRUPT] sudo route -n add …` | | Route entfernen | `[PRIV][CHANGE][DISRUPT] Remove-NetRoute …` | `[PRIV][CHANGE][DISRUPT] sudo ip route del …` | `[PRIV][CHANGE][DISRUPT] sudo route -n delete …` | `mtr` und teilweise `traceroute` sind nicht auf jeder Linux-Installation standardmäßig vorhanden. Fehlende Werkzeuge dürfen nur aus einer freigegebenen Paketquelle installiert werden.
32. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Standort: VLAN: VPN aktiv: Ja / Nein QUELLE Hostname: IPv4-Adresse/Präfix: IPv6-Adresse/Präfix: Schnittstelle: Schnittstellenindex: Schnittstellenmetrik: MAC-Adresse: ZIEL Hostname: Ziel-IPv4: Ziel-IPv6: Zielport: Transportprotokoll: Ziel laut Clientpräfix lokal: Ja / Nein AUSGEWÄHLTE ROUTE Adressfamilie: Zielpräfix: Präfixlänge: Quelladresse: Ausgangsschnittstelle: Next Hop: Routenmetrik: Schnittstellenmetrik: Routenursprung: Routingtabelle/VRF: Policy-Regel: Direkter Nachbar aufgelöst: Nachbar-MAC: STANDARDROUTEN IPv4-Standardroute: IPv4-Next-Hop: IPv4-Schnittstelle: IPv4-Metrik: IPv6-Standardroute: IPv6-Next-Hop: IPv6-Schnittstelle: IPv6-Metrik: PFAD Hop 1: Hop 2: Hop 3: Hop 4: Letzter antwortender Hop: Ziel erreicht: Sternchen oder Timeouts: Schleife erkennbar: Pfadänderungen: RÜCKWEG Tatsächliche Quelladresse: Route des Zielsystems zur Quelle: Next Hop des Zielsystems: Beteiligte Router: Beteiligte Firewalls: Asymmetrischer Weg: NAT beteiligt: Rückantwort am Ziel sichtbar: Rückantwort am Client sichtbar: VPN/POLICY ROUTING Full Tunnel oder Split Tunnel: Vom VPN installierte Route: Überlappendes lokales Netz: Policy-Regel: Separate Routingtabelle: Tunnelinterface: REFERENZVERGLEICH Referenzclient: Ausgewählte Route: Quelladresse: Next Hop: Pfad: Relevante Abweichungen: Arbeitshypothese: Begründung: Gesicherte Routingtabelle: Geplante Änderung: Freigabe: Rückweg: Tatsächliches Ergebnis: Abschlussprüfung: Ermittelte Ursache: ```
33. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute) - [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute) - [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface) - [New-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/new-netroute) - [Remove-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/remove-netroute) - [Test-NetConnection](https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection) - [route](https://learn.microsoft.com/windows-server/administration/windows-commands/route_ws2008) - [tracert](https://learn.microsoft.com/windows-server/administration/windows-commands/tracert) - [pathping](https://learn.microsoft.com/windows-server/administration/windows-commands/pathping) **Linux** - [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html) - [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html) - [ip-vrf – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-vrf.8.html) - [traceroute – Linux Manual Page](https://man7.org/linux/man-pages/man8/traceroute.8.html) **Apple** - Lokale Befehlsreferenzen: `man route`, `man netstat`, `man traceroute` und `man nc` **Wireshark** - [IPv4 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/ip.html) - [IPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/ipv6.html) - [ICMP Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmp.html) - [ICMPv6 Display Filter Reference](https://www.wireshark.org/docs/dfref/i/icmpv6.html) **Standards** - [RFC 1812 – Requirements for IPv4 Routers](https://www.rfc-editor.org/rfc/rfc1812) - [RFC 8200 – IPv6 Specification](https://www.rfc-editor.org/rfc/rfc8200) - [RFC 792 – Internet Control Message Protocol](https://www.rfc-editor.org/rfc/rfc792) - [RFC 4443 – ICMPv6](https://www.rfc-editor.org/rfc/rfc4443) > Routingbefehle auf Firewalls, Routern, Layer-3-Switches und VPN-Gateways sind herstellerabhängig. Für Änderungen muss die offizielle Dokumentation der tatsächlich eingesetzten Plattform verwendet werden.
# 3.8 DNS-Fehler systematisch analysieren Das Domain Name System ordnet Namen technischen Informationen zu. Dazu gehören insbesondere IPv4- und IPv6-Adressen, zuständige Nameserver, Mailserver, Dienstinformationen und Validierungsdaten. Ein DNS-Fehler liegt nahe, wenn ein Dienst über seine IP-Adresse erreichbar ist, aber nicht über seinen Namen. Dieser Vergleich ist jedoch nur dann aussagekräftig, wenn der Dienst einen direkten Zugriff über die IP-Adresse technisch unterstützt. HTTPS, virtuelle Webserver und Load Balancer benötigen häufig zusätzlich den korrekten Hostnamen. > **Grundregel:** Zuerst ermitteln, welcher Name von welchem Client über welchen Resolver aufgelöst werden soll. Danach Antwort, Fehlerstatus, Autorität, Cache, Transportweg und tatsächliche Nutzung durch die Anwendung prüfen. ---
1. Welche Aufgaben erfüllt DNS? DNS kann unter anderem folgende Informationen bereitstellen: | Recordtyp | Aufgabe | |---|---| | `A` | Name zu IPv4-Adresse | | `AAAA` | Name zu IPv6-Adresse | | `CNAME` | Alias auf einen anderen Namen | | `MX` | zuständige Mailserver | | `NS` | autoritative Nameserver einer Zone | | `SOA` | grundlegende Verwaltungsinformationen einer Zone | | `PTR` | IP-Adresse zu Name bei Reverse DNS | | `TXT` | frei definierte Textinformationen und Verifikationsdaten | | `SRV` | Dienst, Zielhost, Port, Priorität und Gewichtung | | `CAA` | zulässige Zertifizierungsstellen | | `DS` | Verweis in der DNSSEC-Vertrauenskette | | `DNSKEY` | öffentlicher DNSSEC-Schlüssel | | `RRSIG` | DNSSEC-Signatur eines Recordsets | **Beispiel** ```text app.example.intern → CNAME proxy.example.intern → A 192.0.2.20 → AAAA 2001:db8:20::20 ``` Die Anwendung kann am Ende IPv4 oder IPv6 verwenden. Daher müssen alle beteiligten Records und der tatsächlich gewählte Zielendpunkt berücksichtigt werden.
2. Welche Symptome sprechen für ein DNS-Problem? - Name kann nicht aufgelöst werden, - IP-Adresse funktioniert, Name jedoch nicht, - falsche IP-Adresse wird zurückgegeben, - interne Namen funktionieren nur im Firmennetz, - Auflösung funktioniert ohne VPN, aber nicht mit VPN, - Auflösung funktioniert mit VPN, aber nicht ohne VPN, - einzelne Clients erhalten andere Antworten, - Antwort wechselt zwischen alten und neuen Adressen, - IPv4 funktioniert, IPv6-Verbindung schlägt fehl, - Reverse-Auflösung fehlt, - DNS-Abfragen laufen in ein Timeout, - Antwort lautet `NXDOMAIN`, `SERVFAIL` oder `REFUSED`, - Suchsuffix erzeugt einen falschen vollständigen Namen, - Anwendung verwendet trotz erfolgreicher manueller Abfrage eine alte Adresse, - Browser und Terminal liefern unterschiedliche Ergebnisse, - nur bestimmte Recordtypen schlagen fehl, - DNSSEC-validierende Resolver lehnen eine Zone ab, - ein nicht vorgesehener DNS-Server wird verwendet, - lokale Hosts-Datei überschreibt die DNS-Antwort.
3. Welche Informationen müssen vor der Analyse erfasst werden? | Information | Beispiel | |---|---| | betroffener Client | `CLIENT-023` | | Betriebssystem | Windows 11 | | betroffener Name | `app.example.intern` | | vollständig qualifizierter Name | `app.example.intern.` | | erwarteter Recordtyp | `A` und `AAAA` | | erwartete IPv4-Adresse | `192.0.2.20` | | erwartete IPv6-Adresse | `2001:db8:20::20` | | verwendeter DNS-Server | `192.0.2.53` | | vorgesehener DNS-Server | `192.0.2.53` | | DNS-Suchdomäne | `example.intern` | | VPN aktiv | Ja | | Fehlerbeginn | `2026-07-31 09:42 CEST` | | letzter funktionierender Zeitpunkt | `2026-07-31 09:35 CEST` | | exakte Fehlermeldung | Name konnte nicht aufgelöst werden | | betroffene Anwendung | Browser | | Vergleichsclient | `CLIENT-024` funktioniert | Zusätzlich sollte geprüft werden: - IPv4- und IPv6-Konnektivität zum Resolver, - Proxy- und VPN-Konfiguration, - lokale Hosts-Datei, - Browserfunktionen wie DNS over HTTPS, - DNS-Cache, - zuständige Zone und autoritative Server.
4. Wie läuft eine rekursive DNS-Auflösung vereinfacht ab? ```text Client → rekursiver Resolver → Root-Nameserver → TLD-Nameserver → autoritativer Nameserver → rekursiver Resolver → Client ``` Für interne Zonen kann der Ablauf anders sein: ```text Client → interner Resolver → interne autoritative Zone → Client ``` Oder über einen Conditional Forwarder: ```text Client → lokaler Resolver → bedingte Weiterleitung für partner.example → Resolver des Partners → autoritative Antwort ``` Caches können den vollständigen Ablauf verkürzen. Eine vorhandene Cacheantwort muss nicht jedes Mal erneut beim autoritativen Server abgefragt werden.
5. Was ist der Unterschied zwischen rekursivem und autoritativem DNS-Server? | Serverrolle | Aufgabe | |---|---| | rekursiver Resolver | ermittelt Antworten im Auftrag des Clients und speichert sie möglicherweise im Cache | | autoritativer Nameserver | liefert verbindliche Daten für eine von ihm verwaltete Zone | | Forwarder | leitet Abfragen an einen anderen Resolver weiter | | Conditional Forwarder | leitet nur bestimmte DNS-Namensräume an definierte Resolver weiter | | Stub Resolver | DNS-Komponente auf dem Endgerät, die Resolver befragt | Ein DNS-Server kann abhängig von Produkt und Konfiguration mehrere Rollen übernehmen. **Wichtige Diagnosefrage** ```text Ist die falsche Antwort bereits auf dem autoritativen Server vorhanden oder entsteht sie erst durch Cache, Weiterleitung oder Clientkonfiguration? ```
6. Welche Ports und Transportprotokolle verwendet DNS? DNS verwendet grundsätzlich: | Transport | Port | Typischer Einsatz | |---|---:|---| | UDP | 53 | viele gewöhnliche Abfragen und Antworten | | TCP | 53 | große Antworten, Wiederholungen nach Truncation und Zonentransfers | | TCP | 853 | DNS over TLS | | TCP | 443 | DNS over HTTPS | | UDP | 443 | DNS over HTTP/3 kann über QUIC verwendet werden | **Wichtig** Eine Firewallregel, die nur UDP 53 erlaubt, kann DNS teilweise funktionieren lassen und bei bestimmten Antworten dennoch Fehler verursachen. Mögliche Ursachen für den Wechsel zu TCP: - Antwort ist für den verwendeten UDP-Transport zu groß, - Antwort wurde als gekürzt markiert, - DNSSEC vergrößert die Antwort, - Anwendung oder Resolver verwendet von Anfang an TCP, - Zonentransfer wird durchgeführt.
7. Wie wird die DNS-Clientkonfiguration unter Windows geprüft? **DNS-Server je Schnittstelle** ```powershell [RO] Get-DnsClientServerAddress | Format-Table InterfaceAlias, InterfaceIndex, AddressFamily, ServerAddresses ``` **DNS-Clientkonfiguration** ```powershell [RO] Get-DnsClient | Format-Table InterfaceAlias, InterfaceIndex, ConnectionSpecificSuffix, RegisterThisConnectionsAddress, UseSuffixWhenRegistering ``` **Vollständige IP-Konfiguration** ```cmd [RO][SENS] ipconfig /all ``` Zu prüfen sind: - DNS-Server, - verbindungsspezifisches DNS-Suffix, - primäres DNS-Suffix, - DNS-Suffixsuchliste, - Schnittstellenreihenfolge, - VPN-Adapter, - virtuelle Adapter. **DNS-over-HTTPS-Konfiguration** Je nach Windows-Version: ```powershell [RO] Get-DnsClientDohServerAddress ``` Das Cmdlet kann abhängig von Windows-Version und installiertem PowerShell-Modul nicht verfügbar sein.
8. Wie werden DNS-Abfragen unter Windows mit Resolve-DnsName durchgeführt? **Standardabfrage** ```powershell [TEST] Resolve-DnsName app.example.intern ``` **A-Record** ```powershell [TEST] Resolve-DnsName app.example.intern -Type A ``` **AAAA-Record** ```powershell [TEST] Resolve-DnsName app.example.intern -Type AAAA ``` **CNAME** ```powershell [TEST] Resolve-DnsName app.example.intern -Type CNAME ``` **MX** ```powershell [TEST] Resolve-DnsName example.com -Type MX ``` **SRV** ```powershell [TEST] Resolve-DnsName ` _ldap._tcp.example.intern ` -Type SRV ``` **PTR beziehungsweise Reverse DNS** ```powershell [TEST] Resolve-DnsName 192.0.2.20 -Type PTR ``` **Bestimmten DNS-Server abfragen** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -Server 192.0.2.53 ``` **Nur DNS verwenden und zusätzliche lokale Namensauflösungsmechanismen vermeiden** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -DnsOnly ``` **TCP erzwingen** ```powershell [TEST] Resolve-DnsName ` app.example.intern ` -Type A ` -TcpOnly ``` Mit `-TcpOnly` kann geprüft werden, ob DNS über TCP 53 funktioniert.
9. Wie wird nslookup unter Windows, Linux und macOS verwendet? **Einfache Abfrage** ```bash [TEST] nslookup app.example.intern ``` **Bestimmten Server abfragen** ```bash [TEST] nslookup app.example.intern 192.0.2.53 ``` **Bestimmten Recordtyp abfragen** ```bash [TEST] nslookup -type=AAAA app.example.intern 192.0.2.53 ``` ```bash [TEST] nslookup -type=MX example.com 192.0.2.53 ``` **Reverse DNS** ```bash [TEST] nslookup 192.0.2.20 192.0.2.53 ``` `nslookup` ist weit verbreitet, bildet aber nicht zwingend denselben Auflösungsweg ab wie eine Anwendung oder der native Systemresolver. Für eine vollständige Analyse sollten zusätzlich die betriebssystemspezifischen Werkzeuge verwendet werden.
10. Wie wird die DNS-Clientkonfiguration unter Linux geprüft? **systemd-resolved** ```bash [RO] resolvectl status ``` Bestimmte Schnittstelle: ```bash [RO] resolvectl status eth0 ``` Zu prüfen sind: - aktueller DNS-Server, - konfigurierte DNS-Server, - DNS-Domänen, - Default-Route für DNS, - DNSSEC-Einstellung, - DNS-over-TLS-Einstellung, - schnittstellenbezogene Resolver. **Resolverdatei** ```bash [RO] cat /etc/resolv.conf ``` Prüfen, ob es sich um einen symbolischen Link handelt: ```bash [RO] ls -l /etc/resolv.conf ``` Beispiel: ```text nameserver 127.0.0.53 search example.intern options edns0 trust-ad ``` `127.0.0.53` kann auf den lokalen Stub Resolver von systemd-resolved verweisen. Der tatsächlich verwendete Upstream-DNS-Server muss dann mit `resolvectl status` bestimmt werden. **NetworkManager** ```bash [RO][SENS] nmcli device show | grep -E 'GENERAL.DEVICE|IP4.DNS|IP6.DNS|IP4.DOMAIN|IP6.DOMAIN' ```
11. Wie werden DNS-Abfragen unter Linux mit resolvectl durchgeführt? **Systemresolver verwenden** ```bash [TEST] resolvectl query app.example.intern ``` **Bestimmten Recordtyp abfragen** ```bash [TEST] resolvectl query \ --type=A \ app.example.intern ``` ```bash [TEST] resolvectl query \ --type=AAAA \ app.example.intern ``` **Bestimmte Schnittstelle verwenden** ```bash [TEST] resolvectl query \ --interface=eth0 \ app.example.intern ``` **Resolverstatistik** ```bash [RO] resolvectl statistics ``` **Serverfunktionen zurücksetzen beziehungsweise Cache leeren** Diese Befehle verändern den Resolverzustand und gehören nicht zur ersten Analyse: ```bash [PRIV][CHANGE] sudo resolvectl reset-statistics ``` ```bash [PRIV][CHANGE] sudo resolvectl flush-caches ``` Vor dem Leeren sollte die vorhandene Antwort dokumentiert werden.
12. Wie werden DNS-Abfragen mit dig durchgeführt? `dig` ist nicht auf jedem System standardmäßig installiert. **A- und AAAA-Abfrage** ```bash [TEST] dig app.example.intern A ``` ```bash [TEST] dig app.example.intern AAAA ``` **Bestimmten Resolver abfragen** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **Kurze Ausgabe** ```bash [TEST] dig +short @192.0.2.53 app.example.intern A ``` **Vollständige Antwort mit Kommentaren** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **TCP verwenden** ```bash [TEST] dig +tcp @192.0.2.53 app.example.intern A ``` **DNSSEC-Daten anfordern** ```bash [TEST] dig +dnssec @192.0.2.53 example.com A ``` **Autoritative Nameserver einer Zone** ```bash [TEST] dig @192.0.2.53 example.intern NS ``` **SOA-Record** ```bash [TEST] dig @192.0.2.53 example.intern SOA ``` **Reverse-Auflösung** ```bash [TEST] dig -x 192.0.2.20 @192.0.2.53 ``` **Delegationsweg verfolgen** ```bash [TEST] dig +trace example.com ``` `dig +trace` befragt die DNS-Hierarchie schrittweise selbst. Es entspricht nicht dem normalen rekursiven Weg über den konfigurierten Resolver und kann durch Firewalls oder interne Zonen eingeschränkt sein.
13. Welche Felder einer dig-Ausgabe sind wichtig? Beispielstruktur: ```text ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345 ;; flags: qr rd ra ;; QUESTION SECTION: ;app.example.intern. IN A ;; ANSWER SECTION: app.example.intern. 300 IN A 192.0.2.20 ;; Query time: 12 msec ;; SERVER: 192.0.2.53#53 ;; WHEN: ... ;; MSG SIZE rcvd: ... ``` | Feld | Bedeutung | |---|---| | `status` | DNS-Antwortstatus | | `id` | Transaktions-ID | | `qr` | Nachricht ist eine Antwort | | `aa` | autoritative Antwort | | `tc` | Antwort wurde gekürzt | | `rd` | Rekursion wurde angefordert | | `ra` | Rekursion ist verfügbar | | `ad` | validierende Stelle kennzeichnet Daten als authentifiziert | | `cd` | Client fordert deaktivierte DNSSEC-Prüfung | | `ANSWER` | eigentliche Antwortrecords | | `AUTHORITY` | zuständige beziehungsweise autoritative Informationen | | `ADDITIONAL` | zusätzliche hilfreiche Records | | `TTL` | verbleibende Cachelebensdauer | | `SERVER` | tatsächlich abgefragter Resolver | | `Query time` | gemessene Abfragedauer | Das `ad`-Flag muss im Zusammenhang mit dem befragten validierenden Resolver bewertet werden. Es beweist nicht, dass der lokale Client selbst die gesamte DNSSEC-Kette validiert hat.
14. Wie wird die DNS-Konfiguration unter macOS geprüft? **Aktuelle Resolverkonfiguration** ```bash [RO][SENS] scutil --dns ``` macOS kann mehrere Resolverkonfigurationen parallel besitzen, beispielsweise für: - allgemeine Anfragen, - VPN-Domänen, - bestimmte Suchdomänen, - Multicast DNS, - schnittstellenbezogene Namensräume. **DNS-Server eines Netzwerkdienstes** ```bash [RO] networksetup -getdnsservers "Wi-Fi" ``` **Suchdomänen** ```bash [RO] networksetup -getsearchdomains "Wi-Fi" ``` **IP-Konfiguration** ```bash [RO] networksetup -getinfo "Wi-Fi" ``` Der tatsächliche Netzwerkdienst muss vorher bestimmt werden: ```bash [RO] networksetup -listallnetworkservices ``` **Hosts-Auflösung über Systemmechanismen** ```bash [TEST] dscacheutil -q host -a name app.example.intern ``` Dieser Test bildet den macOS-Systemresolver besser ab als eine direkte Abfrage eines einzelnen DNS-Servers mit `dig`.
15. Warum können dig und eine Anwendung unterschiedliche Ergebnisse liefern? `dig` sendet eine direkte DNS-Abfrage. Eine Anwendung kann dagegen weitere Mechanismen verwenden: - Systemresolver, - lokale Hosts-Datei, - DNS-Cache des Betriebssystems, - eigener Anwendungscache, - Browsercache, - DNS over HTTPS, - VPN-spezifischer Resolver, - Multicast DNS, - Suchsuffixe, - Proxy, - Sicherheitssoftware, - andere Reihenfolge von IPv4 und IPv6. **Beispiel** ```text dig @192.0.2.53 app.example.intern → 192.0.2.20 Browser → verwendet eigenen DoH-Resolver → erhält keine interne Adresse ``` Deshalb sollten mindestens zwei Ebenen geprüft werden: 1. direkte DNS-Serverantwort, 2. tatsächliche Auflösung über das Betriebssystem beziehungsweise die Anwendung.
16. Wie wird die lokale Hosts-Datei geprüft? Ein Eintrag in der Hosts-Datei kann DNS für den betreffenden Namen übersteuern. **Windows** ```powershell [RO][PRIV][SENS] Get-Content ` "$env:SystemRoot\System32\drivers\etc\hosts" ``` Nicht auskommentierte Zeilen anzeigen: ```powershell [RO][PRIV][SENS] Get-Content ` "$env:SystemRoot\System32\drivers\etc\hosts" | Where-Object { $_.Trim() -and -not $_.Trim().StartsWith('#') } ``` **Linux** ```bash [RO][SENS] cat /etc/hosts ``` **macOS** ```bash [RO][SENS] cat /etc/hosts ``` **Typische Probleme** - veraltete Testadresse, - falscher Hostname, - Eintrag wurde von Software ergänzt, - IPv4- und IPv6-Einträge widersprechen sich, - Eintrag existiert nur auf einem Client, - Eintrag besitzt unsichtbare Formatierungsfehler. Hosts-Dateien dürfen nicht vorschnell geändert werden. Zuerst müssen Ursprung, Zweck und Konfigurationsmanagement geklärt werden.
17. Wie beeinflusst ein DNS-Suchsuffix die Auflösung? Ein nicht vollständig qualifizierter Name kann durch eine Suchdomäne ergänzt werden. Eingabe: ```text app ``` Suchdomäne: ```text example.intern ``` Mögliche Anfrage: ```text app.example.intern ``` Bei mehreren Suchdomänen können mehrere Abfragen entstehen: ```text app.berlin.example.intern app.example.intern app ``` **Prüfung unter Windows** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix ``` Zusätzlich: ```cmd [RO][SENS] ipconfig /all ``` **Linux** ```bash [RO] resolvectl status ``` ```bash [RO] cat /etc/resolv.conf ``` **macOS** ```bash [RO][SENS] scutil --dns ``` **Sicherer Vergleich** ```text Kurzname: app Vollqualifizierter Name: app.example.intern. ``` Der abschließende Punkt kennzeichnet in DNS-Werkzeugen einen absoluten Namen und verhindert dort normalerweise die Ergänzung eines Suchsuffixes.
18. Wie werden DNS-Antwortstatus richtig interpretiert? | Status | Bedeutung | |---|---| | `NOERROR` mit Antwort | Abfrage war erfolgreich und enthält Antwortdaten | | `NOERROR` ohne gesuchten Record | Name kann existieren, aber Recordtyp fehlt | | `NXDOMAIN` | abgefragter Name existiert laut Antwort nicht | | `SERVFAIL` | Server konnte keine gültige Antwort liefern | | `REFUSED` | Server verweigert die Abfrage | | `FORMERR` | Abfrageformat wurde als fehlerhaft bewertet | | `NOTIMP` | Operation wird nicht unterstützt | | Timeout | keine rechtzeitige verwertbare Antwort erhalten | **Wichtige Unterscheidung** ```text NXDOMAIN: Der Name existiert laut DNS-Antwort nicht. NOERROR ohne A-Record: Der Name kann existieren, besitzt aber keinen A-Record. ``` **SERVFAIL kann unter anderem entstehen durch:** - DNSSEC-Validierungsfehler, - nicht erreichbaren autoritativen Server, - fehlerhafte Delegation, - Timeout bei Weiterleitung, - Serverfehler, - beschädigte Zone, - fehlende Erreichbarkeit über TCP, - Schleife zwischen Forwardern.
19. Wie wird zwischen NXDOMAIN und fehlendem Recordtyp unterschieden? **A-Record abfragen** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Mögliche Ergebnisse: **Fall 1 – Name existiert nicht** ```text status: NXDOMAIN ``` **Fall 2 – Name existiert, besitzt aber keinen A-Record** ```text status: NOERROR ANSWER: 0 ``` Im Authority-Bereich kann ein SOA-Record erscheinen. **Fall 3 – Name besitzt nur AAAA** ```bash [TEST] dig @192.0.2.53 app.example.intern AAAA ``` liefert eine IPv6-Adresse. Diese Unterscheidung ist wichtig, weil das Anlegen eines A-Records bei einem vollständig falschen Namen eine andere Maßnahme wäre als das Ergänzen eines fehlenden Recordtyps.
20. Wie werden CNAME-Ketten untersucht? **Direkte Abfrage** ```bash [TEST] dig @192.0.2.53 app.example.intern CNAME ``` **Vollständige Auflösung** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Mögliche Kette: ```text app.example.intern → CNAME proxy.example.intern → CNAME proxy-berlin.example.net → A 192.0.2.20 ``` Zu prüfen sind: - existiert jedes Ziel der Kette? - besitzt das letzte Ziel einen passenden A- oder AAAA-Record? - verweist ein CNAME auf sich selbst? - existiert eine Schleife? - überschreitet die Kette Grenzen zwischen internen und externen Zonen? - stimmt die TTL der beteiligten Records? - passt das TLS-Zertifikat weiterhin zum ursprünglich verwendeten Namen? Der erfolgreiche Abschluss der DNS-Kette beweist noch nicht, dass die Anwendung oder das Zertifikat korrekt ist.
21. Wie wird Split DNS beziehungsweise Split-Horizon DNS geprüft? Bei Split DNS liefert derselbe Name abhängig vom verwendeten Resolver oder Standort unterschiedliche Antworten. **Interner Resolver** ```text app.example.com → 192.0.2.20 ``` **Öffentlicher Resolver** ```text app.example.com → 203.0.113.20 ``` Dies kann beabsichtigt sein. **Vergleichsabfragen** ```bash [TEST] dig @192.0.2.53 app.example.com A ``` ```bash [TEST] dig @ÖFFENTLICHER-RESOLVER app.example.com A ``` Ein öffentlicher Resolver darf nur verwendet werden, wenn dies nach Unternehmensrichtlinie zulässig und aus dem Netz erreichbar ist. **Typische Fehler** - VPN verwendet öffentlichen statt internen Resolver, - interne Zone fehlt auf einem Standort, - Conditional Forwarder fehlt, - Browser umgeht internen DNS per DoH, - Antwort aus öffentlichem Cache wird verwendet, - interne und externe Records wurden verwechselt.
22. Wie beeinflussen VPN und schnittstellenbezogenes DNS die Auflösung? Ein VPN kann: - eigene DNS-Server setzen, - nur bestimmte Domänen über interne Resolver leiten, - alle DNS-Anfragen übernehmen, - Suchdomänen hinzufügen, - DNS over HTTPS blockieren oder konfigurieren, - IPv4 und IPv6 unterschiedlich behandeln. **Prüfung vor und nach VPN-Verbindung** | Eigenschaft | vor VPN | nach VPN | |---|---|---| | DNS-Server | dokumentieren | dokumentieren | | Suchdomänen | dokumentieren | dokumentieren | | Routen zum DNS-Server | dokumentieren | dokumentieren | | A-Antwort | vergleichen | vergleichen | | AAAA-Antwort | vergleichen | vergleichen | | Systemresolver | vergleichen | vergleichen | **Windows** ```powershell [RO] Get-DnsClientServerAddress ``` **Linux** ```bash [RO] resolvectl status ``` **macOS** ```bash [RO][SENS] scutil --dns ``` Ein interner DNS-Server kann korrekt eingetragen sein, aber über die aktuelle Routingtabelle nicht erreichbar sein. Deshalb muss zusätzlich die Route zum Resolver geprüft werden.
23. Wie wird die Erreichbarkeit des DNS-Servers geprüft? **Route zum Resolver** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.0.2.53 ``` Linux: ```bash [RO] ip route get 192.0.2.53 ``` macOS: ```bash [RO] route -n get 192.0.2.53 ``` **TCP-Port 53 testen** Windows: ```powershell [TEST] Test-NetConnection 192.0.2.53 -Port 53 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 192.0.2.53 53 ``` Dieser Test prüft nur TCP 53. **Tatsächliche DNS-Abfrage über UDP** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` **Tatsächliche DNS-Abfrage über TCP** ```bash [TEST] dig +tcp @192.0.2.53 app.example.intern A ``` **Auswertung** | UDP-Abfrage | TCP-Abfrage | Mögliche Richtung | |---|---|---| | erfolgreich | erfolgreich | Transport grundsätzlich verfügbar | | erfolgreich | fehlerhaft | TCP 53, Firewall oder Serverlistener prüfen | | fehlerhaft | erfolgreich | UDP 53, Fragmentierung oder Filter prüfen | | fehlerhaft | fehlerhaft | Route, Firewall, Server oder falsche Adresse |
24. Wie werden große DNS-Antworten und das TC-Flag untersucht? Das DNS-Headerflag `TC` bedeutet, dass eine Antwort gekürzt wurde. Vereinfachter Ablauf: ```text Client → DNS-Abfrage über UDP Server → gekürzte Antwort mit TC=1 Client → Wiederholung über TCP Server → vollständige Antwort über TCP ``` **dig-Ausgabe über UDP** ```bash [TEST] dig @192.0.2.53 example.com DNSKEY ``` **Vergleich über TCP** ```bash [TEST] dig +tcp @192.0.2.53 example.com DNSKEY ``` **Wireshark-Display-Filter** ```text dns.flags.truncated == 1 ``` Mögliche Fehlerursachen: - TCP 53 wird blockiert, - Fragmentierung oder MTU-Problem, - Firewall verwirft große UDP-Antworten, - EDNS wird fehlerhaft behandelt, - Resolver oder Middlebox arbeitet nicht standardkonform.
25. Wie werden TTL und DNS-Caching interpretiert? TTL steht für Time to Live und gibt an, wie lange ein DNS-Record gecacht werden darf. **Beispiel** ```text app.example.intern. 300 IN A 192.0.2.20 ``` TTL: ```text 300 Sekunden = 5 Minuten ``` Nach einer Änderung können Resolver die alte Antwort bis zum Ablauf der noch vorhandenen TTL verwenden. **Wichtig** - verschiedene Resolver können unterschiedliche verbleibende TTLs besitzen, - Anwendungen können zusätzlich eigene Caches verwenden, - negative Antworten können ebenfalls gecacht werden, - Browser können eigene DNS-Zustände verwalten, - Load Balancer können mehrere Adressen liefern, - alte Antworten müssen nicht auf allen Clients gleichzeitig verschwinden. **Vergleich zu unterschiedlichen Zeitpunkten** ```bash [TEST] dig @192.0.2.53 app.example.intern A ``` Zu dokumentieren: - Antwortadresse, - TTL, - Server, - Zeitpunkt, - Antwortstatus.
26. Was ist negatives DNS-Caching? Auch negative Antworten wie `NXDOMAIN` oder das Fehlen eines bestimmten Recordtyps können zeitweise gecacht werden. Mögliche Situation: ```text 09:00 Name existiert noch nicht. 09:01 Client fragt und erhält NXDOMAIN. 09:05 Record wird angelegt. 09:06 Client erhält weiterhin die gecachte negative Antwort. ``` Die Dauer des negativen Cachings hängt unter anderem von den Zonen- und Resolverinformationen ab. **Diagnose** - autoritativen Server direkt abfragen, - rekursiven Resolver abfragen, - Systemresolver abfragen, - Antwortstatus und SOA-Informationen vergleichen, - Zeitpunkt der Recordänderung dokumentieren. Ein Cache sollte erst geleert werden, nachdem die ursprüngliche Antwort und deren TTL gesichert wurden.
27. Wie wird der DNS-Cache unter Windows geprüft? **Cache anzeigen** ```powershell [RO] Get-DnsClientCache ``` Nach einem Namen suchen: ```powershell [RO] Get-DnsClientCache | Where-Object Entry -Match 'app\.example\.intern' ``` **Klassische Anzeige** ```cmd [RO] ipconfig /displaydns ``` **Cache exportieren** ```powershell [RO][FILE][SENS] Get-DnsClientCache | Export-Csv 'C:\Temp\dns-cache-vorher.csv' ` -NoTypeInformation ` -Encoding UTF8 ``` Der Cache kann interne Namen und aufgerufene Ziele enthalten und ist daher als sensibel zu behandeln.
28. Wann darf ein DNS-Cache geleert werden? Das Leeren des Caches verändert den Diagnosezustand und kann eine fehlerhafte Antwort nur vorübergehend verbergen. **Windows** ```powershell [PRIV][CHANGE] Clear-DnsClientCache ``` Alternative: ```cmd [PRIV][CHANGE] ipconfig /flushdns ``` **Linux mit systemd-resolved** ```bash [PRIV][CHANGE] sudo resolvectl flush-caches ``` Andere Linux-Resolver besitzen eigene Verfahren. Es existiert kein allgemeiner Befehl für alle Linux-Systeme. **macOS** ```bash [PRIV][CHANGE] sudo dscacheutil -flushcache ``` Anschließend kann abhängig von macOS-Version zusätzlich ein HUP-Signal an den DNS-Responder erforderlich sein: ```bash [PRIV][CHANGE] sudo killall -HUP mDNSResponder ``` Diese macOS-Befehle sollten nur nach Prüfung der eingesetzten Version und lokalen Dokumentation verwendet werden. **Vorher sichern** - aktuelle Antwort, - TTL, - verwendeter Resolver, - Betriebssystemcache, - Anwendungszustand, - Zeitpunkt.
29. Wie werden autoritative DNS-Daten geprüft? **Zuständige Nameserver ermitteln** ```bash [TEST] dig @192.0.2.53 example.intern NS ``` **SOA-Record prüfen** ```bash [TEST] dig @192.0.2.53 example.intern SOA ``` **Autoritativen Server direkt abfragen** ```bash [TEST] dig @AUTORITATIVER-SERVER app.example.intern A ``` In der Antwort sollte bei einer autoritativen Antwort typischerweise das `aa`-Flag erscheinen. **Zu prüfen** - richtige Zone, - richtiger Record, - korrekte Adresse, - TTL, - Seriennummer der Zone, - Replikationsstand, - primärer und sekundärer Nameserver, - Delegation, - DNSSEC-Signaturen, - unterschiedliche Antworten mehrerer autoritativer Server. Wenn autoritative Server unterschiedliche Zonenversionen liefern, können Clients abhängig vom befragten Server unterschiedliche Ergebnisse erhalten.
30. Wie wird die SOA-Seriennummer verwendet? Der SOA-Record enthält Verwaltungsinformationen einer DNS-Zone, darunter eine Seriennummer. ```bash [TEST] dig @DNS-SERVER example.intern SOA ``` Mehrere autoritative Server vergleichen: ```bash [TEST] dig @DNS-SERVER-1 example.intern SOA ``` ```bash [TEST] dig @DNS-SERVER-2 example.intern SOA ``` **Mögliche Auffälligkeit** ```text Server 1: Serial 2026073105 Server 2: Serial 2026073002 ``` Dies kann auf eine noch nicht erfolgte oder fehlgeschlagene Zonenübertragung beziehungsweise Replikation hinweisen. Die Bedeutung und das Format der Seriennummer werden durch die DNS-Verwaltung der jeweiligen Umgebung bestimmt. Eine höhere dezimale Darstellung ist häufig, aber nicht jede Organisation verwendet dasselbe Schema.
31. Wie werden Delegationsfehler erkannt? Eine übergeordnete Zone verweist per NS-Records auf die autoritativen Server einer untergeordneten Zone. ```text example.com → Delegation für berlin.example.com → ns1.berlin.example.com → ns2.berlin.example.com ``` Mögliche Fehler: - falscher Nameserver eingetragen, - Nameserver ist nicht erreichbar, - Glue Record fehlt oder ist falsch, - Child- und Parent-NS-Records unterscheiden sich, - Firewall blockiert UDP oder TCP 53, - DNSSEC-DS-Record passt nicht mehr, - autoritativer Server kennt die delegierte Zone nicht, - Schleife in der Delegation. **Öffentliche Delegation verfolgen** ```bash [TEST] dig +trace berlin.example.com ``` Für interne Zonen muss der interne Delegations- und Weiterleitungsweg anhand der Unternehmensarchitektur geprüft werden.
32. Wie werden DNSSEC-Probleme erkannt? DNSSEC ermöglicht die kryptografische Prüfung von DNS-Daten. Ein Fehler in der Vertrauenskette kann dazu führen, dass validierende Resolver mit `SERVFAIL` antworten. **Abfrage mit DNSSEC-Daten** ```bash [TEST] dig +dnssec @192.0.2.53 example.com A ``` **Validierung testweise durch den Resolver anfragen, aber Checking Disabled setzen** ```bash [TEST] dig +cdflag @192.0.2.53 example.com A ``` Wenn eine normale Abfrage `SERVFAIL` liefert, dieselbe Abfrage mit `+cdflag` aber Daten zurückgibt, ist ein DNSSEC-Validierungsproblem eine mögliche Hypothese. **Mögliche Ursachen** - abgelaufene Signatur, - falscher DS-Record, - Schlüsselwechsel nicht korrekt abgeschlossen, - inkonsistente autoritative Server, - falsche Systemzeit, - beschädigte Vertrauenskette, - Antwort wird auf dem Weg verändert oder abgeschnitten. `+cdflag` deaktiviert nicht dauerhaft die Serverkonfiguration. Es kennzeichnet die einzelne Abfrage entsprechend. Das Ergebnis darf nur als Diagnosehinweis verwendet werden.
33. Wie beeinflusst DNS over HTTPS die Fehleranalyse? Bei DNS over HTTPS werden DNS-Abfragen in HTTPS-Verbindungen übertragen. Dadurch kann eine Anwendung den betriebssystemseitig konfigurierten DNS-Server umgehen. Mögliche Auswirkungen: - interne Zonen werden nicht gefunden, - Unternehmensfilter greifen nicht, - Browser liefert andere Antworten als `nslookup`, - DNS-Verkehr ist im gewöhnlichen Port-53-Mitschnitt nicht sichtbar, - Split DNS funktioniert in der Anwendung nicht, - zentrale DNS-Protokolle enthalten die Anfrage nicht. **Prüffragen** - verwendet die Anwendung den Systemresolver? - ist DoH durch Browser, Betriebssystem oder Richtlinie aktiviert? - welcher DoH-Endpunkt wird verwendet? - sollen interne Namen vom Systemresolver aufgelöst werden? - existieren betriebliche Vorgaben für verschlüsseltes DNS? DoH sollte nicht pauschal deaktiviert werden. Zuerst müssen Unternehmensrichtlinie, Sicherheitskonzept und tatsächlicher Auflösungsweg geprüft werden.
34. Wie wird DNS-Verkehr mit Wireshark untersucht? **Alle klassischen DNS-Nachrichten** ```text dns ``` **Nur DNS-Anfragen** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten** ```text dns.flags.response == 1 ``` **Bestimmter Name** ```text dns.qry.name == "app.example.intern" ``` **Bestimmter Recordtyp** A-Record: ```text dns.qry.type == 1 ``` AAAA-Record: ```text dns.qry.type == 28 ``` **NXDOMAIN** ```text dns.flags.rcode == 3 ``` **SERVFAIL** ```text dns.flags.rcode == 2 ``` **Gekürzte Antworten** ```text dns.flags.truncated == 1 ``` **Lange Antwortzeit** ```text dns.time > 1 ``` `dns.time` ist verfügbar, wenn Wireshark Anfrage und passende Antwort einander zuordnen konnte.
35. Wie wird DNS-Verkehr sicher mitgeschnitten? **Capture-Filter für klassischen DNS-Verkehr** ```text port 53 ``` **Nur bestimmter DNS-Server** ```text host 192.0.2.53 and port 53 ``` **Zeitlich begrenzte Aufnahme** ```bash [TEST][PRIV][FILE][SENS] dumpcap \ -i INTERFACE \ -f "host 192.0.2.53 and port 53" \ -a duration:30 \ -w dns-diagnose.pcapng ``` **TShark-Liveanzeige** ```bash [TEST][PRIV][SENS] tshark \ -i INTERFACE \ -f "host 192.0.2.53 and port 53" ``` **Felder aus einer Datei ausgeben** ```bash [RO][SENS] tshark \ -r dns-diagnose.pcapng \ -Y "dns" \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e udp.srcport \ -e udp.dstport \ -e dns.id \ -e dns.flags.response \ -e dns.flags.rcode \ -e dns.qry.name \ -e dns.qry.type ``` DNS-Aufzeichnungen können aufgerufene interne und externe Namen offenlegen und müssen gemäß Seite 2.14 geschützt werden.
36. Wie wird eine DNS-Anfrage im Paketmitschnitt ausgewertet? **Erfolgreicher Ablauf** ```text Client → Resolver: Query A app.example.intern Resolver → Client: Response NOERROR A 192.0.2.20 ``` **Timeout** ```text Client → Resolver: Query A app.example.intern Client → Resolver: Wiederholung Keine Antwort ``` **NXDOMAIN** ```text Client → Resolver: Query A app.example.intern Resolver → Client: Response NXDOMAIN ``` **TCP-Fallback** ```text Client → Resolver über UDP: Query Resolver → Client: Response, Truncated Client → Resolver über TCP: SYN, SYN-ACK, ACK DNS Query Resolver → Client über TCP: vollständige DNS Response ``` **Zu prüfen** - Transaktions-ID, - Quell- und Zieladresse, - UDP oder TCP, - abgefragter Name, - Recordtyp, - Antwortstatus, - Antwortrecords, - TTL, - Wiederholungen, - Antwortdauer, - Truncation, - DNSSEC-Flags.
37. Wie wird zwischen Client-, Resolver- und Zonenproblem unterschieden? | Beobachtung | Wahrscheinlichere Richtung | |---|---| | nur eine Anwendung betroffen | Anwendungscache, DoH oder Proxy | | nur ein Client betroffen | Clientcache, Hosts-Datei oder DNS-Konfiguration | | alle Clients eines DNS-Servers betroffen | Resolver, Forwarder oder dessen Netzwerkpfad | | direkter autoritativer Server korrekt, Resolver falsch | Cache oder Weiterleitung | | alle autoritativen Server falsch | Zonendaten | | ein autoritativer Server weicht ab | Replikation oder Zonentransfer | | UDP funktioniert, TCP nicht | Firewall oder TCP-Listener | | TCP funktioniert, UDP nicht | UDP-Filter, Fragmentierung oder Middlebox | | interne Namen nur ohne DoH | Anwendung umgeht internen Resolver | | Auflösung korrekt, Verbindung fehlerhaft | Problem liegt nach DNS | | A funktioniert, AAAA führt zum Fehler | IPv6-Pfad oder Ziel prüfen | | `SERVFAIL` nur bei validierendem Resolver | DNSSEC möglich | | Name mit Punkt funktioniert, Kurzname nicht | Suchsuffix oder Suchreihenfolge |
38. Welche typischen Fehlinterpretationen müssen vermieden werden? | Beobachtung | Falscher Schluss | Richtige Einordnung | |---|---|---| | Ping per IP funktioniert | DNS ist sicher die einzige Ursache | Dienst kann Hostnamen oder TLS benötigen | | nslookup funktioniert | Anwendung verwendet dieselbe Auflösung | Anwendung kann eigenen Resolver verwenden | | DNS-Server ist eingetragen | er wird tatsächlich verwendet | schnittstellen- und anwendungsbezogene Resolver prüfen | | `NXDOMAIN` | DNS-Server ist ausgefallen | Server antwortet, Name existiert laut Antwort nicht | | `SERVFAIL` | Name existiert nicht | Server konnte keine gültige Antwort liefern | | `NOERROR` | gesuchter Record ist vorhanden | Antwort kann leer sein | | DNS-Cache geleert und Zugriff geht | Ursache ist behoben | veraltete Quelle kann erneut cachen | | A-Record ist korrekt | Dienst ist vollständig korrekt | AAAA, CNAME, TLS und Backend prüfen | | öffentliche Antwort unterscheidet sich | eine Seite ist falsch | Split DNS kann beabsichtigt sein | | Port 53 per TCP erreichbar | DNS funktioniert | UDP und tatsächliche Abfrage separat prüfen | | keine Port-53-Pakete sichtbar | Anwendung stellt keine DNS-Anfrage | DoH, Cache oder falscher Messpunkt möglich | | kurze Query Time | gesamte Anwendung ist schnell | nur DNS-Abfragedauer gemessen |
39. Wie sieht der systematische Prüfablauf aus? | Schritt | Prüfung | |---:|---| | 1 | betroffenen Namen und Recordtyp eindeutig bestimmen | | 2 | Clientzeit, Netzwerk und VPN-Zustand dokumentieren | | 3 | konfigurierte und tatsächlich verwendete Resolver bestimmen | | 4 | Hosts-Datei und Suchsuffixe prüfen | | 5 | Systemresolver abfragen | | 6 | konfigurierten DNS-Server direkt abfragen | | 7 | A, AAAA und mögliche CNAME-Kette untersuchen | | 8 | Antwortstatus, TTL, Flags und Server dokumentieren | | 9 | funktionierenden Client oder Resolver vergleichen | | 10 | UDP- und TCP-Abfrage vergleichen | | 11 | autoritative Server direkt prüfen | | 12 | SOA-Seriennummern und Zonendaten vergleichen | | 13 | Split DNS, VPN, DoH und Conditional Forwarding berücksichtigen | | 14 | bei Bedarf autorisierten Paketmitschnitt erstellen | | 15 | Cache erst nach Beweissicherung kontrolliert leeren | | 16 | DNS-Antwort und tatsächliche Dienstverbindung erneut testen | | 17 | Ursache und Änderung dokumentieren | **Merksatz** ```text Name → Recordtyp → Systemresolver → konfigurierter Resolver → autoritativer Server → Cache → tatsächliche Anwendung ```
40. Kompakte Befehlsübersicht für Windows, Linux und macOS | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | DNS-Suffixe | `[RO] Get-DnsClient` | `[RO] resolvectl status` | `[RO] networksetup -getsearchdomains "DIENST"` | | vollständige Netzkonfiguration | `[RO][SENS] ipconfig /all` | `[RO] cat /etc/resolv.conf` | `[RO] networksetup -getinfo "DIENST"` | | Systemauflösung | `[TEST] Resolve-DnsName NAME` | `[TEST] resolvectl query NAME` | `[TEST] dscacheutil -q host -a name NAME` | | A-Record | `[TEST] Resolve-DnsName NAME -Type A` | `[TEST] dig NAME A` | `[TEST] dig NAME A` | | AAAA-Record | `[TEST] Resolve-DnsName NAME -Type AAAA` | `[TEST] dig NAME AAAA` | `[TEST] dig NAME AAAA` | | bestimmten Resolver abfragen | `[TEST] Resolve-DnsName NAME -Server DNS-SERVER` | `[TEST] dig @DNS-SERVER NAME` | `[TEST] dig @DNS-SERVER NAME` | | TCP erzwingen | `[TEST] Resolve-DnsName NAME -Server DNS-SERVER -TcpOnly` | `[TEST] dig +tcp @DNS-SERVER NAME` | `[TEST] dig +tcp @DNS-SERVER NAME` | | Reverse DNS | `[TEST] Resolve-DnsName IP -Type PTR` | `[TEST] dig -x IP @DNS-SERVER` | `[TEST] dig -x IP @DNS-SERVER` | | NS-Records | `[TEST] Resolve-DnsName ZONE -Type NS` | `[TEST] dig @DNS-SERVER ZONE NS` | gleicher Befehl | | SOA-Record | `[TEST] Resolve-DnsName ZONE -Type SOA` | `[TEST] dig @DNS-SERVER ZONE SOA` | gleicher Befehl | | Hosts-Datei | `[RO][PRIV][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"` | `[RO][SENS] cat /etc/hosts` | `[RO][SENS] cat /etc/hosts` | | DNS-Cache anzeigen | `[RO] Get-DnsClientCache` | `[RO] resolvectl statistics` | kein gleichwertiger vollständiger Standardbefehl | | DNS-Cache leeren | `[PRIV][CHANGE] Clear-DnsClientCache` | `[PRIV][CHANGE] sudo resolvectl flush-caches` | `[PRIV][CHANGE] sudo dscacheutil -flushcache` | | DNS mitschneiden | `[TEST][PRIV][FILE][SENS] dumpcap -i INTERFACE -f "host DNS-SERVER and port 53" -a duration:30 -w dns.pcapng` | gleicher Befehl | gleicher Befehl | Die Platzhalter `NAME`, `ZONE`, `IP`, `DNS-SERVER`, `DIENST` und `INTERFACE` müssen durch vorher eindeutig bestimmte Werte ersetzt werden.
41. Dokumentationsvorlage ```text Ticketnummer: Prüfzeitpunkt: Zeitzone: Betroffener Client: Betriebssystem: Benutzer: Standort: VLAN: VPN aktiv: Betroffene Anwendung: ABFRAGE Eingegebener Name: Vollständig qualifizierter Name: Recordtyp: Erwartete Antwort: Tatsächliche Antwort: Exakte Fehlermeldung: CLIENTKONFIGURATION Schnittstelle: IPv4-Adresse: IPv6-Adresse: DNS-Server IPv4: DNS-Server IPv6: DNS-Suchdomänen: Lokale Hosts-Datei geprüft: Passender Hosts-Eintrag: DoH aktiv oder vermutet: Proxy aktiv: Anwendungscache: SYSTEMRESOLVER Verwendeter Test: Antwortstatus: Antwortrecords: TTL: CNAME-Kette: Antwortzeit: Verwendeter Resolver: IPv4 oder IPv6: DIREKTE DNS-ABFRAGE DNS-Server: UDP erfolgreich: TCP erfolgreich: A-Antwort: AAAA-Antwort: CNAME: Status: Flags: TTL: Query Time: AUTORITATIVE DATEN Zone: Autoritative Nameserver: Direkt abgefragter Server: AA-Flag: A-Record: AAAA-Record: CNAME: SOA-Seriennummer: Weitere autoritative Server: Seriennummern identisch: Delegation korrekt: DNSSEC-Status: VERGLEICH Referenzclient: Verwendeter Resolver: Antwort: TTL: Anwendung funktioniert: Relevante Abweichungen: PAKETMITSCHNITT Messpunkt: DNS-Anfrage sichtbar: DNS-Antwort sichtbar: Transaktions-ID: UDP oder TCP: Response Code: Truncated: Wiederholungen: Antwortzeit: Capture-Datei: Hash: CACHE Clientcache vor Änderung gesichert: Resolvercache vermutet: Negative Antwort: Cache geleert: Ergebnis nach Cacheleerung: Arbeitshypothese: Begründung: Durchgeführter Test: Geplante Änderung: Freigabe: Rückweg: Abschlussprüfung: Ermittelte Ursache: ```
42. Offizielle Quellen und weiterführende Dokumentation **Microsoft** - [DNS – technische Übersicht](https://learn.microsoft.com/windows-server/networking/dns/dns-top) - [Resolve-DnsName](https://learn.microsoft.com/powershell/module/dnsclient/resolve-dnsname) - [Get-DnsClientServerAddress](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientserveraddress) - [Get-DnsClient](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclient) - [Get-DnsClientCache](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientcache) - [Clear-DnsClientCache](https://learn.microsoft.com/powershell/module/dnsclient/clear-dnsclientcache) - [nslookup](https://learn.microsoft.com/windows-server/administration/windows-commands/nslookup) **Linux und systemd** - [resolvectl](https://www.freedesktop.org/software/systemd/man/latest/resolvectl.html) - [systemd-resolved](https://www.freedesktop.org/software/systemd/man/latest/systemd-resolved.service.html) - [resolv.conf – Linux Manual Page](https://man7.org/linux/man-pages/man5/resolv.conf.5.html) **ISC BIND** - [BIND 9 Administrator Reference Manual](https://bind9.readthedocs.io/) - [dig Manual](https://bind9.readthedocs.io/en/latest/manpages.html#dig-dns-lookup-utility) **Apple** - Lokale Befehlsreferenzen: `man scutil`, `man networksetup`, `man dscacheutil`, `man dig` und `man nslookup` - [DNS-Einstellungen auf dem Mac ändern](https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac) **Wireshark** - [DNS Display Filter Reference](https://www.wireshark.org/docs/dfref/d/dns.html) - [dumpcap Manual Page](https://www.wireshark.org/docs/man-pages/dumpcap.html) - [tshark Manual Page](https://www.wireshark.org/docs/man-pages/tshark.html) **Standards** - [RFC 1034 – Domain Names: Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034) - [RFC 1035 – Domain Names: Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035) - [RFC 2308 – Negative Caching of DNS Queries](https://www.rfc-editor.org/rfc/rfc2308) - [RFC 6891 – Extension Mechanisms for DNS](https://www.rfc-editor.org/rfc/rfc6891) - [RFC 7766 – DNS Transport over TCP](https://www.rfc-editor.org/rfc/rfc7766) - [RFC 7858 – DNS over TLS](https://www.rfc-editor.org/rfc/rfc7858) - [RFC 8484 – DNS over HTTPS](https://www.rfc-editor.org/rfc/rfc8484) > DNS-Verwaltungsbefehle und Serverprotokolle unterscheiden sich je nach Produkt. Änderungen an Zonen, Delegationen, Forwardern, DNSSEC oder Resolverrichtlinien dürfen nur anhand der Dokumentation des tatsächlich eingesetzten DNS-Systems vorgenommen werden.
# 3.9 Ports und Transportprotokolle prüfen Ein erreichbarer Host bedeutet noch nicht, dass der benötigte Dienst erreichbar ist. `ping` prüft hauptsächlich die IP-Erreichbarkeit über ICMP. Es prüft weder einen TCP-Port noch zuverlässig die Funktionsfähigkeit eines Anwendungsdienstes. Die zentrale Frage dieser Seite lautet: > Ist der benötigte Dienst über das richtige Transportprotokoll, die richtige Zieladresse und den richtigen Port erreichbar? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr oder Protokollanfragen erzeugt | | `[PRIV]` | Erhöhte Rechte beziehungsweise Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Daten enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann einen Dienst oder eine Verbindung beeinträchtigen | **Wichtiger Grundsatz:** Portscans und aktive Verbindungstests dürfen nur auf Systemen durchgeführt werden, für die eine entsprechende Berechtigung vorliegt.
---
2. TCP, UDP und ICMP unterscheiden | Protokoll | Eigenschaft | Typisches Verhalten bei einem Test | |---|---|---| | TCP | Verbindungsorientiert | Vor der Datenübertragung wird eine Verbindung aufgebaut | | UDP | Verbindungslos | Datagramme werden ohne vorherigen Verbindungsaufbau gesendet | | ICMP | Kontroll- und Diagnoseprotokoll | Übermittelt beispielsweise Echo-Antworten oder Fehlermeldungen | | ICMPv6 | Kontrollprotokoll für IPv6 | Wird unter anderem für Fehler, Neighbor Discovery und Path-MTU-Ermittlung benötigt | **TCP-Verbindungsaufbau:** ```text Client Server | | | -------- SYN --------------> | | <----- SYN, ACK ------------ | | -------- ACK --------------> | | | | Verbindung aufgebaut | ``` Der erfolgreiche TCP-Handshake beweist: - Der Client konnte ein TCP-Segment zum Ziel senden. - Das Ziel oder ein vorgeschaltetes System hat geantwortet. - Der Rückweg zum Client funktioniert. - Der betreffende TCP-Port akzeptiert grundsätzlich Verbindungen. Er beweist jedoch noch nicht: - dass die Anwendung fehlerfrei arbeitet, - dass eine Anmeldung möglich ist, - dass TLS-Zertifikate gültig sind, - dass der Benutzer die benötigten Berechtigungen besitzt, - dass die richtige Anwendung hinter dem Port antwortet. **Besonderheit bei UDP:** UDP besitzt keinen vergleichbaren Verbindungsaufbau. Bleibt eine Antwort aus, kann das bedeuten: - Der Dienst ist nicht erreichbar. - Der Port wird durch eine Firewall gefiltert. - Der Dienst antwortet nur auf gültige Protokollanfragen. - Die Antwort geht auf dem Rückweg verloren. - Der UDP-Dienst antwortet grundsätzlich nicht auf die gesendeten Daten. - Das Prüfwerkzeug kann den Zustand nicht eindeutig bestimmen. Ein erfolgreicher UDP-Test benötigt deshalb möglichst eine **gültige Anfrage des jeweiligen Anwendungsprotokolls**, beispielsweise eine DNS-Abfrage anstelle eines beliebigen UDP-Pakets.
---
3. Port, Socket und Verbindung eindeutig beschreiben Ein Port gehört immer zu einem Transportprotokoll. Die Angabe „Port 53“ ist ohne das Protokoll unvollständig, weil TCP-Port 53 und UDP-Port 53 getrennte Endpunkte sind. Eine Netzwerkverbindung wird im Normalfall durch folgende Angaben unterschieden: ```text Transportprotokoll Quell-IP-Adresse Quellport Ziel-IP-Adresse Zielport ``` Beispiel: ```text TCP 192.0.2.25:53144 → 192.0.2.53:443 ``` Dabei ist `53144` normalerweise ein temporärer Clientport und `443` der angesprochene Dienstport. **Wichtige Begriffe:** | Begriff | Bedeutung | |---|---| | Dienstport | Port, auf dem eine Serveranwendung Verbindungen oder Datagramme erwartet | | Quellport | Vom Client verwendeter Port; häufig dynamisch vergeben | | Listening Socket | Lokaler Socket, der auf eingehende TCP-Verbindungen wartet | | UDP Endpoint | Lokaler UDP-Endpunkt, der Datagramme empfangen kann | | Ephemeral Port | Temporärer, vom Betriebssystem vergebener Clientport | | Loopback-Adresse | Nur lokal erreichbare Adresse, beispielsweise `127.0.0.1` oder `::1` | | Wildcard-Adresse | Bindung an mehrere beziehungsweise alle lokalen Adressen | | Verbindungsstatus | Zustand einer TCP-Verbindung, beispielsweise `LISTEN` oder `ESTABLISHED` |
---
4. Häufig verwendete Ports einordnen Die folgende Tabelle enthält typische Standardbelegungen. Anwendungen können jedoch auf abweichende Ports konfiguriert werden. | Dienst | Transportprotokoll | Standardport | |---|---|---:| | SSH | TCP | 22 | | SMTP | TCP | 25 | | DNS | UDP und TCP | 53 | | DHCP-Server | UDP | 67 | | DHCP-Client | UDP | 68 | | HTTP | TCP | 80 | | Kerberos | UDP und TCP | 88 | | NTP | UDP | 123 | | LDAP | TCP und teilweise UDP | 389 | | HTTPS | TCP | 443 | | SMB | TCP | 445 | | LDAPS | TCP | 636 | | Microsoft SQL Server | TCP | 1433 | | MySQL/MariaDB | TCP | 3306 | | RDP | TCP und UDP | 3389 | | PostgreSQL | TCP | 5432 | **Nicht allein auf die Portnummer verlassen:** Ein offener TCP-Port 443 beweist nicht, dass dort tatsächlich ein ordnungsgemäßer HTTPS-Dienst läuft.
---
5. Typische Fehlermeldungen richtig interpretieren | Beobachtung | Wahrscheinliche Bedeutung | |---|---| | Verbindung erfolgreich | TCP-Verbindungsaufbau war möglich | | `Connection refused` | Ziel wurde erreicht, aber der Port wird nicht angenommen oder aktiv abgelehnt | | `Connection timed out` | Keine verwertbare Antwort; Paketverlust, Filterung, Routing- oder Rückwegproblem möglich | | `No route to host` | Lokales oder entferntes Routingproblem beziehungsweise entsprechende ICMP-Rückmeldung | | `Network is unreachable` | Keine geeignete Route oder Schnittstelle vorhanden | | `Host is unreachable` | Ziel oder nächster Hop konnte nicht erreicht werden | | `Name or service not known` | Namensauflösung fehlgeschlagen; der Porttest wurde möglicherweise noch nicht ausgeführt | | `Address already in use` | Ein anderer Prozess oder Socket verwendet bereits die Adresse beziehungsweise den Port | | `Permission denied` | Fehlende Berechtigung oder Sicherheitsrichtlinie verhindert den Zugriff | | Verbindung sofort zurückgesetzt | Anwendung, Zielsystem oder Sicherheitskomponente sendet ein TCP-RST | | TCP-Test erfolgreich, Anwendung fehlerhaft | Fehler liegt wahrscheinlich oberhalb der Transportschicht | Fehlermeldungen können je nach Betriebssystem, Anwendung und Sprache abweichen.
---
6. Auf dem Server prüfen, ob der Port geöffnet wurde Zuerst wird direkt auf dem betroffenen Server geprüft: 1. Läuft der erwartete Prozess? 2. Lauscht er auf dem erwarteten Port? 3. Verwendet er TCP oder UDP? 4. An welche IP-Adresse wurde der Socket gebunden? 5. Ist der Dienst nur über IPv4, nur über IPv6 oder über beides erreichbar? 6. Stimmt der Prozess tatsächlich mit dem erwarteten Dienst überein? | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Verbindungen und Listener | `[RO] Get-NetTCPConnection` | `[RO] ss -tan` | `[RO] netstat -anv -p tcp` | | Nur TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | TCP-Listener mit Prozess | `[RO] Get-NetTCPConnection -State Listen` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte mit Prozess | `[RO] Get-NetUDPEndpoint` | `[RO][PRIV] sudo ss -lunp` | `[RO][PRIV] sudo lsof -nP -iUDP` | | Klassische Übersicht | `[RO] netstat -ano` | `[RO] ss -tuln` | `[RO] netstat -anv` | `lsof` ist auf einigen Linux-Systemen nicht standardmäßig installiert. Unter Linux ist `ss` normalerweise das bevorzugte Werkzeug. **Windows – bestimmten TCP-Port prüfen:** ```powershell [RO] Get-NetTCPConnection -LocalPort 443 -ErrorAction SilentlyContinue ``` **Windows – nur Listener auf einem bestimmten Port:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort 443 -ErrorAction SilentlyContinue ``` **Windows – UDP-Endpunkt prüfen:** ```powershell [RO] Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue ``` **Windows – Prozess zu einem Listener ermitteln:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort 443 | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Anschließend die ermittelte Prozess-ID einsetzen: ```powershell [RO] Get-Process -Id 4321 ``` Alternativ mit klassischen Werkzeugen: ```cmd [RO] netstat -ano [RO] tasklist /FI "PID eq 4321" ``` **Linux – TCP-Port 443 prüfen:** ```bash [RO] ss -ltn 'sport = :443' ``` **Linux – UDP-Port 53 prüfen:** ```bash [RO] ss -lun 'sport = :53' ``` **Linux – Prozessinformationen anzeigen:** ```bash [RO][PRIV] sudo ss -ltnp 'sport = :443' ``` ```bash [RO][PRIV] sudo ss -lunp 'sport = :53' ``` **macOS – TCP-Port 443 prüfen:** ```bash [RO] lsof -nP -iTCP:443 -sTCP:LISTEN ``` **macOS – UDP-Port 53 prüfen:** ```bash [RO][PRIV] sudo lsof -nP -iUDP:53 ``` **Achtung:** Eine leere Ausgabe bedeutet meistens, dass kein passender Socket gefunden wurde. Sie ist nicht automatisch ein Programmfehler.
---
7. Bind-Adressen eines Dienstes beurteilen Ein Prozess kann laufen und trotzdem nur über eine falsche oder zu stark eingeschränkte Adresse erreichbar sein. | Lokale Adresse | Typische Bedeutung | |---|---| | `127.0.0.1:8080` | Nur über IPv4-Loopback auf demselben System erreichbar | | `::1:8080` | Nur über IPv6-Loopback auf demselben System erreichbar | | `192.0.2.10:443` | Nur über diese konkrete lokale IPv4-Adresse erreichbar | | `0.0.0.0:443` | An alle passenden lokalen IPv4-Adressen gebunden | | `[::]:443` | IPv6-Wildcard; ob zusätzlich IPv4 angenommen wird, hängt von Betriebssystem und Anwendung ab | **Typischer Fehler:** ```text Dienst läuft ↓ Port ist lokal geöffnet ↓ Dienst lauscht aber nur auf 127.0.0.1 ↓ Lokaler Test funktioniert ↓ Entfernter Zugriff schlägt fehl ``` Eine Bindung an `0.0.0.0` oder `[::]` bedeutet nicht automatisch, dass der Port von außen erreichbar ist. Firewalls, VLANs, Routing, NAT und Sicherheitsrichtlinien gelten weiterhin.
---
8. TCP-Port von einem Client aus prüfen Der Test sollte möglichst von dem System oder Netzwerksegment ausgeführt werden, in dem der Fehler tatsächlich auftritt. | Betriebssystem | TCP-Porttest | |---|---| | Windows | `[TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed` | | Linux | `[TEST] nc -vz -w 5 server.example.internal 443` | | macOS | `[TEST] nc -vz -w 5 server.example.internal 443` | | Plattformübergreifend mit Nmap | `[TEST] nmap -sT -p 443 server.example.internal` | **Windows:** ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed ``` Besonders relevante Felder: ```text ComputerName RemoteAddress RemotePort InterfaceAlias SourceAddress TcpTestSucceeded ``` Nur das Wesentliche ausgeben: ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 | Select-Object ComputerName, RemoteAddress, RemotePort, SourceAddress, TcpTestSucceeded ``` **Wichtig:** `Test-NetConnection -Port` prüft einen **TCP-Port**. Es ist kein allgemeiner UDP-Porttest. **Linux und macOS:** ```bash [TEST] nc -vz -w 5 server.example.internal 443 ``` Mehrere TCP-Ports einzeln prüfen: ```bash [TEST] nc -vz -w 5 server.example.internal 22 [TEST] nc -vz -w 5 server.example.internal 80 [TEST] nc -vz -w 5 server.example.internal 443 ``` Die verfügbaren `nc`-Optionen unterscheiden sich zwischen Implementierungen. Im Zweifel die lokale Hilfe prüfen: ```bash [RO] nc -h ``` **Nmap – einzelnen TCP-Port prüfen:** ```bash [TEST] nmap -sT -p 443 server.example.internal ``` **Mehrere festgelegte TCP-Ports prüfen:** ```bash [TEST] nmap -sT -p 22,80,443 server.example.internal ``` Nmap nur im freigegebenen Umfang einsetzen. Ein vollständiger Portscan ist für die Prüfung eines bekannten Dienstes normalerweise nicht erforderlich.
---
9. Nmap-Portzustände richtig interpretieren | Zustand | Typische Bedeutung | |---|---| | `open` | Eine Anwendung nimmt Verbindungen oder Datagramme auf diesem Port an | | `closed` | Ziel ist erreichbar, aber auf dem Port lauscht kein Dienst | | `filtered` | Nmap kann wegen Paketfilterung nicht sicher feststellen, ob der Port geöffnet ist | | `unfiltered` | Port ist erreichbar, aber der konkrete Offen-/Geschlossen-Zustand wurde mit der verwendeten Scanmethode nicht bestimmt | | `open\|filtered` | Nmap kann nicht zwischen geöffnet und gefiltert unterscheiden | | `closed\|filtered` | Nmap kann nicht zwischen geschlossen und gefiltert unterscheiden | Die Bewertung hängt von Scanart, Berechtigungen, Zielsystem und den empfangenen Antworten ab.
---
10. UDP-Dienste sinnvoll prüfen Ein allgemeiner UDP-Porttest ist nur eingeschränkt aussagekräftig. Nach Möglichkeit sollte immer das eigentliche Anwendungsprotokoll geprüft werden. | Dienst | Sinnvoller Funktionstest | |---|---| | DNS | `nslookup`, `Resolve-DnsName` oder `dig` | | NTP | `w32tm`, `chronyc`, `ntpq` oder `sntp`, abhängig vom System | | DHCP | DHCP-Ablauf und Paketmitschnitt analysieren | | Syslog über UDP | Empfang auf dem Syslog-Server und Paketmitschnitt prüfen | | SNMP | Autorisierte SNMP-Abfrage mit gültigen Parametern durchführen | **DNS gezielt über UDP testen:** Windows: ```powershell [TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly ``` Linux und macOS, sofern `dig` installiert ist: ```bash [TEST] dig @192.0.2.53 example.org A ``` **DNS gezielt über TCP testen:** Windows: ```powershell [TEST] Resolve-DnsName example.org -Server 192.0.2.53 -Type A -DnsOnly -TcpOnly ``` Linux und macOS: ```bash [TEST] dig +tcp @192.0.2.53 example.org A ``` **Netcat-UDP-Test:** ```bash [TEST] nc -vzu -w 3 192.0.2.53 53 ``` Dieser Test ist nicht mit einem erfolgreichen DNS-Funktionstest gleichzusetzen. Eine scheinbare Erfolgsmeldung kann lediglich bedeuten, dass lokal kein unmittelbarer Fehler festgestellt wurde. **Nmap-UDP-Test:** ```bash [TEST][PRIV] sudo nmap -sU -p 53 192.0.2.53 ``` UDP-Scans können langsam und mehrdeutig sein. Ein Ergebnis wie `open|filtered` ist bei UDP häufig, wenn weder eine Protokollantwort noch eine eindeutige ICMP-Fehlermeldung empfangen wurde.
---
11. Nicht nur den Port, sondern die Anwendung testen Ein Porttest prüft die Transportschicht. Danach sollte ein Test mit dem tatsächlichen Anwendungsprotokoll folgen. | Anwendung | Beispiel | |---|---| | HTTP | `[TEST] curl -v http://server.example.internal/` | | HTTPS | `[TEST] curl -vk https://server.example.internal/` | | HTTPS mit regulärer Zertifikatsprüfung | `[TEST] curl -v https://server.example.internal/` | | TLS-Handshake | `[TEST] openssl s_client -connect server.example.internal:443 -servername server.example.internal` | | DNS über UDP | `[TEST] dig @192.0.2.53 example.org A` | | DNS über TCP | `[TEST] dig +tcp @192.0.2.53 example.org A` | | SSH-Protokolltest | `[TEST] ssh -vvv user@server.example.internal` | **HTTP-Header abrufen:** ```bash [TEST] curl -I https://server.example.internal/ ``` **Ausführliche HTTPS-Diagnose:** ```bash [TEST][SENS] curl -v https://server.example.internal/ ``` Bei `curl -v` können Header, Cookies, interne Hostnamen und weitere sensible Informationen sichtbar werden. Zugangsdaten oder Sitzungstoken dürfen nicht ungeprüft dokumentiert werden. **TLS-Verbindung untersuchen:** ```bash [TEST][SENS] openssl s_client \ -connect server.example.internal:443 \ -servername server.example.internal ``` `-servername` übermittelt den Servernamen per SNI. Das ist wichtig, wenn mehrere TLS-Websites dieselbe IP-Adresse verwenden. **Hinweis zu `curl -k`:** ```bash [TEST] curl -vk https://server.example.internal/ ``` `-k` deaktiviert die Zertifikatsprüfung. Das kann zur Eingrenzung eines Zertifikatsfehlers verwendet werden, darf aber nicht als dauerhafte Lösung betrachtet werden.
---
12. IPv4 und IPv6 getrennt prüfen Ein Hostname kann gleichzeitig eine IPv4- und eine IPv6-Adresse besitzen. Dadurch kann derselbe Porttest je nach ausgewählter Adresse unterschiedlich ausfallen. **Namensauflösung kontrollieren:** Windows: ```powershell [RO] Resolve-DnsName server.example.internal ``` Linux: ```bash [RO] getent ahosts server.example.internal ``` macOS: ```bash [RO] dscacheutil -q host -a name server.example.internal ``` **HTTP gezielt über IPv4 testen:** ```bash [TEST] curl -4 -v https://server.example.internal/ ``` **HTTP gezielt über IPv6 testen:** ```bash [TEST] curl -6 -v https://server.example.internal/ ``` **Netcat gezielt über IPv4 oder IPv6:** ```bash [TEST] nc -4 -vz -w 5 server.example.internal 443 [TEST] nc -6 -vz -w 5 server.example.internal 443 ``` **Windows – aufgelöste Zieladresse beachten:** ```powershell [TEST] Test-NetConnection server.example.internal -Port 443 -InformationLevel Detailed ``` In der Ausgabe muss `RemoteAddress` kontrolliert werden. Ein erfolgreicher IPv4-Test beweist nicht, dass IPv6 funktioniert – und umgekehrt.
---
13. TCP-Zustände beurteilen | TCP-Zustand | Bedeutung | Diagnosehinweis | |---|---|---| | `LISTEN` | Socket wartet auf eingehende Verbindungen | Dienst ist lokal grundsätzlich gebunden | | `SYN-SENT` | Client hat SYN gesendet und wartet | Viele dauerhafte Einträge können auf fehlende Antworten hindeuten | | `SYN-RECEIVED` | SYN wurde empfangen, SYN-ACK gesendet | Viele Einträge können auf fehlende abschließende ACKs hinweisen | | `ESTABLISHED` | TCP-Verbindung besteht | Transportverbindung funktioniert grundsätzlich | | `FIN-WAIT-1` | Aktives Schließen wurde begonnen | Kurzzeitig normal | | `FIN-WAIT-2` | Eigenes FIN wurde bestätigt | Dauerhafte Häufung kann auf Probleme der Gegenstelle hinweisen | | `CLOSE-WAIT` | Gegenstelle hat geschlossen, lokale Anwendung noch nicht | Viele dauerhafte Einträge deuten häufig auf ein Anwendungsproblem hin | | `LAST-ACK` | Lokale Seite wartet auf Bestätigung ihres FIN | Kurzzeitig normal | | `TIME-WAIT` | Verbindung bleibt vorübergehend gespeichert | Viele Einträge können bei hoher Verbindungsrate normal sein | | `CLOSED` | Keine Verbindung vorhanden | Normaler Endzustand | **Windows – bestehende TCP-Verbindungen:** ```powershell [RO] Get-NetTCPConnection -State Established ``` **Windows – Verbindungen zu einem bestimmten Zielport:** ```powershell [RO] Get-NetTCPConnection -RemotePort 443 ``` **Linux – bestehende TCP-Verbindungen:** ```bash [RO] ss -tn state established ``` **Linux – Verbindungen mit Zustand und Timern:** ```bash [RO] ss -tano ``` **macOS – TCP-Zustände:** ```bash [RO] netstat -anv -p tcp ``` Ein einzelner Zustand ist nur eine Momentaufnahme. Bei sporadischen Problemen sind wiederholte Beobachtungen, Anwendungsprotokolle und gegebenenfalls ein Paketmitschnitt erforderlich.
---
14. TCP-Paketmuster interpretieren | Beobachtung im Mitschnitt | Typische Interpretation | |---|---| | `SYN → SYN/ACK → ACK` | TCP-Verbindung wurde aufgebaut | | Wiederholte SYN-Pakete ohne Antwort | Paketverlust, Filterung, falsches Routing, ausgefallenes Ziel oder fehlerhafter Rückweg | | `SYN → RST/ACK` | Ziel ist erreichbar, aber Port ist geschlossen oder wird aktiv abgelehnt | | SYN-ACK kommt an, abschließendes ACK fehlt | Problem auf der Clientseite oder beim Rückweg des ACK möglich | | Verbindung wird aufgebaut und sofort mit RST beendet | Anwendung oder Sicherheitskomponente bricht Verbindung ab | | Viele Retransmissions | Paketverlust, Überlastung, fehlerhafte Verbindung oder asymmetrische Erfassung möglich | | TCP-Verbindung erfolgreich, HTTP-Fehler folgt | Transportschicht funktioniert; Fehler liegt wahrscheinlich auf Anwendungsebene | Ein Paketmitschnitt sollte möglichst gleichzeitig auf Client und Server erfolgen. Dadurch lässt sich feststellen, an welcher Stelle Pakete verloren gehen oder verändert werden.
---
15. Paketmitschnitt für einen Port erstellen Paketmitschnitte können IP-Adressen, Hostnamen, Nutzdaten, Cookies und andere vertrauliche Informationen enthalten. Speicherung und Weitergabe müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen. **Linux – TCP-Port 443 mitschneiden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.20 and tcp port 443' \ -w port-443.pcap ``` **Linux – UDP-Port 53 mitschneiden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.53 and udp port 53' \ -w dns-udp.pcap ``` **macOS – vorher Schnittstellen ermitteln:** ```bash [RO] networksetup -listallhardwareports ``` Anschließend beispielsweise: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.20 and tcp port 443' \ -w port-443.pcap ``` **Windows – verfügbare Schnittstellen mit Dumpcap anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt auf Schnittstelle 1:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.20 and tcp port 443" ` -w port-443.pcapng ``` Die Schnittstellennummer `1` ist nur ein Beispiel und muss vorher mit `dumpcap -D` ermittelt werden.
---
16. Nützliche Wireshark-Anzeigefilter | Aufgabe | Wireshark-Anzeigefilter | |---|---| | TCP-Port 443 | `tcp.port == 443` | | UDP-Port 53 | `udp.port == 53` | | Verkehr zu oder von einer IP-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | IP-Adresse und TCP-Port | `ip.addr == 192.0.2.20 && tcp.port == 443` | | TCP-SYN-Pakete | `tcp.flags.syn == 1` | | Nur erste SYN-Pakete ohne gesetztes ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | Vermutete TCP-Wiederholungen | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | TCP-Verbindungsaufbau | `tcp.connection.syn || tcp.connection.synack` | | ICMP-Meldungen | `icmp` | | ICMPv6-Meldungen | `icmpv6` | Wireshark-Analysehinweise wie `tcp.analysis.retransmission` sind Interpretationen anhand des vorhandenen Mitschnitts. Fehlende Pakete am Beginn oder während der Aufzeichnung können zu irreführenden Markierungen führen.
---
17. Container und veröffentlichte Ports prüfen Bei Containerdiensten müssen mehrere Ebenen unterschieden werden: ```text Client ↓ Host-IP und veröffentlichter Hostport ↓ Portweiterleitung oder Proxy ↓ Container-IP und Containerport ↓ Anwendungsprozess im Container ``` **Laufende Container und Portzuordnungen anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines Containers anzeigen:** ```bash [RO] docker port webserver ``` **Container detailliert untersuchen:** ```bash [RO][SENS] docker inspect webserver ``` Zu prüfen sind: - Ist der Container gestartet? - Ist der benötigte Containerport veröffentlicht? - Wurde der richtige Hostport verwendet? - Ist der Hostport nur an `127.0.0.1` gebunden? - Lauscht die Anwendung innerhalb des Containers? - Verwendet die Anwendung im Container die richtige Bind-Adresse? - Existiert eine vorgeschaltete Firewall oder ein Reverse Proxy? - Ist der Zugriff nur innerhalb eines Container-Netzwerks vorgesehen? Eine Docker-Ausgabe wie diese: ```text 127.0.0.1:8080->80/tcp ``` bedeutet, dass der veröffentlichte Hostport normalerweise nur über die Loopback-Adresse des Docker-Hosts erreichbar ist. Eine Ausgabe wie: ```text 0.0.0.0:8080->80/tcp ``` zeigt eine Veröffentlichung über die passenden IPv4-Adressen des Hosts. Ob ein entfernter Zugriff erlaubt ist, hängt zusätzlich von Firewall, Routing und Netzwerkrichtlinien ab.
---
18. Typische Fehlerbilder systematisch eingrenzen **Fall A – Auf dem Server existiert kein Listener** ```text Porttest vom Client schlägt fehl ↓ Auf dem Server ist kein LISTEN-Socket vorhanden ↓ Dienststatus, Dienstkonfiguration und Protokolldateien prüfen ``` Mögliche Ursachen: - Dienst wurde nicht gestartet. - Dienst ist abgestürzt. - Falscher Port wurde konfiguriert. - Dienst konnte den Port nicht binden. - Ein anderer Prozess verwendet den Port. - Dienst lauscht nur auf einer anderen Adresse oder einem anderen Protokoll. --- **Fall B – Dienst lauscht nur auf Loopback** ```text Lokaler Test erfolgreich Entfernter Test nicht erfolgreich Listener: 127.0.0.1:PORT oder ::1:PORT ``` Wahrscheinliche Ursache: - Der Dienst ist ausschließlich für lokale Verbindungen konfiguriert. --- **Fall C – Listener vorhanden, entfernter Test läuft in einen Timeout** Mögliche Ursachen: - Host-Firewall filtert den Port. - Netzwerk-Firewall oder Access Control List filtert den Port. - Falsches VLAN oder fehlerhaftes Routing. - Rückweg zum Client fehlt. - NAT- oder Portweiterleitungsregel fehlt. - Es wird die falsche IP-Adresse getestet. - Dienst lauscht nur auf IPv4 oder nur auf IPv6. - Zielsystem ist über einen anderen Netzwerkpfad erreichbar als erwartet. --- **Fall D – `Connection refused`** Mögliche Ursachen: - Kein Prozess lauscht auf dem Zielport. - Dienst lauscht nur auf einer anderen IP-Adresse. - Aktive Firewall-Ablehnung. - Portweiterleitung zeigt auf ein Ziel ohne Listener. - Anwendung wurde während des Tests beendet. --- **Fall E – TCP-Test erfolgreich, Anwendung funktioniert nicht** Die Netz- und Transportschicht funktionieren zumindest grundsätzlich. Anschließend prüfen: - TLS-Handshake und Zertifikatskette - Server Name Indication - HTTP-Statuscode - Authentifizierung - Benutzerberechtigung - Reverse Proxy - Backend-Erreichbarkeit - Anwendungskonfiguration - Datenbankverbindung - Anwendungsprotokolle --- **Fall F – Nur manche Clients sind betroffen** Vergleich zwischen funktionierendem und betroffenem Client: - aufgelöste Ziel-IP-Adresse, - IPv4 oder IPv6, - Quell-IP-Adresse, - VLAN, - Standardgateway, - Routingtabelle, - Proxykonfiguration, - lokale Firewall, - VPN-Verbindung, - DNS-Suffix und DNS-Server, - Zeitpunkt des Tests. --- **Fall G – UDP-Test liefert kein eindeutiges Ergebnis** Vorgehen: 1. Gültige Anfrage des Anwendungsprotokolls senden. 2. Gleichzeitig auf Client und Server mitschneiden. 3. Prüfen, ob die Anfrage den Server erreicht. 4. Prüfen, ob der Server eine Antwort erzeugt. 5. Prüfen, ob die Antwort den Client erreicht. 6. ICMP- beziehungsweise ICMPv6-Fehlermeldungen beachten.
---
19. Empfohlener Diagnoseablauf | Schritt | Prüfung | Ergebnisfrage | |---:|---|---| | 1 | Zielhost, Zieladresse, Transportprotokoll und Port bestimmen | Was soll genau erreicht werden? | | 2 | Namensauflösung kontrollieren | Wird die erwartete IP-Adresse verwendet? | | 3 | Routing und Quelladresse kontrollieren | Wird der erwartete Netzwerkpfad verwendet? | | 4 | Dienststatus auf dem Server prüfen | Läuft die Anwendung? | | 5 | Lokalen Listener oder UDP-Endpunkt prüfen | Lauscht der Dienst auf Port und Adresse? | | 6 | Prozess dem Socket zuordnen | Gehört der Port zur erwarteten Anwendung? | | 7 | Lokal auf dem Server testen | Funktioniert der Dienst lokal? | | 8 | Vom betroffenen Clientsegment testen | Ist der Transportweg funktionsfähig? | | 9 | IPv4 und IPv6 getrennt testen | Ist nur eine Adressfamilie betroffen? | | 10 | Anwendungsprotokoll testen | Antwortet der eigentliche Dienst korrekt? | | 11 | Firewall, ACL, NAT und Proxy prüfen | Wird der Verkehr unterwegs beeinflusst? | | 12 | Paketmitschnitt erstellen | Wo endet der erfolgreiche Paketfluss? | | 13 | Vergleich mit funktionierendem System | Welche relevante Abweichung besteht? | | 14 | Ergebnis dokumentieren | Ist die Diagnose reproduzierbar? | **Grundregel:** ```text Listener vorhanden ≠ Port aus jedem Netz erreichbar ≠ Anwendung funktionsfähig ≠ Benutzer kann den Dienst erfolgreich verwenden ``` Jede dieser Aussagen muss getrennt geprüft werden.
---
20. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Listener anzeigen | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte anzeigen | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | Listener mit Prozess | `[RO] Get-NetTCPConnection -State Listen` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | TCP-Port 443 lokal prüfen | `[RO] Get-NetTCPConnection -State Listen -LocalPort 443` | `[RO] ss -ltn 'sport = :443'` | `[RO] lsof -nP -iTCP:443 -sTCP:LISTEN` | | TCP-Port entfernt testen | `[TEST] Test-NetConnection HOST -Port 443` | `[TEST] nc -vz -w 5 HOST 443` | `[TEST] nc -vz -w 5 HOST 443` | | HTTP testen | `[TEST] curl.exe -v http://HOST/` | `[TEST] curl -v http://HOST/` | `[TEST] curl -v http://HOST/` | | HTTPS testen | `[TEST] curl.exe -v https://HOST/` | `[TEST] curl -v https://HOST/` | `[TEST] curl -v https://HOST/` | | TLS-Handshake | Falls OpenSSL installiert: `[TEST] openssl s_client -connect HOST:443 -servername HOST` | `[TEST] openssl s_client -connect HOST:443 -servername HOST` | `[TEST] openssl s_client -connect HOST:443 -servername HOST` | | TCP-Port mit Nmap | `[TEST] nmap -sT -p 443 HOST` | `[TEST] nmap -sT -p 443 HOST` | `[TEST] nmap -sT -p 443 HOST` | | UDP-Port mit Nmap | Administrator-Konsole: `[TEST][PRIV] nmap -sU -p 53 HOST` | `[TEST][PRIV] sudo nmap -sU -p 53 HOST` | `[TEST][PRIV] sudo nmap -sU -p 53 HOST` | | Bestehende TCP-Verbindungen | `[RO] Get-NetTCPConnection -State Established` | `[RO] ss -tn state established` | `[RO] netstat -anv -p tcp` | | Prozess über PID suchen | `[RO] Get-Process -Id PID` | `[RO] ps -fp PID` | `[RO] ps -p PID -o pid,ppid,user,command` | `HOST`, `PID`, IP-Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
21. Änderungen erst nach gesicherter Diagnose durchführen Nicht vorschnell: - die Firewall vollständig deaktivieren, - beliebige Ports dauerhaft freigeben, - Dienste unkontrolliert neu starten, - Sicherheitssoftware abschalten, - Listener an alle Adressen binden, - Ports ohne Freigabe scannen, - NAT- oder Firewallregeln ohne Dokumentation verändern. Stattdessen: 1. Fehlerzustand dokumentieren. 2. Erwarteten Sollzustand bestimmen. 3. Ursache möglichst eindeutig nachweisen. 4. Änderung genehmigen lassen. 5. Nur die erforderliche Änderung durchführen. 6. Funktion und Sicherheit anschließend erneut prüfen. 7. Rückfallmöglichkeit und Ergebnis dokumentieren. Ein temporär deaktivierter Paketfilter kann zwar eine Hypothese bestätigen, erzeugt aber ein Sicherheitsrisiko und kann den ursprünglichen Zustand verändern. Besser ist eine gezielte Auswertung von Regeln, Protokollen und Paketmitschnitten.
---
22. Dokumentationsvorlage für Port- und Transportfehler ```text Störung: Zeitpunkt: Betroffener Benutzer beziehungsweise Standort: Clientname: Client-IP-Adresse: Client-VLAN: Client-Betriebssystem: Zielhostname: Aufgelöste Zieladresse: Verwendete Adressfamilie: IPv4 / IPv6 Transportprotokoll: TCP / UDP Zielport: Erwarteter Dienst: Lokaler Listener vorhanden: Ja / Nein Bind-Adresse: Zugehöriger Prozess: Prozess-ID: Dienststatus: Lokaler Funktionstest: Entfernter Porttest: Anwendungsprotokolltest: TCP- beziehungsweise UDP-Ergebnis: Beobachtete Fehlermeldung: Firewall- oder ACL-Prüfung: Paketmitschnitt vorhanden: Beobachtetes Paketmuster: Vergleich mit funktionierendem System: Festgestellte Ursache: Durchgeführte Änderung: Änderung genehmigt durch: Ergebnis der Nachprüfung: Offene Punkte: ``` Vor der Ablage müssen Passwörter, Sitzungstoken, personenbezogene Daten und andere vertrauliche Inhalte entfernt oder geschützt werden.
---
23. Kontrollfragen nach der Diagnose - Wurde wirklich der richtige Host getestet? - Wurde die tatsächlich aufgelöste IP-Adresse dokumentiert? - Wurde zwischen TCP und UDP unterschieden? - Lauscht der Dienst auf dem erwarteten Port? - Gehört der Listener zur erwarteten Anwendung? - Lauscht der Dienst an der richtigen IP-Adresse? - Wurden IPv4 und IPv6 getrennt betrachtet? - Wurde vom tatsächlich betroffenen Netzsegment getestet? - Wurde ein Anwendungstest zusätzlich zum Porttest durchgeführt? - Wurde bei UDP eine gültige Protokollanfrage verwendet? - Wurden Rückweg und Firewallregeln berücksichtigt? - Wurde ein Timeout nicht vorschnell als „Port geschlossen“ bezeichnet? - Wurde ein erfolgreicher TCP-Test nicht mit einer funktionsfähigen Anwendung gleichgesetzt? - Ist die Ursache durch Messergebnisse belegt? - Wurde der Zustand nach einer Änderung erneut geprüft?
---
24. Quellen und weiterführende Dokumentation - Microsoft Learn – Get-NetTCPConnection: https://learn.microsoft.com/powershell/module/nettcpip/get-nettcpconnection - Microsoft Learn – Get-NetUDPEndpoint: https://learn.microsoft.com/powershell/module/nettcpip/get-netudpendpoint - Microsoft Learn – Test-NetConnection: https://learn.microsoft.com/powershell/module/nettcpip/test-netconnection - Linux-Handbuch – `ss(8)`: https://man7.org/linux/man-pages/man8/ss.8.html - RFC 9293 – Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293.html - RFC 768 – User Datagram Protocol: https://www.rfc-editor.org/rfc/rfc768.html - IANA – Service Name and Transport Protocol Port Number Registry: https://www.iana.org/assignments/service-names-port-numbers/ - Nmap – Port Scanning Basics: https://nmap.org/book/man-port-scanning-basics.html - Nmap – Port Scanning Techniques: https://nmap.org/book/man-port-scanning-techniques.html - Wireshark – TCP Display Filter Reference: https://www.wireshark.org/docs/dfref/t/tcp.html - Wireshark – UDP Display Filter Reference: https://www.wireshark.org/docs/dfref/u/udp.html - Docker Docs – Publishing and exposing ports: https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/
# 3.10 Firewall- und Paketfilterfehler analysieren Firewalls können Verbindungen erlauben, verwerfen, ausdrücklich ablehnen, protokollieren oder an andere Ziele weiterleiten. Eine Anwendung kann korrekt laufen und auf dem richtigen Port lauschen, während der Zugriff trotzdem durch einen lokalen oder zentralen Paketfilter verhindert wird. Die zentrale Frage dieser Seite lautet: > Erreicht der Datenverkehr das Zielsystem, und welche Firewallregel entscheidet tatsächlich über das Paket? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert die Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | Firewallregeln enthalten häufig interne IP-Adressen, Servernamen, Anwendungen, Netzwerkbereiche und Sicherheitsrichtlinien. Entsprechende Ausgaben sind vertraulich zu behandeln.
---
2. Firewallfehler nicht vorschnell vermuten Die Meldung „Das ist bestimmt die Firewall“ ist zunächst nur eine Hypothese. Vor einer Änderung müssen mindestens folgende Punkte geprüft werden: 1. Wurde der richtige Hostname verwendet? 2. Wurde die erwartete IP-Adresse aufgelöst? 3. Ist eine gültige Route zum Ziel vorhanden? 4. Läuft der benötigte Dienst? 5. Lauscht der Dienst auf dem erwarteten Port und Protokoll? 6. Lauscht der Dienst an der richtigen IP-Adresse? 7. Funktioniert der Zugriff lokal auf dem Server? 8. Funktioniert der Zugriff aus einem anderen Netzsegment? 9. Erreicht das Paket das Zielsystem? 10. Wird eine Blockierung protokolliert? **Wichtig:** ```text Timeout ≠ sicherer Nachweis einer Firewallblockierung ``` Ein Timeout kann ebenfalls durch Paketverlust, falsches Routing, einen fehlenden Rückweg, eine falsche Zieladresse, NAT-Fehler oder einen ausgefallenen Host entstehen.
---
3. DROP, REJECT und ALLOW unterscheiden | Aktion | Verhalten | Typische Beobachtung | |---|---|---| | `ALLOW` beziehungsweise `ACCEPT` | Passender Verkehr wird zugelassen | Verbindung kann aufgebaut werden | | `DROP` | Paket wird ohne Antwort verworfen | Client wartet häufig bis zum Timeout | | `REJECT` | Paket wird abgelehnt und eine Fehlermeldung zurückgesendet | Client erhält häufig schnell einen Fehler | | `LOG` | Paketinformationen werden protokolliert | Allein keine endgültige Erlaubnis oder Blockierung | | `DNAT` beziehungsweise Portweiterleitung | Zieladresse oder Zielport wird verändert | Client erreicht möglicherweise ein internes Ziel | | `SNAT` beziehungsweise Masquerading | Quelladresse wird verändert | Ziel erkennt die Adresse des NAT-Systems | | `RETURN` | Verarbeitung kehrt zur aufrufenden Regelkette zurück | Wirkung hängt von weiteren Regeln ab | Bei TCP kann eine aktive Ablehnung beispielsweise durch ein TCP-RST sichtbar werden. Bei anderen Fällen kann eine ICMP- oder ICMPv6-Fehlermeldung zurückgegeben werden. Das genaue Verhalten hängt vom Betriebssystem, Regelwerk und eingesetzten Sicherheitsprodukt ab.
---
4. Prüfen, welche Firewall tatsächlich verwendet wird Auf einem System können mehrere Verwaltungsebenen vorhanden sein: - native Betriebssystem-Firewall, - `firewalld`, - `nftables`, - `iptables`, - `ufw`, - Sicherheitssoftware eines Drittanbieters, - Endpoint-Detection-and-Response-System, - Container-Firewallregeln, - Hypervisor-Firewall, - zentrale Netzwerk-Firewall, - Router-ACL, - Cloud-Sicherheitsgruppe, - VPN- oder Zero-Trust-Client. Eine Oberfläche wie `ufw` oder `firewalld` verwaltet im Hintergrund das eigentliche Paketfiltersystem. Regeln sollten deshalb nicht unkoordiniert über mehrere Werkzeuge verändert werden. | Betriebssystem | Typische lokale Filter | |---|---| | Windows | Windows Defender Firewall, IPsec-Regeln, Sicherheitssoftware | | Linux | nftables, firewalld, ufw, iptables und Sicherheitssoftware | | macOS | Anwendungsfirewall, Packet Filter `pf` und Sicherheitssoftware | **Grundregel:** > Zuerst die aktive Verwaltungs- und Richtlinienebene identifizieren, danach Regeln bewerten.
---
5. Datenfluss und Prüfrichtung festlegen Vor der Regelsuche muss der betroffene Datenfluss eindeutig beschrieben werden. ```text Client-IP:Quellport ↓ Transportprotokoll ↓ Ziel-IP:Zielport ↓ Serveranwendung ``` Zu dokumentieren sind: | Merkmal | Beispiel | |---|---| | Richtung | Client zum Server | | Adressfamilie | IPv4 | | Transportprotokoll | TCP | | Quelladresse | `192.0.2.25` | | Quellport | dynamisch, beispielsweise `53144` | | Zieladresse | `192.0.2.53` | | Zielport | `443` | | Schnittstelle | `Ethernet` beziehungsweise `eth0` | | Netzwerkprofil oder Zone | `Domain` beziehungsweise `public` | | Anwendung | Webserver | | Zeitpunkt | Mit Zeitzone und Sekunden | **Eingehend und ausgehend sind standortabhängig:** ```text Client: ausgehende Verbindung Server: eingehende Verbindung ``` Bei Routern, NAT-Systemen und Firewalls zwischen Netzen kann zusätzlich die Weiterleitungsrichtung betroffen sein.
---
6. Windows-Firewallstatus und aktive Profile prüfen Windows verwendet die Profile: - `Domain` - `Private` - `Public` Je nach aktiver Netzwerkverbindung können unterschiedliche Profile und Regeln gelten. **Aktives Netzwerkprofil prüfen:** ```powershell [RO] Get-NetConnectionProfile | Format-Table InterfaceAlias, Name, NetworkCategory, IPv4Connectivity, IPv6Connectivity ``` **Status aller Firewallprofile:** ```powershell [RO] Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction ``` **Ausführliche Profileinstellungen:** ```powershell [RO] Get-NetFirewallProfile | Format-List Name, Enabled, DefaultInboundAction, DefaultOutboundAction, AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules, NotifyOnListen, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes ``` **Klassische Statusanzeige:** ```cmd [RO] netsh advfirewall show allprofiles ``` Zu kontrollieren sind: - Welches Netzwerkprofil ist aktiv? - Ist die Firewall für dieses Profil aktiviert? - Was ist die Standardaktion für eingehenden Verkehr? - Was ist die Standardaktion für ausgehenden Verkehr? - Dürfen lokale Regeln angewendet werden? - Werden die Einstellungen durch Gruppenrichtlinien verwaltet? - Ist die Protokollierung zugelassener oder blockierter Pakete aktiviert? **Typischer Fehler:** ```text Regel gilt nur für Profil Private ↓ Netzwerk wurde als Public erkannt ↓ Regel greift nicht ``` Das Netzwerkprofil darf nicht allein zur Fehlerbehebung verändert werden. Zuerst ist zu prüfen, warum Windows das Netzwerk entsprechend eingestuft hat und welche Unternehmensrichtlinie gelten soll.
---
7. Windows-Firewallregeln untersuchen **Alle aktivierten Regeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True | Format-Table DisplayName, Direction, Action, Profile ``` **Aktive Blockierungsregeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True -Action Block | Format-Table DisplayName, Direction, Profile ``` **Aktive eingehende Erlaubnisregeln anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Format-Table DisplayName, Profile ``` **Bestimmte Regel ausführlich anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Format-List * ``` Windows speichert Port-, Adress-, Programm-, Dienst- und Schnittstellenbedingungen in zugehörigen Filterobjekten. `Get-NetFirewallRule` allein zeigt deshalb nicht alle Bedingungen einer Regel. **Portbedingungen einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallPortFilter | Format-List * ``` **Adressbedingungen einer Regel:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallAddressFilter | Format-List * ``` **Anwendungsbedingung einer Regel:** ```powershell [RO][SENS] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallApplicationFilter | Format-List * ``` **Dienstbedingung einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallServiceFilter | Format-List * ``` **Schnittstellenbedingung einer Regel:** ```powershell [RO] Get-NetFirewallRule -DisplayName "NAME DER REGEL" | Get-NetFirewallInterfaceFilter | Format-List * ``` **Regeln für lokalen TCP-Port 443 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol TCP | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` **Regeln für lokalen UDP-Port 53 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol UDP | Where-Object LocalPort -eq "53" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` **Regeln für eine bestimmte Anwendung suchen:** ```powershell [RO][SENS] Get-NetFirewallApplicationFilter | Where-Object Program -like "*\PROGRAMM.exe" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ``` Der Programmpfad muss durch den tatsächlichen Pfad beziehungsweise ein eindeutiges Suchmuster ersetzt werden.
---
8. Windows-Regeln vollständig beurteilen Bei einer vermeintlich passenden Regel müssen alle Bedingungen kontrolliert werden: | Bedingung | Kontrollfrage | |---|---| | `Enabled` | Ist die Regel aktiviert? | | `Direction` | Gilt sie eingehend oder ausgehend? | | `Action` | Erlaubt oder blockiert sie? | | `Profile` | Gilt sie für das aktive Profil? | | `Protocol` | TCP, UDP, ICMPv4 oder ICMPv6? | | `LocalPort` | Stimmt der lokale Port? | | `RemotePort` | Ist ein bestimmter entfernter Port vorgegeben? | | `LocalAddress` | Gilt sie für die verwendete lokale Adresse? | | `RemoteAddress` | Ist die Clientadresse oder ihr Netz erlaubt? | | `Program` | Stimmt der ausführbare Programmpfad? | | `Service` | Ist die Regel an einen bestimmten Dienst gebunden? | | `InterfaceType` | Gilt sie für LAN, WLAN oder Remotezugriff? | | `EdgeTraversalPolicy` | Ist spezieller eingehender Verkehr betroffen? | | Richtlinienquelle | Stammt sie lokal, aus Gruppenrichtlinien oder MDM? | **Richtlinienquelle anzeigen:** ```powershell [RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore | Select-Object DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSourceType, PolicyStoreSource | Format-Table -AutoSize ``` `ActiveStore` repräsentiert die wirksame Zusammenführung der angewendeten Richtlinien. Eine lokal sichtbare Regel kann durch zentral verwaltete Vorgaben eingeschränkt sein. **Wichtig:** Eine scheinbar passende Erlaubnisregel beweist nicht automatisch, dass keine andere wirksame Regel oder Sicherheitskomponente den Datenverkehr blockiert.
---
9. Windows-Firewallprotokollierung prüfen **Konfigurierte Protokolldateien und Einstellungen anzeigen:** ```powershell [RO] Get-NetFirewallProfile | Select-Object Name, LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes | Format-List ``` Der konkrete Speicherort muss aus `LogFileName` übernommen werden. Er sollte nicht angenommen oder fest im Diagnoseablauf vorgegeben werden. **Konfigurierte Protokolldatei lesen:** ```powershell [RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 100 ``` **Datei fortlaufend beobachten:** ```powershell [RO][PRIV][SENS] Get-Content "PFAD AUS LogFileName" -Tail 20 -Wait ``` Während der Beobachtung wird der fehlgeschlagene Verbindungstest erneut ausgeführt. Dabei müssen Zeitpunkt, Quelladresse, Zieladresse, Protokoll und Port abgeglichen werden. **Ereignisprotokolle zur Firewall suchen:** ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *Firewall* | Select-Object LogName, IsEnabled, RecordCount ``` Anschließend kann ein tatsächlich vorhandenes Protokoll gezielt abgefragt werden: ```powershell [RO][PRIV][SENS] Get-WinEvent -LogName "ERMITTELTER PROTOKOLLNAME" -MaxEvents 50 ``` Nicht jede Paketblockierung erscheint automatisch im Windows-Ereignisprotokoll. Die erforderliche Überwachung beziehungsweise Protokollierung muss zuvor aktiviert und durch die Unternehmensrichtlinie erlaubt sein.
---
10. Linux-Firewallsystem identifizieren **Vorhandene Werkzeuge ermitteln:** ```bash [RO] command -v firewall-cmd [RO] command -v nft [RO] command -v ufw [RO] command -v iptables ``` **Aktive Dienste prüfen:** ```bash [RO] systemctl is-active firewalld [RO] systemctl is-active nftables [RO] systemctl is-active ufw ``` Eine Ausgabe wie `inactive`, `failed` oder `unknown` muss im Kontext der jeweiligen Distribution bewertet werden. Beispielsweise kann ein nftables-Regelwerk aktiv sein, obwohl kein dauerhaft laufender `nftables`-Dienst angezeigt wird. **Geladene nftables-Regeln prüfen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **iptables-Regeln prüfen:** ```bash [RO][PRIV][SENS] sudo iptables -S [RO][PRIV][SENS] sudo ip6tables -S ``` **iptables-Regeln mit Zählern:** ```bash [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers [RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers ``` Auf modernen Linux-Systemen kann der Befehl `iptables` ein Kompatibilitätsfrontend für nftables sein. Deshalb muss geprüft werden, welche Verwaltungsebene die Distribution tatsächlich verwendet.
---
11. firewalld analysieren `firewalld` arbeitet mit Zonen. Schnittstellen oder Quellnetze werden einer Zone zugeordnet, für die Dienste, Ports und weitere Regeln gelten. **Status prüfen:** ```bash [RO] firewall-cmd --state ``` **Standardzone anzeigen:** ```bash [RO] firewall-cmd --get-default-zone ``` **Aktive Zonen und zugehörige Schnittstellen anzeigen:** ```bash [RO] firewall-cmd --get-active-zones ``` **Zone einer bestimmten Schnittstelle ermitteln:** ```bash [RO] firewall-cmd --get-zone-of-interface=eth0 ``` `eth0` muss durch die tatsächliche Schnittstelle ersetzt werden. **Komplette Laufzeitkonfiguration einer Zone anzeigen:** ```bash [RO][SENS] firewall-cmd --zone=public --list-all ``` **Alle Zonen anzeigen:** ```bash [RO][SENS] firewall-cmd --list-all-zones ``` **Freigegebene Dienste:** ```bash [RO] firewall-cmd --zone=public --list-services ``` **Freigegebene Ports:** ```bash [RO] firewall-cmd --zone=public --list-ports ``` **Prüfen, ob TCP-Port 443 in der Laufzeitkonfiguration freigegeben ist:** ```bash [RO] firewall-cmd --zone=public --query-port=443/tcp ``` **Prüfen, ob der HTTPS-Dienst freigegeben ist:** ```bash [RO] firewall-cmd --zone=public --query-service=https ``` **Rich Rules anzeigen:** ```bash [RO][SENS] firewall-cmd --zone=public --list-rich-rules ``` **Policies anzeigen:** ```bash [RO][SENS] firewall-cmd --get-policies ``` Bei jeder Prüfung muss die tatsächlich aktive Zone verwendet werden. Die Zone `public` ist nur ein Beispiel.
---
12. firewalld: Laufzeit- und dauerhafte Konfiguration vergleichen `firewalld` trennt zwischen: - **Runtime-Konfiguration:** aktuell im laufenden System wirksam - **Permanent-Konfiguration:** für erneutes Laden beziehungsweise Neustart gespeichert **Aktuelle Laufzeitkonfiguration:** ```bash [RO][SENS] firewall-cmd --zone=public --list-all ``` **Dauerhafte Konfiguration:** ```bash [RO][SENS] firewall-cmd --permanent --zone=public --list-all ``` **Typische Abweichungen:** | Situation | Folge | |---|---| | Port nur zur Laufzeit freigegeben | Freigabe verschwindet nach Reload oder Neustart | | Port nur dauerhaft eingetragen | Freigabe ist noch nicht zwingend zur Laufzeit aktiv | | Falsche Zone bearbeitet | Regel existiert, gilt aber nicht für die betroffene Schnittstelle | | Dienstname freigegeben, aber andere Portdefinition erwartet | Tatsächlicher Dienstport kann abweichen | | Schnittstellenzuordnung geändert | Anderes Zonenregelwerk wird wirksam | Eine Abweichung ist nicht automatisch ein Fehler. Sie muss mit dem vorgesehenen Sollzustand verglichen werden.
---
13. ufw analysieren **Status und Standardrichtlinien anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw status verbose ``` **Regeln nummeriert anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw status numbered ``` **Erweiterte Rohdarstellung anzeigen:** ```bash [RO][PRIV][SENS] sudo ufw show raw ``` Zu kontrollieren sind: - Ist `ufw` aktiv? - Welche Standardaktion gilt eingehend? - Welche Standardaktion gilt ausgehend? - Ist der richtige Port freigegeben? - Gilt die Regel für TCP oder UDP? - Ist die Regel auf eine Quelladresse beschränkt? - Existiert eine separate IPv6-Regel? - Gilt die Regel für die richtige Schnittstelle? - Gibt es vorhergehende Ablehnungsregeln? **Beispiel einer begrenzten Regelbeschreibung:** ```text TCP-Port 443 nur aus 192.0.2.0/24 eingehend über die vorgesehene Schnittstelle ``` Eine Ausgabe wie `443 ALLOW Anywhere` muss zusätzlich hinsichtlich IPv4, IPv6 und der tatsächlich aktiven Backend-Regeln bewertet werden.
---
14. nftables-Regelwerk untersuchen **Gesamtes geladenes Regelwerk anzeigen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **Tabellen anzeigen:** ```bash [RO][PRIV] sudo nft list tables ``` **Regelwerk mit Handles anzeigen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` **Regelwerk mit Zählern und Handles beobachten:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Bei nftables sind insbesondere zu prüfen: | Bestandteil | Bedeutung | |---|---| | Familie | `ip`, `ip6`, `inet`, `arp`, `bridge` oder `netdev` | | Tabelle | Logische Sammlung von Chains und Regeln | | Base Chain | An einen Netfilter-Hook gebundene Kette | | Hook | Beispielsweise `input`, `output` oder `forward` | | Priority | Reihenfolge gegenüber anderen Base Chains | | Policy | Standardaktion der Base Chain | | Match | Bedingung wie Adresse, Port, Protokoll oder Schnittstelle | | Verdict | Beispielsweise `accept`, `drop`, `reject`, `jump` oder `return` | | Counter | Anzahl passender Pakete und Bytes | | Handle | Interne Kennung einer Regel | **Wichtige Diagnosefrage:** > Steigt der Zähler der vermuteten Regel, während der Verbindungstest ausgeführt wird? Wenn der Zähler nicht steigt, kann dies bedeuten: - Das Paket erreicht das System nicht. - Das Paket durchläuft eine andere Chain. - Eine vorherige Regel entscheidet bereits. - Protokoll, Port oder Adresse stimmen nicht. - IPv4 und IPv6 wurden verwechselt. - Eine andere Firewallkomponente greift ein.
---
15. iptables-Regeln untersuchen **Filterregeln mit Zählern und Zeilennummern:** ```bash [RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers ``` **IPv6-Regeln:** ```bash [RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers ``` **Regeln in Befehlsschreibweise:** ```bash [RO][PRIV][SENS] sudo iptables -S ``` **NAT-Tabelle:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers ``` **Weitere häufig relevante Tabellen:** ```bash [RO][PRIV][SENS] sudo iptables -t mangle -L -n -v --line-numbers [RO][PRIV][SENS] sudo iptables -t raw -L -n -v --line-numbers ``` Zu prüfen sind: - Standardrichtlinie der Chain, - Reihenfolge der Regeln, - Quell- und Zieladressen, - Eingangs- und Ausgangsschnittstelle, - Transportprotokoll, - Quell- und Zielport, - Verbindungszustand, - Sprung in benutzerdefinierte Chains, - Paket- und Bytezähler, - IPv4- und IPv6-Regeln, - NAT-Regeln. Bei iptables entscheidet häufig die erste zutreffende Regel, die ein endgültiges Ziel wie `ACCEPT`, `DROP` oder `REJECT` ausführt. Eine Erlaubnisregel unterhalb einer bereits passenden Blockierungsregel wird dann nicht erreicht.
---
16. macOS-Anwendungsfirewall prüfen Die macOS-Anwendungsfirewall kontrolliert hauptsächlich eingehende Verbindungen anhand von Anwendungen und Diensten. Sie ist nicht mit dem Packet Filter `pf` gleichzusetzen. **Grafische Prüfung:** ```text Systemeinstellungen → Netzwerk → Firewall ``` Je nach macOS-Version können die genaue Position und Bezeichnungen abweichen. **Status der Anwendungsfirewall:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate ``` **Prüfen, ob alle eingehenden Verbindungen blockiert werden:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall ``` **Stealth-Modus prüfen:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode ``` **Automatische Freigabe signierter Software prüfen:** ```bash [RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getallowsigned ``` **Konfigurierte Anwendungen anzeigen:** ```bash [RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps ``` Zu kontrollieren sind: - Ist die Anwendungsfirewall eingeschaltet? - Werden alle eingehenden Verbindungen blockiert? - Ist die betroffene Anwendung aufgeführt? - Ist die Anwendung zugelassen oder blockiert? - Hat sich der Programmpfad nach einem Update geändert? - Wird der Dienst durch eine andere ausführbare Datei gestartet? - Wird die Einstellung durch ein Konfigurationsprofil oder MDM verwaltet? Die genaue Ausgabe von `socketfilterfw` kann zwischen macOS-Versionen variieren.
---
17. macOS Packet Filter pf prüfen `pf` ist ein paketbasierter Filter und getrennt von der macOS-Anwendungsfirewall zu betrachten. **Status und grundlegende Informationen:** ```bash [RO][PRIV] sudo pfctl -s info ``` **Geladene Filterregeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s rules ``` **NAT-Regeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s nat ``` **Alle verfügbaren pf-Informationen anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s all ``` **Zustandstabelle anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s states ``` **Regeln mit zusätzlichen Informationen anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -vvs rules ``` Zu kontrollieren sind: - Ist `pf` aktiviert? - Welche Regeln und Anchors wurden geladen? - Gibt es NAT- oder Weiterleitungsregeln? - Stimmen Schnittstelle, Adressfamilie, Adresse, Protokoll und Port? - Erhöhen sich Regelzähler während des Tests? - Wird das Regelwerk durch VPN-, Virtualisierungs- oder Sicherheitssoftware ergänzt? **Nicht ausführen, solange keine ausdrücklich genehmigte Änderung vorgesehen ist:** ```text pf aktivieren oder deaktivieren Regelwerk neu laden Zustandstabellen leeren Anchors verändern ``` Solche Aktionen können bestehende Netzwerkverbindungen und Sicherheitsrichtlinien beeinflussen.
---
18. Host-Firewall oder Netzwerk-Firewall unterscheiden Ein Vergleich mehrerer Messpunkte hilft, die blockierende Stelle einzugrenzen. ```text Client ↓ Client-Firewall ↓ Switch/VLAN ↓ Router oder zentrale Firewall ↓ Server-Firewall ↓ Serveranwendung ``` | Beobachtung | Mögliche Schlussfolgerung | |---|---| | Paket verlässt den Client nicht | Client-Firewall, Anwendung oder lokales Routing prüfen | | Paket verlässt Client, erreicht Server aber nicht | Netzwerkpfad, ACL, VPN, NAT oder zentrale Firewall prüfen | | Paket erreicht Server, aber Anwendung erhält es nicht | Server-Firewall oder falsche Bindung prüfen | | SYN erreicht Server, keine Antwort verlässt ihn | Listener, Server-Firewall oder lokales Routing prüfen | | SYN-ACK verlässt Server, erreicht Client nicht | Rückweg oder Filter zwischen Server und Client prüfen | | Verbindung funktioniert lokal, aber nicht entfernt | Bind-Adresse, Server-Firewall oder Netzwerkfilter prüfen | | Nur ein Quellnetz ist betroffen | Quellnetz-, VLAN-, Zonen- oder Adressregel prüfen | | Nur IPv6 ist betroffen | IPv6-Regeln und ICMPv6 gesondert prüfen | Ein gleichzeitiger Paketmitschnitt auf Client und Server ist wesentlich aussagekräftiger als ein einseitiger Porttest.
---
19. Paketmitschnitt zur Firewallanalyse verwenden **Linux – TCP-Port 443 auf allen Schnittstellen:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ 'host 192.0.2.25 and tcp port 443' \ -w firewall-test.pcap ``` **macOS – TCP-Port 443 auf einer konkreten Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w firewall-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt auf der zuvor bestimmten Schnittstelle:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25 and tcp port 443" ` -w firewall-test.pcapng ``` Die Schnittstellennamen und -nummern sind Beispiele und müssen vorher ermittelt werden. **Wireshark-Anzeigefilter:** | Aufgabe | Filter | |---|---| | Gesamter Verkehr zwischen zwei IPv4-Systemen | `ip.addr == 192.0.2.25 && ip.addr == 192.0.2.53` | | TCP-Port 443 | `tcp.port == 443` | | Erste TCP-SYN-Pakete | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | ICMP-Fehler | `icmp` | | ICMPv6-Fehler | `icmpv6` | | Vermutete Wiederholungen | `tcp.analysis.retransmission` | **Interpretation:** | Paketmuster | Mögliche Bedeutung | |---|---| | Wiederholtes SYN ohne Antwort | DROP, Paketverlust, falscher Rückweg oder ausgefallenes Ziel | | SYN gefolgt von RST/ACK | Port geschlossen oder aktive Ablehnung | | ICMP administratively prohibited | Paketfilter oder Richtlinie lehnt Verkehr ausdrücklich ab | | SYN und SYN-ACK sichtbar, ACK fehlt | Rückweg oder Clientseite prüfen | | Vollständiger Handshake sichtbar | Firewall lässt den TCP-Aufbau grundsätzlich zu | | Handshake erfolgreich, danach Abbruch | Anwendungs-, TLS- oder Sitzungsproblem möglich | Der Mitschnitt beweist nur, was am jeweiligen Messpunkt sichtbar war.
---
20. Firewallprotokolle zeitlich korrekt auswerten Für eine zuverlässige Zuordnung werden folgende Werte benötigt: ```text Datum und Uhrzeit Zeitzone Quelladresse Zieladresse Transportprotokoll Quellport Zielport Richtung Aktion Schnittstelle oder Zone Regelname beziehungsweise Regel-ID ``` **Systemzeit prüfen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | Bei zentralen Firewalls können Zeitstempel in UTC gespeichert werden. Client-, Server- und Firewallzeit müssen deshalb einschließlich Zeitzone verglichen werden. **Empfohlener Testablauf:** 1. Exakten Startzeitpunkt notieren. 2. Einen einzelnen reproduzierbaren Verbindungstest durchführen. 3. Exakten Endzeitpunkt notieren. 4. Protokolle auf dieses Zeitfenster beschränken. 5. Quell- und Zieladresse sowie Port abgleichen. 6. Regelname und Aktion dokumentieren. 7. Bei NAT sowohl ursprüngliche als auch übersetzte Adressen berücksichtigen.
---
21. Stateful Inspection und Verbindungszustände berücksichtigen Moderne Firewalls arbeiten häufig zustandsorientiert. Sie verfolgen bestehende Verbindungen und unterscheiden beispielsweise: - neue Verbindung, - bestehende Verbindung, - zugehörige Verbindung, - ungültiger Zustand. Dadurch kann Rückverkehr erlaubt sein, obwohl keine allgemeine eingehende Freigabe für den dynamischen Clientport existiert. **Linux – Conntrack-Werkzeug vorhanden?** ```bash [RO] command -v conntrack ``` **Verbindungseinträge anzeigen, sofern das Werkzeug installiert ist:** ```bash [RO][PRIV][SENS] sudo conntrack -L ``` **Nur TCP-Verbindungen zu Port 443 filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443 ``` `conntrack` ist nicht auf jedem Linux-System standardmäßig installiert. Mögliche Fehlerbilder: - asymmetrisches Routing führt nur eine Richtung durch die zustandsorientierte Firewall, - veraltete Zustandseinträge beeinflussen neue Verbindungen, - NAT-Zustände stimmen nicht mit dem aktuellen Pfad überein, - Pakete werden als ungültig bewertet, - mehrere Firewalls sehen unterschiedliche Teile derselben Verbindung. Zustandstabellen dürfen nicht ohne Freigabe geleert werden. Das kann zahlreiche bestehende Verbindungen unterbrechen.
---
22. ICMP und ICMPv6 nicht pauschal blockieren ICMP beziehungsweise ICMPv6 wird nicht nur für `ping` verwendet. Es übermittelt wichtige Netzwerk- und Fehlermeldungen. Dazu gehören unter anderem: - Ziel nicht erreichbar, - Fragmentierung erforderlich, - Packet Too Big, - Time Exceeded, - Echo Request und Echo Reply, - Router- und Neighbor-Discovery-Funktionen bei IPv6. Eine zu weitgehende Blockierung kann zu schwer erkennbaren Fehlern führen: ```text Kleine Pakete funktionieren ↓ Größere Übertragungen bleiben hängen ↓ Erforderliche MTU-Fehlermeldung wird blockiert ↓ Path-MTU-Ermittlung funktioniert nicht richtig ``` Bei IPv6 sind bestimmte ICMPv6-Funktionen für den regulären Betrieb notwendig. „ICMP vollständig blockieren“ ist daher keine geeignete allgemeine Sicherheitsregel.
---
23. Typische Firewallfehler | Fehler | Wirkung | |---|---| | Falsches Windows-Profil | Regel ist vorhanden, aber nicht aktiv | | Falsche firewalld-Zone | Regel gilt nicht für die betroffene Schnittstelle | | TCP statt UDP freigegeben | Anwendung bleibt nicht erreichbar | | UDP statt TCP freigegeben | TCP-Verbindung schlägt weiterhin fehl | | Falscher lokaler oder entfernter Port | Regel passt nicht zum Datenfluss | | Zu enges Quellnetz | Bestimmte Clients funktionieren, andere nicht | | IPv4-Regel ohne IPv6-Entsprechung | Zugriff funktioniert nur über IPv4 | | Falscher Programmpfad | Anwendungsregel greift nach Update nicht mehr | | Erlaubnisregel unterhalb einer Blockierungsregel | Vorherige Regel entscheidet bereits | | Runtime- und permanente Regeln weichen ab | Fehler erscheint nach Reload oder Neustart | | Eingehend und ausgehend verwechselt | Falsche Richtung wurde freigegeben | | INPUT und FORWARD verwechselt | Router- oder Containerverkehr wird falsch bewertet | | Rückweg läuft über andere Firewall | Stateful Inspection kann Verbindung verwerfen | | Lokale und zentrale Richtlinie widersprechen sich | Erwartete lokale Regel ist nicht wirksam | | Containerport nicht veröffentlicht | Host-Firewallregel allein löst das Problem nicht | | Sicherheitssoftware zusätzlich aktiv | Native Firewallregeln erklären das Verhalten nicht vollständig |
---
24. Containerverkehr und Firewalls berücksichtigen Containerverkehr kann zusätzliche Regelketten, Bridges, NAT-Regeln und Weiterleitungen verwenden. ```text Client ↓ Host-Firewall ↓ veröffentlichter Hostport ↓ NAT oder Container-Proxy ↓ Container-Netzwerk ↓ Containerport ``` **Docker-Portzuordnungen prüfen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines Containers:** ```bash [RO] docker port CONTAINERNAME ``` **Docker-Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Konkretes Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` Zu prüfen sind: - Ist der Port überhaupt veröffentlicht? - Ist er nur an `127.0.0.1` gebunden? - Stimmen Hostport und Containerport? - Lauscht die Anwendung im Container? - Ist IP-Forwarding erforderlich und aktiv? - Wird der Verkehr durch die `FORWARD`-Kette verarbeitet? - Verwalten Docker und das Host-Firewallsystem gemeinsame Regeln? - Existiert ein Reverse Proxy vor dem Container? Firewallregeln, die von einer Containerplattform erzeugt wurden, dürfen nicht manuell verändert werden, ohne deren Verwaltungslogik und Auswirkungen zu berücksichtigen.
---
25. Sichere Gegenprobe ohne vollständiges Abschalten Eine Firewall vollständig zu deaktivieren ist keine bevorzugte Diagnosemethode. Bessere Gegenproben sind: 1. Regelzähler vor und nach einem einzelnen Test vergleichen. 2. Blockierungsprotokoll aktivieren, sofern genehmigt. 3. Gleichzeitig auf Client und Server mitschneiden. 4. Eine eng begrenzte temporäre Testregel beantragen. 5. Nur eine definierte Quelladresse erlauben. 6. Nur den benötigten Zielport und das richtige Protokoll erlauben. 7. Testzeitraum begrenzen. 8. Änderung und Rückbau dokumentieren. 9. Regel nach dem Test entfernen oder deaktivieren. 10. Anschließend den ursprünglichen Zustand bestätigen. **Beispiel für den Umfang einer genehmigten Testregel:** ```text Quelle: 192.0.2.25 Ziel: 192.0.2.53 Protokoll: TCP Zielport: 443 Richtung: eingehend Gültigkeit: nur während des Wartungsfensters Protokoll: aktiv ``` Die konkreten Änderungsbefehle werden erst nach Prüfung des vorhandenen Regelwerks, der Verwaltungsplattform und des genehmigten Sollzustands erstellt.
---
26. Warum die Firewall nicht einfach deaktiviert werden sollte Ein vollständiges Abschalten kann: - das System ungeschützt erreichbar machen, - gegen Unternehmensrichtlinien verstoßen, - andere Sicherheitsfunktionen beeinträchtigen, - den ursprünglichen Fehlerzustand verändern, - zentrale Richtlinien umgehen oder Konflikte erzeugen, - nicht beweisen, welche konkrete Regel verantwortlich war, - zusätzliche Verbindungen zulassen, die den Test verfälschen, - bei Remoteadministration zum Verbindungsabbruch führen. Microsoft empfiehlt ausdrücklich, die Windows-Firewall nicht einfach zu deaktivieren. Stattdessen sollen gezielte Regeln und Diagnosefunktionen verwendet werden. **Nicht als allgemeiner Diagnoseschritt verwenden:** ```text Windows-Firewall vollständig ausschalten firewalld stoppen ufw deaktivieren nftables-Regelwerk leeren iptables-Regeln leeren pf deaktivieren Sicherheitssoftware beenden ``` Diese Aktionen sind Änderungen mit potenziell weitreichenden Sicherheits- und Betriebsfolgen.
---
27. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Datenfluss definieren | Welche Quelle muss welches Ziel über welches Protokoll und welchen Port erreichen? | | 2 | Fehler reproduzieren | Ist das Verhalten reproduzierbar und zeitlich dokumentiert? | | 3 | DNS und Zieladresse prüfen | Wird wirklich das erwartete System angesprochen? | | 4 | Routing prüfen | Verwendet das Paket den erwarteten Weg? | | 5 | Serverdienst prüfen | Läuft der Dienst und lauscht er richtig? | | 6 | Lokalen Test durchführen | Funktioniert der Dienst direkt auf dem Server? | | 7 | Firewallsystem identifizieren | Welches Werkzeug und welche Richtlinie sind tatsächlich aktiv? | | 8 | Profil, Zone oder Schnittstelle prüfen | Welcher Regelbereich gilt für den Verkehr? | | 9 | Passende Regeln suchen | Stimmen Richtung, Protokoll, Port, Adressen und Anwendung? | | 10 | Reihenfolge und Priorität prüfen | Entscheidet vorher bereits eine andere Regel? | | 11 | Zähler und Protokolle beobachten | Trifft der Testverkehr auf die vermutete Regel? | | 12 | Client- und Servermitschnitt vergleichen | An welcher Stelle verschwindet das Paket? | | 13 | Zentrale Filter prüfen | Gibt es ACL, VPN-, Cloud- oder Netzwerk-Firewalls? | | 14 | Eng begrenzte Änderung planen | Welche minimale Änderung stellt den Sollzustand her? | | 15 | Änderung genehmigen und dokumentieren | Wer hat Umfang und Zeitraum freigegeben? | | 16 | Nachprüfung durchführen | Funktioniert der Dienst und bleibt die Sicherheit erhalten? |
---
28. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Aktives Netzwerkprofil oder Zone | `[RO] Get-NetConnectionProfile` | firewalld: `[RO] firewall-cmd --get-active-zones` | Anwendungsfirewall besitzt keine direkt vergleichbaren Netzwerkprofile | | Firewallstatus | `[RO] Get-NetFirewallProfile` | firewalld: `[RO] firewall-cmd --state` | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Aktive Regeln | `[RO][SENS] Get-NetFirewallRule -Enabled True` | nftables: `[RO][PRIV][SENS] sudo nft list ruleset` | pf: `[RO][PRIV][SENS] sudo pfctl -s rules` | | Blockierungsregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Action Block` | Regelwerk nach `drop` beziehungsweise `reject` untersuchen | Anwendungsregeln: `[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | TCP-Portregel suchen | `[RO] Get-NetFirewallPortFilter -Protocol TCP` | firewalld: `[RO] firewall-cmd --zone=ZONE --query-port=443/tcp` | pf-Regeln: `[RO][PRIV][SENS] sudo pfctl -vvs rules` | | UDP-Portregel suchen | `[RO] Get-NetFirewallPortFilter -Protocol UDP` | firewalld: `[RO] firewall-cmd --zone=ZONE --query-port=53/udp` | pf-Regeln: `[RO][PRIV][SENS] sudo pfctl -vvs rules` | | Firewallprofile ausführlich | `[RO] Get-NetFirewallProfile \| Format-List *` | Nicht direkt vergleichbar | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall` | | iptables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers` | Nicht standardmäßig verwendet | | nftables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | ufw-Status | Nicht zutreffend | `[RO][PRIV][SENS] sudo ufw status verbose` | Nicht zutreffend | | pf-Status | Nicht zutreffend | Nicht standardmäßig für alle Distributionen | `[RO][PRIV] sudo pfctl -s info` | | TCP-Porttest | `[TEST] Test-NetConnection HOST -Port 443` | `[TEST] nc -vz -w 5 HOST 443` | `[TEST] nc -vz -w 5 HOST 443` | | Paketmitschnitt | Dumpcap oder pktmon | `[TEST][PRIV][FILE][SENS] sudo tcpdump ...` | `[TEST][PRIV][FILE][SENS] sudo tcpdump ...` | `HOST`, `ZONE`, Schnittstellen, Adressen und Ports müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
29. Dokumentationsvorlage für Firewallfehler ```text Störung: Zeitpunkt: Zeitzone: Betroffener Standort: Betroffener Benutzer oder Dienst: Clienthostname: Client-IP-Adresse: Client-VLAN: Client-Schnittstelle: Zielhostname: Ziel-IP-Adresse: Zielport: Transportprotokoll: Adressfamilie: IPv4 / IPv6 Erwartete Anwendung: Dienststatus: Lokaler Listener: Bind-Adresse: Lokaler Funktionstest: Entfernter Verbindungstest: Fehlermeldung: Aktive lokale Firewall: Aktives Profil beziehungsweise aktive Zone: Standardaktion eingehend: Standardaktion ausgehend: Vermutete Regel: Regelrichtung: Regelaktion: Quellbeschränkung: Zielbeschränkung: Portbedingung: Programmbedingung: Richtlinienquelle: Regelzähler vor dem Test: Regelzähler nach dem Test: Firewallprotokolleintrag: Paket am Client sichtbar: Paket am Server sichtbar: Antwort am Server sichtbar: Antwort am Client sichtbar: Zentrale Firewall oder ACL: NAT beteiligt: Container oder Reverse Proxy beteiligt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
30. Kontrollfragen nach der Diagnose - Wurde der Datenfluss vollständig beschrieben? - Wurde zwischen eingehendem, ausgehendem und weitergeleitetem Verkehr unterschieden? - Wurde TCP, UDP, ICMP oder ICMPv6 korrekt bestimmt? - Wurde die tatsächlich verwendete Zieladresse dokumentiert? - Wurde geprüft, ob der Dienst lokal lauscht? - Wurde das aktive Windows-Profil beziehungsweise die aktive Linux-Zone ermittelt? - Wurde zwischen IPv4- und IPv6-Regeln unterschieden? - Wurden Adress-, Port-, Anwendungs- und Dienstfilter geprüft? - Wurde die Reihenfolge beziehungsweise Priorität der Regeln berücksichtigt? - Wurden zentrale Richtlinien und Drittanbieterprodukte berücksichtigt? - Wurde zwischen Runtime- und permanenter Konfiguration unterschieden? - Wurden Regelzähler während eines reproduzierbaren Tests beobachtet? - Wurden Client- und Servermitschnitt verglichen? - Wurde ein Timeout nicht automatisch als Firewallbeweis gewertet? - Wurde die Firewall nicht unnötig vollständig deaktiviert? - Wurde eine Änderung auf das erforderliche Minimum begrenzt? - Wurde der Sollzustand nach der Änderung erneut geprüft? - Wurde die Änderung einschließlich Rückfallplan dokumentiert?
---
31. Quellen und weiterführende Dokumentation - Microsoft Learn – Windows Firewall overview: https://learn.microsoft.com/windows/security/operating-system-security/network-security/windows-firewall/ - Microsoft Learn – Windows-Firewall über die Befehlszeile verwalten: https://learn.microsoft.com/de-de/windows/security/operating-system-security/network-security/windows-firewall/configure-with-command-line - Microsoft Learn – Get-NetFirewallProfile: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallprofile - Microsoft Learn – Get-NetFirewallRule: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallrule - Microsoft Learn – Get-NetFirewallPortFilter: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewallportfilter - Microsoft Learn – Get-NetFirewallAddressFilter: https://learn.microsoft.com/powershell/module/netsecurity/get-netfirewalladdressfilter - firewalld – Offizielle Dokumentation: https://firewalld.org/documentation/ - firewalld – Handbuch zu `firewall-cmd`: https://firewalld.org/documentation/man-pages/firewall-cmd - Netfilter – nftables Wiki: https://wiki.nftables.org/ - Netfilter – nftables-Regelwerk nachverfolgen: https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing - Ubuntu – UFW-Dokumentation: https://documentation.ubuntu.com/server/how-to/security/firewalls/ - Linux-Handbuch – `iptables(8)`: https://man7.org/linux/man-pages/man8/iptables.8.html - Linux-Handbuch – `nft(8)`: https://man7.org/linux/man-pages/man8/nft.8.html - Apple – Firewall-Sicherheit bei macOS: https://support.apple.com/de-de/guide/security/seca0e83763f/web - Apple – Verbindungen auf dem Mac mit einer Firewall blockieren: https://support.apple.com/de-de/guide/mac-help/mh34041/mac - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/
# 3.11 NAT- und Portweiterleitungsfehler analysieren Network Address Translation verändert IP-Adressen und teilweise auch Portnummern während der Übertragung. NAT wird unter anderem an Internetroutern, Firewalls, VPN-Gateways, Virtualisierungshosts und Containerplattformen eingesetzt. Eine Portweiterleitung kann korrekt eingetragen aussehen und trotzdem nicht funktionieren. Neben der eigentlichen NAT-Regel müssen Routing, Firewall, öffentlicher Anschluss, Rückweg und Zielanwendung geprüft werden. Die zentralen Fragen dieser Seite lauten: > Erreicht das Paket das NAT-System, wird es korrekt übersetzt und kann das Zielsystem über einen gültigen Rückweg antworten? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | NAT-Tabellen und Routerkonfigurationen können interne Adressen, öffentliche Adressen und erreichbare Dienste offenlegen. Ausgaben dürfen nicht ungeprüft veröffentlicht werden.
---
2. NAT-Grundbegriffe unterscheiden | Begriff | Bedeutung | |---|---| | NAT | Allgemeiner Begriff für die Übersetzung von Netzwerkadressen | | Source NAT – SNAT | Verändert die Quelladresse eines Pakets | | Destination NAT – DNAT | Verändert die Zieladresse eines Pakets | | PAT | Verändert zusätzlich Portnummern; mehrere Verbindungen können eine öffentliche Adresse teilen | | Masquerading | Dynamische Form von SNAT, häufig mit der Adresse der ausgehenden Schnittstelle | | Portweiterleitung | Eingehender Port wird an eine interne Adresse und gegebenenfalls einen anderen Port weitergeleitet | | Redirect | Verkehr wird auf das NAT-System selbst beziehungsweise einen lokalen Port umgeleitet | | Hairpin NAT | Interne Clients greifen über die öffentliche Adresse auf einen ebenfalls internen Dienst zu | | Static NAT | Feste Zuordnung zwischen Adressen | | Dynamic NAT | Dynamische Zuordnung aus einem Adresspool | | Double NAT | Zwei aufeinanderfolgende Systeme führen NAT durch | | CGNAT | Provider übersetzt mehrere Kundenanschlüsse hinter gemeinsamen öffentlichen Adressen | | NAT-Tabelle | Regel- oder Zustandsspeicher für Übersetzungen | | Conntrack | Zustandsverfolgung von Netzwerkverbindungen | **Wichtig:** Eine Portweiterleitung ist keine automatische Bestätigung, dass der Verkehr auch durch die Firewall erlaubt wird.
---
3. SNAT, DNAT und PAT am Beispiel **Ausgehende Verbindung mit SNAT beziehungsweise PAT:** ```text Interner Client 192.168.10.25:53144 ↓ Internetrouter ↓ Öffentliche Darstellung 203.0.113.10:62001 ↓ Webserver 198.51.100.20:443 ``` Der Webserver sieht als Quelle normalerweise die öffentliche Adresse des NAT-Systems und nicht unmittelbar die private Clientadresse. **Eingehende Portweiterleitung mit DNAT:** ```text Externer Client 198.51.100.25:54000 ↓ 203.0.113.10:8443 Öffentliche Routeradresse und externer Port ↓ DNAT 192.168.10.50:443 Interner Server und interner Port ``` Die vollständige Zuordnung lautet in diesem Beispiel: ```text TCP 203.0.113.10:8443 → TCP 192.168.10.50:443 ``` Diese Angaben müssen getrennt dokumentiert werden: - externe IP-Adresse, - externer Port, - Transportprotokoll, - interne Zieladresse, - interner Zielport, - erlaubte Quelladressen, - verwendete Schnittstelle, - zugehörige Firewallregel.
---
4. Private, öffentliche und gemeinsam genutzte Adressen erkennen **Private IPv4-Adressbereiche nach RFC 1918:** | Bereich | CIDR | |---|---| | `10.0.0.0` bis `10.255.255.255` | `10.0.0.0/8` | | `172.16.0.0` bis `172.31.255.255` | `172.16.0.0/12` | | `192.168.0.0` bis `192.168.255.255` | `192.168.0.0/16` | **Shared Address Space für Carrier-Grade NAT:** ```text 100.64.0.0/10 ``` Das entspricht: ```text 100.64.0.0 bis 100.127.255.255 ``` **Weitere nicht öffentlich weiterleitbare Beispiele:** | Bereich | Verwendung | |---|---| | `127.0.0.0/8` | IPv4-Loopback | | `169.254.0.0/16` | IPv4-Link-Local | | `224.0.0.0/4` | IPv4-Multicast | | `::1/128` | IPv6-Loopback | | `fe80::/10` | IPv6-Link-Local | | `fc00::/7` | IPv6 Unique Local Addresses | Eine Adresse aus einem privaten oder CGNAT-Bereich auf der WAN-Seite des eigenen Routers ist ein deutlicher Hinweis darauf, dass noch ein vorgeschaltetes NAT-System existiert.
---
5. Häufige Ursachen einer fehlerhaften Portweiterleitung | Ursache | Typische Wirkung | |---|---| | Falsche öffentliche IP-Adresse | Test erreicht nicht den vorgesehenen Router | | Dynamische öffentliche Adresse hat sich geändert | Alter DNS-Eintrag oder alte Dokumentation zeigt auf falsches Ziel | | CGNAT beim Provider | Eingehende Verbindungen erreichen den Kundenrouter nicht direkt | | Double NAT | Weiterleitung existiert nur auf einem von zwei Routern | | Falsches Transportprotokoll | TCP wurde weitergeleitet, Dienst benötigt aber UDP oder umgekehrt | | Falscher externer Port | Client spricht einen anderen Port an | | Falscher interner Port | Weiterleitung endet nicht am Listener der Anwendung | | Falsche interne Zieladresse | Serveradresse wurde geändert oder per DHCP neu vergeben | | Dienst lauscht nur auf Loopback | NAT erreicht den Server, aber nicht den Dienst | | Dienst läuft nicht | Zielport ist geschlossen | | Host-Firewall blockiert | Paket erreicht das Zielsystem, wird dort aber verworfen | | Router-Firewall blockiert | DNAT-Regel allein reicht nicht aus | | Fehlender Rückweg | Antwort nimmt einen anderen oder ungültigen Weg | | Hairpin NAT fehlt | Interner Test über öffentliche Adresse schlägt fehl, externer Zugriff kann trotzdem funktionieren | | Quelladressbeschränkung | Nur bestimmte externe Netze dürfen zugreifen | | Falsche Schnittstelle | Regel gilt nicht für die tatsächliche WAN-Schnittstelle | | IPv4 und IPv6 verwechselt | IPv4-Portweiterleitung beeinflusst eine direkte IPv6-Verbindung nicht | | Mehrfach belegter externer Port | Regelkonflikt oder falsches Ziel | | VPN verändert den Pfad | Anfrage oder Antwort läuft über einen Tunnel | | Containerport nicht veröffentlicht | NAT endet am Host, aber nicht am Container |
---
6. Portweiterleitung vollständig dokumentieren Eine Beschreibung wie „Port 443 ist freigegeben“ ist nicht ausreichend. **Vollständige Beschreibung:** ```text Bezeichnung: Externer Webzugriff Adressfamilie: IPv4 WAN-Schnittstelle: WAN Quelladresse: beliebig oder definierter Bereich Öffentliche IP: 203.0.113.10 Transport: TCP Externer Port: 8443 Internes Ziel: 192.168.10.50 Interner Port: 443 Firewallaktion: Erlauben Protokollierung: Aktiviert Zeitplan: Dauerhaft ``` Zusätzlich sollte dokumentiert werden: - Hersteller und Modell des NAT-Systems, - Firmware- oder Betriebssystemversion, - zuständige Konfigurationsoberfläche, - Zeitpunkt der letzten Änderung, - genehmigender Verantwortlicher, - zugehörige DNS-Namen, - Rückfallplan, - Testergebnis von intern und extern.
---
7. Zuerst den internen Zieldienst prüfen Bevor NAT untersucht wird, muss der Dienst ohne Portweiterleitung direkt im internen Netz funktionieren. **Listener auf dem Zielsystem prüfen:** | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | TCP-Port 443 | `[RO] Get-NetTCPConnection -State Listen -LocalPort 443` | `[RO] ss -ltn 'sport = :443'` | `[RO] lsof -nP -iTCP:443 -sTCP:LISTEN` | **Dienst direkt über seine interne Adresse testen:** Windows: ```powershell [TEST] Test-NetConnection 192.168.10.50 -Port 443 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 192.168.10.50 443 ``` **Anwendungstest:** ```bash [TEST] curl -v https://192.168.10.50/ ``` Bei HTTPS kann ein Zertifikatsfehler auftreten, wenn das Zertifikat für einen Hostnamen und nicht für die IP-Adresse ausgestellt wurde. Für eine korrekte Anwendungsprüfung sollte möglichst der vorgesehene Hostname verwendet werden. **Entscheidung:** ```text Interner Zugriff funktioniert nicht ↓ Zuerst Dienst, Bind-Adresse, lokale Firewall und internes Routing prüfen ↓ NAT noch nicht als Hauptursache behandeln ```
---
8. Statische interne Zieladresse sicherstellen Eine Portweiterleitung verweist normalerweise auf eine konkrete interne IP-Adresse. Ändert sich diese Adresse durch DHCP, zeigt die Regel anschließend möglicherweise auf das falsche System. **Windows:** ```powershell [RO] Get-NetIPConfiguration ``` ```powershell [RO] Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength, PrefixOrigin ``` **Linux:** ```bash [RO] ip -br address ``` ```bash [RO] ip address show ``` **macOS:** ```bash [RO] ifconfig ``` ```bash [RO] networksetup -listallhardwareports ``` Zu prüfen sind: - Stimmt die aktuelle Serveradresse mit dem NAT-Ziel überein? - Ist die Adresse statisch konfiguriert? - Existiert eine DHCP-Reservierung? - Liegt eine doppelte IP-Adresse vor? - Wurde der Server in ein anderes VLAN verschoben? - Stimmt das Präfix beziehungsweise die Subnetzmaske? - Ist das Standardgateway korrekt? Eine statische Adresse außerhalb des verwalteten Adressplans kann ebenfalls zu Konflikten führen. Bevorzugt wird eine dokumentierte statische Zuweisung oder DHCP-Reservierung entsprechend der Unternehmensvorgaben.
---
9. Öffentliche Adresse des Anschlusses bestimmen Zuerst wird die WAN-Adresse direkt in der Verwaltungsoberfläche des Routers oder der Firewall abgelesen. Anschließend kann sie mit der von einem externen Dienst erkannten Adresse verglichen werden. **Lokale Adressen anzeigen:** Windows: ```powershell [RO] Get-NetIPAddress | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength ``` Linux: ```bash [RO] ip -br address ``` macOS: ```bash [RO] ifconfig ``` Lokale Befehle zeigen auf einem Client hinter NAT normalerweise nicht die öffentliche IPv4-Adresse des Internetanschlusses. **Öffentlich sichtbare IPv4-Adresse über einen externen Dienst abfragen:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` **Öffentlich sichtbare IPv6-Adresse:** ```bash [TEST][SENS] curl -6 https://api64.ipify.org ``` Dabei wird die öffentliche Quelladresse an einen externen Dienst übertragen. Die Nutzung muss durch die betrieblichen Richtlinien erlaubt sein. **Auswertung:** | Vergleich | Mögliche Bedeutung | |---|---| | Router-WAN-Adresse entspricht externer IPv4-Adresse | Router besitzt wahrscheinlich direkt diese öffentliche IPv4-Adresse | | Router-WAN-Adresse ist privat | Vorgeschalteter Router oder Provider-NAT vorhanden | | Router-WAN-Adresse liegt in `100.64.0.0/10` | CGNAT ist wahrscheinlich | | Router-WAN-Adresse und erkannte öffentliche Adresse unterscheiden sich | Weiteres NAT-System oder Proxy vorhanden | | Keine öffentliche IPv4-Adresse vorhanden | Anschluss kann IPv6, DS-Lite oder andere Providertechnik verwenden | Die genaue Anschlussart muss anhand der Router- und Providerinformationen bestätigt werden.
---
10. CGNAT, DS-Lite und Double NAT erkennen **Double NAT:** ```text Internet ↓ Router oder Modemrouter 1 ↓ privates Netz Router 2 ↓ privates Netz Interner Server ``` Für eine klassische eingehende IPv4-Verbindung kann eine Weiterleitung auf beiden NAT-Systemen erforderlich sein. **Carrier-Grade NAT:** ```text Internet ↓ Öffentliche Provideradresse ↓ Provider-NAT ↓ Kundenrouter mit Adresse aus 100.64.0.0/10 ``` Eine Portweiterleitung auf dem Kundenrouter kann das vorgeschaltete Provider-NAT nicht automatisch konfigurieren. **DS-Lite:** Bei DS-Lite wird IPv4-Verkehr über eine Providerinfrastruktur transportiert und typischerweise auf Providerseite übersetzt. Eine frei erreichbare öffentliche IPv4-Adresse steht dem eigenen Router dabei häufig nicht direkt zur Verfügung. **Prüfschritte:** 1. WAN-Adresse des Routers ablesen. 2. Extern erkannte IPv4-Adresse abfragen. 3. Adressen miteinander vergleichen. 4. Prüfen, ob die WAN-Adresse privat oder aus `100.64.0.0/10` ist. 5. Anschlussinformationen des Providers kontrollieren. 6. Prüfen, ob eine öffentliche IPv4-Adresse gebucht oder verfügbar ist. 7. Alternativen wie IPv6, VPN, Reverse Tunnel oder Providerfreigabe nur nach Sicherheitsprüfung planen.
---
11. Portweiterleitung wirklich von außen testen Ein Test aus demselben LAN über die öffentliche Adresse ist kein zuverlässiger Ersatz für einen externen Test. Er hängt von der Unterstützung für Hairpin NAT ab. Geeignete externe Testquellen sind beispielsweise: - freigegebener Administrationsanschluss an einem anderen Standort, - Mobilfunkverbindung ohne Verbindung zum Firmen-WLAN, - freigegebener externer Monitoring-Server, - autorisiertes System in einem anderen Netz, - definierter Prüfserver in einer Cloudumgebung. **Externer TCP-Test unter Windows:** ```powershell [TEST] Test-NetConnection 203.0.113.10 -Port 8443 -InformationLevel Detailed ``` **Externer TCP-Test unter Linux oder macOS:** ```bash [TEST] nc -vz -w 5 203.0.113.10 8443 ``` **Anwendungstest mit Hostname:** ```bash [TEST] curl -v https://service.example.net:8443/ ``` **Gezielter Nmap-Test:** ```bash [TEST] nmap -sT -p 8443 203.0.113.10 ``` Tests dürfen nur gegen die eigene beziehungsweise ausdrücklich freigegebene Infrastruktur ausgeführt werden.
---
12. Hairpin NAT richtig beurteilen Hairpin NAT wird benötigt, wenn ein interner Client über die öffentliche Adresse oder den öffentlichen DNS-Namen auf einen internen Server zugreift. ```text Interner Client ↓ öffentliche Adresse des eigenen Routers ↓ Portweiterleitung ↓ interner Server im gleichen Standort ``` **Typisches Fehlerbild:** ```text Zugriff über Mobilfunk funktioniert Zugriff aus dem internen LAN über öffentliche Adresse funktioniert nicht Direkter Zugriff über interne Adresse funktioniert ``` Das deutet auf fehlendes oder fehlerhaftes Hairpin NAT hin. Es beweist nicht, dass die allgemeine externe Portweiterleitung defekt ist. **Mögliche Lösungen abhängig von der Infrastruktur:** - Hairpin NAT korrekt konfigurieren, - internes und externes DNS unterschiedlich beantworten, - internen Clients die interne Serveradresse liefern, - Reverse Proxy mit passender interner Erreichbarkeit verwenden. Änderungen an DNS oder NAT müssen zum vorgesehenen Netzdesign passen.
---
13. Split DNS als Alternative zu Hairpin NAT erkennen Bei Split DNS kann derselbe Hostname intern und extern unterschiedliche Antworten liefern. **Extern:** ```text service.example.net → 203.0.113.10 ``` **Intern:** ```text service.example.net → 192.168.10.50 ``` **DNS-Antwort prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net -Type A ``` Linux und macOS: ```bash [TEST] dig service.example.net A ``` **Bestimmten internen DNS-Server abfragen:** ```bash [TEST] dig @192.168.10.53 service.example.net A ``` **Bestimmten externen DNS-Server abfragen:** ```bash [TEST] dig @1.1.1.1 service.example.net A ``` Die Verwendung öffentlicher DNS-Server muss durch die Netz- und Datenschutzrichtlinien erlaubt sein. Unternehmensinterne Namen dürfen nicht unnötig an externe Resolver übermittelt werden. Zu prüfen sind: - Welche Antwort erhält ein interner Client? - Welche Antwort erhält ein externer Client? - Sind TTL und Cache berücksichtigt? - Verweist der interne Datensatz auf den richtigen Server? - Passt das TLS-Zertifikat weiterhin zum Hostnamen?
---
14. Windows-NAT-Konfiguration prüfen Die folgenden Befehle betreffen Windows-NAT-Konfigurationen, die über das NetNat-Modul verwaltet werden, beispielsweise in bestimmten Hyper-V- oder Windows-Container-Szenarien. Sie zeigen nicht automatisch die NAT-Regeln eines externen Routers an. **Vorhandene Windows-NAT-Objekte anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNat ``` **Ausführliche Anzeige:** ```powershell [RO][PRIV][SENS] Get-NetNat | Format-List * ``` **Statische Zuordnungen anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNatStaticMapping ``` **NAT-Sitzungen anzeigen:** ```powershell [RO][PRIV][SENS] Get-NetNatSession ``` **Interne Hyper-V-Switches prüfen, sofern Hyper-V eingesetzt wird:** ```powershell [RO][PRIV] Get-VMSwitch ``` **IP-Adressen der virtuellen Schnittstellen:** ```powershell [RO] Get-NetIPAddress | Where-Object InterfaceAlias -Like "vEthernet*" | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength ``` Zu prüfen sind: - Existiert das erwartete NAT-Objekt? - Stimmt das interne Adresspräfix? - Existiert die erwartete statische Portzuordnung? - Stimmen externes und internes Protokoll? - Stimmen externe und interne Ports? - Stimmt die interne Zieladresse? - Existiert eine passende Firewallregel? - Besteht ein Konflikt mit Container- oder Virtualisierungssoftware? **Keine NAT-Objekte löschen oder neu erstellen, solange der Sollzustand und die Auswirkungen nicht vollständig geklärt sind.**
---
15. Linux-NAT mit nftables prüfen **Gesamtes nftables-Regelwerk anzeigen:** ```bash [RO][PRIV][SENS] sudo nft list ruleset ``` **Tabellen anzeigen:** ```bash [RO][PRIV] sudo nft list tables ``` **Regelwerk einschließlich Handles anzeigen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Bei NAT-Regeln sind insbesondere folgende Hooks relevant: | Hook | Typische Verwendung | |---|---| | `prerouting` | DNAT eingehender Pakete vor der Routingentscheidung | | `output` | DNAT lokal erzeugter Pakete | | `postrouting` | SNAT oder Masquerading nach der Routingentscheidung | | `input` | Bestimmte SNAT-Sonderfälle für lokal zugestellte Pakete | **Typische nftables-Ausdrücke erkennen:** ```text dnat to 192.168.10.50:443 snat to 203.0.113.10 masquerade redirect to :8080 ``` **Regeln mit Zählern untersuchen:** ```bash [RO][PRIV][SENS] sudo nft -a list ruleset ``` Zu prüfen ist, ob die Paket- und Bytezähler der erwarteten NAT- und Filterregeln während eines einzelnen Tests steigen. **Wichtig:** NAT-Anweisungen sind an NAT-Chains und die dafür vorgesehenen Hooks gebunden. Eine sichtbare Regel beweist nicht, dass das Paket den dazugehörigen Pfad tatsächlich durchläuft.
---
16. Linux-NAT mit iptables prüfen **NAT-Tabelle mit Zählern und Zeilennummern:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers ``` **NAT-Regeln in Befehlsschreibweise:** ```bash [RO][PRIV][SENS] sudo iptables -t nat -S ``` **IPv6-NAT-Regeln, sofern in der Umgebung verwendet:** ```bash [RO][PRIV][SENS] sudo ip6tables -t nat -L -n -v --line-numbers ``` **Filterregeln für weitergeleiteten Verkehr:** ```bash [RO][PRIV][SENS] sudo iptables -L FORWARD -n -v --line-numbers ``` **Typische Ziele:** | Ziel | Bedeutung | |---|---| | `DNAT` | Zieladresse oder Zielport verändern | | `SNAT` | Quelladresse oder Quellport verändern | | `MASQUERADE` | Dynamische Quelladressübersetzung | | `REDIRECT` | Verkehr an das lokale System umleiten | | `ACCEPT` | Verkehr zulassen | | `DROP` | Verkehr ohne Antwort verwerfen | | `REJECT` | Verkehr aktiv ablehnen | Eine passende DNAT-Regel allein reicht nicht aus. Weitergeleiteter Verkehr muss zusätzlich durch die Filterregeln zugelassen und korrekt geroutet werden.
---
17. IP-Forwarding prüfen Ein Linux-System, das Pakete zwischen Schnittstellen weiterleiten soll, benötigt eine passende Forwarding-Konfiguration. **IPv4-Forwarding:** ```bash [RO] sysctl net.ipv4.ip_forward ``` Alternative Anzeige: ```bash [RO] cat /proc/sys/net/ipv4/ip_forward ``` Typische Werte: | Wert | Bedeutung | |---:|---| | `0` | IPv4-Weiterleitung deaktiviert | | `1` | IPv4-Weiterleitung aktiviert | **IPv6-Forwarding:** ```bash [RO] sysctl net.ipv6.conf.all.forwarding ``` Die Aktivierung von Forwarding ist eine Konfigurationsänderung und darf nicht automatisch vorgenommen werden. Zuerst muss geklärt werden, ob das System laut Netzdesign als Router arbeiten soll. **Zusätzlich prüfen:** ```bash [RO] ip route show [RO] ip -6 route show ``` NAT ersetzt keine gültige Routingkonfiguration.
---
18. macOS-NAT- und pf-Regeln prüfen macOS kann NAT und Weiterleitung über den Packet Filter `pf` beziehungsweise durch Anwendungen und Systemdienste umsetzen. **pf-Status:** ```bash [RO][PRIV] sudo pfctl -s info ``` **NAT-Regeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s nat ``` **Filterregeln anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s rules ``` **Zustände anzeigen:** ```bash [RO][PRIV][SENS] sudo pfctl -s states ``` **Regeln mit zusätzlichen Informationen und Zählern:** ```bash [RO][PRIV][SENS] sudo pfctl -vvs nat ``` ```bash [RO][PRIV][SENS] sudo pfctl -vvs rules ``` **Routingtabelle prüfen:** ```bash [RO] netstat -rn ``` **IPv4-Forwardingstatus:** ```bash [RO] sysctl net.inet.ip.forwarding ``` Zu beachten ist, dass VPN-, Virtualisierungs-, Container- und Sicherheitssoftware eigene `pf`-Anchors oder Regeln verwenden kann. Das Regelwerk darf nicht ohne Kenntnis dieser Abhängigkeiten neu geladen oder geleert werden.
---
19. Connection Tracking und NAT-Zustände prüfen NAT ist normalerweise zustandsorientiert. Das System merkt sich, wie eine Verbindung übersetzt wurde, damit Antwortpakete korrekt zurückübersetzt werden können. **Linux – prüfen, ob conntrack vorhanden ist:** ```bash [RO] command -v conntrack ``` **Alle Verbindungseinträge anzeigen:** ```bash [RO][PRIV][SENS] sudo conntrack -L ``` **TCP-Verbindungen zu einem Zielport filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p tcp --dport 443 ``` **UDP-Verbindungen zu einem Zielport filtern:** ```bash [RO][PRIV][SENS] sudo conntrack -L -p udp --dport 53 ``` Je nach Übersetzungsrichtung können in einem Eintrag ursprüngliche und übersetzte Adressen erscheinen. Zu kontrollieren sind: - Wird beim Test ein Zustandseintrag erzeugt? - Stimmen ursprüngliches und übersetztes Ziel? - Ist Antwortverkehr sichtbar? - Läuft der Eintrag frühzeitig ab? - Gibt es sehr viele Verbindungseinträge? - Ist nur eine Richtung sichtbar? Zustandstabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen unterbrochen werden.
---
20. Rückweg und asymmetrisches Routing prüfen Nach DNAT erreicht ein Paket möglicherweise den internen Server. Der Server muss jedoch über einen gültigen Weg antworten. **Sollzustand:** ```text Externer Client ↓ NAT-Gateway ↓ Interner Server ↓ NAT-Gateway ↓ Externer Client ``` **Problematischer asymmetrischer Rückweg:** ```text Anfrage: Client → NAT-Gateway A → Server Antwort: Server → Gateway B → Client ``` Das NAT-Gateway A sieht die Antwort nicht und kann die notwendige Rückübersetzung nicht durchführen. **Standardgateway des Zielservers prüfen:** Windows: ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Format-Table InterfaceAlias, NextHop, RouteMetric ``` Linux: ```bash [RO] ip route show default ``` macOS: ```bash [RO] route -n get default ``` **Route zu einer externen Testadresse prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 198.51.100.25 ``` Linux: ```bash [RO] ip route get 198.51.100.25 ``` macOS: ```bash [RO] route -n get 198.51.100.25 ``` Die Beispieladresse muss durch die tatsächliche Adresse des autorisierten Testsystems ersetzt werden.
---
21. Paketmitschnitt vor und nach der Übersetzung erstellen Idealerweise wird auf beiden Seiten des NAT-Systems gleichzeitig mitgeschnitten. ```text WAN-Mitschnitt: Ziel 203.0.113.10:8443 LAN-Mitschnitt: Ziel 192.168.10.50:443 ``` **Linux – WAN-Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i WAN_INTERFACE -nn \ 'tcp port 8443' \ -w nat-wan.pcap ``` **Linux – LAN-Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i LAN_INTERFACE -nn \ 'host 192.168.10.50 and tcp port 443' \ -w nat-lan.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'tcp port 8443 or tcp port 443' \ -w nat-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Mitschnitt auf einer bestimmten Schnittstelle:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "tcp port 8443 or tcp port 443" ` -w nat-test.pcapng ``` `WAN_INTERFACE`, `LAN_INTERFACE`, `INTERFACE` und die Dumpcap-Schnittstellennummer müssen vorher ermittelt werden.
---
22. Paketmuster bei NAT-Fehlern interpretieren | WAN-Seite | LAN-Seite | Mögliche Interpretation | |---|---|---| | Kein Paket sichtbar | Kein Paket sichtbar | Falsche öffentliche Adresse, CGNAT, vorgeschalteter Filter oder Clientproblem | | SYN sichtbar | Kein weitergeleitetes SYN | DNAT-Regel, Firewall oder Routing auf dem NAT-System prüfen | | SYN an externen Port sichtbar | SYN an richtiges internes Ziel sichtbar | Übersetzung funktioniert grundsätzlich | | SYN erreicht internen Server | Kein SYN-ACK vom Server | Dienst, Bind-Adresse, Host-Firewall oder Serverrouting prüfen | | SYN-ACK verlässt Server | Keine Antwort auf WAN-Seite | NAT-Zustand, Forwarding, Filter oder Rückweg prüfen | | Vollständiger Handshake auf beiden Seiten | Anwendung schlägt dennoch fehl | Fehler wahrscheinlich oberhalb der Transportschicht | | RST kommt vom internen Server | Ziel erreichbar, aber Port wird nicht angenommen | | ICMP-Fehler sichtbar | Abhängig vom Fehlercode | Routing-, Filter- oder Erreichbarkeitsproblem weiter untersuchen | **Wichtig:** Ein Mitschnitt auf nur einer Schnittstelle zeigt nicht den gesamten Übersetzungsvorgang.
---
23. Docker-Portweiterleitungen prüfen Docker verwendet bei Bridge-Netzwerken Port Publishing, NAT beziehungsweise Firewallregeln, um Hostports an Containerports weiterzuleiten. **Container und Portzuordnungen anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Portzuordnung eines bestimmten Containers:** ```bash [RO] docker port CONTAINERNAME ``` **Containerkonfiguration prüfen:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` **Docker-Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` **Beispiele:** ```text 0.0.0.0:8080->80/tcp ``` Der Hostport `8080/TCP` wurde an den Containerport `80/TCP` veröffentlicht und ist an den passenden IPv4-Adressen des Hosts gebunden. ```text 127.0.0.1:8080->80/tcp ``` Der Hostport ist an die Loopback-Adresse gebunden und normalerweise nur vom Docker-Host erreichbar. ```text 8080->80/tcp ``` Die genaue Bindung muss über die vollständige Docker-Ausgabe beziehungsweise `docker inspect` geprüft werden. **Wichtig:** ```dockerfile EXPOSE 80 ``` `EXPOSE` dokumentiert den vorgesehenen Containerport, veröffentlicht ihn aber nicht automatisch auf dem Host.
---
24. Docker-NAT systematisch testen **Ebene 1 – Anwendung im Container** ```bash [RO] docker ps ``` ```bash [RO][SENS] docker logs --tail 100 CONTAINERNAME ``` **Ebene 2 – Portzuordnung** ```bash [RO] docker port CONTAINERNAME ``` **Ebene 3 – Zugriff vom Docker-Host** ```bash [TEST] curl -v http://127.0.0.1:8080/ ``` **Ebene 4 – Zugriff über die LAN-Adresse des Hosts** ```bash [TEST] curl -v http://HOST_LAN_IP:8080/ ``` **Ebene 5 – Zugriff aus einem anderen LAN-System** ```bash [TEST] nc -vz -w 5 HOST_LAN_IP 8080 ``` **Ebene 6 – Zugriff über eine externe Routerweiterleitung** ```bash [TEST] nc -vz -w 5 OEFFENTLICHE_IP EXTERNER_PORT ``` Der letzte Test muss wirklich aus einem externen Netz erfolgen, sofern Hairpin NAT nicht ausdrücklich mitgeprüft werden soll.
---
25. IPv4-NAT und IPv6-Zugriff nicht verwechseln Bei IPv4 wird NAT häufig eingesetzt, weil private Adressen nicht direkt aus dem Internet erreichbar sind. Bei IPv6 besitzt ein System häufig eine global routbare Adresse. Eine klassische IPv4-Portweiterleitung ist dann nicht automatisch beteiligt. Der Zugriff wird stattdessen insbesondere durch folgende Komponenten bestimmt: - IPv6-Adressierung, - IPv6-Routing, - IPv6-Firewall, - DNS-AAAA-Eintrag, - Dienstbindung an IPv6, - Provider- und Routerrichtlinien. **DNS-Einträge prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net -Type A [TEST] Resolve-DnsName service.example.net -Type AAAA ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **HTTPS getrennt testen:** ```bash [TEST] curl -4 -v https://service.example.net/ [TEST] curl -6 -v https://service.example.net/ ``` **Typischer Fehler:** ```text IPv4-Portweiterleitung ist korrekt ↓ Client bevorzugt jedoch den vorhandenen AAAA-Eintrag ↓ Verbindung erfolgt über IPv6 ↓ IPv6-Firewall oder IPv6-Dienstbindung ist fehlerhaft ```
---
26. Dynamisches DNS prüfen Bei wechselnden öffentlichen Adressen wird häufig Dynamic DNS verwendet. Zu prüfen sind: - Welche öffentliche Adresse besitzt der Anschluss aktuell? - Welche Adresse liefert der DNS-Eintrag? - Wann wurde der Eintrag zuletzt aktualisiert? - Wie hoch ist die TTL? - Funktioniert der Update-Client? - Wird IPv4, IPv6 oder beides aktualisiert? - Existiert ein alter A- oder AAAA-Eintrag? **DNS-Eintrag prüfen:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **Autoritativen Nameserver ermitteln:** ```bash [TEST] dig service.example.net NS ``` **Antwort eines bestimmten autoritativen Servers abfragen:** ```bash [TEST] dig @AUTORITATIVER_DNS_SERVER service.example.net A ``` Ein veralteter lokaler Cache kann sich von der bereits aktualisierten autoritativen Antwort unterscheiden.
---
27. NAT-Loopback, Proxy und Reverse Proxy auseinanderhalten Ein öffentlich erreichbarer Dienst kann über mehrere Weiterleitungsstufen verfügen: ```text Internet ↓ Router-DNAT ↓ Reverse Proxy ↓ Container-Port ↓ Anwendung ``` Jede Ebene benötigt eine eigene Prüfung. | Ebene | Prüffrage | |---|---| | Router-DNAT | Wird der externe Port an das richtige interne System weitergeleitet? | | Host-Firewall | Darf der Verkehr den Reverse Proxy erreichen? | | Reverse Proxy | Existiert die richtige Host- und Zielkonfiguration? | | Container Publishing | Ist der Hostport an den Containerport gebunden? | | Anwendung | Lauscht die Anwendung und verarbeitet sie die Anfrage? | | DNS | Zeigt der Hostname auf die erwartete öffentliche Adresse? | | TLS | Stimmt Zertifikat, Hostname und SNI? | Ein funktionierender Router-DNAT beweist nicht, dass der Reverse Proxy oder das Backend funktioniert.
---
28. Keine unkontrollierte Exposition interner Dienste Eine Portweiterleitung macht einen Dienst potenziell aus externen Netzen erreichbar. Vor einer Freigabe müssen mindestens geprüft werden: - Ist die externe Erreichbarkeit wirklich erforderlich? - Unterstützt der Dienst eine sichere Authentifizierung? - Wird eine verschlüsselte Verbindung verwendet? - Ist die Software aktuell? - Ist der Zugriff auf erforderliche Quelladressen beschränkbar? - Kann stattdessen ein VPN oder Zero-Trust-Zugang verwendet werden? - Existiert eine Protokollierung und Überwachung? - Gibt es Schutz vor Brute-Force-Angriffen? - Ist der Dienst für eine Veröffentlichung vorgesehen? - Enthält der Dienst eine administrative Oberfläche? - Ist ein Reverse Proxy mit zusätzlicher Zugriffskontrolle sinnvoll? - Existiert ein dokumentierter Rückbauplan? Besonders Datenbanken, interne Verwaltungsoberflächen, Dateifreigaben und unverschlüsselte Protokolle sollten nicht unkontrolliert direkt veröffentlicht werden. **Keine automatische oder pauschale Portfreigabe über UPnP voraussetzen.** Dynamisch erstellte Weiterleitungen müssen ebenso geprüft und dokumentiert werden.
---
29. Änderungen nur kontrolliert durchführen Nicht vorschnell: - NAT-Tabellen leeren, - Conntrack-Zustände löschen, - Router auf Werkseinstellungen zurücksetzen, - Firewall vollständig deaktivieren, - alle Quelladressen freigeben, - DMZ- beziehungsweise Exposed-Host-Funktionen aktivieren, - mehrere Weiterleitungen für denselben Port erstellen, - interne Server direkt und ungeschützt veröffentlichen, - IPv6-Firewall deaktivieren, - Docker-Regeln manuell überschreiben. **Sicherer Änderungsablauf:** 1. Istzustand exportieren oder dokumentieren. 2. Gewünschten Datenfluss vollständig definieren. 3. Bestehende Regeln und Abhängigkeiten prüfen. 4. Änderung genehmigen lassen. 5. Eng begrenzte Regel erstellen. 6. Protokollierung aktivieren, soweit vorgesehen. 7. Von intern und extern testen. 8. Sicherheitsprüfung durchführen. 9. Ergebnis dokumentieren. 10. Bei Misserfolg den vorherigen Zustand wiederherstellen.
---
30. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Datenfluss dokumentieren | Welche externe Adresse und welcher Port sollen wohin übersetzt werden? | | 2 | Zielanwendung prüfen | Läuft der interne Dienst? | | 3 | Listener prüfen | Lauscht der Dienst auf Adresse, Port und Protokoll? | | 4 | Internen Zugriff testen | Funktioniert der Dienst ohne NAT? | | 5 | Interne Zieladresse prüfen | Stimmt die NAT-Regel noch mit der Serveradresse überein? | | 6 | WAN-Adresse prüfen | Besitzt der Router die erwartete öffentliche Adresse? | | 7 | CGNAT oder Double NAT prüfen | Existiert ein vorgeschaltetes NAT-System? | | 8 | DNS prüfen | Zeigt der Hostname auf die aktuelle öffentliche Adresse? | | 9 | NAT-Regel prüfen | Stimmen Protokoll, externe und interne Ports sowie Zieladresse? | | 10 | Firewallregeln prüfen | Wird der übersetzte Verkehr zugelassen? | | 11 | Forwarding prüfen | Darf das System Pakete zwischen Schnittstellen weiterleiten? | | 12 | Rückweg prüfen | Antwortet der Server über das NAT-Gateway? | | 13 | Extern testen | Erreicht ein Client außerhalb des LANs den Port? | | 14 | Hairpin NAT getrennt testen | Betrifft der Fehler nur interne Clients? | | 15 | Paketmitschnitt auf beiden Seiten | Wird das Paket korrekt übersetzt? | | 16 | NAT- und Regelzähler prüfen | Trifft der Test die erwartete Regel? | | 17 | Container oder Proxy prüfen | Existieren weitere Weiterleitungsstufen? | | 18 | Änderung minimal planen | Welche kleinste genehmigte Korrektur behebt die Ursache? | | 19 | Nachprüfung | Funktioniert der Dienst intern und extern? | | 20 | Dokumentation | Sind Regel, Risiko und Rückfallplan festgehalten? |
---
31. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Lokale IP-Adressen | `[RO] Get-NetIPAddress` | `[RO] ip -br address` | `[RO] ifconfig` | | Standardgateway | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zu einem Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | Internen TCP-Port testen | `[TEST] Test-NetConnection IP -Port PORT` | `[TEST] nc -vz -w 5 IP PORT` | `[TEST] nc -vz -w 5 IP PORT` | | Windows-NAT anzeigen | `[RO][PRIV][SENS] Get-NetNat` | Nicht zutreffend | Nicht zutreffend | | Statische Windows-NAT-Zuordnungen | `[RO][PRIV][SENS] Get-NetNatStaticMapping` | Nicht zutreffend | Nicht zutreffend | | nftables-Regeln | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | iptables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers` | Nicht zutreffend | | pf-NAT | Nicht zutreffend | Nicht standardmäßig allgemein vorhanden | `[RO][PRIV][SENS] sudo pfctl -vvs nat` | | IPv4-Forwarding | Abhängig von Windows-Rolle | `[RO] sysctl net.ipv4.ip_forward` | `[RO] sysctl net.inet.ip.forwarding` | | Conntrack | Abhängig von Windows-NAT | `[RO][PRIV][SENS] sudo conntrack -L` | pf: `[RO][PRIV][SENS] sudo pfctl -s states` | | Docker-Portzuordnung | `[RO] docker port CONTAINER` | `[RO] docker port CONTAINER` | `[RO] docker port CONTAINER` | | Öffentliche IPv4 abfragen | `[TEST][SENS] Invoke-RestMethod https://api.ipify.org` | `[TEST][SENS] curl -4 https://api.ipify.org` | `[TEST][SENS] curl -4 https://api.ipify.org` | | DNS-A- und AAAA-Einträge | `[TEST] Resolve-DnsName HOST` | `[TEST] dig HOST A` und `[TEST] dig HOST AAAA` | `[TEST] dig HOST A` und `[TEST] dig HOST AAAA` | | Externen TCP-Port testen | `[TEST] Test-NetConnection PUBLIC_IP -Port PORT` | `[TEST] nc -vz -w 5 PUBLIC_IP PORT` | `[TEST] nc -vz -w 5 PUBLIC_IP PORT` | `IP`, `PORT`, `HOST`, `PUBLIC_IP` und `CONTAINER` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
32. Dokumentationsvorlage für NAT-Fehler ```text Störung: Zeitpunkt: Zeitzone: Betroffener Dienst: Betroffener Standort: Öffentlicher DNS-Name: Aufgelöste IPv4-Adresse: Aufgelöste IPv6-Adresse: Router-WAN-Adresse: Extern erkannte IPv4-Adresse: CGNAT oder Double NAT vermutet: Ja / Nein Anschlussart: Transportprotokoll: Externe IP-Adresse: Externer Port: Interne Zieladresse: Interner Zielport: WAN-Schnittstelle: LAN-Schnittstelle: Erlaubte Quelladressen: Interner Server: Aktuelle Server-IP: Server-Standardgateway: Listener vorhanden: Bind-Adresse: Host-Firewall geprüft: Interner Funktionstest: NAT-System: NAT-Regelname: NAT-Regel aktiviert: DNAT-Regel: SNAT- oder Masquerading-Regel: Forwarding aktiviert: Filterregel: Regelzähler vor Test: Regelzähler nach Test: Test aus internem Netz: Test über öffentliche Adresse aus internem Netz: Test aus externem Netz: Hairpin NAT erforderlich: Paket auf WAN-Seite sichtbar: Paket auf LAN-Seite sichtbar: Antwort des Servers sichtbar: Antwort auf WAN-Seite sichtbar: Container beteiligt: Reverse Proxy beteiligt: VPN beteiligt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
33. Kontrollfragen nach der Diagnose - Funktioniert der Dienst direkt über seine interne Adresse? - Lauscht der Dienst auf dem richtigen Port und Transportprotokoll? - Stimmt die aktuelle interne Serveradresse mit der NAT-Regel überein? - Ist die Serveradresse dauerhaft reserviert oder statisch verwaltet? - Stimmt die Router-WAN-Adresse mit der extern erkannten Adresse überein? - Liegt die WAN-Adresse in einem privaten oder CGNAT-Adressbereich? - Existiert ein zweiter vorgeschalteter Router? - Zeigt DNS auf die aktuelle öffentliche Adresse? - Wurden A- und AAAA-Einträge getrennt geprüft? - Stimmen externer und interner Port? - Wurde TCP nicht mit UDP verwechselt? - Gilt die NAT-Regel für die richtige Schnittstelle? - Existiert eine passende Firewallregel? - Ist IP-Forwarding entsprechend dem Sollzustand aktiviert? - Verwendet der Server das NAT-System als Rückweg? - Wurde wirklich aus einem externen Netz getestet? - Wurde Hairpin NAT getrennt von der externen Erreichbarkeit bewertet? - Wurden Paketmitschnitte vor und nach der Übersetzung verglichen? - Steigen die Zähler der erwarteten NAT- und Firewallregel? - Existiert eine weitere Ebene wie Container, Proxy oder VPN? - Wurde die öffentliche Freigabe auf das erforderliche Minimum begrenzt? - Wurde der Zustand nach der Änderung erneut intern und extern geprüft?
---
34. Quellen und weiterführende Dokumentation - Microsoft Learn – NAT-Netzwerk mit Windows und Hyper-V einrichten: https://learn.microsoft.com/windows-server/virtualization/hyper-v/setup-nat-network - Microsoft Learn – Get-NetNat: https://learn.microsoft.com/powershell/module/netnat/get-netnat - Microsoft Learn – Get-NetNatStaticMapping: https://learn.microsoft.com/powershell/module/netnat/get-netnatstaticmapping - Microsoft Learn – Get-NetNatSession: https://learn.microsoft.com/powershell/module/netnat/get-netnatsession - Netfilter – Network Address Translation mit nftables: https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT) - Netfilter – Offizielle nftables-Dokumentation: https://netfilter.org/projects/nftables/manpage.html - Linux-Handbuch – iptables: https://man7.org/linux/man-pages/man8/iptables.8.html - Linux-Handbuch – conntrack: https://manpages.debian.org/conntrack/conntrack.8.en.html - Docker Docs – Port publishing and mapping: https://docs.docker.com/engine/network/port-publishing/ - Docker Docs – Container networking: https://docs.docker.com/engine/network/ - Docker Docs – Dockerfile `EXPOSE`: https://docs.docker.com/reference/dockerfile/#expose - RFC 1918 – Address Allocation for Private Internets: https://www.rfc-editor.org/rfc/rfc1918.html - RFC 6598 – Shared Address Space für Carrier-Grade NAT: https://www.rfc-editor.org/rfc/rfc6598.html - RFC 6888 – Common Requirements for Carrier-Grade NAT: https://www.rfc-editor.org/rfc/rfc6888.html - RFC 4787 – NAT Behavioral Requirements for UDP: https://www.rfc-editor.org/rfc/rfc4787.html - RFC 5382 – NAT Behavioral Requirements for TCP: https://www.rfc-editor.org/rfc/rfc5382.html
# 3.12 Proxy- und Reverse-Proxy-Fehler analysieren Ein Proxy befindet sich zwischen Client und Zielsystem. Je nach Proxyart verarbeitet, filtert, protokolliert oder vermittelt er Verbindungen. Dadurch kann eine direkte Verbindung funktionieren, während der Zugriff über den Proxy fehlschlägt – oder umgekehrt. Die zentralen Fragen dieser Seite lauten: > Welcher Proxy wird tatsächlich verwendet, wie wurde er ausgewählt und an welcher Stelle zwischen Client, Proxy und Zielsystem scheitert die Verbindung? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | Proxykonfigurationen und ausführliche HTTP-Ausgaben können interne Hostnamen, Benutzernamen, Cookies, Autorisierungsheader und Sitzungstoken enthalten. Sie dürfen nicht ungeprüft dokumentiert oder weitergegeben werden.
---
2. Proxyarten unterscheiden | Proxyart | Position und Aufgabe | |---|---| | Forward Proxy | Vermittelt Verbindungen von Clients zu externen oder internen Zielen | | Explicit Proxy | Client kennt Proxyadresse und Proxyport ausdrücklich | | Transparent Proxy | Verkehr wird ohne ausdrückliche Proxykonfiguration umgeleitet | | Reverse Proxy | Nimmt Anfragen für Serverdienste entgegen und leitet sie an Backends weiter | | SOCKS-Proxy | Vermittelt TCP-Verbindungen und abhängig von Version und Werkzeug weitere Funktionen | | Caching Proxy | Speichert Antworten zwischen, um Zugriffe zu beschleunigen oder Datenverkehr zu reduzieren | | Filtering Proxy | Filtert Ziele, Kategorien, Inhalte oder Dateitypen | | TLS-Inspection-Proxy | Entschlüsselt und untersucht TLS-Verbindungen entsprechend der Sicherheitsrichtlinie | | PAC-Proxy | Proxy wird durch eine Proxy-Autokonfigurationsdatei ausgewählt | | WPAD | Verfahren zur automatischen Ermittlung einer Proxykonfiguration | | Application Proxy | Gilt nur für eine bestimmte Anwendung oder einen bestimmten Dienst | | System Proxy | Wird durch Betriebssystemkomponenten oder mehrere Anwendungen verwendet | **Wichtig:** Nicht jede Anwendung verwendet automatisch die systemweite Proxykonfiguration.
---
3. Forward Proxy und Reverse Proxy auseinanderhalten **Forward Proxy:** ```text Client ↓ Forward Proxy ↓ Zielserver im Internet oder Netzwerk ``` Der Client oder das Betriebssystem kennt den Proxy normalerweise. **Reverse Proxy:** ```text Client ↓ Reverse Proxy ↓ Backend-Anwendung ``` Der Client kennt normalerweise nur den öffentlichen Dienstnamen. Dass dahinter ein Reverse Proxy und ein oder mehrere Backends stehen, muss für ihn nicht sichtbar sein. | Fehlerstelle | Typische Prüfung | |---|---| | Client zum Forward Proxy | DNS, Route, Port, Authentifizierung | | Forward Proxy zum Zielserver | Proxyprotokoll, Filterregel, DNS und Ausgangsverbindung | | Client zum Reverse Proxy | DNS, Port, TLS und Firewall | | Reverse Proxy zum Backend | Backendadresse, Port, Protokoll, TLS und Anwendung | | Backend selbst | Dienststatus, Listener, Protokolle und Antwortzeit |
---
4. Typische Fehlermeldungen einordnen | Meldung oder Status | Typische Bedeutung | |---|---| | `Could not resolve proxy` | Proxyhostname konnte nicht aufgelöst werden | | `Failed to connect to proxy` | Proxyadresse wurde ermittelt, Verbindung zum Proxyport schlägt fehl | | `407 Proxy Authentication Required` | Forward Proxy verlangt eine Authentifizierung | | `403 Forbidden` | Zugriff wird durch Zielserver, Proxy oder Richtlinie verweigert | | `502 Bad Gateway` | Reverse Proxy erhielt keine gültige Antwort vom Backend | | `503 Service Unavailable` | Dienst oder Backend ist nicht verfügbar | | `504 Gateway Timeout` | Proxy erhielt innerhalb der vorgesehenen Zeit keine Backendantwort | | `Connection refused` | Ziel erreichbar, aber Port wird nicht angenommen | | `Connection timed out` | Keine rechtzeitige Antwort; Filterung, Routing oder Ausfall möglich | | `ERR_PROXY_CONNECTION_FAILED` | Browser konnte den konfigurierten Proxy nicht verwenden | | `ERR_TUNNEL_CONNECTION_FAILED` | Aufbau eines Proxytunnels, häufig per CONNECT, ist fehlgeschlagen | | Zertifikat nicht vertrauenswürdig | Zertifikatskette, TLS-Inspection oder falsches Zertifikat prüfen | | Umleitungsschleife | Proxy-, Anwendungsschema- oder Hostheaderkonfiguration prüfen | | Nur Browser funktioniert | Anwendung verwendet möglicherweise andere Proxyeinstellungen | | Browser funktioniert nicht, CLI schon | Browser-, PAC-, Zertifikats- oder Erweiterungskonfiguration prüfen | Ein HTTP-Statuscode beweist noch nicht eindeutig, welche Komponente ihn erzeugt hat. Antwortheader und Protokolle müssen miteinander verglichen werden.
---
5. Den betroffenen Datenfluss dokumentieren Vor der Diagnose müssen folgende Angaben bekannt sein: ```text Client: Client-IP: Benutzerkontext: Anwendung: Ziel-URL: Zielhostname: Zielport: Proxyart: Proxyhostname: Proxy-IP: Proxyport: PAC-URL: Verwendete Authentifizierung: Zeitpunkt: Fehlermeldung: ``` Zusätzlich prüfen: - Tritt der Fehler bei allen Benutzern auf? - Tritt er bei allen Anwendungen auf? - Sind nur interne oder externe Ziele betroffen? - Funktioniert HTTP, aber HTTPS nicht? - Funktioniert der Zugriff ohne VPN? - Tritt der Fehler nur in einem bestimmten Netzwerk auf? - Ist nur ein einzelner Hostname oder eine gesamte Kategorie betroffen? - Funktioniert derselbe Zugriff auf einem Vergleichssystem?
---
6. Mehrere Proxykonfigurationen berücksichtigen Auf demselben System können unterschiedliche Einstellungen gleichzeitig existieren: - Betriebssystem-Proxy, - WinHTTP-Proxy, - benutzerbezogene Windows-Einstellungen, - Browserkonfiguration, - PAC-Datei, - WPAD, - Umgebungsvariablen, - Anwendungskonfiguration, - Java-Proxyparameter, - Paketmanagerkonfiguration, - Container-Umgebungsvariablen, - Gruppenrichtlinie oder MDM-Profil, - VPN- oder Sicherheitssoftware, - transparenter Netzwerkproxy. **Typisches Fehlerbild:** ```text Browser verwendet PAC-Datei PowerShell-Dienst verwendet WinHTTP CLI-Programm verwendet HTTPS_PROXY Anwendung besitzt eigene Proxykonfiguration ``` Deshalb muss immer genau geprüft werden, **welche Anwendung unter welchem Benutzerkonto** betroffen ist.
---
7. Proxy-Umgebungsvariablen prüfen Häufig verwendete Variablen: ```text http_proxy https_proxy all_proxy no_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY ``` Die unterstützte Schreibweise hängt von Anwendung und Bibliothek ab. Bei curl besitzt insbesondere `http_proxy` eine besondere Behandlung und wird aus Sicherheitsgründen nur in Kleinbuchstaben ausgewertet. **Windows PowerShell:** ```powershell [RO][SENS] Get-ChildItem Env: | Where-Object Name -Match '^(http|https|all|no)_proxy$' | Sort-Object Name ``` **Windows CMD:** ```cmd [RO][SENS] set | findstr /I "http_proxy https_proxy all_proxy no_proxy" ``` **Linux und macOS:** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **Nur Variablennamen ohne Werte anzeigen:** ```bash [RO] env | sed -n 's/^\([^=]*[Pp][Rr][Oo][Xx][Yy]\)=.*/\1/p' ``` Proxy-URLs können Zugangsdaten enthalten: ```text http://benutzer:passwort@proxy.example.internal:8080 ``` Solche Werte dürfen nicht in Tickets, Bildschirmfotos oder Dokumentationen übernommen werden.
---
8. Windows: WinHTTP-Proxy prüfen WinHTTP wird von bestimmten Windows-Diensten und Anwendungen verwendet. Seine Konfiguration kann von den benutzerbezogenen Proxy-Einstellungen abweichen. **Grundlegende WinHTTP-Konfiguration:** ```cmd [RO][SENS] netsh winhttp show proxy ``` **Erweiterte WinHTTP-Konfiguration:** ```cmd [RO][SENS] netsh winhttp show advproxy ``` Mögliche Informationen: - Proxyserver, - Proxyport, - Umgehungsliste, - PAC-URL, - automatische Erkennung, - direkte Verbindung. **Wichtig:** ```text Direkter Zugriff im Browser funktioniert ≠ WinHTTP-Dienst funktioniert ``` und: ```text WinHTTP funktioniert ≠ Browser verwendet dieselbe Konfiguration ``` Änderungsbefehle wie `netsh winhttp reset proxy`, `set proxy` oder `import proxy` dürfen nicht als rein lesende Diagnosebefehle verwendet werden.
---
9. Windows: benutzerbezogene Proxyeinstellungen prüfen **Relevante Benutzereinstellungen auslesen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL, AutoDetect ``` Je nach Windows-Version und Richtlinienquelle können einzelne Eigenschaften fehlen oder anders verwaltet werden. | Eigenschaft | Typische Bedeutung | |---|---| | `ProxyEnable` | Manuell eingetragener Proxy aktiviert | | `ProxyServer` | Proxyadresse beziehungsweise protokollspezifische Zuordnungen | | `ProxyOverride` | Umgehungsliste | | `AutoConfigURL` | URL einer PAC-Datei | | `AutoDetect` | Automatische Erkennung aktiviert | **Nur vorhandene Werte einzeln prüfen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" ` -ErrorAction SilentlyContinue ``` Zu kontrollieren sind: - Wird ein manueller Proxy verwendet? - Ist zusätzlich eine PAC-Datei eingetragen? - Ist automatische Erkennung aktiviert? - Enthält die Umgehungsliste das Ziel? - Wird die Einstellung durch Gruppenrichtlinien verwaltet? - Tritt der Fehler nur bei einem Benutzerprofil auf? Registrywerte sollten nicht direkt verändert werden, solange Verwaltungsquelle und Sollzustand nicht geklärt sind.
---
10. Windows: Richtlinien und Benutzerkontext prüfen **Angewendete Gruppenrichtlinien anzeigen:** ```cmd [RO][FILE][SENS] gpresult /h "%TEMP%\gpresult-proxy.html" ``` Die erzeugte HTML-Datei befindet sich im temporären Verzeichnis des aktuellen Benutzers. **Nur Textausgabe:** ```cmd [RO][SENS] gpresult /r ``` Zu prüfen sind: - Computer- oder Benutzerrichtlinie, - Proxyserver, - PAC-URL, - Browserrichtlinien, - Zertifikatsverteilung, - Sicherheitszonen, - lokale Umgehungsmöglichkeiten, - Richtlinien des Sicherheitsprodukts. **Benutzerkontext bestimmen:** ```powershell [RO] whoami ``` Ein Dienstkonto, Systemkonto oder anderer Benutzer kann eine andere Proxy- und Zertifikatskonfiguration besitzen als der interaktiv angemeldete Benutzer.
---
11. macOS-Proxyeinstellungen prüfen Unter macOS werden Proxyeinstellungen pro Netzwerkdienst verwaltet, beispielsweise getrennt für WLAN und Ethernet. **Netzwerkdienste anzeigen:** ```bash [RO] networksetup -listallnetworkservices ``` Ein Sternchen vor einem Dienstnamen weist in der Ausgabe darauf hin, dass der Netzwerkdienst deaktiviert ist. **HTTP-Proxy eines Netzwerkdienstes:** ```bash [RO][SENS] networksetup -getwebproxy "Wi-Fi" ``` **HTTPS-Proxy:** ```bash [RO][SENS] networksetup -getsecurewebproxy "Wi-Fi" ``` **SOCKS-Proxy:** ```bash [RO][SENS] networksetup -getsocksfirewallproxy "Wi-Fi" ``` **PAC-URL:** ```bash [RO][SENS] networksetup -getautoproxyurl "Wi-Fi" ``` **Proxy-Umgehungsliste:** ```bash [RO][SENS] networksetup -getproxybypassdomains "Wi-Fi" ``` `Wi-Fi` muss durch den tatsächlich verwendeten Netzwerkdienst ersetzt werden. **Alle aktiven Proxyinformationen zusammengefasst anzeigen:** ```bash [RO][SENS] scutil --proxy ``` Zu kontrollieren sind: - Welcher Netzwerkdienst ist aktiv? - Ist der Proxy für diesen Dienst aktiviert? - Stimmen Proxyhostname und Port? - Ist eine PAC-URL aktiv? - Existieren Ausnahmen? - Wird die Konfiguration durch ein MDM-Profil verwaltet? - Ändert ein VPN-Client die Proxykonfiguration?
---
12. Linux-Proxyeinstellungen prüfen Linux besitzt keine für alle Distributionen und Anwendungen einheitliche Proxyverwaltung. Zu prüfen sind insbesondere: - Umgebungsvariablen, - Desktopumgebung, - Paketmanager, - systemd-Dienstkonfiguration, - Anwendungskonfiguration, - Containerkonfiguration, - Shell-Startdateien, - zentrale Konfigurationsverwaltung. **Umgebungsvariablen:** ```bash [RO][SENS] env | grep -iE '^(http|https|all|no)_proxy=' ``` **Systemweite Umgebungsdatei prüfen, sofern vorhanden:** ```bash [RO][SENS] test -f /etc/environment && sed -n '/[Pp][Rr][Oo][Xx][Yy]/p' /etc/environment ``` **systemd-Umgebung eines Dienstes anzeigen:** ```bash [RO][PRIV][SENS] sudo systemctl show DIENSTNAME \ --property=Environment \ --property=EnvironmentFiles ``` **Vollständige Unit-Konfiguration anzeigen:** ```bash [RO][PRIV][SENS] sudo systemctl cat DIENSTNAME ``` **Laufenden Prozess und Benutzer prüfen:** ```bash [RO] systemctl status DIENSTNAME ``` `DIENSTNAME` muss durch den tatsächlichen Dienst ersetzt werden. Ein interaktiver Shell-Test beweist nicht, dass ein systemd-Dienst dieselben Umgebungsvariablen verwendet.
---
13. Manuelle Proxyverbindung mit curl testen **HTTP-Ziel ausdrücklich über einen Proxy testen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ http://example.com/ ``` **HTTPS-Ziel über einen HTTP-Proxy testen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Bei HTTPS verwendet curl über einen HTTP-Proxy normalerweise einen CONNECT-Tunnel zum Ziel. **Nur Antwortheader abrufen:** ```bash [TEST][SENS] curl -I \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Zeitlimit setzen:** ```bash [TEST][SENS] curl -v \ --connect-timeout 5 \ --max-time 15 \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Wichtige Ausgaben:** ```text Trying PROXY_IP:PORT Connected to proxy CONNECT ziel.example:443 HTTP/1.1 200 Connection established Proxy-Authenticate HTTP-Statuscode TLS-Handshake Zertifikatskette ``` `curl -v` kann sensible Header ausgeben. Vor der Dokumentation müssen Zugangsdaten, Cookies und Token entfernt werden.
---
14. Direkten Zugriff und Proxyzugriff vergleichen **Proxy ausdrücklich umgehen:** ```bash [TEST][SENS] curl -v --noproxy "*" https://example.com/ ``` **Proxy ausdrücklich verwenden:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` **Nur für ein bestimmtes Ziel den Proxy umgehen:** ```bash [TEST][SENS] curl -v \ --noproxy "example.com" \ https://example.com/ ``` **Vergleich:** | Direkter Zugriff | Proxyzugriff | Mögliche Eingrenzung | |---|---|---| | Erfolgreich | Fehlerhaft | Proxy, Authentifizierung, PAC oder Filterrichtlinie prüfen | | Fehlerhaft | Erfolgreich | Direkter Weg blockiert oder Proxy ist vorgeschrieben | | Beide fehlerhaft | Ziel, DNS, Clientnetz oder allgemeine Störung prüfen | | Beide erfolgreich | Fehler ist möglicherweise anwendungsspezifisch | | Nur Browser fehlerhaft | Browserprofil, PAC, Zertifikat oder Erweiterung prüfen | | Nur Systemdienst fehlerhaft | WinHTTP-, Dienstkonto- oder Dienstumgebung prüfen | Ein direkter Test darf nur durchgeführt werden, wenn die Sicherheitsrichtlinie einen Proxy-Bypass erlaubt.
---
15. Proxyhostname, Port und Erreichbarkeit prüfen **Namensauflösung des Proxys:** Windows: ```powershell [TEST] Resolve-DnsName proxy.example.internal ``` Linux: ```bash [TEST] getent ahosts proxy.example.internal ``` macOS: ```bash [TEST] dscacheutil -q host -a name proxy.example.internal ``` **Proxyport testen:** Windows: ```powershell [TEST] Test-NetConnection proxy.example.internal -Port 8080 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 proxy.example.internal 8080 ``` **Route zum Proxy prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress PROXY_IP ``` Linux: ```bash [RO] ip route get PROXY_IP ``` macOS: ```bash [RO] route -n get PROXY_IP ``` Ein erfolgreicher TCP-Porttest beweist nur, dass eine Verbindung zum Proxyport aufgebaut werden konnte. Er beweist nicht, dass der Proxy die gewünschte Zielverbindung erlaubt.
---
16. PAC-Datei und automatische Proxyauswahl prüfen Eine PAC-Datei enthält JavaScript und liefert über die Funktion `FindProxyForURL()` eine Proxyentscheidung. Typische Rückgabewerte: ```text DIRECT PROXY proxy.example.internal:8080 HTTPS proxy.example.internal:8443 SOCKS socks.example.internal:1080 ``` Mehrere Möglichkeiten können in einer Reihenfolge angegeben werden: ```text PROXY proxy1.example.internal:8080; PROXY proxy2.example.internal:8080; DIRECT ``` **Konfigurierte PAC-URL ermitteln:** - Windows: `AutoConfigURL` beziehungsweise WinHTTP-Advanced-Proxy prüfen - macOS: `networksetup -getautoproxyurl` oder `scutil --proxy` - Linux: Desktop- oder Anwendungskonfiguration prüfen **PAC-Datei kontrolliert abrufen:** ```bash [TEST][SENS] curl -v "http://config.example.internal/proxy.pac" ``` **Ohne möglicherweise bereits gesetzte Proxyvariablen abrufen:** ```bash [TEST][SENS] curl -v --noproxy "*" \ "http://config.example.internal/proxy.pac" ``` Zu prüfen sind: - Ist die PAC-URL per DNS erreichbar? - Ist der Webserver erreichbar? - Wird ein erfolgreicher HTTP-Status geliefert? - Ist der MIME-Typ plausibel? - Ist die Datei syntaktisch gültig? - Welche Entscheidung trifft sie für die konkrete URL? - Werden interne und externe Namen unterschiedlich behandelt? - Gibt es Zeitverzögerungen durch DNS-Abfragen? - Enthält die Datei veraltete Proxynamen? - Wird die PAC-Datei zwischengespeichert? PAC-Dateien sind ausführbarer JavaScript-Code und dürfen nur aus vertrauenswürdigen Quellen bezogen werden.
---
17. WPAD und automatische Erkennung beurteilen WPAD kann eine Proxykonfiguration automatisch bereitstellen. Abhängig von der Umgebung kann die Ermittlung unter anderem über DHCP oder DNS erfolgen. Mögliche Fehler: - falscher WPAD-DNS-Eintrag, - WPAD-Server nicht erreichbar, - veraltete PAC-Datei, - unterschiedliche Suchdomänen, - VPN verändert DNS oder Suchsuffixe, - Client verwendet automatische Erkennung nicht, - Sicherheitsrichtlinie blockiert WPAD, - nicht autorisierter WPAD-Server. **Windows-DNS-Suffixe prüfen:** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix ``` **Windows-DNS-Konfiguration:** ```powershell [RO] Get-DnsClientGlobalSetting ``` **Linux-Suchdomänen prüfen:** ```bash [RO] resolvectl status ``` Falls `resolvectl` nicht vorhanden ist: ```bash [RO] cat /etc/resolv.conf ``` **macOS-DNS-Konfiguration:** ```bash [RO][SENS] scutil --dns ``` WPAD darf nicht durch willkürlich angelegte DNS-Einträge getestet werden. Eine fehlerhafte oder manipulierte WPAD-Konfiguration kann den gesamten Webverkehr umleiten.
---
18. Proxy-Umgehungslisten prüfen Eine Umgehungsliste bestimmt, welche Ziele direkt und nicht über den Proxy erreicht werden. Typische Einträge: ```text localhost 127.0.0.1 ::1 *.example.internal 192.168.0.0/16 ``` Die unterstützte Syntax unterscheidet sich zwischen Betriebssystemen und Anwendungen. Nicht jede Anwendung versteht CIDR-Netze, Platzhalter oder `` gleich. **Typische Fehler:** - Hostname passt nicht zum Platzhaltermuster. - Kurzname wird umgangen, FQDN jedoch nicht. - IP-Adresse wird umgangen, Hostname dagegen nicht. - Falscher Trenner wurde verwendet. - Portnummer wurde unnötig in das Muster aufgenommen. - IPv6-Ziel fehlt. - `NO_PROXY` enthält Leerzeichen oder eine ungeeignete Syntax. - Anwendung interpretiert führende Punkte anders. - Interner Dienst wird versehentlich über externen Proxy gesendet. **curl-Entscheidung sichtbar machen:** ```bash [TEST][SENS] curl -v https://service.example.internal/ ``` In der ausführlichen Ausgabe kann curl anzeigen, welche Proxy- beziehungsweise `NO_PROXY`-Variable berücksichtigt wurde.
---
19. Proxy-Authentifizierung untersuchen Ein Forward Proxy kann unter anderem folgende Verfahren verwenden: - Basic, - Digest, - NTLM, - Negotiate beziehungsweise Kerberos, - zertifikatsbasierte Authentifizierung, - IP- oder gerätebasierte Freigabe. **Proxyantwort ohne Zugangsdaten prüfen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Auf folgende Header achten: ```text HTTP/1.1 407 Proxy Authentication Required Proxy-Authenticate: Basic Proxy-Authenticate: NTLM Proxy-Authenticate: Negotiate ``` **Sicherheitsregeln:** - Passwörter nicht direkt in die Befehlszeile schreiben. - Zugangsdaten nicht in Shell-History speichern. - Autorisierungsheader nicht in Tickets kopieren. - Keine produktiven Kennwörter in PAC-Dateien oder Umgebungsvariablen ablegen. - Authentifizierungsverfahren nicht ohne Freigabe herabsetzen. - Uhrzeit und Domänenanmeldung bei Kerberos-Problemen prüfen. **Benutzerkontext prüfen:** Windows: ```powershell [RO] whoami ``` Linux und macOS: ```bash [RO] id ``` Ein Hintergrunddienst besitzt möglicherweise keine interaktive Benutzersitzung und kann daher keine integrierte Proxyauthentifizierung durchführen.
---
20. TLS-Inspection und Zertifikatsfehler analysieren Bei TLS-Inspection baut die Sicherheitskomponente getrennte TLS-Verbindungen auf: ```text Client ↓ TLS-Verbindung 1 Inspection-Proxy ↓ TLS-Verbindung 2 Zielserver ``` Der Client sieht dabei ein vom Inspection-System ausgestelltes Zertifikat. **Zertifikat über den vorgesehenen Verbindungsweg prüfen:** ```bash [TEST][SENS] curl -v https://example.com/ ``` **TLS-Verbindung zu einem HTTPS-Ziel über HTTP-Proxy untersuchen:** ```bash [TEST][SENS] curl -v \ --proxy http://proxy.example.internal:8080 \ https://example.com/ ``` Zu prüfen sind: - Aussteller des präsentierten Zertifikats, - Hostname im Zertifikat, - Gültigkeitszeitraum, - Vertrauenskette, - Unternehmens-Stammzertifikat, - Zertifikatsspeicher der betroffenen Anwendung, - Systemzeit, - TLS-Version, - SNI, - Ausnahmen von der TLS-Inspection. **Typisches Fehlerbild:** ```text Browser funktioniert CLI-Anwendung meldet unbekannte Zertifizierungsstelle ``` Mögliche Ursache: - Browser und Anwendung verwenden unterschiedliche Zertifikatsspeicher. Die Zertifikatsprüfung darf nicht dauerhaft deaktiviert werden. Optionen wie `curl -k` dienen höchstens einer genehmigten Eingrenzung und stellen keine Fehlerbehebung dar.
---
21. Reverse Proxy vom Backend trennen Ein Reverse-Proxy-Datenfluss besteht mindestens aus zwei Verbindungen: ```text Verbindung 1: Client → Reverse Proxy Verbindung 2: Reverse Proxy → Backend ``` Beide Verbindungen können unterschiedliche Eigenschaften besitzen: | Eigenschaft | Clientseite | Backendseite | |---|---|---| | Protokoll | HTTPS | HTTP oder HTTPS | | Port | 443 | beispielsweise 80, 8080 oder 8443 | | DNS | öffentlicher Dienstname | interner Backendname | | Zertifikat | öffentliches oder internes Frontendzertifikat | gegebenenfalls internes Backendzertifikat | | Authentifizierung | Benutzeranmeldung | Dienst- oder keine zusätzliche Anmeldung | | Firewall | Client zum Proxy | Proxy zum Backend | | Timeout | Frontendtimeout | Upstreamtimeout | Ein erfolgreicher Zugriff auf den Reverse-Proxy-Port beweist nicht, dass das Backend erreichbar ist.
---
22. Reverse Proxy systematisch prüfen **Schritt 1 – DNS des öffentlichen Dienstnamens:** Windows: ```powershell [TEST] Resolve-DnsName service.example.net ``` Linux und macOS: ```bash [TEST] dig service.example.net A [TEST] dig service.example.net AAAA ``` **Schritt 2 – Frontend-Port:** Windows: ```powershell [TEST] Test-NetConnection service.example.net -Port 443 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 service.example.net 443 ``` **Schritt 3 – Frontend-Anwendung:** ```bash [TEST][SENS] curl -v https://service.example.net/ ``` **Schritt 4 – Backend vom Reverse-Proxy-System aus:** ```bash [TEST][SENS] curl -v http://backend.example.internal:8080/ ``` **Schritt 5 – Backend-Port:** ```bash [TEST] nc -vz -w 5 backend.example.internal 8080 ``` **Schritt 6 – Protokolle des Reverse Proxys:** - Zugriffsprotokoll, - Fehlerprotokoll, - Upstreamstatus, - Antwortzeit, - ausgewähltes Backend, - TLS-Fehler, - Namensauflösungsfehler. Der Backendtest muss vom Reverse-Proxy-System beziehungsweise aus dessen Netzwerk- oder Containerkontext erfolgen. Ein Test von einem Administrator-PC kann einen anderen Netzwerkpfad verwenden.
---
23. Wichtige Reverse-Proxy-Header prüfen Reverse Proxys übermitteln dem Backend häufig Informationen über die ursprüngliche Anfrage. Typische Header: ```text Host X-Forwarded-For X-Forwarded-Host X-Forwarded-Proto Forwarded ``` | Header | Typische Aufgabe | |---|---| | `Host` | Ursprünglich angesprochener Hostname | | `X-Forwarded-For` | Ursprüngliche Clientadresse beziehungsweise Proxykette | | `X-Forwarded-Host` | Ursprünglich verwendeter Host | | `X-Forwarded-Proto` | Ursprüngliches Schema wie `http` oder `https` | | `Forwarded` | Standardisierter Header für Proxyinformationen | **Mögliche Fehler:** - Backend erhält falschen Hostheader. - Anwendung erkennt HTTPS nicht und erzeugt HTTP-Links. - Endlose HTTP-zu-HTTPS-Umleitung. - Client-IP wird nicht korrekt übergeben. - Anwendung vertraut beliebigen `X-Forwarded-For`-Werten. - Mehrere Proxys erzeugen eine fehlerhafte Headerkette. - Anwendung ist nicht für vertrauenswürdige Proxys konfiguriert. Forwarded-Header dürfen nur von ausdrücklich vertrauenswürdigen Proxys als verlässlich behandelt werden.
---
24. Reverse-Proxy-Statuscodes untersuchen | Status | Mögliche Ursache | |---:|---| | `400` | Ungültige Anfrage, fehlerhafter Hostheader oder Protokollfehler | | `401` | Anwendung verlangt Authentifizierung | | `403` | Zugriff durch Proxy oder Backend verweigert | | `404` | Falscher Host, Pfad oder Backendrouting | | `408` | Anfrage wurde nicht rechtzeitig vollständig empfangen | | `413` | Anfrage oder Upload überschreitet eine Größenbegrenzung | | `421` | Anfrage wurde einem unpassenden Ziel beziehungsweise virtuellen Host zugeordnet | | `429` | Rate Limit wurde erreicht | | `431` | Header sind zu groß | | `499` | Nicht standardisierter, insbesondere bei NGINX verwendeter Status für Clientabbruch | | `500` | Interner Anwendungs- oder Proxyfehler | | `502` | Backend nicht erreichbar oder ungültige Backendantwort | | `503` | Kein verfügbares Backend oder Dienst absichtlich nicht verfügbar | | `504` | Backend antwortet nicht rechtzeitig | Zur eindeutigen Zuordnung müssen Antwortheader, Proxyprotokoll und Backendprotokoll zum selben Zeitpunkt verglichen werden.
---
25. NGINX-Reverse-Proxy prüfen Die folgenden Befehle gelten nur, wenn NGINX tatsächlich eingesetzt wird. **Konfigurationssyntax prüfen:** ```bash [RO][PRIV][SENS] sudo nginx -t ``` Dieser Befehl prüft die Konfiguration, lädt sie aber nicht neu. **Vollständig aufgelöste Konfiguration anzeigen:** ```bash [RO][PRIV][SENS] sudo nginx -T ``` Die Ausgabe kann Zertifikatspfade, interne Hostnamen und weitere sensible Konfigurationswerte enthalten. **Dienststatus:** ```bash [RO] systemctl status nginx ``` **Prozess und Listener:** ```bash [RO] ss -ltnp ``` **Dienstprotokolle über systemd:** ```bash [RO][PRIV][SENS] sudo journalctl -u nginx --since "-15 minutes" ``` Zu prüfen sind: - passende `server_name`-Direktive, - `listen`-Adresse und Port, - richtige `location`, - korrektes `proxy_pass`-Ziel, - Backendprotokoll HTTP oder HTTPS, - Namensauflösung des Backends, - TLS-SNI zum Backend, - Weitergabe benötigter Header, - Verbindungs- und Antworttime-outs, - Uploadgrößen, - WebSocket- beziehungsweise Upgrade-Header, - verfügbares Backend. Ein erfolgreicher `nginx -t` beweist nur, dass NGINX die Konfiguration syntaktisch akzeptiert. Er beweist nicht, dass das Backend erreichbar ist.
---
26. Container und Reverse Proxy prüfen Bei containerisierten Anwendungen entstehen zusätzliche Ebenen: ```text Client ↓ Hostport ↓ Reverse-Proxy-Container ↓ Docker-Netzwerk ↓ Backend-Container ↓ Anwendung ``` **Container und Ports anzeigen:** ```bash [RO] docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` **Netzwerke anzeigen:** ```bash [RO] docker network ls ``` **Netzwerk untersuchen:** ```bash [RO][SENS] docker network inspect NETZWERKNAME ``` **Containerprotokolle:** ```bash [RO][SENS] docker logs --tail 100 CONTAINERNAME ``` **Umgebungsvariablen eines Containers kontrollieren:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` Zu prüfen sind: - Befinden sich Proxy und Backend im selben Docker-Netzwerk? - Wird der richtige Containername als DNS-Name verwendet? - Stimmt der interne Containerport? - Wird versehentlich der veröffentlichte Hostport als Containerziel verwendet? - Lauscht die Anwendung auf `0.0.0.0` beziehungsweise einer erreichbaren Containeradresse? - Startet das Backend später als der Proxy? - Ist der Backendname nach einer Umbenennung veraltet? - Enthält der Container Proxy-Umgebungsvariablen? - Umgeht `NO_PROXY` interne Containerziele korrekt?
---
27. NO_PROXY bei Containern und internen Diensten prüfen Ein Container kann ausgehende Verbindungen über einen Forward Proxy senden. Interne Dienste sollten abhängig vom Sollzustand möglicherweise direkt erreichbar sein. Beispiel: ```text HTTP_PROXY=http://proxy.example.internal:8080 HTTPS_PROXY=http://proxy.example.internal:8080 NO_PROXY=localhost,127.0.0.1,backend,backend.example.internal ``` **Typisches Fehlerbild:** ```text Anwendung möchte internen Backend-Container erreichen ↓ Backendname fehlt in NO_PROXY ↓ Anfrage wird an Unternehmensproxy gesendet ↓ Proxy kann internen Containernamen nicht auflösen ↓ Verbindung schlägt fehl ``` **Konfiguration anzeigen:** ```bash [RO][SENS] docker inspect CONTAINERNAME ``` Die genaue `NO_PROXY`-Syntax hängt von Anwendung und verwendeter Bibliothek ab. Änderungen müssen deshalb mit deren Dokumentation abgeglichen werden.
---
28. DNS-Auflösung aus dem richtigen Kontext prüfen Client, Forward Proxy, Reverse Proxy und Backend können unterschiedliche DNS-Server und Antworten verwenden. | System | Muss auflösen können | |---|---| | Client | Proxyhostname und gegebenenfalls Zielhostname | | Forward Proxy | Externes oder internes Ziel | | Reverse Proxy | Backendhostname | | Backend | Abhängige Datenbanken, APIs und Dienste | | Container | Containername oder internen DNS-Namen | **Windows:** ```powershell [TEST] Resolve-DnsName HOSTNAME ``` **Linux:** ```bash [TEST] getent ahosts HOSTNAME ``` **macOS:** ```bash [TEST] dscacheutil -q host -a name HOSTNAME ``` Der Befehl muss auf dem System ausgeführt werden, das die jeweilige Verbindung tatsächlich aufbaut. **Typisches Beispiel:** ```text Administrator-PC kann backend.example.internal auflösen Reverse-Proxy-Container kann den Namen nicht auflösen ``` Der erfolgreiche Test vom Administrator-PC ist dann für die Backendverbindung nicht ausreichend.
---
29. Zeitüberschreitungen systematisch unterscheiden Ein Proxyweg kann mehrere Time-outs besitzen: ```text Client-Verbindungszeit Proxy-Verbindungszeit zum Backend Zeit zum Senden der Anfrage Zeit bis zum ersten Antwortbyte Zeit zwischen Antwortdaten Gesamtdauer der Anfrage ``` **curl-Zeitmessung:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` **Über einen expliziten Proxy:** ```bash [TEST][SENS] curl -sS -o /dev/null \ --proxy http://proxy.example.internal:8080 \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` Die Zeitwerte müssen mit Proxy- und Backendprotokollen verglichen werden. Ein `504` beweist nicht automatisch, dass das Backend vollständig ausgefallen ist; es kann lediglich später als das konfigurierte Zeitlimit geantwortet haben.
---
30. Paketmitschnitt für Proxyfehler erstellen **Verkehr zwischen Client und Forward Proxy:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host PROXY_IP and tcp port PROXY_PORT' \ -w client-proxy.pcap ``` **Verkehr zwischen Reverse Proxy und Backend:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host BACKEND_IP and tcp port BACKEND_PORT' \ -w proxy-backend.pcap ``` **Windows mit Dumpcap – Schnittstellen anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Proxyverkehr aufzeichnen:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host PROXY_IP and tcp port PROXY_PORT" ` -w proxy-test.pcapng ``` **Wireshark-Anzeigefilter:** | Aufgabe | Filter | |---|---| | Proxyport 8080 | `tcp.port == 8080` | | HTTP-Statuscodes | `http.response.code` | | Status 407 | `http.response.code == 407` | | Status 502 | `http.response.code == 502` | | Status 504 | `http.response.code == 504` | | HTTP-CONNECT | `http.request.method == "CONNECT"` | | TLS-Handshake | `tls.handshake` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-Wiederholungen | `tcp.analysis.retransmission` | Verschlüsselter Datenverkehr zeigt ohne zulässige Entschlüsselung nicht den vollständigen HTTP-Inhalt.
---
31. Typische Fehlerbilder systematisch eingrenzen **Fall A – Proxyhostname kann nicht aufgelöst werden** Prüfen: - Proxyname, - DNS-Server, - DNS-Suffix, - VPN, - PAC-Datei, - veralteter Proxyname. --- **Fall B – Proxyport ist nicht erreichbar** Prüfen: - Route, - Firewall, - Proxybetrieb, - falscher Port, - nur aus bestimmten VLANs erlaubt, - IPv4- oder IPv6-Auswahl. --- **Fall C – HTTP 407** Prüfen: - Authentifizierungsverfahren, - Benutzerkonto, - Dienstkonto, - Domänenverbindung, - Systemzeit, - Kerberos, - gespeicherte Anmeldeinformationen, - Unterstützung der Anwendung. --- **Fall D – Browser funktioniert, Dienst nicht** Prüfen: - WinHTTP, - Dienstkonto, - Umgebungsvariablen, - Zertifikatsspeicher, - PAC-Unterstützung der Anwendung, - interaktive Authentifizierung. --- **Fall E – Direkter Zugriff funktioniert, Proxyzugriff nicht** Prüfen: - Proxyfilter, - Zielkategorie, - Proxy-DNS, - Authentifizierung, - CONNECT-Erlaubnis, - TLS-Inspection, - Proxyprotokolle. --- **Fall F – Reverse Proxy liefert 502** Prüfen: - Backenddienst, - Backendname, - Backendport, - HTTP gegenüber HTTPS, - Firewall, - Container-Netzwerk, - ungültige Backendantwort, - TLS-Zertifikat des Backends. --- **Fall G – Reverse Proxy liefert 504** Prüfen: - Backendantwortzeit, - Datenbank oder externe API, - Upstreamtimeout, - Paketverlust, - DNS-Verzögerung, - ausgelastetes Backend. --- **Fall H – Endlose Umleitung** Prüfen: - `X-Forwarded-Proto`, - HTTPS-Erkennung der Anwendung, - HTTP-zu-HTTPS-Regeln, - doppelten Redirect, - Basis-URL der Anwendung, - Hostheader.
---
32. Keine vorschnellen Proxyänderungen durchführen Nicht unkontrolliert: - Systemproxy zurücksetzen, - PAC-URL entfernen, - WPAD-DNS-Einträge anlegen, - Proxy-Authentifizierung deaktivieren, - TLS-Inspection umgehen, - Zertifikatsprüfung dauerhaft abschalten, - Unternehmenszertifikate löschen, - beliebige Ziele auf die Bypassliste setzen, - Forwarded-Header ungeprüft vertrauen, - Proxyprotokolle mit Zugangsdaten weitergeben, - Reverse Proxy neu laden, bevor die Konfiguration geprüft wurde. **Sicheres Vorgehen:** 1. Istkonfiguration dokumentieren. 2. Verwaltungsquelle bestimmen. 3. Betroffene Anwendung und Benutzerkontext feststellen. 4. Direkten und proxied Datenfluss getrennt prüfen. 5. Proxy- und Backendprotokolle zeitlich zuordnen. 6. Ursache nachweisen. 7. Änderung genehmigen lassen. 8. Kleinste erforderliche Änderung durchführen. 9. Funktion und Sicherheit prüfen. 10. Rückfallmöglichkeit dokumentieren.
---
33. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Anwendung und Benutzerkontext bestimmen | Wer baut die Verbindung tatsächlich auf? | | 2 | Ziel-URL dokumentieren | Welcher Host, Port und welches Protokoll werden verwendet? | | 3 | Proxyart bestimmen | Forward Proxy, PAC, transparent oder Reverse Proxy? | | 4 | Konfigurationsquelle ermitteln | System, Anwendung, Richtlinie, Variable oder MDM? | | 5 | Proxyhostname auflösen | Wird die erwartete Proxyadresse verwendet? | | 6 | Proxyport prüfen | Ist der Proxy transportseitig erreichbar? | | 7 | PAC- beziehungsweise WPAD-Auswahl prüfen | Welcher Proxy wird für diese URL gewählt? | | 8 | Umgehungsliste prüfen | Soll das Ziel direkt oder über Proxy erreicht werden? | | 9 | Proxytest durchführen | Welche Antwort liefert der Proxy? | | 10 | Authentifizierung prüfen | Wird 407 oder ein anderes Verfahren verwendet? | | 11 | Direkten Vergleichstest durchführen | Liegt der Fehler nur im Proxyweg? | | 12 | Zertifikatskette prüfen | Ist TLS-Inspection oder ein Vertrauensproblem beteiligt? | | 13 | Reverse-Proxy-Frontend prüfen | Erreicht der Client den Reverse Proxy? | | 14 | Backend vom Proxy aus prüfen | Kann der Proxy das Backend erreichen? | | 15 | Header und Protokoll prüfen | Stimmen Host, Schema und Forwarded-Header? | | 16 | Protokolle vergleichen | Welche Komponente erzeugt den Fehler? | | 17 | Paketmitschnitt erstellen | An welcher Verbindung scheitert der Datenfluss? | | 18 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 19 | Nachprüfung | Funktionieren Anwendung, Authentifizierung und TLS? | | 20 | Dokumentation | Sind Ursache, Änderung und Rückfallplan festgehalten? |
---
34. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Proxyvariablen | `[RO][SENS] Get-ChildItem Env: \| Where-Object Name -Match 'proxy'` | `[RO][SENS] env \| grep -i proxy` | `[RO][SENS] env \| grep -i proxy` | | WinHTTP-Proxy | `[RO][SENS] netsh winhttp show proxy` | Nicht zutreffend | Nicht zutreffend | | Erweiterter WinHTTP-Proxy | `[RO][SENS] netsh winhttp show advproxy` | Nicht zutreffend | Nicht zutreffend | | Benutzerproxy | `[RO][SENS] Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"` | Abhängig von Desktop und Anwendung | `[RO][SENS] scutil --proxy` | | HTTP-Proxy | Abhängig von Anwendung | Über Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getwebproxy "Wi-Fi"` | | HTTPS-Proxy | Abhängig von Anwendung | Über Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"` | | PAC-URL | Registry beziehungsweise WinHTTP prüfen | Abhängig von Desktop und Anwendung | `[RO][SENS] networksetup -getautoproxyurl "Wi-Fi"` | | Proxyhostname auflösen | `[TEST] Resolve-DnsName PROXY` | `[TEST] getent ahosts PROXY` | `[TEST] dscacheutil -q host -a name PROXY` | | Proxyport prüfen | `[TEST] Test-NetConnection PROXY -Port PORT` | `[TEST] nc -vz -w 5 PROXY PORT` | `[TEST] nc -vz -w 5 PROXY PORT` | | Expliziter Proxytest | `[TEST][SENS] curl.exe -v --proxy http://PROXY:PORT URL` | `[TEST][SENS] curl -v --proxy http://PROXY:PORT URL` | `[TEST][SENS] curl -v --proxy http://PROXY:PORT URL` | | Proxy umgehen | `[TEST][SENS] curl.exe -v --noproxy "*" URL` | `[TEST][SENS] curl -v --noproxy "*" URL` | `[TEST][SENS] curl -v --noproxy "*" URL` | | Dienstumgebung | Windows-Dienstkontext getrennt prüfen | `[RO][PRIV][SENS] sudo systemctl show DIENST --property=Environment` | Abhängig von LaunchDaemon und Anwendung | | Reverse-Proxy-Backend testen | `[TEST] Test-NetConnection BACKEND -Port PORT` | `[TEST] nc -vz -w 5 BACKEND PORT` | `[TEST] nc -vz -w 5 BACKEND PORT` | | NGINX-Konfiguration | Falls installiert: `[RO] nginx -t` | `[RO][PRIV][SENS] sudo nginx -t` | Falls installiert: `[RO][PRIV][SENS] sudo nginx -t` | | Containerprotokolle | `[RO][SENS] docker logs --tail 100 CONTAINER` | `[RO][SENS] docker logs --tail 100 CONTAINER` | `[RO][SENS] docker logs --tail 100 CONTAINER` | `PROXY`, `PORT`, `URL`, `DIENST`, `BACKEND` und `CONTAINER` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
35. Dokumentationsvorlage für Proxyfehler ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Client: Client-IP: Betriebssystem: Betroffene Anwendung: Anwendungsversion: Ziel-URL: Zielhostname: Ziel-IP: Zielport: HTTP oder HTTPS: Fehlermeldung: HTTP-Statuscode: Proxyart: Proxyhostname: Proxy-IP: Proxyport: Konfigurationsquelle: PAC-URL: WPAD verwendet: Umgehungsliste: Proxy-Authentifizierung: TLS-Inspection: WinHTTP-Konfiguration: Benutzerkonfiguration: Umgebungsvariablen: Anwendungseigene Konfiguration: Gruppenrichtlinie oder MDM: Proxy-DNS erfolgreich: Proxyport erreichbar: Expliziter Proxytest: Direkter Vergleichstest: Zertifikatsaussteller: Proxyprotokolleintrag: Reverse Proxy beteiligt: Frontend erreichbar: Backendhostname: Backend-IP: Backendport: Backendprotokoll: Backend vom Proxy erreichbar: Backenddienst aktiv: Proxy-Fehlerprotokoll: Backend-Fehlerprotokoll: Forwarded-Header geprüft: Paketmitschnitt vorhanden: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
36. Kontrollfragen nach der Diagnose - Welche Anwendung baut die Verbindung auf? - Unter welchem Benutzer- oder Dienstkonto läuft sie? - Wird ein Forward Proxy, Reverse Proxy oder beides verwendet? - Welche Proxykonfiguration verwendet genau diese Anwendung? - Stimmen Proxyhostname und Proxyport? - Kann der Proxyname aufgelöst werden? - Ist der Proxyport erreichbar? - Wird eine PAC-Datei oder WPAD verwendet? - Welche Proxyentscheidung gilt für die konkrete URL? - Soll das Ziel laut Umgehungsliste direkt erreicht werden? - Existieren widersprüchliche Proxyvariablen? - Wurde ein Test mit ausdrücklich gesetztem Proxy durchgeführt? - Wurde ein genehmigter direkter Vergleichstest durchgeführt? - Verlangt der Proxy eine Authentifizierung? - Kann die Anwendung das Verfahren unterstützen? - Wird TLS-Inspection eingesetzt? - Verwendet die Anwendung den richtigen Zertifikatsspeicher? - Erreicht der Client den Reverse Proxy? - Kann der Reverse Proxy das Backend auflösen und erreichen? - Stimmen Backendprotokoll und Backendport? - Werden Host- und Forwarded-Header korrekt übermittelt? - Wurde der HTTP-Statuscode anhand der Protokolle einer Komponente zugeordnet? - Wurden Client-, Proxy- und Backendzeitstempel verglichen? - Wurde die Konfiguration nicht vorschnell zurückgesetzt? - Wurde die Funktion nach einer Änderung erneut vollständig geprüft?
---
37. Quellen und weiterführende Dokumentation - Microsoft Learn – `netsh winhttp`: https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/netsh-winhttp - Microsoft Learn – WinHTTP AutoProxy Support: https://learn.microsoft.com/windows/win32/winhttp/winhttp-autoproxy-support - Microsoft Learn – WPAD-Prozess: https://learn.microsoft.com/windows-server/networking/automatic-tunneling/disable-http-proxy-auth-features - Apple – `networksetup`-Handbuch: Auf dem Mac lokal abrufbar mit `man networksetup` - Apple – Netzwerk-Proxyeinstellungen auf dem Mac: https://support.apple.com/de-de/guide/mac-help/mchlp2591/mac - curl – Proxy-Unterstützung: https://curl.se/docs/manpage.html#-x - curl – Proxy-Umgebungsvariablen: https://curl.se/libcurl/c/libcurl-env.html - curl – Alles rund um Proxys: https://everything.curl.dev/usingcurl/proxies/index.html - MDN – Proxy-Autokonfigurationsdatei: https://developer.mozilla.org/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file - MDN – HTTP-Statuscode 407: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/407 - MDN – HTTP-Statuscode 502: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/502 - MDN – HTTP-Statuscode 504: https://developer.mozilla.org/docs/Web/HTTP/Reference/Status/504 - NGINX – Reverse Proxy: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/ - NGINX – Modul `ngx_http_proxy_module`: https://nginx.org/en/docs/http/ngx_http_proxy_module.html - RFC 9110 – HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html - RFC 7239 – Forwarded HTTP Extension: https://www.rfc-editor.org/rfc/rfc7239.html
# 3.13 VPN- und Tunnelverbindungen analysieren Ein Virtual Private Network erweitert die lokale Netzwerkumgebung um einen verschlüsselten oder logisch getrennten Tunnel. Eine angezeigte VPN-Verbindung kann erfolgreich aufgebaut sein, obwohl interne Dienste, DNS-Auflösung oder einzelne Netzbereiche weiterhin nicht funktionieren. Die zentralen Fragen dieser Seite lauten: > Wird der Tunnel vollständig aufgebaut, erhält der Client die richtige Konfiguration und wird der betroffene Datenverkehr tatsächlich durch den vorgesehenen Tunnel geleitet? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann Verbindungen oder Dienste beeinträchtigen | VPN-Ausgaben können Benutzernamen, öffentliche Schlüssel, interne Netze, Serveradressen, Zertifikatsinformationen und Sicherheitsrichtlinien enthalten. Private Schlüssel, Pre-Shared Keys, Passwörter und Sitzungstoken dürfen niemals dokumentiert oder weitergegeben werden.
---
2. VPN- und Tunnelarten unterscheiden | Art | Typische Verwendung | |---|---| | Remote-Access-VPN | Einzelne Clients verbinden sich mit einem Unternehmensnetz | | Site-to-Site-VPN | Zwei oder mehr Netzwerke werden miteinander verbunden | | Full Tunnel | Grundsätzlich wird der gesamte vorgesehene Datenverkehr durch das VPN geleitet | | Split Tunnel | Nur definierte Netze oder Anwendungen verwenden den Tunnel | | Device Tunnel | Verbindung wird im Gerätekontext aufgebaut | | User Tunnel | Verbindung wird im Benutzerkontext aufgebaut | | Always-On-VPN | Tunnel wird automatisch oder dauerhaft aufgebaut | | Policy-Based VPN | Auswahl des Tunnelverkehrs anhand definierter Richtlinien | | Route-Based VPN | Tunnel wird als routbare virtuelle Schnittstelle behandelt | | Application VPN | Nur ausgewählte Anwendungen verwenden den Tunnel | | Overlay-Netzwerk | Virtuelles Netz wird über ein bestehendes Netz gelegt | | Zero-Trust-Zugang | Zugriff wird zusätzlich anhand von Identität, Gerät und Richtlinien bewertet | **Wichtig:** Die Anzeige „Verbunden“ bestätigt häufig nur den Tunnelaufbau. Sie beweist nicht, dass die benötigte Anwendung erreichbar ist.
---
3. Häufige VPN-Protokolle und Transportwege | VPN-Technik | Typischer Transport | |---|---| | IKEv2/IPsec | UDP 500 und bei NAT-T UDP 4500 | | IPsec ESP | IP-Protokollnummer 50, kein TCP- oder UDP-Port | | IPsec AH | IP-Protokollnummer 51, kein TCP- oder UDP-Port | | L2TP | Typischerweise UDP 1701, häufig zusammen mit IPsec | | SSTP | TCP 443 | | OpenVPN | Häufig UDP oder TCP 1194, aber frei konfigurierbar | | WireGuard | UDP, Port frei konfigurierbar; häufig wird 51820 verwendet | | GRE | IP-Protokollnummer 47, kein TCP- oder UDP-Port | | TLS-basierte Hersteller-VPNs | Häufig TCP 443 oder UDP-basierter Transport | | SSH-Tunnel | TCP, häufig Port 22, aber konfigurierbar | Die tatsächlichen Ports und Protokolle müssen immer aus der produktiven VPN-Konfiguration entnommen werden. **Nicht verwechseln:** ```text GRE = IP-Protokoll 47 ESP = IP-Protokoll 50 AH = IP-Protokoll 51 ``` Diese Zahlen sind keine Portnummern.
---
4. Die Diagnose in Phasen aufteilen | Phase | Zentrale Frage | |---|---| | 1. Basisverbindung | Besitzt der Client eine funktionierende Verbindung zum Internet oder Unternehmensnetz? | | 2. Serverauflösung | Kann der VPN-Gatewayname korrekt aufgelöst werden? | | 3. Transport | Ist der benötigte Port beziehungsweise das IP-Protokoll erreichbar? | | 4. Authentifizierung | Werden Benutzer, Gerät, Zertifikat und MFA akzeptiert? | | 5. Tunnelerstellung | Wird eine virtuelle Schnittstelle beziehungsweise Security Association aufgebaut? | | 6. Adressierung | Erhält der Client die vorgesehene Tunneladresse? | | 7. Routing | Werden die benötigten Zielnetze in den Tunnel geleitet? | | 8. DNS | Werden interne Namen über die vorgesehenen Resolver aufgelöst? | | 9. Richtlinie | Darf Benutzer und Gerät auf das Ziel zugreifen? | | 10. Anwendung | Antwortet der eigentliche Dienst? | | 11. Stabilität | Bleibt der Tunnel verbunden und leistungsfähig? | Durch diese Trennung wird verhindert, dass ein Anwendungsfehler fälschlich als VPN-Aufbaufehler behandelt wird.
---
5. Störungsumfang zuerst bestimmen Vor den technischen Prüfungen sind folgende Fragen zu beantworten: - Ist nur ein Benutzer betroffen? - Ist nur ein Gerät betroffen? - Sind alle Benutzer eines Standorts betroffen? - Funktioniert das VPN über ein anderes Netzwerk? - Funktioniert es über Mobilfunk, aber nicht über WLAN? - Ist nur ein internes Ziel betroffen? - Sind alle internen Namen betroffen? - Funktionieren interne IP-Adressen, aber keine Hostnamen? - Funktioniert der Tunnelaufbau, aber kein Datenverkehr? - Bricht die Verbindung nach einer bestimmten Zeit ab? - Begann der Fehler nach Passwort-, Zertifikats- oder Clientänderung? - Betrifft der Fehler IPv4, IPv6 oder beides? - Wird Full Tunnel oder Split Tunnel erwartet? - Existiert eine aktuelle allgemeine VPN-Störung? **Wichtiger Vergleichstest:** ```text Gleiches Gerät + anderes Zugangsnetz Gleiches Benutzerkonto + anderes Gerät Anderer Benutzer + gleiches Gerät Funktionierender und fehlerhafter Client im Vergleich ``` Dabei müssen Datenschutz, Kontosicherheit und betriebliche Berechtigungen eingehalten werden.
---
6. Basisverbindung vor dem VPN prüfen Ein VPN benötigt zunächst eine funktionierende Verbindung zum VPN-Gateway. | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Schnittstellen | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] ifconfig` | | IP-Konfiguration | `[RO] Get-NetIPConfiguration` | `[RO] ip -br address` | `[RO] ifconfig` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | DNS-Konfiguration | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | Internetziel testen | `[TEST] Test-NetConnection example.com -Port 443` | `[TEST] curl -I https://example.com/` | `[TEST] curl -I https://example.com/` | Vor dem Verbindungsversuch dokumentieren: - lokale IP-Adresse, - Standardgateway, - verwendete Schnittstelle, - DNS-Server, - Proxykonfiguration, - öffentliche Quelladresse, - Datum und Uhrzeit. Ein Captive Portal in einem Hotel-, Bahn- oder Gastnetz kann den VPN-Aufbau verhindern, obwohl eine WLAN-Verbindung angezeigt wird.
---
7. VPN-Gateway auflösen und Transportweg prüfen **Namensauflösung:** Windows: ```powershell [TEST] Resolve-DnsName vpn.example.net ``` Linux: ```bash [TEST] getent ahosts vpn.example.net ``` macOS: ```bash [TEST] dscacheutil -q host -a name vpn.example.net ``` **Route zum Gateway prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress VPN_GATEWAY_IP ``` Linux: ```bash [RO] ip route get VPN_GATEWAY_IP ``` macOS: ```bash [RO] route -n get VPN_GATEWAY_IP ``` **TCP-basierten Gatewayport prüfen:** Windows: ```powershell [TEST] Test-NetConnection vpn.example.net -Port 443 -InformationLevel Detailed ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 vpn.example.net 443 ``` Ein erfolgreicher TCP-Porttest gilt nur für TCP. Er prüft keine UDP-basierten IKEv2-, OpenVPN- oder WireGuard-Verbindungen.
---
8. Windows-VPN-Profile und Status prüfen **VPN-Profile des aktuellen Benutzers:** ```powershell [RO][SENS] Get-VpnConnection ``` **Geräteweite VPN-Profile:** ```powershell [RO][PRIV][SENS] Get-VpnConnection -AllUserConnection ``` **Ausführliche Darstellung:** ```powershell [RO][SENS] Get-VpnConnection | Format-List * ``` **Klassische Anzeige aktiver RAS-Verbindungen:** ```cmd [RO] rasdial ``` **Netzwerkadapter einschließlich virtueller Adapter:** ```powershell [RO] Get-NetAdapter -IncludeHidden | Sort-Object Status, Name | Format-Table Name, InterfaceDescription, Status, LinkSpeed ``` **IP-Konfiguration aller Schnittstellen:** ```powershell [RO][SENS] Get-NetIPConfiguration -All ``` Zu kontrollieren sind: - Name des VPN-Profils, - Tunneltyp, - Serveradresse, - Verbindungsstatus, - Authentifizierungsverfahren, - Split-Tunneling-Einstellung, - Routingrichtlinien, - Benutzer- oder Geräteprofil, - verwendeter virtueller Adapter. `Get-VpnConnection` zeigt nur VPN-Profile, die über die entsprechenden Windows-VPN-Komponenten verwaltet werden. Herstellerclients können eigene Konfigurationen und Diagnosewerkzeuge verwenden.
---
9. Windows-Routen vor und nach dem VPN vergleichen **Routingtabelle:** ```powershell [RO] Get-NetRoute | Sort-Object AddressFamily, DestinationPrefix, RouteMetric | Format-Table AddressFamily, DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ``` **IPv4-Routingtabelle klassisch:** ```cmd [RO] route print -4 ``` **IPv6-Routingtabelle:** ```cmd [RO] route print -6 ``` **Route zu einem internen Ziel bestimmen:** ```powershell [RO] Find-NetRoute -RemoteIPAddress 10.20.30.40 ``` Besonders relevant: ```text DestinationPrefix NextHop InterfaceAlias RouteMetric InterfaceMetric ``` **Vergleichsablauf:** 1. Routingtabelle ohne VPN erfassen. 2. VPN verbinden. 3. Routingtabelle erneut erfassen. 4. Neue und veränderte Routen vergleichen. 5. Route zum betroffenen internen Ziel bestimmen. 6. Prüfen, ob die Route über den VPN-Adapter führt. Eine vorhandene Route beweist noch nicht, dass die VPN-Gegenstelle den Verkehr erlaubt oder korrekt zurückleitet.
---
10. Windows-VPN-Ereignisprotokolle prüfen **Vorhandene VPN- und RAS-Protokolle ermitteln:** ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *Ras* | Select-Object LogName, IsEnabled, RecordCount ``` ```powershell [RO][PRIV][SENS] Get-WinEvent -ListLog *VPN* | Select-Object LogName, IsEnabled, RecordCount ``` **RasClient-Protokoll abfragen, sofern vorhanden:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-RasClient/Operational" ` -MaxEvents 100 ``` **Zeitlich begrenzen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -FilterHashtable @{ LogName = "Microsoft-Windows-RasClient/Operational" StartTime = (Get-Date).AddMinutes(-30) } ``` Zusätzlich können abhängig vom VPN-Typ Protokolle zu folgenden Komponenten relevant sein: - IKE, - IPsec, - EAP, - Zertifikate, - NPS, - Geräteverwaltung, - Hersteller-VPN-Client. Nicht jede Umgebung aktiviert alle Diagnoseprotokolle standardmäßig.
---
11. Windows-IPsec-Sicherheitszuordnungen prüfen Bei IPsec-basierten Verbindungen können Security Associations wichtige Informationen liefern. **Main-Mode-Sicherheitszuordnungen:** ```powershell [RO][PRIV][SENS] Get-NetIPsecMainModeSA ``` **Quick-Mode-Sicherheitszuordnungen:** ```powershell [RO][PRIV][SENS] Get-NetIPsecQuickModeSA ``` **Main-Mode-Regeln:** ```powershell [RO][PRIV][SENS] Get-NetIPsecMainModeRule ``` **Verbindungs-Sicherheitsregeln:** ```powershell [RO][PRIV][SENS] Get-NetIPsecRule ``` Zu prüfen sind: - lokale und entfernte Adresse, - Authentifizierungsverfahren, - Verschlüsselungs- und Integritätsverfahren, - Status der Security Association, - Lebensdauer, - verwendete Richtlinie. Leere Ausgaben können bedeuten, dass keine entsprechende aktive IPsec-Sicherheitszuordnung existiert oder dass der eingesetzte VPN-Client nicht über diese Windows-Komponenten arbeitet.
---
12. Linux: Tunnel, Verbindungen und Schnittstellen prüfen **Aktive NetworkManager-Verbindungen:** ```bash [RO][SENS] nmcli connection show --active ``` **Gerätestatus:** ```bash [RO] nmcli device status ``` **Alle Schnittstellen:** ```bash [RO] ip -br link ``` **IP-Adressen:** ```bash [RO][SENS] ip -br address ``` **Routingtabelle:** ```bash [RO] ip route show ``` **IPv6-Routingtabelle:** ```bash [RO] ip -6 route show ``` **Policy-Routingregeln:** ```bash [RO] ip rule show ``` **Alle Routingtabellen:** ```bash [RO][SENS] ip route show table all ``` Mögliche Tunnelschnittstellen tragen abhängig von Technik und Hersteller Namen wie: ```text tun0 tap0 wg0 ppp0 ipsec0 Herstellerspezifischer Name ``` Der Name allein bestätigt nicht, dass der Tunnel vollständig funktionsfähig ist.
---
13. Linux-Protokolle prüfen **NetworkManager-Protokolle:** ```bash [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" ``` **Aktuelle Kernelmeldungen zu Netzwerkproblemen:** ```bash [RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes" ``` **Vorhandene VPN-Dienste suchen:** ```bash [RO] systemctl list-units --type=service | grep -Ei 'openvpn|wireguard|strongswan|ipsec|vpn' ``` **Protokoll eines konkret ermittelten Dienstes:** ```bash [RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_DIENSTNAME \ --since "-30 minutes" ``` Der Unit-Name muss vorher ermittelt werden. Namen wie `openvpn.service` oder `openvpn-client@NAME.service` dürfen nicht ohne Prüfung angenommen werden.
---
14. macOS: VPN-Status und virtuelle Schnittstellen prüfen **VPN-Konfigurationen anzeigen:** ```bash [RO][SENS] scutil --nc list ``` **Status einer bekannten VPN-Konfiguration:** ```bash [RO][SENS] scutil --nc status "VPN-DIENSTNAME" ``` **Alle Schnittstellen anzeigen:** ```bash [RO][SENS] ifconfig ``` **Routingtabelle:** ```bash [RO] netstat -rn ``` **Standardroute:** ```bash [RO] route -n get default ``` **Route zu einem internen Ziel:** ```bash [RO] route -n get 10.20.30.40 ``` **DNS-Konfiguration:** ```bash [RO][SENS] scutil --dns ``` **Proxykonfiguration:** ```bash [RO][SENS] scutil --proxy ``` Viele Hersteller-VPN-Clients verwalten Tunnel und Filter über System Extensions oder Network Extensions. Ihre vollständige Konfiguration ist nicht zwingend über `networksetup` oder `scutil --nc` sichtbar.
---
15. WireGuard-Verbindungen prüfen Die folgenden Befehle gelten nur, wenn WireGuard eingesetzt wird und die Werkzeuge installiert sind. **WireGuard-Status:** ```bash [RO][PRIV][SENS] sudo wg show ``` Typische Angaben: ```text interface public key listening port peer endpoint allowed ips latest handshake transfer persistent keepalive ``` **Bestimmte Schnittstelle:** ```bash [RO][PRIV][SENS] sudo wg show wg0 ``` **Routing und Adresse der Schnittstelle:** ```bash [RO] ip address show dev wg0 ``` ```bash [RO] ip route show ``` Besonders relevant: | Feld | Diagnose | |---|---| | `latest handshake` | Fand kürzlich ein Handshake statt? | | `transfer` | Steigen gesendete und empfangene Datenmengen? | | `endpoint` | Wird die erwartete Gegenstellenadresse verwendet? | | `allowed ips` | Welche Zielnetze werden diesem Peer zugeordnet? | | `persistent keepalive` | Ist bei NAT-Szenarien ein Keepalive konfiguriert? | **Typische Muster:** | Beobachtung | Mögliche Bedeutung | |---|---| | Kein aktueller Handshake | Endpoint, UDP-Port, Schlüssel, Firewall oder Gegenstelle prüfen | | Gesendet steigt, empfangen nicht | Rückweg, Peer-Konfiguration oder Firewall prüfen | | Handshake aktuell, internes Ziel nicht erreichbar | Routen, AllowedIPs, Forwarding und Zielnetz prüfen | | Nur nach Datenverkehr Handshake sichtbar | Kann je nach Nutzung normal sein | | Tunnel funktioniert nur kurz | NAT-Zustand, Keepalive oder Netzwechsel prüfen | Konfigurationsausgaben, die private oder vorab geteilte Schlüssel enthalten könnten, dürfen nicht veröffentlicht werden.
---
16. OpenVPN-Verbindungen prüfen Die folgenden Prüfungen gelten nur, wenn OpenVPN eingesetzt wird. **Installierte Version:** ```bash [RO] openvpn --version ``` **Laufenden Prozess suchen:** ```bash [RO][SENS] ps aux | grep '[o]penvpn' ``` **Ermittelte systemd-Dienste prüfen:** ```bash [RO] systemctl list-units --type=service | grep -i openvpn ``` **Protokoll eines konkret ermittelten Dienstes:** ```bash [RO][PRIV][SENS] sudo journalctl -u TATSAECHLICHER_OPENVPN_DIENST \ --since "-30 minutes" ``` Typische Meldungsgruppen: | Meldung | Mögliche Bedeutung | |---|---| | TLS handshake failed | Zertifikat, Uhrzeit, Transport oder Gegenstelle prüfen | | AUTH_FAILED | Benutzeranmeldung, MFA oder Kontostatus prüfen | | Cannot resolve host address | DNS-Auflösung des Gateways fehlgeschlagen | | Connection timed out | Transportweg, Firewall oder Gateway prüfen | | Inactivity timeout | Kein ausreichender Datenverkehr oder Gegenstelle nicht erreichbar | | Route addition failed | Rechte, Routenkonflikt oder Plattformproblem | | TUN/TAP device error | Virtueller Adapter oder Berechtigung fehlerhaft | | Initialization Sequence Completed | Tunnelinitialisierung wurde abgeschlossen | Die exakte Formulierung hängt von OpenVPN-Version, Plattform und Verwaltungslösung ab.
---
17. VPN-Adressierung prüfen Nach erfolgreichem Aufbau erhält der Client abhängig vom VPN eine Adresse auf einer virtuellen Schnittstelle. **Windows:** ```powershell [RO][SENS] Get-NetIPAddress | Sort-Object InterfaceAlias, AddressFamily | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength, AddressState ``` **Linux:** ```bash [RO][SENS] ip -br address ``` **macOS:** ```bash [RO][SENS] ifconfig ``` Zu kontrollieren sind: - Existiert eine Tunneladresse? - Stammt sie aus dem erwarteten Adressbereich? - Ist die Präfixlänge korrekt? - Existiert ein Adresskonflikt? - Überschneidet sich das VPN-Netz mit dem lokalen Netz? - Wird IPv4, IPv6 oder beides bereitgestellt? - Ist die Adresse nur temporär oder instabil? - Verwendet der Server die richtige Rückroute zum VPN-Adresspool?
---
18. Überschneidende lokale und entfernte Netze erkennen Ein häufiges Remote-Access-Problem entsteht, wenn das lokale Netz denselben Adressbereich wie das entfernte Unternehmensnetz verwendet. **Beispiel:** ```text Lokales Heimnetz: 192.168.1.0/24 Entferntes Firmennetz: 192.168.1.0/24 ``` Der Client kann dann nicht allein anhand der Zieladresse eindeutig entscheiden, ob das Ziel lokal oder über das VPN erreichbar ist. **Route zum Ziel prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` Linux: ```bash [RO] ip route get 192.168.1.50 ``` macOS: ```bash [RO] route -n get 192.168.1.50 ``` **Mögliche Lösungen im Netzdesign:** - lokale oder entfernte Netze neu adressieren, - spezifischere VPN-Routen verwenden, - NAT im VPN-Konzept einsetzen, - alternative interne Adressen bereitstellen, - virtualisierte oder anwendungsbasierte Zugänge verwenden. Eine manuell gesetzte Einzelroute ist höchstens eine kontrollierte Zwischenlösung und kann andere lokale Ziele unerreichbar machen.
---
19. Split Tunnel und Full Tunnel prüfen **Full Tunnel:** ```text Interne Ziele → VPN Internetverkehr → VPN ``` **Split Tunnel:** ```text Interne Ziele → VPN Internetverkehr → lokale Verbindung ``` **Windows-Profil prüfen:** ```powershell [RO][SENS] Get-VpnConnection | Select-Object Name, ConnectionStatus, SplitTunneling, TunnelType, ServerAddress ``` **Standardrouten unter Windows:** ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Format-Table InterfaceAlias, NextHop, RouteMetric ``` **Linux:** ```bash [RO] ip route show [RO] ip rule show ``` **macOS:** ```bash [RO] netstat -rn ``` Zu prüfen sind: - Existiert eine Standardroute über das VPN? - Werden nur bestimmte interne Präfixe verteilt? - Fehlt das Netz des betroffenen Dienstes? - Existieren mehrere gleichwertige Routen? - Wird Policy Routing verwendet? - Überschreibt der VPN-Client lokale Routen? - Bleibt der direkte Internetzugang laut Sollzustand erhalten? Split Tunneling ist eine Sicherheits- und Architekturentscheidung und darf nicht eigenmächtig aktiviert oder deaktiviert werden.
---
20. Route zu einem betroffenen Ziel eindeutig bestimmen **Windows:** ```powershell [RO] Find-NetRoute -RemoteIPAddress 10.20.30.40 ``` **Linux:** ```bash [RO] ip route get 10.20.30.40 ``` **macOS:** ```bash [RO] route -n get 10.20.30.40 ``` Zu dokumentieren sind: ```text Zieladresse verwendete Schnittstelle nächster Hop Quelladresse Routenpräfix Metrik ``` **Typische Diagnose:** ```text Tunnel ist verbunden ↓ Route zum Ziel zeigt auf WLAN statt VPN ↓ Benötigte VPN-Route fehlt oder wird durch spezifischere Route verdrängt ``` Die längste passende Präfixroute ist grundsätzlich besonders relevant. Eine spezifischere Route kann eine weniger spezifische VPN-Standardroute übersteuern.
---
21. Interne DNS-Auflösung über VPN prüfen **Windows-DNS-Server pro Schnittstelle:** ```powershell [RO][SENS] Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses ``` **Windows-Suffixe:** ```powershell [RO] Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, RegisterThisConnectionsAddress ``` **Linux:** ```bash [RO][SENS] resolvectl status ``` **macOS:** ```bash [RO][SENS] scutil --dns ``` **Internen Namen über den vorgesehenen DNS-Server prüfen:** Windows: ```powershell [TEST] Resolve-DnsName server.example.internal ` -Server 10.20.0.53 ``` Linux und macOS: ```bash [TEST] dig @10.20.0.53 server.example.internal A ``` **IP-Adresse und Hostname getrennt testen:** ```text Zugriff über interne IP funktioniert Zugriff über internen Hostnamen funktioniert nicht ``` Das deutet eher auf DNS, Suchsuffixe oder Namensrichtlinien als auf einen allgemeinen Tunnelfehler hin.
---
22. Split DNS und DNS-Leaks beurteilen Bei Split DNS sollen bestimmte interne Namensräume über interne DNS-Server und andere Namen über lokale oder öffentliche Resolver aufgelöst werden. Beispiel: ```text *.example.internal → interner DNS-Server über VPN andere Namen → lokaler oder definierter externer DNS-Server ``` Mögliche Fehler: - interne Zone wird an öffentlichen DNS-Server gesendet, - interner DNS-Server ist nicht über den Tunnel erreichbar, - Suchsuffix fehlt, - lokale Schnittstelle besitzt eine höhere DNS-Priorität, - VPN-Client setzt DNS nur für IPv4, - Browser verwendet DNS over HTTPS unabhängig vom Betriebssystem, - ein lokaler Filter oder Proxy verändert die Namensauflösung. **Vergleichstest:** ```bash [TEST] dig server.example.internal ``` ```bash [TEST] dig @10.20.0.53 server.example.internal ``` Unterschiedliche Antworten zeigen, dass Resolverauswahl, Cache oder Split-DNS-Regeln weiter untersucht werden müssen.
---
23. Authentifizierung, Zertifikate und Uhrzeit prüfen Mögliche Authentifizierungsbestandteile: - Benutzername und Passwort, - Multifaktor-Authentifizierung, - Clientzertifikat, - Gerätezertifikat, - Pre-Shared Key, - Smartcard, - Geräteidentität, - SAML- oder Browseranmeldung, - Kerberos oder EAP. **Systemzeit prüfen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | **Zeitsynchronisation:** Windows: ```powershell [RO] w32tm /query /status ``` Linux: ```bash [RO] timedatectl status ``` macOS: ```bash [RO] systemsetup -getusingnetworktime ``` Für den macOS-Befehl können erhöhte Rechte erforderlich sein: ```bash [RO][PRIV] sudo systemsetup -getusingnetworktime ``` Zu prüfen sind: - Zertifikat noch gültig? - Zertifikat bereits gültig? - Richtiger Aussteller? - Private-Key-Zugriff vorhanden? - Servername passt zum Zertifikat? - Zertifikat wurde widerrufen? - Benutzerkonto gesperrt? - Passwort abgelaufen? - MFA vollständig bestätigt? - Gerätekonformität erfüllt? - Systemzeit korrekt? Private Schlüssel dürfen niemals mit Diagnoseausgaben exportiert werden.
---
24. MTU- und Fragmentierungsprobleme erkennen VPN-Protokolle fügen zusätzliche Header hinzu. Dadurch sinkt die nutzbare Paketgröße innerhalb des Tunnels. **Typische Symptome:** - Tunnel verbindet sich erfolgreich. - Ping mit kleinen Paketen funktioniert. - Webseiten laden nur teilweise. - Dateiübertragungen bleiben hängen. - RDP oder SSH friert sporadisch ein. - Kleine API-Anfragen funktionieren, große nicht. - TLS-Handshake bleibt stehen. - Bestimmte Netze oder Provider sind betroffen. **Windows – IPv4-Paket mit gesetztem Don't-Fragment-Bit:** ```cmd [TEST] ping -4 -f -l 1400 10.20.30.40 ``` **Linux:** ```bash [TEST] ping -4 -M do -s 1400 10.20.30.40 ``` **macOS:** ```bash [TEST] ping -D -s 1400 10.20.30.40 ``` Die angegebene Nutzdatenlänge ist nicht identisch mit der gesamten IP-Paketgröße. Bei IPv4 kommen üblicherweise mindestens IP- und ICMP-Header hinzu. **Schnittstellen-MTU anzeigen:** Windows: ```powershell [RO] Get-NetIPInterface | Format-Table InterfaceAlias, AddressFamily, NlMtu, InterfaceMetric ``` Linux: ```bash [RO] ip link show ``` macOS: ```bash [RO] ifconfig ``` Die MTU darf nicht ohne Messung und Freigabe verändert werden. Eine zu kleine MTU kann Leistung reduzieren; eine zu große MTU kann Fragmentierungs- oder Black-Hole-Probleme verursachen.
---
25. Path-MTU-Discovery und ICMP berücksichtigen Path-MTU-Discovery benötigt bestimmte ICMP- beziehungsweise ICMPv6-Rückmeldungen. Wichtige Meldungen: - IPv4: Fragmentierung erforderlich - IPv6: Packet Too Big Werden diese Meldungen blockiert, kann ein Path-MTU-Black-Hole entstehen: ```text Kleine Pakete funktionieren ↓ Großes Paket überschreitet Pfad-MTU ↓ Router kann oder darf nicht fragmentieren ↓ ICMP-Fehlermeldung wird blockiert ↓ Sender erfährt die zulässige Größe nicht ↓ Übertragung bleibt hängen ``` **Paketmitschnittfilter:** ```text icmp icmpv6 ``` ICMP und ICMPv6 dürfen nicht pauschal als unnötig betrachtet oder vollständig blockiert werden.
---
26. Lokale Firewall und VPN-Kill-Switch prüfen Ein VPN-Client kann zusätzliche Filterregeln installieren, um Verkehr außerhalb des Tunnels zu verhindern. Mögliche Funktionen: - Kill Switch, - Always-On, - Lockdown Mode, - Blockierung lokaler Netze, - Blockierung unverschlüsselten DNS-Verkehrs, - anwendungsbasierte Filterung, - Gerätetunnelrichtlinien, - Filter über System- oder Network Extensions. **Typische Fehlerbilder:** - Nach VPN-Abbruch funktioniert kein Netzwerk mehr. - Lokale Drucker sind während des VPNs nicht erreichbar. - Internet funktioniert nur bei aktivem VPN. - DNS bleibt nach dem Trennen fehlerhaft. - Filterregeln bleiben nach Clientabsturz aktiv. - Herstellerclient zeigt getrennt, Filterkomponente arbeitet aber weiter. Zu prüfen sind: - native Host-Firewall, - Regeln des VPN-Clients, - Sicherheitssoftware, - Filtertreiber beziehungsweise System Extensions, - Proxykonfiguration, - DNS-Konfiguration, - Standardrouten. Kill-Switch- oder Sicherheitsfunktionen dürfen nicht ohne Freigabe deaktiviert werden.
---
27. Lokale Netzwerkzugriffe während des VPNs prüfen Ein VPN kann Zugriffe auf lokale Netze absichtlich unterbinden. Betroffene Beispiele: - lokale Drucker, - NAS-Systeme, - Routeroberfläche, - lokale Entwicklungsserver, - Smartcard- oder Lizenzserver, - Geräte im gleichen WLAN. **Route zum lokalen Ziel prüfen:** Windows: ```powershell [RO] Find-NetRoute -RemoteIPAddress 192.168.1.50 ``` Linux: ```bash [RO] ip route get 192.168.1.50 ``` macOS: ```bash [RO] route -n get 192.168.1.50 ``` Mögliche Ursachen: - Full Tunnel erfasst auch lokale Netze, - Sicherheitsrichtlinie blockiert LAN-Zugriff, - lokales und entferntes Netz überschneiden sich, - VPN-Client setzt spezifische Blockierungsrouten, - Host-Firewall behandelt den VPN-Adapter anders, - lokales Ziel antwortet nicht auf die VPN-Quelladresse. Lokalen LAN-Zugriff während des VPNs zu erlauben ist eine Sicherheitsentscheidung und keine rein technische Komforteinstellung.
---
28. VPN über restriktive Netze prüfen Hotels, Gast-WLANs, Mobilfunkanbieter und Unternehmensnetze können bestimmte VPN-Protokolle einschränken. **Vergleichstest:** ```text VPN über Firmennetz fehlerhaft VPN über Mobilfunk erfolgreich ``` Das deutet auf einen Unterschied im Zugangsnetz hin, beispielsweise: - UDP wird blockiert, - IPsec ESP wird blockiert, - NAT-T wird fehlerhaft behandelt, - Captive Portal ist noch nicht bestätigt, - TCP 443 ist nur über einen Proxy erlaubt, - DNS-Antwort wird verändert, - IPv6- und IPv4-Pfade unterscheiden sich, - Provider verwendet problematisches NAT. **Öffentliche Quelladresse vergleichen:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` Die Nutzung eines externen Dienstes muss durch die betrieblichen Richtlinien erlaubt sein.
---
29. Stabilität und wiederkehrende Abbrüche untersuchen Bei sporadischen Abbrüchen dokumentieren: - exakten Zeitpunkt, - Dauer bis zum Abbruch, - Wechsel zwischen WLAN und Mobilfunk, - Standby oder Bildschirmruhe, - DHCP-Erneuerung, - Änderung der öffentlichen Adresse, - MFA- oder Sitzungslaufzeit, - Rekey- beziehungsweise SA-Lebensdauer, - NAT-Timeout, - Paketverlust, - Wechsel des Access Points, - Energiesparzustand, - parallelen VPN-Client, - Anzahl gleichzeitiger Sitzungen. **Kontinuierlicher Test zu einem internen Ziel:** Windows: ```powershell [TEST] ping -t 10.20.30.40 ``` Linux: ```bash [TEST] ping 10.20.30.40 ``` macOS: ```bash [TEST] ping 10.20.30.40 ``` Zusätzlich sollte ein Ziel außerhalb des VPNs getestet werden, um zwischen Verlust der Basisverbindung und Verlust des Tunnels zu unterscheiden. **Windows – zeitlich begrenzte PowerShell-Ausgabe:** ```powershell [TEST] Test-Connection 10.20.30.40 -Count 20 ``` Ping kann durch Richtlinien blockiert sein. Ein fehlender Ping ist deshalb kein alleiniger Nachweis eines Tunnelausfalls.
---
30. Anwendung statt nur Ping testen Nach Routing- und DNS-Prüfung muss der benötigte Dienst getestet werden. | Dienst | Beispiel | |---|---| | HTTPS | `[TEST] curl -v https://service.example.internal/` | | TCP-Port | `[TEST] Test-NetConnection HOST -Port PORT` | | SSH | `[TEST] ssh -vvv user@HOST` | | DNS | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER` | | SMB | Unter Windows: `[TEST] Test-NetConnection HOST -Port 445` | | RDP | Unter Windows: `[TEST] Test-NetConnection HOST -Port 3389` | **Linux und macOS – TCP-Port:** ```bash [TEST] nc -vz -w 5 HOST PORT ``` **Reihenfolge:** ```text Tunnelstatus → Route → DNS → Port → Anwendungsprotokoll → Authentifizierung ``` Ein erfolgreicher VPN-Aufbau beweist nicht, dass eine Zugriffsrichtlinie den jeweiligen Anwendungsdienst erlaubt.
---
31. Paketmitschnitt für VPN-Fehler erstellen Es können zwei Datenebenen betrachtet werden: ```text Äußerer Verkehr: Client ↔ VPN-Gateway Innerer Verkehr: Tunneladresse ↔ internes Ziel ``` **Linux – äußerer Verkehr zum VPN-Gateway:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i PHYSISCHE_SCHNITTSTELLE -nn \ 'host VPN_GATEWAY_IP' \ -w vpn-outer.pcap ``` **Linux – innerer Verkehr auf einer Tunnelschnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \ 'host INTERNES_ZIEL' \ -w vpn-inner.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host VPN_GATEWAY_IP' \ -w vpn-test.pcap ``` **Windows – Schnittstellen mit Dumpcap anzeigen:** ```powershell [RO] dumpcap -D ``` **Windows – Mitschnitt:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host VPN_GATEWAY_IP" ` -w vpn-test.pcapng ``` Die Schnittstellen müssen vorher eindeutig ermittelt werden.
---
32. Wireshark-Filter für VPN-Diagnosen | Aufgabe | Anzeigefilter | |---|---| | IKE | `isakmp` | | UDP 500 | `udp.port == 500` | | NAT-T über UDP 4500 | `udp.port == 4500` | | ESP | `esp` | | AH | `ah` | | OpenVPN auf Standardport | `udp.port == 1194 || tcp.port == 1194` | | WireGuard auf häufigem Port | `udp.port == 51820` | | SSTP-Verkehr | `tcp.port == 443` | | DNS | `dns` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | TCP-Reset | `tcp.flags.reset == 1` | | Wiederholte TCP-Pakete | `tcp.analysis.retransmission` | Die tatsächlichen Ports können abweichen und müssen aus der Konfiguration übernommen werden. Verschlüsselter VPN-Verkehr zeigt im äußeren Mitschnitt normalerweise nicht die ursprünglichen Anwendungsdaten.
---
33. Paketmuster interpretieren | Beobachtung | Mögliche Interpretation | |---|---| | Keine Pakete zum VPN-Gateway | DNS, Route, Anwendung oder lokaler Filter prüfen | | Ausgehende Pakete, keine Antwort | Gateway, Firewall, Provider, NAT oder Rückweg prüfen | | IKE-Austausch beginnt und endet | Authentifizierung, Richtlinie oder Verfahren prüfen | | Tunnelhandshake erfolgreich | Transport und kryptografischer Aufbau funktionieren grundsätzlich | | Tunnelverkehr wird gesendet, nichts empfangen | Gegenstelle, Rückroute oder Filter prüfen | | Inneres Paket verlässt Tunnel, keine Antwort | Zielnetz, Zielhost oder serverseitige Route prüfen | | Antworten kommen im Tunnel an, Anwendung erhält sie nicht | Lokale Firewall, Route oder Anwendung prüfen | | Kleine Pakete funktionieren, große nicht | MTU und Path-MTU-Discovery prüfen | | Häufige Neuverbindungen | Basisnetz, Rekey, NAT-Timeout oder Clientstabilität prüfen | Ein einseitiger Paketmitschnitt zeigt nur den jeweiligen Messpunkt. Bei komplexen Fehlern sollten Client, VPN-Gateway und internes Ziel zeitgleich betrachtet werden.
---
34. Typische Fehlerbilder systematisch eingrenzen **Fall A – VPN-Gatewayname wird nicht aufgelöst** Prüfen: - DNS-Server vor dem VPN, - Gatewayhostname, - Suchsuffix, - Captive Portal, - Proxy, - IPv4- und IPv6-Antworten. --- **Fall B – Authentifizierung schlägt fehl** Prüfen: - Benutzerkonto, - Passwortablauf, - MFA, - Zertifikat, - Systemzeit, - Geräteidentität, - Kontosperre, - Richtlinie, - maximal zulässige Sitzungen. --- **Fall C – VPN verbunden, keine internen Ziele erreichbar** Prüfen: - Tunneladresse, - Routen, - Split Tunnel, - Netzüberlappung, - lokale Firewall, - zentrale VPN-Richtlinie, - serverseitige Rückroute, - DNS. --- **Fall D – Interne IP funktioniert, Hostname nicht** Prüfen: - interne DNS-Server, - DNS-Suffix, - Split DNS, - DNS-Priorität, - DNS over HTTPS, - VPN-DNS-Richtlinie. --- **Fall E – Nur ein internes Netz ist nicht erreichbar** Prüfen: - fehlende Route, - falsches Präfix, - Access Control, - Rückroute, - Firewall zwischen VPN-Pool und Zielnetz, - überlappende Netze. --- **Fall F – VPN funktioniert über Mobilfunk, aber nicht über WLAN** Prüfen: - Captive Portal, - UDP-Blockierung, - lokales NAT, - Router-Firewall, - DNS-Manipulation, - IPsec-Passthrough, - IPv4-/IPv6-Unterschiede. --- **Fall G – Verbindung bricht bei großen Übertragungen ab** Prüfen: - MTU, - ICMP-Blockierung, - Paketverlust, - Time-outs, - Rekey, - Überlastung, - instabile Basisverbindung. --- **Fall H – Nach dem Trennen funktioniert das Internet nicht** Prüfen: - Standardroute, - DNS-Server, - Proxy, - Kill Switch, - Firewallfilter, - virtuellen Adapter, - fehlerhaft beendeten Herstellerclient.
---
35. VPN-Serverseite mit einbeziehen Die Clientdiagnose allein reicht nicht immer aus. Auf der Serverseite sind zu prüfen: - erreicht der Verbindungsversuch das Gateway, - wird die Authentifizierung akzeptiert, - wird eine Tunneladresse vergeben, - wird das richtige Benutzer- oder Geräteprofil angewendet, - werden die vorgesehenen Routen verteilt, - werden DNS-Server und Suffixe verteilt, - greift eine Zugriffsrichtlinie, - existiert eine Route zum VPN-Clientpool, - kennt das interne Netz den Rückweg, - arbeitet NAT wie vorgesehen, - ist der Adresspool erschöpft, - wird eine maximale Sitzungszahl erreicht, - sind Zertifikate gültig, - sind Zeit und Zeitzone synchron, - treten Rekey- oder SA-Fehler auf, - ist der Gateway-Cluster vollständig verfügbar. Client- und Serverprotokolle müssen anhand von Benutzer, Tunneladresse und Zeitstempel zugeordnet werden.
---
36. Keine vorschnellen VPN-Änderungen durchführen Nicht unkontrolliert: - VPN-Profil löschen, - Zertifikate entfernen, - private Schlüssel exportieren, - Split Tunneling aktivieren, - Kill Switch deaktivieren, - Firewall ausschalten, - MTU beliebig verändern, - manuelle Standardroute hinzufügen, - DNS-Server dauerhaft überschreiben, - VPN-Client neu installieren, - Security Associations oder Zustandstabellen leeren, - mehrere VPN-Clients gleichzeitig starten. **Sicherer Ablauf:** 1. Istzustand dokumentieren. 2. Client- und Profilversion feststellen. 3. Fehler reproduzieren. 4. Basisnetz und Gatewaytransport prüfen. 5. Tunnelstatus, Adresse, Route und DNS prüfen. 6. Client- und Serverprotokolle vergleichen. 7. Ursache nachweisen. 8. Änderung genehmigen lassen. 9. Kleinste erforderliche Korrektur durchführen. 10. Tunnelaufbau und Zielanwendung erneut testen. 11. Rückfallmöglichkeit und Ergebnis dokumentieren.
---
37. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Störungsumfang bestimmen | Benutzer, Gerät, Standort oder allgemeine Störung? | | 2 | Basisverbindung prüfen | Funktioniert das Netz ohne VPN? | | 3 | Captive Portal ausschließen | Ist der Internetzugang vollständig freigeschaltet? | | 4 | Gateway auflösen | Wird die richtige VPN-Adresse verwendet? | | 5 | Route zum Gateway prüfen | Läuft der äußere Verkehr über die Basisschnittstelle? | | 6 | Transport prüfen | Erreichen benötigte Ports und Protokolle das Gateway? | | 7 | Authentifizierung prüfen | Werden Konto, MFA und Zertifikat akzeptiert? | | 8 | Tunnelstatus prüfen | Wurde der Tunnel tatsächlich aufgebaut? | | 9 | Tunneladresse prüfen | Hat der Client die vorgesehene Adresse erhalten? | | 10 | Routen vergleichen | Werden die Zielnetze durch den Tunnel geleitet? | | 11 | Netzüberlappungen prüfen | Konfligiert das lokale Netz mit dem Zielnetz? | | 12 | DNS prüfen | Werden interne Namen über richtige Resolver aufgelöst? | | 13 | Zielport testen | Ist der benötigte Dienst transportseitig erreichbar? | | 14 | Anwendung testen | Funktioniert das eigentliche Protokoll? | | 15 | MTU prüfen | Scheitern nur größere Pakete oder Übertragungen? | | 16 | Stabilität beobachten | Wann und unter welchen Bedingungen bricht der Tunnel ab? | | 17 | Protokolle vergleichen | Welche Seite beendet oder verweigert die Verbindung? | | 18 | Paketmitschnitt erstellen | Wo endet der erfolgreiche Datenfluss? | | 19 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 20 | Nachprüfung | Funktionieren Tunnel, DNS, Routing und Anwendung? |
---
38. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | VPN-Profile | `[RO][SENS] Get-VpnConnection` | `[RO][SENS] nmcli connection show` | `[RO][SENS] scutil --nc list` | | Geräteweite Profile | `[RO][PRIV][SENS] Get-VpnConnection -AllUserConnection` | Abhängig vom VPN-Client | Abhängig von MDM und VPN-Client | | Aktiver VPN-Status | `[RO] rasdial` | `[RO][SENS] nmcli connection show --active` | `[RO][SENS] scutil --nc status "VPN-NAME"` | | Schnittstellen | `[RO] Get-NetAdapter -IncludeHidden` | `[RO] ip -br link` | `[RO] ifconfig` | | IP-Adressen | `[RO][SENS] Get-NetIPAddress` | `[RO][SENS] ip -br address` | `[RO][SENS] ifconfig` | | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | DNS-Konfiguration | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | Gateway auflösen | `[TEST] Resolve-DnsName VPN_HOST` | `[TEST] getent ahosts VPN_HOST` | `[TEST] dscacheutil -q host -a name VPN_HOST` | | TCP-Gatewayport | `[TEST] Test-NetConnection VPN_HOST -Port PORT` | `[TEST] nc -vz -w 5 VPN_HOST PORT` | `[TEST] nc -vz -w 5 VPN_HOST PORT` | | Internen Port testen | `[TEST] Test-NetConnection INTERNER_HOST -Port PORT` | `[TEST] nc -vz -w 5 INTERNER_HOST PORT` | `[TEST] nc -vz -w 5 INTERNER_HOST PORT` | | MTU anzeigen | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | DF-Test | `[TEST] ping -4 -f -l 1400 IP` | `[TEST] ping -4 -M do -s 1400 IP` | `[TEST] ping -D -s 1400 IP` | | WireGuard | Falls installiert: `[RO][PRIV][SENS] wg show` | `[RO][PRIV][SENS] sudo wg show` | Falls installiert: `[RO][PRIV][SENS] sudo wg show` | | NetworkManager-Protokoll | Nicht zutreffend | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"` | Nicht zutreffend | | RAS-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational"` | Nicht zutreffend | Nicht zutreffend | `VPN-NAME`, `IP`, `VPN_HOST`, `PORT` und `INTERNER_HOST` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
39. Dokumentationsvorlage für VPN-Fehler ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Gerät: Betriebssystem: VPN-Client: VPN-Clientversion: VPN-Profil: VPN-Technik: Zugangsnetz: Zugangsart: LAN / WLAN / Mobilfunk Lokale IP-Adresse: Standardgateway: Öffentliche IP-Adresse: Captive Portal ausgeschlossen: Proxy vorhanden: VPN-Gatewayname: Aufgelöste Gatewayadresse: Verwendete Adressfamilie: Gatewayport beziehungsweise IP-Protokoll: Route zum Gateway: Transporttest: Authentifizierungsverfahren: MFA: Zertifikat geprüft: Systemzeit geprüft: Tunnelstatus: Tunneladresse: Virtuelle Schnittstelle: Split Tunnel oder Full Tunnel: Verteilte IPv4-Routen: Verteilte IPv6-Routen: Route zum betroffenen Ziel: Lokale Netzüberlappung: VPN-DNS-Server: DNS-Suffixe: Interne Namensauflösung: Betroffenes Ziel: Ziel-IP: Zielport: Transportprotokoll: Porttest: Anwendungstest: MTU-Test: Paketverlust: Abbruchzeitpunkt: Clientprotokoll: Gatewayprotokoll: Serverseitige Richtlinie: Rückroute zum VPN-Adresspool: Paketmitschnitt vorhanden: Vergleich über anderes Zugangsnetz: Vergleich mit anderem Benutzer: Vergleich mit anderem Gerät: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
40. Kontrollfragen nach der Diagnose - Funktioniert das Netzwerk ohne VPN? - Wurde ein Captive Portal ausgeschlossen? - Wird der VPN-Gatewayname richtig aufgelöst? - Führt die Route zum Gateway über die physische Basisschnittstelle? - Ist das benötigte Transportprotokoll erreichbar? - Werden Benutzer, Gerät, MFA und Zertifikat akzeptiert? - Ist der Tunnel wirklich aufgebaut? - Hat der Client eine gültige Tunneladresse erhalten? - Existieren die benötigten Routen? - Führt die Route zum Ziel tatsächlich über das VPN? - Überschneiden sich lokales und entferntes Netz? - Ist Full Tunnel oder Split Tunnel vorgesehen? - Werden die richtigen DNS-Server und Suffixe verwendet? - Funktioniert das Ziel über IP-Adresse? - Funktioniert das Ziel über Hostname? - Ist nur ein bestimmter Port oder Dienst betroffen? - Wurden IPv4 und IPv6 getrennt geprüft? - Gibt es Hinweise auf ein MTU-Problem? - Funktioniert das VPN über ein anderes Zugangsnetz? - Wurde ein Kill Switch beziehungsweise lokaler Filter berücksichtigt? - Wurde der serverseitige Rückweg zum VPN-Adresspool geprüft? - Wurden Client- und Gatewayprotokolle zeitlich abgeglichen? - Wurde die Ursache nachgewiesen, bevor Einstellungen verändert wurden? - Wurde nach der Änderung der gesamte Datenfluss erneut geprüft?
---
41. Quellen und weiterführende Dokumentation - Microsoft Learn – Get-VpnConnection: https://learn.microsoft.com/powershell/module/vpnclient/get-vpnconnection - Microsoft Learn – Windows-VPN-Client und VPN-Protokolle: https://learn.microsoft.com/windows-server/remote/remote-access/vpn/vpn-top - Microsoft Learn – Always-On-VPN: https://learn.microsoft.com/windows-server/remote/remote-access/tutorial-aovpn-deploy-setup - Microsoft Learn – Windows-VPN-Gerätetunnel: https://learn.microsoft.com/windows-server/remote/remote-access/vpn/vpn-device-tunnel-config - Microsoft Learn – Get-NetIPsecMainModeSA: https://learn.microsoft.com/powershell/module/netsecurity/get-netipsecmainmodesa - Microsoft Learn – Get-NetIPsecQuickModeSA: https://learn.microsoft.com/powershell/module/netsecurity/get-netipsecquickmodesa - Apple – VPN-Verbindung auf dem Mac konfigurieren: https://support.apple.com/de-de/guide/mac-help/mchlp2963/mac - Apple – VPN-Einstellungen auf dem Mac ändern: https://support.apple.com/de-de/guide/mac-help/mchlp1579/mac - WireGuard – Offizielle Kurzanleitung: https://www.wireguard.com/quickstart/ - WireGuard – Protokollbeschreibung: https://www.wireguard.com/protocol/ - OpenVPN – Offizielle Dokumentation: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ - NetworkManager – nmcli-Dokumentation: https://networkmanager.dev/docs/api/latest/nmcli.html - strongSwan – Dokumentation: https://docs.strongswan.org/docs/latest/ - RFC 7296 – Internet Key Exchange Protocol Version 2: https://www.rfc-editor.org/rfc/rfc7296.html - RFC 3947 – Negotiation of NAT-Traversal in IKE: https://www.rfc-editor.org/rfc/rfc3947.html - RFC 3948 – UDP Encapsulation of IPsec ESP Packets: https://www.rfc-editor.org/rfc/rfc3948.html - RFC 4301 – Security Architecture for the Internet Protocol: https://www.rfc-editor.org/rfc/rfc4301.html - RFC 8201 – Path MTU Discovery for IPv6: https://www.rfc-editor.org/rfc/rfc8201.html
# 3.14 WLAN- und Funkverbindungsfehler analysieren Eine WLAN-Verbindung besteht nicht nur aus „verbunden“ oder „nicht verbunden“. Zwischen Client und Anwendung liegen Funkübertragung, Authentifizierung, Zuordnung zu einem Access Point, VLAN-Zuweisung, IP-Konfiguration, Routing, DNS und der eigentliche Netzwerkdienst. Die zentralen Fragen dieser Seite lauten: > Kann der Client das gewünschte WLAN zuverlässig empfangen, sich korrekt authentifizieren und anschließend über das zugewiesene Netzwerk störungsfrei kommunizieren? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Funk- oder Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder Funkversorgung beeinträchtigen | WLAN-Diagnosen können SSIDs, BSSIDs, MAC-Adressen, Standorte, Benutzernamen, interne Netze und Authentifizierungsinformationen enthalten. Kennwörter und private Schlüssel dürfen niemals exportiert oder dokumentiert werden.
---
2. WLAN-Fehler in Schichten aufteilen | Ebene | Zentrale Frage | |---|---| | Hardware | Ist der WLAN-Adapter vorhanden und betriebsbereit? | | Funk | Ist das gewünschte WLAN mit ausreichender Qualität empfangbar? | | 802.11-Verbindung | Kann sich der Client mit dem Access Point verbinden? | | Authentifizierung | Werden Kennwort, Zertifikat oder 802.1X-Anmeldung akzeptiert? | | Netzwerkzuweisung | Erhält der Client das richtige VLAN und die richtige IP-Konfiguration? | | Routing | Ist das Standardgateway erreichbar? | | DNS | Funktioniert die Namensauflösung? | | Internetzugang | Ist ein externer Zugriff möglich? | | Anwendung | Funktioniert der tatsächlich benötigte Dienst? | | Stabilität | Bleibt die Verbindung bei Bewegung und Last erhalten? | **Grundregel:** ```text Mit WLAN verbunden ≠ gültige IP-Konfiguration ≠ Internetzugang ≠ Anwendung funktioniert ```
---
3. Wichtige WLAN-Begriffe unterscheiden | Begriff | Bedeutung | |---|---| | SSID | Sichtbarer beziehungsweise konfigurierter WLAN-Netzwerkname | | BSSID | Kennung einer konkreten Funkzelle, üblicherweise eine MAC-Adresse | | Access Point | Stellt die WLAN-Funkzelle bereit | | Band | Frequenzbereich, beispielsweise 2,4 GHz, 5 GHz oder 6 GHz | | Kanal | Genutzter Teil des Frequenzbereichs | | Kanalbreite | Beispielsweise 20, 40, 80 oder 160 MHz | | RSSI | Empfangssignalstärke, häufig in dBm angegeben | | Noise | Gemessener beziehungsweise geschätzter Rauschpegel | | SNR | Abstand zwischen Nutzsignal und Rauschen | | PHY-Rate | Ausgehandelte Bruttodatenrate der Funkverbindung | | Durchsatz | Tatsächlich nutzbare Datenübertragungsrate | | Roaming | Wechsel eines Clients zwischen Funkzellen | | Band Steering | Access Point versucht, Clients in ein geeignetes Frequenzband zu lenken | | Airtime | Anteil der Funkzeit, den Geräte für Übertragungen verwenden | | DFS | Dynamische Kanalauswahl zum Schutz bestimmter Radarsysteme | | Hidden SSID | SSID wird nicht regulär in Beacon-Frames angekündigt | | 802.1X | Portbasierte Authentifizierung, häufig in Unternehmens-WLANs | | Captive Portal | Webbasierte Freischaltung, häufig in Gastnetzen | Mehrere Access Points können dieselbe SSID anbieten, aber jeweils eine eigene BSSID verwenden.
---
4. Störungsumfang zuerst bestimmen Vor technischen Änderungen ist zu klären: - Ist nur ein Client betroffen? - Sind mehrere Clients am gleichen Standort betroffen? - Ist nur eine SSID betroffen? - Ist nur ein Access Point beziehungsweise eine BSSID betroffen? - Tritt der Fehler nur in einem bestimmten Raum auf? - Sind 2,4 GHz, 5 GHz oder 6 GHz unterschiedlich betroffen? - Funktioniert die Verbindung in unmittelbarer Nähe zum Access Point? - Tritt der Fehler nur während hoher Auslastung auf? - Tritt er nur beim Roaming auf? - Funktioniert Ethernet am selben Standort? - Funktioniert das WLAN, aber nicht der Internetzugang? - Erhalten andere Clients eine gültige DHCP-Konfiguration? - Tritt der Fehler seit einer Treiber-, Firmware- oder Richtlinienänderung auf? - Sind ältere oder nur neuere WLAN-Geräte betroffen? - Betrifft der Fehler nur ein Benutzerkonto? **Sinnvolle Vergleichsmatrix:** | Vergleich | Erkenntnis | |---|---| | Gleiches Gerät, anderer Standort | Funkzelle oder Standortproblem | | Gleiches Gerät, andere SSID | SSID-, Authentifizierungs- oder VLAN-Problem | | Anderes Gerät, gleiche Position | Client- oder allgemeines Funkproblem | | WLAN gegenüber Ethernet | Funkebene gegenüber allgemeinem Netzwerkproblem | | Betroffener gegenüber funktionierendem Client | Konfigurationsunterschiede | | Nähe zum AP gegenüber Randbereich | Signal-, Störungs- oder Roamingproblem |
---
5. Signalstärke in dBm richtig interpretieren WLAN-Signalstärken werden häufig als negative dBm-Werte angegeben. ```text -45 dBm ist stärker als -75 dBm ``` Eine näher an null liegende Zahl bedeutet ein stärkeres Signal. | RSSI-Beispiel | Grobe praktische Einordnung | |---:|---| | `-30 dBm` | Extrem stark, meist in unmittelbarer Nähe | | `-40 bis -50 dBm` | Sehr stark | | `-50 bis -60 dBm` | Häufig gut für anspruchsvolle Anwendungen | | `-60 bis -67 dBm` | Häufig noch brauchbar bis gut | | `-67 bis -70 dBm` | Je nach Anwendung und Umgebung grenzwertig | | `-70 bis -80 dBm` | Schwach, geringere Datenraten und Wiederholungen wahrscheinlich | | unter `-80 dBm` | Häufig instabil oder nicht mehr sinnvoll nutzbar | Diese Werte sind keine universellen Garantien. Antennen, Clienthardware, Kanalbreite, Störungen, Anwendung und Messverfahren beeinflussen das Ergebnis. **Signal-Rausch-Abstand näherungsweise:** ```text SNR = Signalpegel − Rauschpegel ``` Beispiel: ```text Signal: -60 dBm Rauschen: -90 dBm SNR = 30 dB ``` Ein starkes Signal kann trotzdem schlecht nutzbar sein, wenn das Rauschen oder die Kanalbelegung ebenfalls hoch ist.
---
6. PHY-Rate und tatsächlichen Durchsatz unterscheiden Die angezeigte Verbindungsrate ist eine ausgehandelte Bruttodatenrate und nicht der tatsächlich nutzbare Anwendungsdurchsatz. Abzüge entstehen unter anderem durch: - WLAN-Protokoll-Overhead, - Management- und Kontrollframes, - Verschlüsselung, - gemeinsam genutzte Funkzeit, - Wiederholungen, - Störungen, - Halbduplexbetrieb, - Entfernung, - Kanalbreite, - Anzahl der Spatial Streams, - Leistungsfähigkeit des Clients, - Auslastung des Access Points, - TCP- und Anwendungs-Overhead. **Deshalb gilt:** ```text PHY-Rate 866 Mbit/s ≠ 866 Mbit/s nutzbarer Datendurchsatz ``` Ein Internet-Speedtest misst zusätzlich Internetanschluss, WAN, Testserver und Providerpfad. Zur reinen WLAN-Beurteilung ist ein lokaler Testserver im kabelgebundenen LAN besser geeignet.
---
7. Windows: WLAN-Schnittstelle und Verbindung prüfen **WLAN-Schnittstellen und aktuelle Verbindung:** ```cmd [RO][SENS] netsh wlan show interfaces ``` Typische Angaben: ```text Name Beschreibung GUID Physische Adresse Status SSID BSSID Netzwerktyp Funktyp Authentifizierung Verschlüsselung Kanal Empfangsrate Übertragungsrate Signal Profil ``` **Alle relevanten WLAN-Informationen:** ```cmd [RO][SENS] netsh wlan show all ``` **Windows-Netzwerkadapter:** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **IP-Konfiguration:** ```powershell [RO][SENS] Get-NetIPConfiguration ``` **Adapterstatistik:** ```powershell [RO] Get-NetAdapterStatistics | Format-Table Name, ReceivedBytes, SentBytes, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors ``` Paketfehler und verworfene Pakete müssen über einen Zeitraum beziehungsweise im Vergleich zu einem funktionierenden Zustand bewertet werden.
---
8. Windows: sichtbare Netze, BSSIDs und Kanäle prüfen **Sichtbare WLAN-Netze:** ```cmd [RO][SENS] netsh wlan show networks ``` **Sichtbare Netze einschließlich BSSIDs:** ```cmd [RO][SENS] netsh wlan show networks mode=bssid ``` Damit lassen sich unter anderem vergleichen: - SSID, - BSSID, - Signal, - Funktyp, - Kanal, - mehrere Access Points derselben SSID, - Authentifizierungsverfahren, - Verschlüsselungsverfahren. **Wichtige Fragen:** - Ist die gewünschte SSID sichtbar? - Sind mehrere BSSIDs derselben SSID vorhanden? - Mit welcher BSSID ist der Client verbunden? - Ist diese BSSID am Standort sinnvoll? - Verwendet der Client das erwartete Frequenzband? - Befinden sich viele starke Nachbarn auf demselben Kanal? - Wechselt die BSSID während des Fehlers? Ein einfacher Scan ist nur eine Momentaufnahme und erkennt nicht jede Störung oder Auslastung.
---
9. Windows: Treiber und Fähigkeiten prüfen **WLAN-Treiberinformationen:** ```cmd [RO][SENS] netsh wlan show drivers ``` Mögliche Angaben: - Hersteller, - Anbieter, - Datum, - Version, - unterstützte Funktypen, - unterstützte Authentifizierungs- und Verschlüsselungsverfahren, - Treibermodell, - unterstützte WLAN-Funktionen. **Wireless Capabilities:** ```cmd [RO][SENS] netsh wlan show wirelesscapabilities ``` **PowerShell-Treiberinformationen:** ```powershell [RO][SENS] Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceClass -eq "NET" | Select-Object DeviceName, DriverProviderName, DriverVersion, DriverDate ``` Treiberstände sollten mit der offiziellen Freigabe des Geräte- oder Adapterherstellers verglichen werden. Ein neuerer generischer Treiber ist nicht automatisch besser als der vom Systemhersteller freigegebene Treiber.
---
10. Windows: gespeicherte WLAN-Profile prüfen **Gespeicherte Profile:** ```cmd [RO][SENS] netsh wlan show profiles ``` **Bestimmtes Profil anzeigen:** ```cmd [RO][SENS] netsh wlan show profile name="SSID-ODER-PROFILNAME" ``` Zu kontrollieren sind: - Profilname, - SSID, - Verbindung automatisch oder manuell, - Authentifizierungsverfahren, - Verschlüsselungsverfahren, - Richtlinienquelle, - zufällige Hardwareadresse, - unternehmensweite oder benutzerbezogene Bereitstellung. **Nicht verwenden:** ```text key=clear ``` Dadurch könnte ein gespeicherter WLAN-Schlüssel im Klartext ausgegeben werden. Das ist für eine normale Fehleranalyse nicht erforderlich und darf nicht in Dokumentationen verwendet werden.
---
11. Windows-WLAN-Bericht erstellen **WLAN-Bericht erzeugen:** ```cmd [RO][PRIV][FILE][SENS] netsh wlan show wlanreport ``` Windows zeigt nach der Erstellung den konkreten Speicherort des Berichts an. Dieser Pfad sollte aus der Ausgabe übernommen und nicht angenommen werden. Der Bericht kann unter anderem enthalten: - WLAN-Sitzungen, - Verbindungs- und Trennereignisse, - Adapterinformationen, - Treiberdaten, - Netzwerkprofile, - Fehlerursachen, - Zeitverlauf, - Ereignisse aus relevanten Windows-Protokollen. Der Bericht enthält sensible Netzwerkdaten und muss entsprechend geschützt werden. **WLAN-Ereignisprotokoll prüfen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" ` -MaxEvents 100 ``` **Zeitlich begrenzen:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -FilterHashtable @{ LogName = "Microsoft-Windows-WLAN-AutoConfig/Operational" StartTime = (Get-Date).AddMinutes(-30) } ```
---
12. Linux: WLAN-Schnittstellen und Verbindungsstatus prüfen **Netzwerkgeräte:** ```bash [RO] ip -br link ``` **NetworkManager-Gerätestatus:** ```bash [RO] nmcli device status ``` **Aktive Verbindungen:** ```bash [RO][SENS] nmcli connection show --active ``` **WLAN-Schnittstellen mit iw:** ```bash [RO] iw dev ``` **Aktuelle Verbindung einer bestimmten Schnittstelle:** ```bash [RO][SENS] iw dev wlan0 link ``` `wlan0` muss durch den tatsächlich ermittelten Schnittstellennamen ersetzt werden. Typische Angaben von `iw dev wlan0 link`: ```text BSSID SSID Frequenz RX-Daten TX-Daten Signal RX-Bitrate TX-Bitrate ``` **Stationsinformationen:** ```bash [RO][SENS] iw dev wlan0 station dump ``` Abhängig von Treiber und Betriebsmodus können zusätzliche Werte wie Signal, Bitrate, Wiederholungen und übertragene Daten angezeigt werden.
---
13. Linux: sichtbare Netze und Funkumgebung prüfen **WLAN-Scan mit NetworkManager:** ```bash [TEST][SENS] nmcli device wifi list ``` **Scan für eine bestimmte Schnittstelle:** ```bash [TEST][SENS] nmcli device wifi list ifname wlan0 ``` **Ausgewählte Felder anzeigen:** ```bash [TEST][SENS] nmcli -f IN-USE,SSID,BSSID,MODE,CHAN,FREQ,RATE,SIGNAL,SECURITY \ device wifi list ``` **Regulierungsdomäne prüfen:** ```bash [RO] iw reg get ``` **WLAN-Fähigkeiten des Adapters:** ```bash [RO][SENS] iw list ``` `iw list` kann eine sehr umfangreiche Ausgabe erzeugen. Relevant sind unter anderem: - unterstützte Bänder, - Frequenzen, - Kanalbreiten, - Schnittstellenmodi, - Verschlüsselungsfähigkeiten, - räumliche Streams, - regulatorische Einschränkungen. Die Regulierungsdomäne darf nicht willkürlich verändert werden. Zulässige Kanäle und Sendeleistungen sind landesabhängig reguliert.
---
14. Linux: NetworkManager-Protokolle auswerten **Aktuelle NetworkManager-Protokolle:** ```bash [RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes" ``` **WLAN-bezogene Kernelmeldungen:** ```bash [RO][PRIV][SENS] sudo journalctl -k --since "-30 minutes" | grep -Ei 'wlan|wifi|wireless|80211|firmware' ``` **Treiberzuordnung der Netzwerkschnittstellen:** ```bash [RO][SENS] lspci -k | grep -A 4 -Ei 'network|wireless' ``` Bei USB-WLAN-Adaptern: ```bash [RO][SENS] lsusb ``` Zu suchen sind unter anderem: - Firmware konnte nicht geladen werden, - Authentifizierung fehlgeschlagen, - Verbindung wurde getrennt, - DHCP fehlgeschlagen, - Access Point nicht erreichbar, - regulatorische Einschränkung, - Treiberabsturz, - Energiesparzustand, - Roamingereignis.
---
15. macOS: WLAN-Schnittstelle und Verbindung prüfen **Hardwareports und Gerätenamen anzeigen:** ```bash [RO] networksetup -listallhardwareports ``` Dadurch wird ermittelt, welche Schnittstelle zum WLAN gehört, beispielsweise `en0` oder `en1`. Der Name darf nicht ohne Prüfung vorausgesetzt werden. **Aktuell verbundenes WLAN:** ```bash [RO][SENS] networksetup -getairportnetwork en0 ``` `en0` muss durch die tatsächlich ermittelte WLAN-Schnittstelle ersetzt werden. **Ausführliche WLAN- und Hardwareinformationen:** ```bash [RO][SENS] system_profiler SPAirPortDataType ``` **IP-Konfiguration:** ```bash [RO][SENS] ifconfig en0 ``` **Netzwerkdienstkonfiguration:** ```bash [RO][SENS] networksetup -getinfo "Wi-Fi" ``` `Wi-Fi` muss durch den tatsächlichen Namen des Netzwerkdienstes ersetzt werden.
---
16. macOS: aktuelle WLAN-Diagnoseinformationen prüfen Auf aktuellen macOS-Versionen kann `wdutil` WLAN-Diagnoseinformationen bereitstellen. **Verfügbarkeit und Hilfe prüfen:** ```bash [RO] command -v wdutil ``` ```bash [RO] wdutil help ``` **Aktuelle Diagnoseinformationen, sofern von der installierten Version unterstützt:** ```bash [RO][PRIV][SENS] sudo wdutil info ``` Die verfügbaren Unterbefehle und Ausgaben können sich zwischen macOS-Versionen unterscheiden. Deshalb muss zuerst die lokale Hilfe geprüft werden. Mögliche Informationen sind: - SSID, - BSSID, - Kanal, - Signal, - Rauschpegel, - Übertragungsrate, - Sicherheitsverfahren, - Schnittstelle. Ältere Anleitungen verwenden häufig das interne `airport`-Werkzeug. Dessen Verfügbarkeit und Verhalten ist auf aktuellen macOS-Versionen nicht zuverlässig vorauszusetzen; deshalb wird es hier nicht als Standardbefehl verwendet.
---
17. macOS Wireless Diagnostics verwenden Apple stellt die grafische Anwendung „Diagnose für drahtlose Umgebungen“ beziehungsweise „Wireless Diagnostics“ bereit. **Aufruf:** 1. Mit dem problematischen WLAN verbinden, soweit möglich. 2. Wahltaste beziehungsweise `Option` gedrückt halten. 3. Auf das WLAN-Symbol in der Menüleiste klicken. 4. „Diagnose für drahtlose Umgebungen öffnen“ auswählen. 5. Den Anweisungen folgen. Apple gibt an, dass die Diagnose selbst die Netzwerkeinstellungen nicht verändert. Die Diagnose kann ein komprimiertes Archiv erzeugen. Apple dokumentiert dafür: ```text /var/tmp ``` Der Dateiname beginnt mit: ```text WirelessDiagnostics ``` und endet mit: ```text .tar.gz ``` Das Archiv kann umfangreiche und sensible System- und Netzwerkdaten enthalten und darf nur geschützt weitergegeben werden.
---
18. Frequenzbänder praktisch unterscheiden | Eigenschaft | 2,4 GHz | 5 GHz | 6 GHz | |---|---|---|---| | Reichweite | Häufig größer | Häufig geringer als 2,4 GHz | Häufig stärker durch Entfernung und Hindernisse beeinflusst | | Kanalkapazität | Begrenzter | Mehr verfügbare Kanalressourcen | Große zusätzliche Frequenzressourcen | | Störquellen | Viele WLAN- und Nicht-WLAN-Geräte | Häufig weniger Nicht-WLAN-Störungen | Abhängig von regionaler Freigabe und Nutzung | | Wanddurchdringung | Häufig günstiger | Häufig geringer | Häufig geringer | | Geräteunterstützung | Sehr weit verbreitet | Weit verbreitet | Nur geeignete neuere Geräte | | Kanalbreiten | Häufig 20 oder 40 MHz | Häufig 20 bis 160 MHz | Abhängig von Standard und Gerät auch sehr breite Kanäle | Die tatsächlich nutzbaren Frequenzen und Kanalbreiten hängen von Land, Gerät, Treiber, Access Point und WLAN-Standard ab. **Typischer Zielkonflikt:** ```text Breitere Kanäle → potenziell höhere Datenrate → benötigen mehr Frequenzspektrum → höhere Wahrscheinlichkeit von Überlappungen oder Störungen ```
---
19. Kanalbelegung und Störungen beurteilen Ein WLAN-Kanal ist ein gemeinsam genutztes Medium. Alle Geräte auf demselben oder überlappenden Kanal teilen sich die verfügbare Funkzeit. Mögliche Störquellen: - benachbarte WLANs, - Bluetooth, - Mikrowellengeräte, - Funkkameras, - drahtlose Audio- oder Videoübertragung, - USB-3-Geräte und schlecht abgeschirmte Kabel im 2,4-GHz-Umfeld, - Radarerkennung auf DFS-Kanälen, - defekte oder stark sendende Geräte, - sehr breite Kanalbelegung, - versteckte Stationen. **Co-Channel-Interference:** Mehrere WLANs verwenden denselben Kanal und müssen sich die Funkzeit teilen. **Adjacent-Channel-Interference:** Überlappende Kanäle beeinflussen sich, ohne sauber koordiniert zu werden. Im 2,4-GHz-Band werden bei 20-MHz-Kanalbreite häufig überlappungsarme Planungen verwendet. Welche Kanäle zulässig und sinnvoll sind, hängt von der regionalen Regulierung und dem vorhandenen Kanalplan ab. Ein Scan zeigt andere WLANs, aber nicht zuverlässig alle Nicht-WLAN-Störquellen. Dafür kann ein geeigneter Spektrumanalysator erforderlich sein.
---
20. DFS-Ereignisse berücksichtigen Bestimmte 5-GHz-Kanäle unterliegen Dynamic Frequency Selection. Erkennt ein Access Point ein relevantes Radarsignal, kann er den Kanal wechseln oder die Aussendung vorübergehend einstellen. **Mögliche Symptome:** - WLAN verschwindet kurzfristig, - Clients werden gleichzeitig getrennt, - Access Point wechselt den Kanal, - nur bestimmte 5-GHz-Kanäle sind betroffen, - Verbindung kehrt nach einer Wartezeit zurück, - Ereignis tritt standortabhängig auf. Zu prüfen sind: - Access-Point-Ereignisprotokolle, - Controllerereignisse, - Kanalverlauf, - DFS- beziehungsweise Radarereignisse, - automatischer Kanalwechsel, - Clientunterstützung des neuen Kanals. DFS darf nicht pauschal als Fehler betrachtet werden. Es handelt sich um eine regulatorisch vorgesehene Schutzfunktion.
---
21. Authentifizierung und Verschlüsselung prüfen Mögliche WLAN-Sicherheitsverfahren: - WPA2-Personal, - WPA3-Personal, - WPA2-Enterprise, - WPA3-Enterprise, - Übergangsmodi, - 802.1X/EAP, - Enhanced Open beziehungsweise OWE, - offene Gastnetze mit Captive Portal. Zu kontrollieren sind: - unterstützt der Client das Verfahren, - stimmt das Kennwort, - wird ein altes Profil verwendet, - ist WPA3 erforderlich oder optional, - ist Protected Management Frames erforderlich, - funktioniert die 802.1X-Authentifizierung, - ist das Serverzertifikat vertrauenswürdig, - stimmt der Servername im Zertifikat, - ist das Benutzer- oder Gerätezertifikat gültig, - ist das Benutzerkonto gesperrt, - ist das Gerät durch Richtlinie zugelassen, - ist die Systemzeit korrekt. **Systemzeit:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | Bei Zertifikats- und Kerberos-basierten Verfahren kann eine falsche Systemzeit die Anmeldung verhindern.
---
22. 802.1X- und Enterprise-WLAN eingrenzen Ein Enterprise-WLAN kann mehrere Komponenten enthalten: ```text WLAN-Client ↓ Access Point ↓ WLAN-Controller ↓ RADIUS-Server ↓ Identitätsdienst ↓ VLAN- und Zugriffsrichtlinie ``` Zu dokumentieren sind: - Benutzer- oder Geräteauthentifizierung, - EAP-Verfahren, - Zertifikatsaussteller, - Identität beziehungsweise anonyme Identität, - RADIUS-Antwort, - zugewiesenes VLAN, - angewendete Rolle, - Access-Control-List, - Zeitpunkt, - Access Point und BSSID. **Typische Fehler:** | Beobachtung | Mögliche Ursache | |---|---| | Kennwortabfrage wiederholt sich | Zugangsdaten, EAP oder Zertifikatsprüfung | | Zertifikatswarnung | Vertrauenskette oder Serveridentität | | Verbindung hergestellt, falsches Netz | Dynamische VLAN-Zuweisung oder Richtlinie | | Nur Gerätetunnel vor Anmeldung fehlt | Computerzertifikat oder Geräteauthentifizierung | | Benutzer funktioniert auf anderem Gerät | Gerätezertifikat, Profil oder Gerätekonformität | | Alle Benutzer an einem AP betroffen | AP-, Controller- oder Netzwerkpfad zum RADIUS | Client-, Controller- und RADIUS-Protokolle müssen zeitlich miteinander verglichen werden.
---
23. Nach der WLAN-Verbindung DHCP prüfen **Windows:** ```powershell [RO][SENS] Get-NetIPConfiguration ``` ```cmd [RO][SENS] ipconfig /all ``` **Linux:** ```bash [RO][SENS] ip -br address ``` ```bash [RO] ip route show ``` **macOS:** ```bash [RO][SENS] networksetup -getinfo "Wi-Fi" ``` ```bash [RO][SENS] ifconfig en0 ``` Zu kontrollieren sind: - gültige IP-Adresse, - Präfix beziehungsweise Subnetzmaske, - Standardgateway, - DHCP-Server, - DNS-Server, - Lease-Zeit, - richtige VLAN-Zuweisung, - IPv4- und IPv6-Konfiguration. **Typisches Fehlerbild:** ```text WLAN-Authentifizierung erfolgreich ↓ Client wird dem falschen VLAN zugeordnet ↓ DHCP-Server nicht erreichbar oder falscher Adressbereich ↓ Kein nutzbarer Netzwerkzugang ``` Eine IPv4-Adresse aus `169.254.0.0/16` weist häufig darauf hin, dass keine reguläre IPv4-DHCP-Zuweisung erfolgt ist.
---
24. Gateway, DNS und Internet getrennt testen **Stufe 1 – eigene IP-Konfiguration prüfen** ```text IP-Adresse Subnetzmaske beziehungsweise Präfix Standardgateway DNS-Server ``` **Stufe 2 – Standardgateway testen** Windows: ```powershell [TEST] Test-Connection GATEWAY_IP -Count 4 ``` Linux und macOS: ```bash [TEST] ping -c 4 GATEWAY_IP ``` **Stufe 3 – externe IP-Adresse testen:** Windows: ```powershell [TEST] Test-NetConnection 1.1.1.1 -Port 443 ``` Linux und macOS: ```bash [TEST] nc -vz -w 5 1.1.1.1 443 ``` **Stufe 4 – DNS-Auflösung testen** Windows: ```powershell [TEST] Resolve-DnsName example.com ``` Linux und macOS: ```bash [TEST] dig example.com ``` **Stufe 5 – Anwendung testen** ```bash [TEST] curl -I https://example.com/ ``` Öffentliche Testziele dürfen nur verwendet werden, wenn dies durch die betrieblichen Richtlinien erlaubt ist.
---
25. Captive Portal erkennen Gast-, Hotel- und öffentliche WLANs verlangen häufig eine browserbasierte Freischaltung. **Typische Symptome:** - WLAN ist verbunden, - IP-Adresse und Gateway sind vorhanden, - Internetzugriff funktioniert nicht, - Browser wird auf eine Anmeldeseite umgeleitet, - HTTPS-Seiten zeigen Fehler, - VPN-Verbindung kann nicht aufgebaut werden, - DNS-Antworten werden verändert. Zu prüfen sind: - wurde die Nutzungsseite vollständig bestätigt, - ist die Sitzung abgelaufen, - wurde das Gerät anhand seiner MAC-Adresse registriert, - verwendet der Client eine zufällige MAC-Adresse, - blockiert ein VPN oder Proxy die Portalerkennung, - ist die Systemzeit korrekt, - wurde die maximal zulässige Gerätezahl erreicht? Zertifikatswarnungen auf HTTPS-Seiten dürfen nicht einfach bestätigt werden. Für die Portalanmeldung sollte die vom Betreiber vorgesehene sichere Methode verwendet werden.
---
26. Zufällige MAC-Adressen berücksichtigen Moderne Betriebssysteme können pro WLAN eine private beziehungsweise zufällige MAC-Adresse verwenden. Das kann folgende Auswirkungen haben: - DHCP vergibt eine neue Adresse, - Captive Portal erkennt ein neues Gerät, - MAC-basierte Freigabe greift nicht, - NAC behandelt das Gerät als unbekannt, - Gerät erscheint mehrfach im Controller, - statische DHCP-Reservierung passt nicht, - Inventarisierung wird erschwert. **Windows-Status anzeigen:** ```cmd [RO][SENS] netsh wlan show randomization ``` **Windows-Schnittstellenadresse:** ```powershell [RO] Get-NetAdapter | Format-Table Name, MacAddress, Status ``` **Linux:** ```bash [RO] ip link show ``` **macOS:** ```bash [RO] ifconfig en0 ``` Die aktuelle Schnittstellenadresse allein zeigt nicht zwingend, ob und nach welchem Verfahren sie für ein bestimmtes WLAN erzeugt wurde. Die Einstellung sollte zusätzlich in der WLAN-Konfiguration des Betriebssystems geprüft werden. Private MAC-Adressen dürfen nicht pauschal deaktiviert werden. Ihre Nutzung ist eine Datenschutz- und Netzwerkdesignentscheidung.
---
27. Roamingprobleme analysieren Beim Roaming entscheidet der Client normalerweise selbst, wann er zu einer anderen Funkzelle wechselt. Access Points und Controller können diese Entscheidung unterstützen oder beeinflussen. **Typische Symptome:** - Verbindung bricht beim Wechsel zwischen Räumen ab, - Sprach- oder Videokonferenz stockt beim Laufen, - Client bleibt an einem weit entfernten Access Point hängen, - BSSID wechselt häufig hin und her, - Problem tritt nur bei bestimmten Clientmodellen auf, - Anmeldung wird bei jedem AP-Wechsel wiederholt, - IP-Adresse ändert sich beim Roaming. Zu dokumentieren sind: - SSID, - alte BSSID, - neue BSSID, - Kanal und Band, - Signal vor dem Wechsel, - Signal nach dem Wechsel, - Zeitpunkt und Dauer der Unterbrechung, - zugewiesenes VLAN, - IP-Adresse vor und nach dem Wechsel, - unterstützte Roamingfunktionen, - Clienttreiber und Firmware. **Wichtige Standards und Funktionen:** | Funktion | Aufgabe | |---|---| | 802.11k | Informationen über benachbarte Funkzellen | | 802.11v | Unterstützung bei Netzwerkauswahl und Übergängen | | 802.11r | Beschleunigte Übergänge zwischen Access Points | | PMK-Caching | Wiederverwendung bestimmter Authentifizierungsinformationen | Unterstützung und Verhalten hängen von Client, Access Point, Sicherheitsverfahren und Konfiguration ab.
---
28. Sticky Clients und Ping-Pong-Roaming erkennen **Sticky Client:** ```text Client bleibt mit schwacher BSSID verbunden obwohl eine nähere BSSID verfügbar ist ``` Mögliche Ursachen: - Roamingentscheidung des Clients, - Treibereinstellung, - Sendeleistung der Access Points, - ungünstige Zellüberlappung, - fehlende beziehungsweise inkompatible Roamingunterstützung, - zu niedrige Datenraten weiterhin erlaubt. **Ping-Pong-Roaming:** ```text Client wechselt wiederholt zwischen zwei BSSIDs ``` Mögliche Ursachen: - ähnliche Signalstärke, - schwankende Funkbedingungen, - ungeeignete Schwellenwerte, - übermäßige Zellüberlappung, - Band-Steering-Konflikte, - Clienttreiber. Ein erzwungenes Trennen des Clients kann kurzfristig helfen, beweist aber keine nachhaltige Fehlerbehebung.
---
29. Energiesparfunktionen berücksichtigen WLAN-Adapter und Betriebssysteme können die Funkhardware zum Energiesparen in reduzierte Betriebszustände versetzen. **Typische Symptome:** - Verbindung bricht im Akkubetrieb ab, - nach Standby kein Netzwerkzugang, - hoher erster Paketverlust nach Inaktivität, - Verbindung ist nach Deaktivieren und Aktivieren des Adapters wieder vorhanden, - Problem tritt nur bei bestimmten Energiesparprofilen auf. **Windows-Energiezustände:** ```powershell [RO] powercfg /getactivescheme ``` **Windows-WLAN-Bericht:** ```cmd [RO][PRIV][FILE][SENS] netsh wlan show wlanreport ``` **Linux:** ```bash [RO] iw dev wlan0 get power_save ``` Nicht jeder Treiber unterstützt dieselbe Abfrage. **macOS:** ```bash [RO] pmset -g ``` Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, bevor Treiber, Firmware und das konkrete Fehlerbild geprüft wurden.
---
30. Paketverlust und Latenz lokal messen Zuerst wird das lokale Standardgateway getestet. Dadurch bleiben Internetprovider und externe Netze zunächst außerhalb der Messung. **Windows:** ```powershell [TEST] Test-Connection GATEWAY_IP -Count 50 ``` Alternativ: ```cmd [TEST] ping -n 50 GATEWAY_IP ``` **Linux und macOS:** ```bash [TEST] ping -c 50 GATEWAY_IP ``` Zu bewerten sind: - Paketverlust, - minimale Latenz, - durchschnittliche Latenz, - maximale Latenz, - starke Schwankungen, - zeitlicher Zusammenhang mit Bewegung oder Last. **Wichtig:** Access Points oder Gateways können ICMP niedriger priorisieren. Ein Ping-Test ist deshalb ein Hinweis, aber keine vollständige Qualitätsmessung.
---
31. Durchsatz im lokalen Netz mit iperf3 testen Ein lokaler kabelgebundener `iperf3`-Server hilft, WLAN und Internetanschluss voneinander zu trennen. **Auf dem autorisierten kabelgebundenen Testserver:** ```bash [TEST] iperf3 -s ``` **Auf dem WLAN-Client:** ```bash [TEST] iperf3 -c SERVER_IP ``` **Gegenrichtung testen:** ```bash [TEST] iperf3 -c SERVER_IP -R ``` **Bestimmte Testdauer:** ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` **UDP-Test mit begrenzter Zielrate:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 20M -t 30 ``` UDP-Tests erzeugen gezielt Last und müssen mit einer angemessenen Bandbreite begonnen werden. Zu dokumentieren sind: - Standort des Clients, - SSID und BSSID, - Frequenzband, - Kanal, - Signal, - PHY-Rate, - TCP-Durchsatz in beide Richtungen, - UDP-Verlust und Jitter, - Anzahl paralleler Clients, - Uhrzeit.
---
32. Internet-Speedtest nicht mit WLAN-Messung verwechseln Ein Internet-Speedtest umfasst: ```text WLAN + lokales LAN + Router + Firewall + Internetanschluss + Provider + Routing zum Testserver + Testserver ``` Ein schlechtes Ergebnis kann daher auch bei einem fehlerfreien WLAN entstehen. **Empfohlene Reihenfolge:** 1. WLAN-Signal und Verbindungsparameter prüfen. 2. Lokales Gateway testen. 3. Lokalen kabelgebundenen `iperf3`-Server testen. 4. Erst danach Internetdurchsatz messen. 5. WLAN- und Ethernetmessung zum selben Ziel vergleichen. 6. Messung zu mehreren Zeitpunkten wiederholen. Die Aussage „WLAN liefert nur 50 Mbit/s“ ist ohne lokalen Vergleich nicht ausreichend belegt.
---
33. Airtime und hohe Clientdichte berücksichtigen WLAN ist ein geteiltes Medium. Auch langsam sendende Clients verbrauchen Funkzeit. Mögliche Ursachen hoher Airtime-Auslastung: - viele aktive Clients, - langsame oder weit entfernte Clients, - viele Wiederholungen, - niedrige Basisdatenraten, - Broadcast- und Multicastverkehr, - breite Kanäle mit Störungen, - Legacy-Geräte, - hohe Datenübertragungen, - mehrere SSIDs mit Management-Overhead, - schlecht platzierte Access Points. **Typische Symptome:** - starkes Signal, aber geringer Durchsatz, - hohe Latenz unter Last, - Problem nur zu bestimmten Uhrzeiten, - alle Clients einer Funkzelle betroffen, - andere Funkzellen funktionieren, - viele Wiederholungen und wechselnde Datenraten. Für eine zuverlässige Bewertung werden Controllerstatistiken oder geeignete WLAN-Analysewerkzeuge benötigt.
---
34. Access Point, Switch und VLAN gemeinsam prüfen Ein Access Point benötigt selbst eine funktionierende kabelgebundene Infrastruktur. Zu prüfen sind: - AP-Stromversorgung beziehungsweise PoE, - Ethernet-Link, - Linkgeschwindigkeit, - Switchportfehler, - VLAN-Trunk, - native beziehungsweise untagged VLAN-Zuweisung, - Management-VLAN, - SSID-zu-VLAN-Zuordnung, - DHCP-Relay, - Controllererreichbarkeit, - AP-Firmware, - Uplink-Auslastung. **Typisches Fehlerbild:** ```text Client verbindet sich erfolgreich mit SSID ↓ Access Point ordnet Client falschem VLAN zu ↓ Client erhält keine oder falsche IP-Konfiguration ``` **Switchportzähler beachten:** - CRC-Fehler, - Drops, - Duplexprobleme, - Link-Flaps, - PoE-Unterbrechungen, - Port-Security-Ereignisse, - Spanning-Tree-Ereignisse. Ein scheinbares Funkproblem kann tatsächlich auf dem kabelgebundenen AP-Uplink entstehen.
---
35. Mesh- und Repeater-Probleme erkennen Bei Mesh-Systemen und Repeatern wird Verkehr zusätzlich über einen drahtlosen oder kabelgebundenen Backhaul übertragen. ```text Client ↓ WLAN Mesh-Knoten oder Repeater ↓ Backhaul Haupt-Access-Point ↓ LAN Ziel ``` Zu prüfen sind: - Qualität des Clientlinks, - Qualität des Backhauls, - kabelgebundener oder drahtloser Backhaul, - verwendetes Frequenzband, - mehrere Funkübertragungen desselben Datenpakets, - Position des Repeaters, - Roaming zwischen Hauptgerät und Repeater, - Kanalplanung, - Uplink-Auslastung, - Firmwarestand. Ein Repeater mit starkem Signal zum Client kann trotzdem eine schlechte Gesamtverbindung liefern, wenn sein eigener Uplink schwach ist.
---
36. Versteckte SSIDs und Netzwerkprofile beurteilen Eine versteckte SSID verbessert die Verschlüsselung nicht. Clients müssen möglicherweise aktiv nach dem bekannten Netz suchen. Mögliche Nachteile: - erschwerte Diagnose, - zusätzliche Probe Requests, - Verbindungsprobleme bei fehlerhaftem Profil, - Datenschutzprobleme durch aktive Suche, - nicht einheitliches Verhalten verschiedener Clients. Zu prüfen sind: - SSID exakt geschrieben, - Sicherheitsverfahren korrekt, - Netzwerkprofil aktuell, - automatische Verbindung vorgesehen, - Richtlinienprofil vorhanden, - Access Point sendet die erwartete Konfiguration. Das Löschen und Neuerstellen eines Profils ist eine Änderung. Vorher sollten Profilquelle, Unternehmensrichtlinie und Zugangsdaten geklärt werden.
---
37. Keine vorschnellen WLAN-Änderungen durchführen Nicht unkontrolliert: - WLAN-Profil löschen, - Kennwort im Klartext exportieren, - Access Point neu starten, - Kanal oder Kanalbreite beliebig ändern, - Regulierungsdomäne verändern, - Sendeleistung maximieren, - WPA3 oder 802.1X deaktivieren, - Zertifikatsprüfung umgehen, - private MAC-Adresse pauschal deaktivieren, - Treiber ungeprüft ersetzen, - Controllerkonfiguration ändern, - Roamingfunktionen abschalten, - Funknetz während der Geschäftszeit neu planen. **Sicherer Ablauf:** 1. Istzustand und Standort dokumentieren. 2. SSID, BSSID, Kanal, Band und Signal erfassen. 3. Fehler reproduzieren. 4. Client und Vergleichsgerät prüfen. 5. Authentifizierung und VLAN-Zuweisung kontrollieren. 6. DHCP, Gateway und DNS testen. 7. Lokalen Durchsatz messen. 8. Client-, AP-, Controller- und RADIUS-Protokolle vergleichen. 9. Ursache nachweisen. 10. Änderung genehmigen lassen. 11. Auswirkung auf andere Funkzellen und Clients berücksichtigen. 12. Nachprüfung am ursprünglichen Fehlerort durchführen.
---
38. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Störungsumfang bestimmen | Client, Standort, BSSID, SSID oder gesamtes WLAN? | | 2 | Hardwarestatus prüfen | Wird der WLAN-Adapter korrekt erkannt? | | 3 | Treiber und Fähigkeiten prüfen | Unterstützt der Client Band und Sicherheitsverfahren? | | 4 | Funkumgebung erfassen | Ist die SSID sichtbar und wie stark ist das Signal? | | 5 | BSSID und Kanal dokumentieren | Mit welcher Funkzelle ist der Client verbunden? | | 6 | Authentifizierung prüfen | Wird Personal- oder Enterprise-Anmeldung akzeptiert? | | 7 | VLAN-Zuweisung prüfen | Landet der Client im vorgesehenen Netz? | | 8 | IP-Konfiguration prüfen | Sind Adresse, Gateway und DNS korrekt? | | 9 | Gateway testen | Funktioniert der lokale Netzwerkpfad? | | 10 | DNS testen | Werden Namen korrekt aufgelöst? | | 11 | Anwendung testen | Funktioniert der tatsächlich benötigte Dienst? | | 12 | Paketverlust messen | Ist die Funkverbindung stabil? | | 13 | Lokalen Durchsatz messen | Welche Leistung liefert nur das WLAN? | | 14 | Roaming prüfen | Tritt der Fehler beim BSSID-Wechsel auf? | | 15 | Kanal und Auslastung prüfen | Ist die Funkzelle gestört oder überlastet? | | 16 | AP-Uplink prüfen | Funktioniert die kabelgebundene Infrastruktur? | | 17 | Protokolle vergleichen | Welche Komponente lehnt ab oder trennt? | | 18 | Minimale Änderung planen | Welche konkrete Korrektur stellt den Sollzustand her? | | 19 | Nachprüfung | Funktioniert es am ursprünglichen Standort unter Last? | | 20 | Dokumentation | Sind Ursache, Messwerte und Änderung festgehalten? |
---
39. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | WLAN-Verbindungsstatus | `[RO][SENS] netsh wlan show interfaces` | `[RO][SENS] iw dev wlan0 link` | `[RO][SENS] networksetup -getairportnetwork en0` | | Netzwerkschnittstellen | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] networksetup -listallhardwareports` | | Sichtbare WLANs | `[RO][SENS] netsh wlan show networks mode=bssid` | `[TEST][SENS] nmcli device wifi list` | Wireless Diagnostics beziehungsweise `[RO][PRIV][SENS] sudo wdutil info`, falls unterstützt | | WLAN-Treiber | `[RO][SENS] netsh wlan show drivers` | `[RO][SENS] lspci -k` beziehungsweise `[RO][SENS] lsusb` | `[RO][SENS] system_profiler SPAirPortDataType` | | WLAN-Fähigkeiten | `[RO][SENS] netsh wlan show wirelesscapabilities` | `[RO][SENS] iw list` | `[RO][SENS] system_profiler SPAirPortDataType` | | Gespeicherte Profile | `[RO][SENS] netsh wlan show profiles` | `[RO][SENS] nmcli connection show` | Über WLAN-Einstellungen beziehungsweise MDM prüfen | | IP-Konfiguration | `[RO][SENS] Get-NetIPConfiguration` | `[RO][SENS] ip -br address` | `[RO][SENS] networksetup -getinfo "Wi-Fi"` | | Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | DNS-Konfiguration | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | Adapterstatistik | `[RO] Get-NetAdapterStatistics` | `[RO][SENS] iw dev wlan0 station dump` | Abhängig von macOS-Version: `wdutil` prüfen | | WLAN-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational"` | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager` | Wireless Diagnostics | | WLAN-Bericht | `[RO][PRIV][FILE][SENS] netsh wlan show wlanreport` | Protokolle und Befehlsausgaben getrennt sichern | Wireless Diagnostics erzeugt Diagnosearchiv | | Gatewaytest | `[TEST] Test-Connection GATEWAY_IP -Count 20` | `[TEST] ping -c 20 GATEWAY_IP` | `[TEST] ping -c 20 GATEWAY_IP` | | Lokaler Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `wlan0`, `en0`, `Wi-Fi`, `GATEWAY_IP` und `SERVER_IP` müssen durch die tatsächlich ermittelten Werte ersetzt werden.
---
40. Dokumentationsvorlage für WLAN-Fehler ```text Störung: Zeitpunkt: Zeitzone: Standort: Raum beziehungsweise Bereich: Benutzer: Client: Betriebssystem: WLAN-Adapter: Treiberversion: SSID: BSSID: Access Point: Frequenzband: Frequenz: Kanal: Kanalbreite: WLAN-Standard: Signal beziehungsweise RSSI: Rauschpegel: SNR: TX-PHY-Rate: RX-PHY-Rate: Sicherheitsverfahren: Authentifizierung erfolgreich: 802.1X-Verfahren: RADIUS-Ergebnis: Zugewiesenes VLAN: Client-IP-Adresse: Präfix: Standardgateway: DHCP-Server: DNS-Server: IPv6-Konfiguration: Gatewaytest: Paketverlust: Latenz: DNS-Test: Anwendungstest: Lokaler iperf3-Test: Internettest: Captive Portal: Private MAC-Adresse: Alte BSSID vor Roaming: Neue BSSID nach Roaming: Unterbrechungsdauer: Roamingzeitpunkt: Vergleichsgerät: Vergleich an anderem Standort: Vergleich über Ethernet: Andere Clients betroffen: Andere SSIDs betroffen: Access-Point-Protokoll: Controllerprotokoll: RADIUS-Protokoll: Switchportstatus: PoE-Status: Uplinkfehler: DFS-Ereignis: Kanalauslastung: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
41. Kontrollfragen nach der Diagnose - Ist nur ein Client, Standort, Access Point oder die gesamte SSID betroffen? - Wird der WLAN-Adapter fehlerfrei erkannt? - Unterstützt der Client das verwendete Band und Sicherheitsverfahren? - Ist die gewünschte SSID sichtbar? - Mit welcher BSSID ist der Client verbunden? - Stimmen Frequenzband, Kanal und Kanalbreite? - Wie hoch sind Signal, Rauschen und SNR? - Ist die angezeigte PHY-Rate plausibel? - Wird die Authentifizierung erfolgreich abgeschlossen? - Ist bei Enterprise-WLAN das Zertifikat gültig? - Wird das vorgesehene VLAN zugewiesen? - Erhält der Client eine gültige IP-Konfiguration? - Ist das Standardgateway erreichbar? - Funktioniert DNS? - Funktioniert die Anwendung über IP-Adresse und Hostname? - Tritt Paketverlust bereits zum lokalen Gateway auf? - Wurde der lokale Durchsatz unabhängig vom Internet gemessen? - Tritt der Fehler nur bei hoher Auslastung auf? - Tritt er beim Wechsel der BSSID auf? - Bleibt der Client an einer weit entfernten BSSID hängen? - Wurden DFS- und Kanalwechselereignisse geprüft? - Ist der kabelgebundene Uplink des Access Points fehlerfrei? - Wurden Client-, AP-, Controller- und RADIUS-Protokolle zeitlich verglichen? - Wurde die Ursache vor einer Kanal-, Profil- oder Sicherheitsänderung nachgewiesen? - Wurde nach der Änderung am ursprünglichen Fehlerort erneut gemessen?
---
42. Quellen und weiterführende Dokumentation - Microsoft Learn – `netsh wlan`: https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-wlan - Microsoft Support – WLAN-Bericht unter Windows analysieren: https://support.microsoft.com/windows/analyze-the-wireless-network-report-76da0daa-1db2-6049-d154-7bb679eb03ed - Microsoft Learn – WLAN-AutoConfig-Dienst: https://learn.microsoft.com/windows-server/networking/technologies/extensible-authentication-protocol/network-access - Linux Wireless Documentation – `iw`: https://wireless.docs.kernel.org/en/latest/en/users/documentation/iw.html - NetworkManager – `nmcli`: https://networkmanager.dev/docs/api/latest/nmcli.html - NetworkManager – WLAN-Einstellungen: https://networkmanager.dev/docs/api/latest/settings-802-11-wireless.html - Apple – Diagnose für drahtlose Umgebungen verwenden: https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac - Apple – Wenn der Mac keine WLAN-Internetverbindung herstellt: https://support.apple.com/de-de/101588 - Apple – `networksetup` in Remote Desktop: https://support.apple.com/de-de/guide/remote-desktop/apdd0c5a2d5/mac - Wi-Fi Alliance – Discover Wi-Fi: https://www.wi-fi.org/discover-wi-fi - IEEE 802.11 Working Group: https://www.ieee802.org/11/ - RFC 5416 – CAPWAP Protocol Binding for IEEE 802.11: https://www.rfc-editor.org/rfc/rfc5416.html - iPerf3 – Offizielle Dokumentation: https://software.es.net/iperf/
# 3.15 Paketverlust, Latenz, Jitter und Bandbreite analysieren Netzwerkleistung besteht aus mehreren voneinander unabhängigen Messgrößen. Eine Verbindung kann einen hohen Durchsatz erreichen und trotzdem für Sprache, Remotezugriff oder Echtzeitanwendungen ungeeignet sein. Umgekehrt kann eine Verbindung mit begrenzter Bandbreite sehr stabil und reaktionsschnell arbeiten. Die zentralen Fragen dieser Seite lauten: > An welchem Abschnitt des Datenpfads verschlechtert sich die Verbindung, welche Messgröße ist betroffen und tritt das Problem dauerhaft oder nur unter Last auf? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen | Bandbreiten- und Lasttests dürfen nur gegen ausdrücklich freigegebene Systeme durchgeführt werden. Sie können Leitungen, Firewalls, Server und andere Benutzer erheblich belasten.
---
2. Die wichtigsten Leistungsbegriffe unterscheiden | Begriff | Bedeutung | |---|---| | Latenz | Zeit, die eine Übertragung von einem Punkt zu einem anderen benötigt | | Round-Trip Time – RTT | Zeit für Hin- und Rückweg | | Jitter | Schwankung der Paketlaufzeit | | Paketverlust | Anteil gesendeter Pakete, die das Ziel beziehungsweise die Messstelle nicht erreichen | | Bandbreite | Theoretische oder konfigurierte Übertragungskapazität | | Durchsatz | Tatsächlich übertragene Datenmenge pro Zeit | | Goodput | Für die Anwendung nutzbare Datenmenge ohne Protokoll- und Wiederholungsdaten | | Retransmission | Erneute Übertragung verlorener oder nicht bestätigter TCP-Daten | | Congestion | Überlastung eines Netzwerkpfads oder einer Warteschlange | | Bufferbloat | Stark steigende Latenz durch übermäßig gefüllte Warteschlangen | | Burst Loss | Mehrere Paketverluste in kurzer Folge | | Out-of-Order | Pakete treffen in anderer Reihenfolge ein | | Duplication | Pakete treffen mehrfach ein | | Queueing Delay | Verzögerung durch Warteschlangen | | Serialization Delay | Zeit, um ein Paket auf einen Link zu übertragen | | Processing Delay | Verarbeitungszeit in einem Netzwerkgerät | | Propagation Delay | Physikalische Signallaufzeit über das Medium |
---
3. Bit, Byte und Übertragungsraten richtig umrechnen ```text 1 Byte = 8 Bit ``` | Einheit | Bedeutung | |---|---:| | `1 kbit/s` | üblicherweise 1.000 Bit pro Sekunde | | `1 Mbit/s` | üblicherweise 1.000.000 Bit pro Sekunde | | `1 Gbit/s` | üblicherweise 1.000.000.000 Bit pro Sekunde | | `1 MB/s` | 8 Mbit/s | | `100 MB/s` | 800 Mbit/s | | `125 MB/s` | 1.000 Mbit/s beziehungsweise 1 Gbit/s | Dateigrößen können binär oder dezimal angegeben werden. Zusätzlich reduzieren Protokoll-Overhead, Verschlüsselung, Wiederholungen und Dateisystemverarbeitung den nutzbaren Durchsatz. **Beispiel:** ```text 1-Gbit/s-Ethernet ≠ 125 MB/s garantierte Nutzdatenrate ```
---
4. Messziel und Datenpfad vollständig beschreiben Vor der Messung ist der genaue Pfad zu dokumentieren: ```text Client ↓ WLAN oder Ethernet ↓ Access Point oder Switch ↓ Router beziehungsweise Firewall ↓ VPN, WAN oder Internet ↓ Zielnetz ↓ Server ↓ Anwendung und Datenträger ``` Benötigte Angaben: ```text Quelle: Quell-IP: Quellschnittstelle: Ziel: Ziel-IP: Transportprotokoll: Zielport: IPv4 oder IPv6: VPN beteiligt: Proxy beteiligt: NAT beteiligt: Testzeitpunkt: Gegenrichtung: Erwartete Leistung: Beobachtete Leistung: ``` Ohne definierten Messpfad ist die Aussage „Das Netzwerk ist langsam“ nicht technisch verwertbar.
---
5. Die Verbindung abschnittsweise messen | Messabschnitt | Typisches Ziel | |---|---| | Client zur lokalen Schnittstelle | Adapter und Betriebssystem | | Client zum Standardgateway | lokales LAN beziehungsweise WLAN | | Client zu lokalem Server | internes Netzwerk | | Client zu anderem VLAN | Routing und interne Firewall | | Client zum VPN-Gateway | Internet- oder WAN-Basisverbindung | | Client durch VPN zum internen Server | Tunnel, VPN-Routing und Zielnetz | | Client zum Internetziel | Provider- und Internetpfad | | Reverse Proxy zum Backend | Servernetz und Backend | | Server zum Datenspeicher | Speicher- oder Anwendungsengpass | **Grundregel:** > Mit der nächstgelegenen sinnvollen Messstelle beginnen und den Pfad schrittweise erweitern.
---
6. Einzelmessung und Langzeitmessung unterscheiden Eine einzelne Messung kann zufällig in einem guten oder schlechten Moment stattfinden. Für eine belastbare Diagnose dokumentieren: - Anzahl der Messwerte, - Messdauer, - Messintervall, - Minimum, - Maximum, - Durchschnitt, - Median, - relevante Perzentile, - Paketverlust, - Zeitpunkt auffälliger Spitzen, - gleichzeitige Netzlast, - Benutzerzahl, - Testmethode. **Durchschnittswerte können kurze Ausfälle verdecken:** ```text 99 Messungen: 10 ms 1 Messung: 2.000 ms Durchschnitt: 29,9 ms ``` Der Durchschnitt wirkt noch relativ niedrig, obwohl eine einzelne Verzögerung von zwei Sekunden für Echtzeitanwendungen deutlich spürbar sein kann.
---
7. ICMP-Ping sinnvoll einsetzen Ping misst die Round-Trip Time von ICMP Echo Request und Echo Reply. **Windows:** ```cmd [TEST] ping -n 20 ZIEL_IP ``` **Windows PowerShell:** ```powershell [TEST] Test-Connection ZIEL_IP -Count 20 ``` **Linux:** ```bash [TEST] ping -c 20 ZIEL_IP ``` **macOS:** ```bash [TEST] ping -c 20 ZIEL_IP ``` Zu dokumentieren sind: - gesendete Pakete, - empfangene Pakete, - Verlust in Prozent, - minimale RTT, - durchschnittliche RTT, - maximale RTT, - starke Schwankungen. **Wichtig:** Ein Ziel kann ICMP blockieren oder niedriger priorisieren, während Anwendungsverkehr weiterhin funktioniert.
---
8. Ping-Ergebnisse korrekt interpretieren | Beobachtung | Mögliche Bedeutung | |---|---| | Gleichmäßig niedrige RTT | Pfad ist für diese Messung stabil | | Dauerhaft hohe RTT | Entfernung, langsamer Link, Tunnel oder Überlastung | | Einzelne starke Spitzen | Queueing, Funkstörung, Last oder Verarbeitungsspitze | | Regelmäßige Spitzen | periodischer Datenverkehr, Scan, Backup oder Energiesparfunktion | | Vereinzelter Verlust | Störung, Überlastung oder ICMP-Priorisierung | | Verlust in Bursts | Link-Flap, Funkproblem, Queue Drop oder Pfadwechsel | | Kein Ping, Anwendung funktioniert | ICMP wird möglicherweise gefiltert | | Ping zur IP funktioniert, zum Namen nicht | Namensauflösung prüfen | | Gatewayping schlecht | Problem wahrscheinlich bereits im lokalen Zugangsnetz | | Gatewayping gut, externes Ziel schlecht | Problem liegt wahrscheinlich hinter dem Gateway | Ein Ping beweist nicht die Leistungsfähigkeit von TCP, UDP oder der Anwendung.
---
9. Lokales Gateway zuerst messen **Standardgateway ermitteln:** Windows: ```powershell [RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Format-Table InterfaceAlias, NextHop, RouteMetric ``` Linux: ```bash [RO] ip route show default ``` macOS: ```bash [RO] route -n get default ``` **Gateway über längeren Zeitraum testen:** Windows: ```cmd [TEST] ping -n 100 GATEWAY_IP ``` Linux und macOS: ```bash [TEST] ping -c 100 GATEWAY_IP ``` Wenn bereits zum lokalen Gateway Paketverlust oder starke Latenzschwankungen auftreten, sollten zuerst folgende Komponenten geprüft werden: - WLAN-Funkverbindung, - Ethernetkabel, - Switchport, - Netzwerkadapter, - Treiber, - Duplex und Linkgeschwindigkeit, - lokaler Router, - Clientauslastung.
---
10. Mehrere Messziele parallel vergleichen Für die Eingrenzung werden mehrere Ziele betrachtet: ```text Ziel 1: lokales Gateway Ziel 2: interner Server Ziel 3: WAN-Gegenstelle Ziel 4: Anwendungsserver ``` **Interpretationsbeispiel:** | Gateway | Interner Server | Externes Ziel | Mögliche Eingrenzung | |---|---|---|---| | gut | gut | schlecht | WAN, Provider oder externer Pfad | | gut | schlecht | gut | internes Routing, VLAN oder Serverpfad | | schlecht | schlecht | schlecht | lokales Zugangsnetz | | gut | gut | gut | möglicherweise anwendungsspezifisches Problem | | gut | nur VPN-Ziel schlecht | gut | VPN oder entferntes Netz | Parallele Messungen müssen mit sinnvollen Intervallen erfolgen, damit die Diagnose nicht selbst unnötige Last erzeugt.
---
11. TCP-Erreichbarkeit und TCP-Latenz prüfen Wenn ICMP blockiert wird, kann ein Test zum tatsächlichen TCP-Port sinnvoller sein. **Windows:** ```powershell [TEST] Test-NetConnection server.example.internal ` -Port 443 ` -InformationLevel Detailed ``` **Linux und macOS:** ```bash [TEST] nc -vz -w 5 server.example.internal 443 ``` Diese Befehle zeigen hauptsächlich, ob ein TCP-Verbindungsaufbau möglich ist. Sie liefern noch keine vollständige Leistungsmessung. **Windows mit PsPing, sofern autorisiert installiert:** ```cmd [TEST] psping -n 20 server.example.internal:443 ``` PsPing kann TCP-Verbindungszeiten messen und ist besonders nützlich, wenn ICMP nicht beantwortet wird.
---
12. Anwendungsantwortzeiten mit curl zerlegen **Zeitanteile einer HTTP- beziehungsweise HTTPS-Anfrage:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://service.example.net/ ``` | curl-Wert | Bedeutung | |---|---| | `time_namelookup` | Zeit bis zum Abschluss der Namensauflösung | | `time_connect` | Zeit bis zum TCP-Verbindungsaufbau | | `time_appconnect` | Zeit bis zum Abschluss des TLS-Handshakes | | `time_starttransfer` | Zeit bis zum ersten Antwortbyte | | `time_total` | Gesamtdauer | | `http_code` | HTTP-Statuscode | **Typische Eingrenzung:** | Auffälliger Wert | Mögliche Ursache | |---|---| | DNS-Zeit hoch | DNS-Server, Suche oder Netzwerkpfad | | Connect-Zeit hoch | Latenz, Paketverlust, Firewall oder Serverlistener | | TLS-Zeit hoch | TLS-Handshake, Zertifikatsprüfung oder CPU | | StartTransfer hoch | Server, Datenbank oder Backend | | Total hoch, StartTransfer normal | große Antwort, begrenzte Bandbreite oder langsamer Client |
---
13. Netzwerkpfad mit traceroute und tracert prüfen **Windows ohne Namensauflösung:** ```cmd [TEST] tracert -d ZIEL_IP ``` **Linux:** ```bash [TEST] traceroute -n ZIEL_IP ``` Falls `traceroute` nicht installiert ist: ```bash [TEST] tracepath -n ZIEL_IP ``` **macOS:** ```bash [TEST] traceroute -n ZIEL_IP ``` Zu kontrollieren sind: - Anzahl der Hops, - Änderung des Pfads, - sprunghafter Latenzanstieg, - Zeitüberschreitungen, - unterschiedliche IPv4- und IPv6-Pfade, - asymmetrische oder lastverteilte Pfade. Ein Sternchen bei einem Zwischenrouter beweist keinen Paketverlust des weitergeleiteten Nutzverkehrs. Der Router kann Antworten auf Diagnosepakete begrenzen oder vollständig unterdrücken.
---
14. IPv4 und IPv6 getrennt messen Ein Hostname kann sowohl IPv4- als auch IPv6-Adressen besitzen. Die Pfade und Leistungswerte können deutlich voneinander abweichen. **Windows:** ```cmd [TEST] ping -4 -n 20 HOSTNAME [TEST] ping -6 -n 20 HOSTNAME ``` ```cmd [TEST] tracert -4 -d HOSTNAME [TEST] tracert -6 -d HOSTNAME ``` **Linux:** ```bash [TEST] ping -4 -c 20 HOSTNAME [TEST] ping -6 -c 20 HOSTNAME ``` **macOS:** ```bash [TEST] ping -c 20 IPV4_ADRESSE [TEST] ping6 -c 20 IPV6_ADRESSE ``` **HTTP getrennt testen:** ```bash [TEST] curl -4 -I https://service.example.net/ [TEST] curl -6 -I https://service.example.net/ ``` Ein gutes IPv4-Ergebnis beweist nicht, dass der IPv6-Pfad ebenfalls funktioniert.
---
15. Windows pathping verwenden `pathping` kombiniert Pfadermittlung mit wiederholten Messungen zu Zwischenstationen. **Ohne Namensauflösung:** ```cmd [TEST] pathping /n ZIEL_IP ``` **IPv4:** ```cmd [TEST] pathping /n /4 ZIEL_IP ``` **IPv6:** ```cmd [TEST] pathping /n /6 ZIEL_IP ``` Die Messung kann mehrere Minuten dauern. **Wichtige Interpretation:** Wenn ein Zwischenhop hohen Verlust zeigt, spätere Hops und das Ziel aber keinen entsprechenden Verlust zeigen, priorisiert oder begrenzt der Zwischenrouter wahrscheinlich nur seine eigenen ICMP-Antworten. Ein echter Weiterleitungsverlust wird typischerweise ab einer Stelle auch an nachfolgenden Hops beziehungsweise am Ziel sichtbar.
---
16. MTR unter Linux und macOS verwenden `mtr` kombiniert fortlaufende Pfad- und Latenzmessungen. Es ist nicht auf jedem System standardmäßig installiert. **Prüfen, ob MTR vorhanden ist:** ```bash [RO] command -v mtr ``` **Interaktive Messung ohne Namensauflösung:** ```bash [TEST] mtr -n ZIEL_IP ``` **Berichtsmodus mit 100 Messzyklen:** ```bash [TEST] mtr -n -r -c 100 ZIEL_IP ``` **TCP-basierter Test zu Port 443, sofern von der installierten Version unterstützt:** ```bash [TEST][PRIV] sudo mtr -n -r -c 100 -T -P 443 ZIEL_IP ``` Vor Verwendung erweiterter Optionen lokale Hilfe prüfen: ```bash [RO] mtr --help ``` Auch bei MTR gilt: Verlust an einem Zwischenhop allein ist kein Beweis für weitergeleiteten Paketverlust.
---
17. Paketverlust mathematisch einordnen ```text Paketverlust in Prozent = (verlorene Pakete ÷ gesendete Pakete) × 100 ``` Beispiel: ```text Gesendet: 1.000 Empfangen: 990 Verloren: 10 Paketverlust = 1 % ``` Die Auswirkungen hängen von Anwendung und Verteilung des Verlusts ab. | Verlustmuster | Mögliche Wirkung | |---|---| | Einzelne gleichmäßig verteilte Verluste | TCP-Wiederholungen, kurze Audiofehler | | Mehrere Verluste in Folge | deutliche Unterbrechung oder Timeout | | Verlust nur unter Last | überfüllte Queue oder überlasteter Link | | Verlust nur in eine Richtung | asymmetrisches Problem | | Verlust nur großer Pakete | MTU- oder Fragmentierungsproblem | | ICMP-Verlust ohne Anwendungsverlust | mögliche ICMP-Priorisierung | Burst Loss ist für Echtzeitanwendungen häufig problematischer als derselbe prozentuale Verlust gleichmäßig verteilt.
---
18. Jitter messen und beurteilen Jitter beschreibt die Schwankung von Paketlaufzeiten. Es gibt unterschiedliche Berechnungsmethoden; Werte verschiedener Werkzeuge sind daher nicht immer direkt vergleichbar. **Typische Symptome hohen Jitters:** - abgehackte Sprache, - schwankende Videoqualität, - Ruckeln bei Remote-Desktop, - ungleichmäßige Echtzeitdaten, - vergrößerte Wiedergabepuffer, - kurze Aussetzer trotz geringem Durchschnittsping. `ping` zeigt Schwankungen der RTT, ist aber kein vollständiger Ersatz für eine anwendungsnahe Jittermessung. Für UDP kann `iperf3` Jitter und Datagrammverlust ausgeben: ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 ``` Mit niedriger, kontrollierter Zielrate beginnen. Eine zu hohe Testbandbreite erzeugt selbst Verlust und Jitter.
---
19. iperf3-Testumgebung vorbereiten Für eine kontrollierte Messung werden benötigt: ```text iperf3-Client iperf3-Server freigegebener Testpfad bekannte Schnittstellen ausreichende Serverleistung definierte Testdauer ``` **Server starten:** ```bash [TEST] iperf3 -s ``` Standardmäßig verwendet iperf3 Port `5201`. Der Port kann verändert werden. **Clienttest:** ```bash [TEST] iperf3 -c SERVER_IP ``` **Anderer Port:** Server: ```bash [TEST] iperf3 -s -p 5202 ``` Client: ```bash [TEST] iperf3 -c SERVER_IP -p 5202 ``` Firewallregeln müssen zum gewählten Transport und Port passen. Bei UDP-Tests verwendet iperf3 zusätzlich eine TCP-Steuerverbindung. Die genaue Port- und Firewallkonfiguration ist deshalb vorab zu prüfen.
---
20. TCP-Durchsatz mit iperf3 messen **Standardtest vom Client zum Server:** ```bash [TEST] iperf3 -c SERVER_IP ``` **30 Sekunden testen:** ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` **Gegenrichtung – Server sendet zum Client:** ```bash [TEST] iperf3 -c SERVER_IP -R -t 30 ``` **Beide Richtungen gleichzeitig, sofern unterstützt:** ```bash [TEST] iperf3 -c SERVER_IP --bidir -t 30 ``` **Mehrere parallele TCP-Datenströme:** ```bash [TEST] iperf3 -c SERVER_IP -P 4 -t 30 ``` Parallele Datenströme können einen Pfad stärker auslasten und höhere Messwerte erzielen. Sie können aber Probleme eines einzelnen Datenstroms verdecken und erhebliche Last erzeugen. **Empfohlene Reihenfolge:** 1. Ein TCP-Datenstrom zum Server. 2. Ein TCP-Datenstrom in Gegenrichtung. 3. Bei Bedarf mehrere Datenströme. 4. Erst danach gleichzeitiger bidirektionaler Test.
---
21. UDP mit iperf3 kontrolliert messen **UDP-Test mit 10 Mbit/s Zielrate:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 ``` **Gegenrichtung:** ```bash [TEST] iperf3 -c SERVER_IP -u -b 10M -t 30 -R ``` **Relevante Ergebnisse:** - gesendete Bitrate, - empfangene Bitrate, - Jitter, - verlorene Datagramme, - Verlustquote, - Out-of-Order-Pakete, falls ausgegeben. **Teststrategie:** ```text niedrige Rate → Ergebnis prüfen → Rate schrittweise erhöhen → Beginn von Verlust und Jitter dokumentieren ``` Nicht sofort mit der maximal erwarteten Linkgeschwindigkeit beginnen. Ein UDP-Test besitzt keine TCP-Staukontrolle und kann andere Verbindungen stark beeinträchtigen.
---
22. iperf3-Ergebnisse als JSON speichern **JSON-Ausgabe anzeigen:** ```bash [TEST][SENS] iperf3 -c SERVER_IP -J ``` **In Datei speichern:** ```bash [TEST][FILE][SENS] iperf3 -c SERVER_IP -t 30 -J > iperf3-test.json ``` **UDP-Ergebnis speichern:** ```bash [TEST][FILE][SENS] iperf3 -c SERVER_IP \ -u -b 10M -t 30 -J > iperf3-udp-test.json ``` Vor einer Weitergabe prüfen, ob die Datei interne IP-Adressen, Hostnamen oder andere sensible Angaben enthält.
---
23. iperf3-Ergebnisse richtig interpretieren | Beobachtung | Mögliche Bedeutung | |---|---| | Hinrichtung gut, Rückrichtung schlecht | asymmetrischer Pfad, QoS, Empfangs- oder Sendeseite | | Ein Stream schlecht, mehrere gut | RTT, TCP-Fenster, Verlust oder CPU pro Stream | | TCP gut, UDP bei niedriger Rate schlecht | Queue, Policing, Funk- oder UDP-spezifischer Pfad | | UDP erst ab bestimmter Rate mit Verlust | Kapazitäts- beziehungsweise Queuegrenze | | Werte schwanken stark | Funk, Last, Pfadwechsel oder konkurrierender Verkehr | | Server- und Clientwerte unterscheiden sich | Verlust beziehungsweise unvollständige Übertragung | | Hohe Retransmissions | Paketverlust, Überlastung oder fehlerhafter Link | | Durchsatz exakt an einer Rate begrenzt | Policer, Shaper, Vertrag oder Schnittstellenlimit | | CPU nahe 100 Prozent | Endsystem kann der Engpass sein | | Datenträger langsam, iperf3 gut | Speicher oder Anwendung statt Netzwerk | Ein iperf3-Test misst Arbeitsspeicher-zu-Arbeitsspeicher-Netzwerkleistung und nicht automatisch Datei-, Datenbank- oder Anwendungsleistung.
---
24. TCP-Wiederholungen und Zustände prüfen **Windows-TCP-Statistik:** ```cmd [RO] netstat -s -p tcp ``` **Windows-Verbindungen:** ```powershell [RO] Get-NetTCPConnection | Format-Table LocalAddress, LocalPort, RemoteAddress, RemotePort, State ``` **Linux-TCP-Statistik:** ```bash [RO] nstat ``` Falls `nstat` nicht vorhanden ist: ```bash [RO] netstat -s ``` **Linux-Socketdiagnose:** ```bash [RO][SENS] ss -ti ``` **macOS-TCP-Statistik:** ```bash [RO] netstat -s -p tcp ``` Zähler sind kumulativ und müssen über einen definierten Messzeitraum verglichen werden. Ein hoher Gesamtwert allein beweist kein aktuelles Problem.
---
25. Schnittstellenzähler und physische Fehler prüfen **Windows:** ```powershell [RO] Get-NetAdapterStatistics | Format-Table Name, ReceivedBytes, SentBytes, ReceivedDiscardedPackets, OutboundDiscardedPackets, ReceivedPacketErrors, OutboundPacketErrors ``` **Linux:** ```bash [RO] ip -s link ``` **Linux – erweiterte Treiberstatistiken:** ```bash [RO][PRIV][SENS] sudo ethtool -S INTERFACE ``` **macOS:** ```bash [RO] netstat -ib ``` ```bash [RO] ifconfig ``` Zu prüfen sind: - RX- und TX-Fehler, - Drops, - verworfene Pakete, - CRC- beziehungsweise Framefehler, - Overruns, - Carrierfehler, - Link-Flaps, - steigende Fehlerzähler unter Last. Entscheidend ist, ob Zähler während des reproduzierten Fehlers ansteigen.
---
26. Linkgeschwindigkeit und Duplex prüfen **Windows:** ```powershell [RO] Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MediaConnectionState ``` **Linux:** ```bash [RO] ip link show INTERFACE ``` ```bash [RO][PRIV] sudo ethtool INTERFACE ``` **macOS:** ```bash [RO] ifconfig INTERFACE ``` Abhängig vom Adapter können zusätzliche Informationen über `networksetup` oder `system_profiler` verfügbar sein. Zu prüfen sind: - erwartete Linkgeschwindigkeit, - Full Duplex oder Half Duplex, - Autonegotiation, - Linkstatus, - unerwartete Begrenzung auf 100 Mbit/s, - wiederholte Neuverhandlung, - Kabel- oder Portfehler. Ein Link mit 1 Gbit/s Anzeige beweist nicht, dass er fehlerfrei oder vollständig auslastbar ist.
---
27. Bufferbloat erkennen Bufferbloat liegt vor, wenn Warteschlangen unter Last stark anwachsen und dadurch die Latenz deutlich steigt. **Typisches Verhalten:** ```text Ping ohne Last: 10 ms Ping unter Last: 300 ms Paketverlust: möglicherweise gering Durchsatz: hoch ``` Trotz hohen Durchsatzes reagieren Sprache, Spiele, Remote-Desktop und interaktive Anwendungen schlecht. **Testablauf:** 1. Kontinuierlichen Ping zum geeigneten Ziel starten. 2. Basislatenz ohne Last dokumentieren. 3. Kontrollierten iperf3-Test starten. 4. Latenz während Downloadrichtung beobachten. 5. Latenz während Uploadrichtung beobachten. 6. Test stoppen. 7. Erholung der Latenz dokumentieren. **Beispiel:** Terminal 1: ```bash [TEST] ping ZIEL_IP ``` Terminal 2: ```bash [TEST] iperf3 -c SERVER_IP -t 30 ``` Anschließend: ```bash [TEST] iperf3 -c SERVER_IP -R -t 30 ``` Eine Optimierung kann Queue Management oder Traffic Shaping erfordern. Solche Änderungen müssen am tatsächlichen Engpass und nicht willkürlich am Client erfolgen.
---
28. QoS, Shaping und Policing berücksichtigen | Funktion | Wirkung | |---|---| | Classification | Verkehr wird einer Klasse zugeordnet | | Marking | Pakete erhalten beispielsweise eine DSCP-Markierung | | Queuing | Pakete werden in Warteschlangen eingeordnet | | Scheduling | Reihenfolge der Übertragung wird bestimmt | | Shaping | Datenrate wird durch Puffern geglättet | | Policing | Überschreitender Verkehr wird verworfen oder neu markiert | | Rate Limit | Datenrate wird begrenzt | | Priorisierung | Bestimmte Klassen werden bevorzugt behandelt | **Typische Symptome einer Richtlinie:** - exakt begrenzter Durchsatz, - nur bestimmte Anwendungen betroffen, - UDP und TCP verhalten sich unterschiedlich, - nur eine Richtung ist begrenzt, - Unterschied zwischen internen und externen Zielen, - Verhalten ändert sich zu bestimmten Uhrzeiten, - DSCP-Markierungen werden verändert oder entfernt. QoS ist kein Ersatz für ausreichende Kapazität. Eine Priorisierung kann wichtige Anwendungen schützen, erzeugt aber keine zusätzliche Bandbreite.
---
29. Server und Client als Engpass ausschließen Während des Netzwerktests sind auf beiden Endsystemen zu prüfen: - CPU-Auslastung, - Arbeitsspeicher, - Interruptlast, - Netzwerktreiber, - Energiesparzustand, - Verschlüsselungsleistung, - virtuelle CPU, - Hypervisor-Auslastung, - Containerlimits, - Datenträger, falls Anwendungstest, - Sicherheitssoftware. **Windows:** ```powershell [RO] Get-Counter '\Processor(_Total)\% Processor Time' ``` ```powershell [RO] Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 ``` **Linux:** ```bash [RO] uptime ``` ```bash [RO] top ``` **macOS:** ```bash [RO] top -l 1 ``` Ein Durchsatztest kann durch die Rechenleistung eines virtuellen oder kleinen Systems begrenzt werden, obwohl das Netzwerk höhere Kapazität besitzt.
---
30. Dateiübertragung nicht als alleinigen Netzwerktest verwenden Eine Dateiübertragung misst gleichzeitig: ```text Quelldatenträger + Dateisystem + Serverdienst + Protokoll + Netzwerk + Sicherheitsprüfung + Zieldatenträger ``` Mögliche nicht netzwerkbezogene Engpässe: - langsame HDD, - ausgelastetes RAID, - Virenscanner, - Dateiverschlüsselung, - Deduplizierung, - Kompression, - SMB-Signierung oder Verschlüsselung, - kleine Dateien und Metadatenoperationen, - Datenbankzugriffe, - CPU-Auslastung, - Cachezustand. **Empfohlene Trennung:** ```text iperf3 gut Dateikopie langsam → Speicher, Dateidienst oder Anwendung weiter prüfen ```
---
31. MTU und große Pakete prüfen **Windows mit Don't-Fragment-Bit:** ```cmd [TEST] ping -4 -f -l 1400 ZIEL_IP ``` **Linux:** ```bash [TEST] ping -4 -M do -s 1400 ZIEL_IP ``` **macOS:** ```bash [TEST] ping -D -s 1400 ZIEL_IP ``` **MTU anzeigen:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Get-NetIPInterface` | | Linux | `[RO] ip link show` | | macOS | `[RO] ifconfig` | Die Ping-Nutzdatenlänge ist nicht mit der gesamten IP-Paketgröße identisch. Header müssen zusätzlich berücksichtigt werden. **Typische MTU-Symptome:** - kleine Anfragen funktionieren, - große Übertragungen hängen, - VPN-Verbindungen betroffen, - TLS-Handshake unvollständig, - bestimmte Websites laden nur teilweise, - IPv6 meldet Packet Too Big.
---
32. Paketmitschnitt zur Leistungsanalyse verwenden **Linux:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host ZIEL_IP' \ -w performance-test.pcap ``` **macOS:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host ZIEL_IP' \ -w performance-test.pcap ``` **Windows mit Dumpcap – Schnittstellen ermitteln:** ```powershell [RO] dumpcap -D ``` **Mitschnitt:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host ZIEL_IP" ` -w performance-test.pcapng ``` Paketmitschnitte können vertrauliche Nutzdaten und Metadaten enthalten. Aufzeichnungsdauer und Filter sollten auf den benötigten Umfang begrenzt werden.
---
33. Wireshark-Filter für Leistungsprobleme | Aufgabe | Anzeigefilter | |---|---| | Verkehr zu einer IPv4-Adresse | `ip.addr == 192.0.2.20` | | Verkehr zu einer IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | TCP-Wiederholungen | `tcp.analysis.retransmission` | | Schnelle Wiederholungen | `tcp.analysis.fast_retransmission` | | Vermutete verlorene Segmente | `tcp.analysis.lost_segment` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | Window Full | `tcp.analysis.window_full` | | TCP-Reset | `tcp.flags.reset == 1` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | DNS-Antwortzeit | `dns.time` | | TCP-Verbindungsaufbau | `tcp.connection.syn || tcp.connection.synack` | Wireshark-Analyseflags sind Schlussfolgerungen aus dem vorhandenen Mitschnitt. Fehlende Pakete am Messpunkt können falsche oder irreführende Markierungen erzeugen.
---
34. Einseitige und doppelseitige Mitschnitte unterscheiden **Einseitiger Mitschnitt:** ```text zeigt nur Pakete am lokalen Messpunkt ``` **Doppelseitiger Mitschnitt:** ```text Clientmitschnitt + Servermitschnitt + synchronisierte Zeit ``` Dadurch lässt sich erkennen: - ob ein Paket den Client verlässt, - wann es den Server erreicht, - ob der Server antwortet, - wann die Antwort den Client erreicht, - in welcher Richtung Verlust auftritt, - wo zusätzliche Verzögerung entsteht, - ob ein Netzwerkgerät Pakete verändert. Für exakte Laufzeitvergleiche müssen die Uhren der Messsysteme ausreichend synchronisiert sein.
---
35. Zwischenhop-Verlust nicht falsch interpretieren Beispiel: ```text Hop 1: 0 % Verlust Hop 2: 60 % Verlust Hop 3: 0 % Verlust Ziel: 0 % Verlust ``` Hop 2 leitet den Verkehr offensichtlich weiter, antwortet aber nur eingeschränkt auf Diagnosepakete. **Wahrscheinlicher tatsächlicher Weiterleitungsverlust:** ```text Hop 1: 0 % Verlust Hop 2: 20 % Verlust Hop 3: 20 % Verlust Hop 4: 20 % Verlust Ziel: 20 % Verlust ``` Auch dieses Muster muss mit weiteren Messungen bestätigt werden, da Pfadwechsel, Load Balancing und asymmetrische Routen Ergebnisse beeinflussen können.
---
36. Typische Fehlerbilder systematisch eingrenzen **Fall A – Latenz bereits zum Gateway hoch** Prüfen: - WLAN-Signal und Kanal, - Kabel, - Switchport, - Duplex, - Adaptertreiber, - lokalen Router, - Clientlast. --- **Fall B – Gateway gut, Internet schlecht** Prüfen: - WAN-Auslastung, - Provider, - Routerqueue, - VPN, - Proxy, - externen Pfad, - IPv4 gegenüber IPv6. --- **Fall C – Durchsatz gut, Echtzeitanwendung schlecht** Prüfen: - Jitter, - Burst Loss, - Bufferbloat, - QoS, - UDP-Pfad, - Anwendungsserver. --- **Fall D – Download gut, Upload schlecht** Prüfen: - Upstreamkapazität, - Shaping, - Policing, - WLAN-Senderichtung, - asymmetrischen Pfad, - fehlerhafte TX-Zähler. --- **Fall E – Kleine Übertragungen funktionieren, große nicht** Prüfen: - MTU, - Path-MTU-Discovery, - ICMP-Blockierung, - Fragmentierung, - VPN-Overhead. --- **Fall F – iperf3 gut, Dateikopie langsam** Prüfen: - Datenträger, - Dateisystem, - SMB oder NFS, - Virenscanner, - Verschlüsselung, - Serverlast. --- **Fall G – Nur zu Stoßzeiten schlecht** Prüfen: - Linkauslastung, - Airtime, - Backup, - Synchronisation, - WAN-Kapazität, - Queue Drops, - Serverlast. --- **Fall H – Nur ein TCP-Datenstrom langsam** Prüfen: - RTT, - Paketverlust, - TCP-Fenster, - Empfangspuffer, - Congestion Control, - CPU eines einzelnen Prozesses.
---
37. Keine unkontrollierten Lasttests durchführen Nicht vorschnell: - maximale UDP-Rate senden, - viele parallele Datenströme starten, - Tests während kritischer Geschäftsprozesse durchführen, - produktive Server ohne Freigabe als iperf3-Ziel verwenden, - QoS oder Shaping deaktivieren, - Interfacezähler zurücksetzen, - MTU beliebig ändern, - Firewalls für Tests abschalten, - öffentliche Speedtest-Dienste mit sensiblen Systemen automatisiert belasten, - Messergebnisse verschiedener Pfade direkt vergleichen. **Sicherer Testablauf:** 1. Testumfang genehmigen lassen. 2. Quelle, Ziel und Pfad dokumentieren. 3. Niedrige Last verwenden. 4. Messdauer begrenzen. 5. Überwachung parallel aktivieren. 6. Last schrittweise erhöhen. 7. Test bei negativen Auswirkungen sofort beenden. 8. Hin- und Rückrichtung getrennt messen. 9. Ergebnis samt Uhrzeit dokumentieren. 10. Testdienste anschließend kontrolliert beenden.
---
38. Systematischer Diagnoseablauf | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Problem konkretisieren | Latenz, Jitter, Verlust oder Durchsatz? | | 2 | Quelle und Ziel dokumentieren | Welcher Datenpfad ist betroffen? | | 3 | Schnittstellenstatus prüfen | Stimmen Link, Geschwindigkeit und Fehlerzähler? | | 4 | Lokales Gateway messen | Beginnt das Problem bereits im Zugangsnetz? | | 5 | Internen Server messen | Ist das lokale LAN betroffen? | | 6 | Externen Pfad messen | Beginnt das Problem hinter dem Router? | | 7 | IPv4 und IPv6 vergleichen | Ist nur eine Adressfamilie betroffen? | | 8 | Pfad ermitteln | Welche Hops werden tatsächlich verwendet? | | 9 | Hin- und Rückrichtung messen | Ist das Problem asymmetrisch? | | 10 | TCP-Durchsatz messen | Welche Nutzrate erreicht ein Datenstrom? | | 11 | UDP kontrolliert messen | Wie entwickeln sich Jitter und Verlust? | | 12 | Latenz unter Last prüfen | Liegt Bufferbloat vor? | | 13 | Schnittstellenzähler vergleichen | Steigen Fehler oder Drops während des Tests? | | 14 | Endsystemlast prüfen | Begrenzen CPU oder Anwendung das Ergebnis? | | 15 | MTU prüfen | Scheitern nur größere Pakete? | | 16 | Paketmitschnitt erstellen | Sind Wiederholungen oder Zeitlücken sichtbar? | | 17 | Vergleichssystem messen | Ist das Ergebnis client- oder pfadspezifisch? | | 18 | Ursache nachweisen | Welche Messwerte belegen die Fehlerstelle? | | 19 | Minimale Änderung planen | Welche Korrektur behebt den Engpass? | | 20 | Nachprüfung durchführen | Verbessern sich alle relevanten Messgrößen? |
---
39. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Ping mit 20 Paketen | `[TEST] ping -n 20 ZIEL_IP` | `[TEST] ping -c 20 ZIEL_IP` | `[TEST] ping -c 20 ZIEL_IP` | | Standardgateway | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL_IP` | `[RO] ip route get ZIEL_IP` | `[RO] route -n get ZIEL_IP` | | Pfad ohne DNS | `[TEST] tracert -d ZIEL_IP` | `[TEST] traceroute -n ZIEL_IP` | `[TEST] traceroute -n ZIEL_IP` | | Pfad und Verlust | `[TEST] pathping /n ZIEL_IP` | Falls installiert: `[TEST] mtr -n -r -c 100 ZIEL_IP` | Falls installiert: `[TEST] mtr -n -r -c 100 ZIEL_IP` | | TCP-Porttest | `[TEST] Test-NetConnection HOST -Port PORT` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | TCP-Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | | Gegenrichtung | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | | UDP-Test | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | `[TEST] iperf3 -c SERVER_IP -u -b 10M` | | Schnittstellenzähler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Linkinformationen | `[RO] Get-NetAdapter` | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | TCP-Statistik | `[RO] netstat -s -p tcp` | `[RO] nstat` oder `[RO] netstat -s` | `[RO] netstat -s -p tcp` | | MTU | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | DF-Test | `[TEST] ping -4 -f -l 1400 ZIEL_IP` | `[TEST] ping -4 -M do -s 1400 ZIEL_IP` | `[TEST] ping -D -s 1400 ZIEL_IP` | | HTTP-Zeiten | `[TEST][SENS] curl.exe -w ... URL` | `[TEST][SENS] curl -w ... URL` | `[TEST][SENS] curl -w ... URL` | `ZIEL_IP`, `HOST`, `PORT`, `SERVER_IP`, `INTERFACE` und `URL` müssen durch die Werte des konkreten Störungsfalls ersetzt werden.
---
40. Dokumentationsvorlage für Leistungsprobleme ```text Störung: Zeitpunkt: Zeitzone: Standort: Benutzer: Client: Betriebssystem: Quellschnittstelle: Quell-IP: Linkgeschwindigkeit: Duplex: WLAN-SSID: WLAN-BSSID: WLAN-Signal: VPN beteiligt: Proxy beteiligt: Zielhostname: Ziel-IP: Zielport: Transportprotokoll: IPv4 oder IPv6: Erwarteter Datenpfad: Gemessener Datenpfad: Gateway-RRT Minimum: Gateway-RRT Durchschnitt: Gateway-RRT Maximum: Gateway-Paketverlust: Ziel-RTT Minimum: Ziel-RTT Durchschnitt: Ziel-RTT Maximum: Ziel-Paketverlust: Jitter: Burst Loss: iperf3 TCP Client zu Server: iperf3 TCP Server zu Client: iperf3 parallele Streams: iperf3 UDP Zielrate: iperf3 UDP empfangene Rate: iperf3 UDP Jitter: iperf3 UDP Verlust: Latenz ohne Last: Latenz unter Uploadlast: Latenz unter Downloadlast: RX-Fehler vorher: RX-Fehler nachher: TX-Fehler vorher: TX-Fehler nachher: Drops vorher: Drops nachher: TCP-Retransmissions: Client-CPU: Server-CPU: Server-Datenträger: Testdauer: Anzahl der Messungen: Vergleichssystem: Vergleichszeitpunkt: MTU: Größte erfolgreiche DF-Nutzlast: Paketmitschnitt: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
41. Kontrollfragen nach der Diagnose - Wurde das Problem als Latenz-, Jitter-, Verlust- oder Durchsatzproblem konkretisiert? - Sind Quelle, Ziel, Richtung und Datenpfad dokumentiert? - Wurde zuerst das lokale Gateway gemessen? - Wurden internes und externes Ziel getrennt geprüft? - Wurden IPv4 und IPv6 getrennt verglichen? - Wurde Hin- und Rückrichtung gemessen? - Wurden Einzelspitzen und nicht nur Durchschnittswerte betrachtet? - Wurde ein längerer Messzeitraum verwendet? - Wurde Zwischenhop-Verlust korrekt interpretiert? - Wurde TCP mit einem und mehreren Datenströmen verglichen? - Wurde UDP mit einer kontrollierten Zielrate getestet? - Wurden Jitter und Burst Loss erfasst? - Wurde die Latenz unter Last geprüft? - Steigen Schnittstellenfehler während des Tests? - Stimmen Linkgeschwindigkeit und Duplex? - Wurden Client- und Serverauslastung kontrolliert? - Wurde iperf3 von Datei- oder Anwendungsleistung getrennt? - Wurde die MTU geprüft? - Wurden Paketmitschnitte an beiden Enden erwogen? - War der Testumfang genehmigt und kontrolliert? - Wurde nach der Änderung mit derselben Methode erneut gemessen?
---
42. Quellen und weiterführende Dokumentation - Microsoft Learn – `ping`: https://learn.microsoft.com/windows-server/administration/windows-commands/ping - Microsoft Learn – `tracert`: https://learn.microsoft.com/windows-server/administration/windows-commands/tracert - Microsoft Learn – `pathping`: https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/pathping - Microsoft Sysinternals – PsPing: https://learn.microsoft.com/de-de/sysinternals/downloads/psping - ESnet – iperf3-Dokumentation: https://software.es.net/iperf/ - ESnet – iperf3-Aufruf und Optionen: https://software.es.net/iperf/invoking.html - Linux-Handbuch – `ping`: https://man7.org/linux/man-pages/man8/ping.8.html - Linux-Handbuch – `tracepath`: https://man7.org/linux/man-pages/man8/tracepath.8.html - MTR – Offizielle Dokumentation: https://mtr.readthedocs.io/ - Wireshark – TCP Display Filter Reference: https://www.wireshark.org/docs/dfref/t/tcp.html - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - RFC 3393 – IP Packet Delay Variation Metric: https://www.rfc-editor.org/rfc/rfc3393.html - RFC 2680 – One-way Packet Loss Metric: https://www.rfc-editor.org/rfc/rfc2680.html - RFC 6349 – Framework for TCP Throughput Testing: https://www.rfc-editor.org/rfc/rfc6349.html - RFC 8201 – Path MTU Discovery for IPv6: https://www.rfc-editor.org/rfc/rfc8201.html
# 3.16 Paketmitschnitt mit Wireshark, tcpdump, Dumpcap und Pktmon Ein Paketmitschnitt zeigt, welche Netzwerkpakete an einem bestimmten Messpunkt tatsächlich sichtbar sind. Damit lassen sich Vermutungen durch überprüfbare Beobachtungen ersetzen. Ein Mitschnitt beantwortet jedoch nur Fragen über den gewählten Messpunkt. Ein dort fehlendes Paket kann bereits vorher verloren gegangen sein, während ein sichtbares Paket hinter dem Messpunkt weiterhin verworfen werden kann. Die zentralen Fragen dieser Seite lauten: > Welcher Datenfluss muss untersucht werden, an welchem Punkt muss dafür aufgezeichnet werden und welches Paketmuster würde die jeweilige Hypothese bestätigen oder widerlegen? ---
1. Sicherheits- und Aktionskennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl, der normalerweise keine Konfiguration verändert | | `[TEST]` | Aktive Diagnose beziehungsweise Paketaufzeichnung | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Der Befehl schreibt Ausgaben in eine Datei | | `[SENS]` | Die Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Der Befehl verändert eine Konfiguration | | `[DISRUPT]` | Der Befehl kann eine Verbindung oder einen Dienst beeinträchtigen | Paketmitschnitte können enthalten: - interne und öffentliche IP-Adressen, - MAC-Adressen, - Hostnamen, - DNS-Anfragen, - unverschlüsselte Nutzdaten, - Cookies, - Sitzungstoken, - Benutzernamen, - E-Mail-Inhalte, - Dateiübertragungen, - API-Daten, - Authentifizierungsinformationen, - Netzwerk- und Sicherheitsarchitektur. Paketaufzeichnungen dürfen nur im genehmigten Umfang erstellt, gespeichert und weitergegeben werden.
---
2. Paketmitschnitt und Protokollierung unterscheiden | Datenquelle | Inhalt | |---|---| | Paketmitschnitt | Tatsächlich sichtbare Netzwerkframes beziehungsweise Pakete | | Betriebssystemprotokoll | Interpretation und Ereignisse des Betriebssystems | | Firewallprotokoll | Regelentscheidung wie Allow, Drop oder Reject | | Anwendungsprotokoll | Verarbeitung innerhalb der Anwendung | | Proxyprotokoll | Client-, Ziel-, Backend- und HTTP-Informationen | | Switchzähler | Fehler, Drops, Auslastung und Portstatus | | Controllerprotokoll | WLAN-, VPN- oder Infrastrukturereignisse | | Flow-Daten | Zusammengefasste Informationen über Netzwerkflüsse | | SNMP-Messwert | Zähler und Status eines Netzwerkgeräts | Ein Paketmitschnitt zeigt nicht automatisch: - welche Firewallregel entschieden hat, - warum eine Anwendung einen Fehler erzeugt hat, - ob ein Paket vor dem Messpunkt verworfen wurde, - ob ein verschlüsselter Inhalt fachlich korrekt ist, - ob ein Benutzer die richtige Berechtigung besitzt. Die beste Diagnose kombiniert Paketmitschnitt, Systemprotokoll und Anwendungsergebnis.
---
3. Datenfluss vor der Aufzeichnung definieren Vor dem Start müssen mindestens diese Angaben bekannt sein: ```text Clienthostname: Client-IP-Adresse: Serverhostname: Server-IP-Adresse: Transportprotokoll: Clientport: Serverport: Anwendungsprotokoll: IPv4 oder IPv6: Startzeitpunkt: Fehlerauslöser: Erwartetes Paketmuster: ``` **Beispiel:** ```text Client: 192.0.2.25 Server: 192.0.2.53 Transport: TCP Serverport: 443 Anwendung: HTTPS Fehler: Verbindung läuft in einen Timeout ``` Passender enger Filter: ```text host 192.0.2.25 and host 192.0.2.53 and tcp port 443 ``` Ein enger Filter reduziert Datenmenge und Datenschutzrisiko. Er kann jedoch wichtige Begleitprotokolle wie DNS, ARP, ICMP oder ICMPv6 ausblenden.
---
4. Den richtigen Messpunkt auswählen ```text Client ↓ Access Point oder Switch ↓ Router beziehungsweise Firewall ↓ VPN oder WAN ↓ Servernetz ↓ Server ↓ Anwendung ``` Mögliche Messpunkte: - direkt auf dem Client, - direkt auf dem Server, - auf dem Reverse Proxy, - auf dem VPN-Gateway, - auf der Firewall, - auf dem Router, - über einen Switch-Mirror-Port, - über einen Network TAP, - im Container, - auf dem Containerhost, - in der virtuellen Maschine, - auf dem Hypervisor. **Leitfrage:** > Welche Netzwerkkomponente baut die betroffene Verbindung tatsächlich auf? Bei einem Reverse Proxy ist der Administrator-PC nicht der richtige Messpunkt für die Verbindung zwischen Proxy und Backend.
---
5. Einseitigen und doppelseitigen Mitschnitt unterscheiden **Einseitiger Mitschnitt:** ```text Clientmitschnitt ``` Er zeigt nur, was am Client sichtbar ist. **Doppelseitiger Mitschnitt:** ```text Clientmitschnitt + Servermitschnitt + synchronisierte Zeit ``` Damit lässt sich feststellen: - ob ein Paket den Client verlässt, - ob es den Server erreicht, - ob der Server antwortet, - ob die Antwort den Client erreicht, - in welcher Richtung Verlust entsteht, - wo zusätzliche Verzögerung auftritt, - ob NAT oder Proxy Adressen verändert, - ob ein Netzwerkgerät Pakete zurücksetzt. Bei komplexen Problemen ist ein gleichzeitiger Mitschnitt an beiden Endpunkten wesentlich aussagekräftiger.
---
6. Zeit und Zeitzone synchronisieren Für den Vergleich mehrerer Mitschnitte und Protokolle müssen Zeit und Zeitzone bekannt sein. | Betriebssystem | Lokale Zeit | |---|---| | Windows | `[RO] Get-Date -Format o` | | Linux | `[RO] date --iso-8601=seconds` | | macOS | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | **UTC-Zeit:** Windows: ```powershell [RO] (Get-Date).ToUniversalTime().ToString("o") ``` Linux und macOS: ```bash [RO] date -u "+%Y-%m-%dT%H:%M:%SZ" ``` Zu dokumentieren sind: - Beginn der Aufzeichnung, - Zeitpunkt der Fehlerauslösung, - Ende der Aufzeichnung, - Zeitzone, - Zeitabweichung zwischen Messsystemen. Eine Zeitabweichung von wenigen Sekunden kann die Zuordnung kurzer Verbindungsversuche erheblich erschweren.
---
7. Aufzeichnungsschnittstelle eindeutig bestimmen **Windows mit Dumpcap:** ```powershell [RO] dumpcap -D ``` **Windows-Netzwerkadapter:** ```powershell [RO] Get-NetAdapter -IncludeHidden | Format-Table Name, InterfaceDescription, Status, MacAddress ``` **Linux:** ```bash [RO] ip -br link ``` ```bash [RO] tcpdump -D ``` **macOS:** ```bash [RO] networksetup -listallhardwareports ``` ```bash [RO] ifconfig ``` ```bash [RO] tcpdump -D ``` Zu prüfen sind: - physische Schnittstelle, - WLAN oder Ethernet, - VPN-Tunnel, - Bridge, - VLAN-Interface, - Container-Bridge, - Loopback, - virtuelle Maschine, - aktive Route zum Ziel. **Route zum Ziel:** | Betriebssystem | Befehl | |---|---| | Windows | `[RO] Find-NetRoute -RemoteIPAddress ZIEL_IP` | | Linux | `[RO] ip route get ZIEL_IP` | | macOS | `[RO] route -n get ZIEL_IP` |
---
8. Besonderheiten der Schnittstelle any unter Linux Mit `any` kann tcpdump gleichzeitig auf mehreren Linux-Schnittstellen aufzeichnen: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i any -nn \ -w capture.pcap ``` Vorteile: - hilfreich bei unbekanntem Pfad, - zeigt Verkehr auf mehreren Schnittstellen, - geeignet für Router-, Proxy- und Containerhosts. Einschränkungen: - Link-Layer-Darstellung kann sich von einer konkreten Ethernetaufzeichnung unterscheiden, - derselbe Datenfluss kann an mehreren Stellen erscheinen, - Adressen können vor und nach NAT sichtbar sein, - Reihenfolge und Interpretation werden komplexer, - nicht jede hardwarenahe Information ist verfügbar. Für eine präzise Layer-2-Analyse sollte möglichst die konkrete Schnittstelle gewählt werden.
---
9. Promiscuous Mode und WLAN Monitor Mode unterscheiden **Promiscuous Mode:** Eine Ethernet-Schnittstelle nimmt zusätzlich Frames an, die nicht direkt an ihre eigene MAC-Adresse adressiert sind. In einem geswitchten Netzwerk werden dadurch jedoch nicht automatisch alle Frames anderer Switchports sichtbar. **WLAN Monitor Mode:** Ein geeigneter WLAN-Adapter erfasst 802.11-Funkframes auf einem bestimmten Kanal beziehungsweise Frequenzbereich. | Modus | Typische Verwendung | |---|---| | Normaler WLAN-Clientmodus | Verkehr des eigenen Clients untersuchen | | Promiscuous Mode | Zusätzliche sichtbare Ethernetframes erfassen | | Monitor Mode | WLAN-Management-, Kontroll- und Datenframes untersuchen | | Switch Port Mirroring | Verkehr ausgewählter Switchports oder VLANs spiegeln | | Network TAP | Physischer Messpunkt in einer Verbindung | Monitor Mode kann die normale WLAN-Verbindung unterbrechen und wird nicht von jeder Hardware, jedem Treiber oder Betriebssystem unterstützt.
---
10. Grenzen eines Mitschnitts im geswitchten Netzwerk Ein Client an einem Switchport sieht normalerweise: - eigenen Unicastverkehr, - Broadcastverkehr im eigenen Broadcastbereich, - relevanten Multicastverkehr, - bestimmte Kontrollprotokolle. Er sieht normalerweise nicht automatisch: - Unicastverkehr zwischen zwei anderen Switchports, - Verkehr in anderen VLANs, - Pakete hinter einer Firewall, - Verkehr eines anderen virtuellen Switches. Für fremden Unicastverkehr sind abhängig von Infrastruktur und Berechtigung erforderlich: - SPAN beziehungsweise Port Mirroring, - Remote SPAN, - Network TAP, - Aufzeichnung direkt auf dem Zielsystem, - Aufzeichnung auf Router oder Firewall. Ein falsch konfigurierter Mirror-Port kann Pakete verlieren, wenn die gespiegelte Datenmenge seine Kapazität überschreitet.
---
11. Capture Filter und Display Filter unterscheiden | Filterart | Zeitpunkt | Wirkung | |---|---|---| | Capture Filter | während der Aufzeichnung | Nur passende Pakete werden gespeichert | | Display Filter | nach beziehungsweise während der Anzeige | Alle gespeicherten Pakete bleiben erhalten, nur die Ansicht wird gefiltert | **Capture Filter:** ```text host 192.0.2.20 and tcp port 443 ``` **Wireshark Display Filter:** ```text ip.addr == 192.0.2.20 && tcp.port == 443 ``` Die Syntax ist nicht austauschbar. **Grundentscheidung:** - enger Capture Filter bei Datenschutz- oder Speicheranforderungen, - breiterer Capture Filter bei unklarer Ursache, - Display Filter für schrittweise Auswertung.
---
12. Wichtige Capture Filter | Aufgabe | Capture Filter | |---|---| | Einzelner Host | `host 192.0.2.20` | | Quelle | `src host 192.0.2.20` | | Ziel | `dst host 192.0.2.20` | | Zwei Hosts | `host 192.0.2.20 and host 192.0.2.53` | | Gesamtes IPv4-Netz | `net 192.0.2.0/24` | | TCP | `tcp` | | UDP | `udp` | | ICMP | `icmp` | | ICMPv6 | `icmp6` | | TCP-Port 443 | `tcp port 443` | | UDP-Port 53 | `udp port 53` | | Quellport | `src port 443` | | Zielport | `dst port 443` | | DNS über TCP oder UDP | `port 53` | | DHCPv4 | `udp port 67 or udp port 68` | | DHCPv6 | `udp port 546 or udp port 547` | | ARP | `arp` | | Host und Port | `host 192.0.2.20 and tcp port 443` | | Zwei Ports | `tcp port 80 or tcp port 443` | | Verkehr ohne SSH | `not tcp port 22` | Capture Filter verwenden die Syntax der Paketfilterbibliothek. Vor produktiven Aufzeichnungen sollte die lokale Unterstützung geprüft werden.
---
13. Wichtige Wireshark Display Filter | Aufgabe | Display Filter | |---|---| | IPv4-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | Zwei IPv4-Systeme | `ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53` | | TCP-Port | `tcp.port == 443` | | UDP-Port | `udp.port == 53` | | DNS | `dns` | | DHCPv4 | `dhcp` | | DHCPv6 | `dhcpv6` | | ARP | `arp` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | HTTP-Anfragen | `http.request` | | HTTP-Antworten | `http.response` | | HTTP-Status 502 | `http.response.code == 502` | | TLS-Handshake | `tls.handshake` | | TCP-SYN | `tcp.flags.syn == 1` | | Erstes SYN ohne ACK | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-FIN | `tcp.flags.fin == 1` | | Wiederholungen | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | Vermutetes verlorenes Segment | `tcp.analysis.lost_segment` |
---
14. Linux mit tcpdump aufzeichnen **Alle Pakete einer Schnittstelle:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -w capture.pcap ``` **Nur definierter Client und TCP-Port 443:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w https-test.pcap ``` **DNS-Verkehr:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'port 53' \ -w dns-test.pcap ``` **DHCPv4:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'udp port 67 or udp port 68' \ -w dhcp-test.pcap ``` **Ohne Datei, direkt lesbar:** ```bash [TEST][PRIV][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25 and tcp port 443' ``` `-nn` verhindert die Auflösung von Hostnamen und Dienstnamen. Dadurch wird die Ausgabe schneller und eindeutiger.
---
15. macOS mit tcpdump aufzeichnen Zuerst die tatsächliche Schnittstelle ermitteln: ```bash [RO] networksetup -listallhardwareports ``` **Beispiel für Ethernet oder WLAN auf en0:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'host 192.0.2.25 and tcp port 443' \ -w https-test.pcap ``` **DNS-Verkehr:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i en0 -nn \ 'port 53' \ -w dns-test.pcap ``` **VPN-Tunnel untersuchen:** ```bash [RO] ifconfig ``` Anschließend die tatsächlich ermittelte Tunnelschnittstelle verwenden: ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i TUNNEL_INTERFACE -nn \ 'host INTERNES_ZIEL' \ -w vpn-inner.pcap ``` Schnittstellennamen wie `en0` oder `utun0` dürfen nicht ohne vorherige Prüfung vorausgesetzt werden.
---
16. Windows mit Dumpcap aufzeichnen Dumpcap ist Bestandteil einer Wireshark-Installation und kann ohne grafische Oberfläche aufzeichnen. **Schnittstellen anzeigen:** ```powershell [RO] dumpcap -D ``` **Auf Schnittstelle 1 aufzeichnen:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -w capture.pcapng ``` **Mit Capture Filter:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25 and tcp port 443" ` -w https-test.pcapng ``` **Aufzeichnung nach 60 Sekunden beenden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -a duration:60 ` -w capture-60s.pcapng ``` Die Schnittstellennummer `1` ist nur ein Beispiel und muss vorher mit `dumpcap -D` ermittelt werden.
---
17. Windows mit Pktmon aufzeichnen Pktmon ist ein in Windows integriertes Diagnosewerkzeug. Es kann Pakete an mehreren Stellen innerhalb des Windows-Netzwerkstacks erfassen und verworfene Pakete erkennen. Vor Verwendung lokale Syntax prüfen: ```cmd [RO] pktmon help ``` **Aktuellen Status anzeigen:** ```cmd [RO][PRIV] pktmon status ``` **Netzwerkkomponenten anzeigen:** ```cmd [RO][PRIV][SENS] pktmon list ``` **Aufzeichnung in eine ETL-Datei starten:** ```cmd [TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl ``` **Fehler reproduzieren und Aufzeichnung beenden:** ```cmd [TEST][PRIV][FILE][SENS] pktmon stop ``` **ETL nach PCAPNG konvertieren:** ```cmd [RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng ``` Pktmon-Optionen können sich zwischen unterstützten Windows-Versionen unterscheiden. Vor einer produktiven Aufzeichnung müssen die lokale Hilfe und der geplante Umfang geprüft werden.
---
18. Pktmon-Drop-Erkennung richtig behandeln Pktmon kann zusätzlich Informationen über innerhalb des Windows-Netzwerkstacks verworfene Pakete erfassen. **Pktmon-Zähler anzeigen:** ```cmd [RO][PRIV][SENS] pktmon counters ``` **Nur als verworfen markierte Pakete konvertieren:** ```cmd [RO][FILE][SENS] pktmon etl2pcap pktmon.etl ^ --drop-only ^ --out pktmon-drops.pcapng ``` Microsoft weist darauf hin, dass bei der PCAPNG-Konvertierung bestimmte Pktmon-Metadaten verloren gehen können. PCAPNG unterscheidet danach nicht automatisch zwischen regulär weitergeleiteten und verworfenen Paketen. Deshalb sollten bei Bedarf getrennte Dateien erzeugt werden: ```text vollständige Aufzeichnung + separate Drop-Aufzeichnung + ursprüngliche ETL-Datei ``` Die ursprüngliche ETL-Datei muss geschützt aufbewahrt werden, wenn die zusätzlichen Pktmon-Informationen für die Diagnose benötigt werden.
---
19. Ringspeicher mit Dumpcap verwenden Eine unbegrenzte Aufzeichnung kann den Datenträger füllen. Dumpcap unterstützt Ringspeicher mit mehreren Dateien. **Datei alle fünf Minuten wechseln und maximal zwölf Dateien behalten:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` **Zusätzlich Capture Filter verwenden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i 1 ` -f "host 192.0.2.25" ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` Damit werden ungefähr die letzten 60 Minuten in zwölf Fünf-Minuten-Dateien gehalten. Dateiverarbeitung und Wechselverhalten müssen mit der installierten Dumpcap-Version geprüft werden.
---
20. Größenbegrenzten Ringspeicher mit tcpdump verwenden **Datei nach ungefähr 100 Millionen Byte wechseln und maximal zehn Dateien verwenden:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -C 100 \ -W 10 \ -w capture.pcap ``` **Mit Filter:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ 'host 192.0.2.25' \ -C 100 \ -W 10 \ -w capture.pcap ``` Die genaue Dateibenennung und Rotation hängt von der installierten tcpdump-Version ab. Vor einer Langzeitaufzeichnung lokale Hilfe prüfen: ```bash [RO] tcpdump --help ``` oder: ```bash [RO] man tcpdump ```
---
21. Capture-Länge und vollständige Pakete berücksichtigen Die Capture-Länge bestimmt, wie viele Byte eines Pakets gespeichert werden. **tcpdump – vollständige Pakete anfordern:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i eth0 -nn \ -s 0 \ -w capture.pcap ``` Bei aktuellen tcpdump-Versionen bedeutet `-s 0`, dass die vom Werkzeug unterstützte maximale Paketlänge erfasst wird. **Abwägung:** | Kurze Capture-Länge | Vollständige Pakete | |---|---| | weniger Speicherbedarf | höhere Datenmenge | | geringeres Datenschutzrisiko | mehr Protokolldetails | | Nutzdaten möglicherweise abgeschnitten | Nutzdaten möglicherweise vollständig enthalten | | Headeranalyse häufig möglich | Anwendungsanalyse eher möglich | Für eine reine Headeranalyse sollte geprüft werden, ob eine begrenzte Capture-Länge ausreicht.
---
22. tcpdump-Datei nachträglich lesen **PCAP-Datei ohne Namensauflösung anzeigen:** ```bash [RO][SENS] tcpdump -nn -r capture.pcap ``` **Nur TCP-Port 443 aus einer vorhandenen Datei anzeigen:** ```bash [RO][SENS] tcpdump -nn -r capture.pcap \ 'tcp port 443' ``` **Zeitstempel ausführlicher anzeigen:** ```bash [RO][SENS] tcpdump -tttt -nn -r capture.pcap ``` Das nachträgliche Filter verändert die Originaldatei nicht.
---
23. TShark für automatisierte Auswertung verwenden TShark ist die Kommandozeilenversion der Wireshark-Protokollanalyse. **Schnittstellen anzeigen:** ```bash [RO] tshark -D ``` **Vorhandene Datei lesen:** ```bash [RO][SENS] tshark -r capture.pcapng ``` **Display Filter anwenden:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.port == 443' ``` **DNS-Anfragen ausgeben:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'dns.flags.response == 0' \ -T fields \ -e frame.time \ -e ip.src \ -e dns.qry.name ``` **TCP-Wiederholungen ausgeben:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.analysis.retransmission' ``` **HTTP-Statuscodes:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'http.response' \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e http.response.code ```
---
24. Capture Filter und Display Filter bei TShark verwenden **Capture Filter während der Aufzeichnung:** ```bash [TEST][PRIV][FILE][SENS] tshark -i INTERFACE \ -f 'host 192.0.2.25 and tcp port 443' \ -w capture.pcapng ``` **Display Filter auf vorhandener Datei:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'ip.addr == 192.0.2.25 && tcp.port == 443' ``` Zuordnung: ```text -f = Capture Filter -Y = Display Filter ``` Ein Display Filter kann nicht als Capture Filter übernommen werden, wenn er eine Wireshark-spezifische Syntax verwendet.
---
25. Dateien mit capinfos untersuchen `capinfos` gehört zur Wireshark-Werkzeugsammlung. **Grundinformationen:** ```bash [RO][SENS] capinfos capture.pcapng ``` Mögliche Angaben: - Dateiformat, - Anzahl der Pakete, - Datenmenge, - Startzeit, - Endzeit, - Aufzeichnungsdauer, - durchschnittliche Paketrate, - Datenrate, - Schnittstelleninformationen. **Mehrere Dateien vergleichen:** ```bash [RO][SENS] capinfos client.pcapng server.pcapng ``` Damit lassen sich unter anderem Zeitbereiche und Größen vor einer Zusammenführung kontrollieren.
---
26. Mitschnitte mit mergecap zusammenführen `mergecap` führt mehrere Capture-Dateien in eine neue Datei zusammen. ```bash [RO][FILE][SENS] mergecap \ -w combined.pcapng \ client.pcapng \ server.pcapng ``` Vorher müssen geprüft werden: - Zeitstempel, - Zeitzone, - Uhrabweichung, - unterschiedliche Schnittstellen, - mögliche Paketduplikate, - unterschiedliche Messpunkte, - NAT- oder Proxyübersetzung. Eine zusammengeführte Datei kann dasselbe Paket mehrfach enthalten, wenn es an mehreren Messpunkten erfasst wurde.
---
27. Mitschnitte mit editcap begrenzen `editcap` kann Capture-Dateien bearbeiten, aufteilen oder zeitlich begrenzen. **Lokale Hilfe:** ```bash [RO] editcap --help ``` **Erste 1.000 Pakete in neue Datei schreiben:** ```bash [RO][FILE][SENS] editcap -r capture.pcapng \ capture-first-1000.pcapng \ 1-1000 ``` **Datei in Paketeinheiten aufteilen:** ```bash [RO][FILE][SENS] editcap -c 10000 \ capture.pcapng \ capture-part.pcapng ``` Vor dem Bearbeiten muss die Originaldatei unverändert aufbewahrt werden. Eine verkleinerte Datei kann für die Weitergabe sinnvoll sein, entfernt aber nicht automatisch alle sensiblen Inhalte.
---
28. Paketnamen und Frame-Nummern richtig verwenden In Wireshark sind wichtige Spalten: | Spalte | Bedeutung | |---|---| | No. | Frame-Nummer innerhalb der geöffneten Datei | | Time | Zeitstempel beziehungsweise relative Zeit | | Source | Quelladresse | | Destination | Zieladresse | | Protocol | erkannter Protokolldissektor | | Length | Frame- beziehungsweise Paketlänge | | Info | zusammengefasste Protokollinformation | **Wichtig:** Frame-Nummern gelten nur innerhalb der konkreten Datei. Nach Filterung, Zusammenführung oder Bearbeitung können sich Nummern ändern. Für eine belastbare Dokumentation zusätzlich angeben: - Dateiname, - Zeitstempel, - Quell- und Zieladresse, - Protokoll, - relevante Sequenz- oder Transaktionskennung.
---
29. Wireshark Follow Stream verwenden Wireshark kann zusammengehörige Datenströme darstellen: - Follow TCP Stream, - Follow UDP Stream, - Follow TLS Stream, - Follow HTTP Stream, - weitere protokollspezifische Streams. Damit lassen sich beispielsweise betrachten: - Anfragen und Antworten, - Reihenfolge der Daten, - Klartextprotokolle, - Verbindungsabbrüche, - HTTP-Fehler, - Protokolldialoge. **Sicherheitswarnung:** Follow Stream kann vollständige unverschlüsselte Anwendungsdaten und Zugangsinformationen anzeigen. Inhalte dürfen nicht ungeprüft kopiert oder weitergegeben werden.
---
30. TCP-Handshake analysieren **Erfolgreicher Verbindungsaufbau:** ```text Client → Server: SYN Server → Client: SYN, ACK Client → Server: ACK ``` **Wireshark-Filter:** ```text tcp.flags.syn == 1 ``` **Nur erste SYN-Pakete:** ```text tcp.flags.syn == 1 && tcp.flags.ack == 0 ``` | Paketmuster | Typische Interpretation | |---|---| | SYN, SYN-ACK, ACK | TCP-Verbindung aufgebaut | | Wiederholte SYN ohne Antwort | Drop, Verlust, falscher Rückweg oder Ziel nicht erreichbar | | SYN gefolgt von RST/ACK | Ziel erreichbar, Port geschlossen oder aktiv abgelehnt | | SYN-ACK erreicht Client, ACK fehlt | Clientseite oder Rückweg des ACK prüfen | | Handshake erfolgreich, danach RST | Anwendung, Proxy oder Sicherheitskomponente beendet Verbindung | | Handshake erfolgreich, keine Nutzdaten | Anwendung wartet oder Protokollablauf fehlerhaft |
---
31. TCP-Verbindungsabbau analysieren Ein regulärer TCP-Abbau verwendet FIN- und ACK-Segmente. Ein RST beendet eine Verbindung unmittelbar. **Filter:** ```text tcp.flags.fin == 1 || tcp.flags.reset == 1 ``` | Beobachtung | Mögliche Bedeutung | |---|---| | FIN/ACK-Austausch | geordneter Verbindungsabbau | | RST vom Client | Clientanwendung oder lokales System bricht ab | | RST vom Server | Serveranwendung oder Serverstack bricht ab | | RST von unbekannter Zwischenadresse | Firewall, Proxy oder anderes Zwischensystem möglich | | FIN nach Anwendungserfolg | häufig normal | | RST direkt nach TLS-Start | TLS-, Richtlinien- oder Protokollproblem möglich | Die Quelladresse eines RST allein beweist nicht immer seine tatsächliche Herkunft, da Sicherheitsgeräte Pakete im Namen eines Endpunkts erzeugen können.
---
32. TCP-Wiederholungen vorsichtig interpretieren **Filter:** ```text tcp.analysis.retransmission ``` Weitere Filter: ```text tcp.analysis.fast_retransmission tcp.analysis.spurious_retransmission tcp.analysis.duplicate_ack tcp.analysis.out_of_order tcp.analysis.lost_segment ``` Mögliche Ursachen: - tatsächlicher Paketverlust, - Paketverlust nur am Capture-Messpunkt, - asymmetrisches Routing, - NIC-Offloading, - Start der Aufzeichnung mitten in der Verbindung, - Pakete in anderer Reihenfolge, - überlasteter Messrechner, - Mirror-Port verwirft Pakete. Wireshark-Analyseflags sind Interpretationen. Sie müssen mit Sequenznummern, ACKs und möglichst einem Mitschnitt der Gegenstelle überprüft werden.
---
33. NIC-Offloading und ungewöhnliche Paketgrößen berücksichtigen Netzwerkadapter und Betriebssysteme können Verarbeitung auslagern: - TCP Segmentation Offload, - Large Send Offload, - Generic Segmentation Offload, - Generic Receive Offload, - Checksum Offload. Dadurch können lokale Mitschnitte zeigen: - scheinbar falsche Prüfsummen, - Pakete größer als die physische MTU, - zusammengefasste Segmente, - Segmentierung erst nach dem Capture-Punkt. **Typischer Hinweis:** ```text Checksum incorrect ``` direkt auf dem sendenden Host bedeutet nicht automatisch, dass das Paket mit falscher Prüfsumme auf dem Netzwerk übertragen wurde. Die Netzwerkkarte kann die Prüfsumme erst nach dem lokalen Capture-Punkt berechnen. Ein Mitschnitt auf der Gegenstelle oder einem externen TAP zeigt eher den tatsächlich übertragenen Zustand.
---
34. ARP und IPv6 Neighbor Discovery analysieren **ARP-Filter:** ```text arp ``` **Typischer IPv4-Ablauf:** ```text Who has 192.0.2.1? 192.0.2.1 is at 00:11:22:33:44:55 ``` Zu prüfen sind: - Anfrage sichtbar, - Antwort sichtbar, - richtige MAC-Adresse, - mehrere Antworten, - häufige Wiederholungen, - Gratuitous ARP, - Adresskonflikt. **IPv6 Neighbor Discovery:** ```text icmpv6 ``` Zu prüfen sind unter anderem: - Neighbor Solicitation, - Neighbor Advertisement, - Router Solicitation, - Router Advertisement, - Duplicate Address Detection, - Packet Too Big. ICMPv6 darf nicht pauschal als unwichtiger Diagnoseverkehr betrachtet werden.
---
35. DHCPv4-Ablauf analysieren **Capture Filter:** ```text udp port 67 or udp port 68 ``` **Display Filter:** ```text dhcp ``` Typischer Ablauf: ```text DHCP Discover DHCP Offer DHCP Request DHCP ACK ``` Bekannt als: ```text DORA ``` | Fehlendes Paket | Mögliche Eingrenzung | |---|---| | Kein Discover sichtbar | Client oder falsche Schnittstelle prüfen | | Discover, kein Offer | DHCP-Server, Relay, VLAN oder Filter prüfen | | Offer sichtbar, Client fordert nicht an | Client, Auswahl oder fehlerhaftes Angebot | | Request, kein ACK | Server, Adresspool, Richtlinie oder Relay | | DHCP NAK | Adresse oder Netzzuordnung wird abgelehnt | | Mehrere unterschiedliche Offers | mehrere DHCP-Server vorhanden |
---
36. DNS-Ablauf analysieren **Capture Filter:** ```text port 53 ``` **Display Filter:** ```text dns ``` **Nur DNS-Anfragen:** ```text dns.flags.response == 0 ``` **Nur DNS-Antworten:** ```text dns.flags.response == 1 ``` **Bestimmter Name:** ```text dns.qry.name == "service.example.internal" ``` Zu prüfen sind: - richtige Zieladresse des DNS-Servers, - Anfrage über UDP oder TCP, - Antwortzeit, - Antwortcode, - zurückgegebene A- und AAAA-Adressen, - CNAME-Kette, - Wiederholungen, - Wechsel zu TCP, - unterschiedliche Antworten verschiedener Resolver. **Typische Antwortcodes:** | Code | Bedeutung | |---|---| | `NOERROR` | Anfrage wurde ohne DNS-Fehler verarbeitet | | `NXDOMAIN` | Name existiert laut Antwort nicht | | `SERVFAIL` | Resolver konnte Anfrage nicht erfolgreich bearbeiten | | `REFUSED` | Server verweigert die Anfrage |
---
37. TLS-Handshake analysieren **Filter:** ```text tls.handshake ``` Typischer Ablauf kann enthalten: ```text Client Hello Server Hello Certificate Schlüsselaustausch Finished Application Data ``` Zu prüfen sind: - verwendeter Servername über SNI, - angebotene TLS-Versionen, - ausgewählte TLS-Version, - Cipher Suites, - präsentierte Zertifikate, - TLS-Alerts, - Zeitpunkt des Abbruchs, - erfolgreiche Application Data nach dem Handshake. **TLS-Alerts:** ```text tls.alert_message ``` Verschlüsselte Anwendungsdaten können ohne zulässige Sitzungsschlüssel nicht inhaltlich analysiert werden. Private Server-Schlüssel sind bei modernen Verfahren nicht automatisch ausreichend, um aufgezeichnete Sitzungen nachträglich zu entschlüsseln.
---
38. HTTP- und Proxyfehler analysieren **HTTP-Anfragen:** ```text http.request ``` **HTTP-Antworten:** ```text http.response ``` **Statuscode:** ```text http.response.code ``` **Proxy-CONNECT:** ```text http.request.method == "CONNECT" ``` Zu prüfen sind: - Hostheader, - Methode, - angefragter Pfad, - Statuscode, - Weiterleitungen, - Proxy-Authentifizierung, - Antwortzeit, - Verbindungsabbruch, - Reverse-Proxy-Header. Bei HTTPS sind HTTP-Inhalte normalerweise verschlüsselt. Sichtbar bleiben abhängig vom Verfahren unter anderem IP-Adressen, Ports, TLS-Handshake und teilweise Servername.
---
39. ICMP- und ICMPv6-Fehler auswerten **Filter:** ```text icmp || icmpv6 ``` Mögliche Meldungen: - Destination Unreachable, - Port Unreachable, - Network Unreachable, - Host Unreachable, - Administratively Prohibited, - Time Exceeded, - Fragmentation Needed, - Packet Too Big, - Redirect. Diese Meldungen enthalten häufig Teile des ursprünglichen Pakets. Dadurch kann festgestellt werden, welche Verbindung die Fehlermeldung ausgelöst hat. ICMP-Fehlermeldungen sind wichtige Bestandteile der Netzwerkfunktion und nicht nur Ping-Antworten.
---
40. NAT-, Proxy- und Containerpfade vergleichen **Vor NAT:** ```text 192.168.10.25:53144 → 198.51.100.20:443 ``` **Nach SNAT:** ```text 203.0.113.10:62001 → 198.51.100.20:443 ``` **Vor DNAT:** ```text 198.51.100.25:54000 → 203.0.113.10:8443 ``` **Nach DNAT:** ```text 198.51.100.25:54000 → 192.168.10.50:443 ``` Für die Zuordnung werden benötigt: - Zeitstempel, - Protokoll, - ursprüngliche Quelladresse, - übersetzte Quelladresse, - ursprüngliche Zieladresse, - übersetzte Zieladresse, - Ports, - TCP-Sequenznummern, - NAT- beziehungsweise Conntrack-Eintrag. Auf Containerhosts kann derselbe Datenfluss an Host-, Bridge- und Containerinterface mehrfach erscheinen.
---
41. Virtuelle Maschinen und Container richtig erfassen Mögliche Messpunkte: ```text physischer Host virtueller Switch VM-Schnittstelle Container-Bridge Container-Netzwerk-Namespace Anwendungscontainer ``` Zu prüfen sind: - Wird NAT verwendet? - Verwendet die VM Bridge- oder Host-Only-Networking? - Ist der Containerport veröffentlicht? - Baut ein Reverse Proxy die Backendverbindung auf? - Existieren mehrere virtuelle Bridges? - Sieht der Host den Verkehr vor oder nach NAT? - Wird Hardware-Offloading eingesetzt? - Greift eine Hypervisor- oder Cloud-Firewall? Ein Mitschnitt auf dem Administrator-PC beantwortet keine Frage über eine interne Container-zu-Container-Verbindung.
---
42. Verschlüsselung und ihre Analysegrenzen Verschlüsselte Protokolle schützen die Nutzdaten: - HTTPS beziehungsweise TLS, - SSH, - VPN, - SMB-Verschlüsselung, - IPsec, - WireGuard, - verschlüsselte Datenbankverbindungen. Ohne zulässige Entschlüsselungsinformationen sind häufig trotzdem sichtbar: - Quell- und Zieladressen, - Ports, - Paketgrößen, - Zeitstempel, - Verbindungsaufbau, - Verbindungsabbau, - Wiederholungen, - TLS-Versionen, - Zertifikate im Handshake, - bestimmte Servernamen, - Datenmengen, - Antwortpausen. **Nicht durchführen:** - private Schlüssel exportieren, - TLS-Prüfung umgehen, - fremde Sitzungen entschlüsseln, - produktive Geheimnisse in Wireshark hinterlegen, - Schlüsselprotokolldateien ungeschützt speichern.
---
43. Fehler bei der Aufzeichnung selbst erkennen Ein Capture-System kann Pakete verlieren. Mögliche Ursachen: - zu hohe Paketrate, - langsamer Datenträger, - kleine Capture-Puffer, - überlastete CPU, - zu breite Aufzeichnung, - Mirror-Port überlastet, - mehrere gespiegelte Vollduplexlinks auf zu kleinem Zielport, - virtuelle Capture-Schicht, - Treiberproblem, - USB-Netzwerkadapter, - Remote-Capture-Verbindung. Wireshark, Dumpcap oder tcpdump können Informationen über vom Capture-Prozess verworfene Pakete ausgeben. **Wichtig:** ```text Im Mitschnitt fehlend ≠ sicher im Netzwerk verloren ``` Das Paket kann lediglich vom Messsystem nicht gespeichert worden sein.
---
44. Aussagekräftige Dateinamen verwenden Empfohlenes Schema: ```text DATUM_UHRZEIT_MESSPUNKT_QUELLE_ZIEL_PROTOKOLL.pcapng ``` Beispiel: ```text 2026-07-31_143500_client01_web01_https.pcapng ``` Keine sensiblen Benutzernamen oder vollständigen personenbezogenen Angaben in Dateinamen verwenden. Zusätzlich eine Textnotiz anlegen: ```text Dateiname: Messpunkt: Schnittstelle: Capture Filter: Startzeit: Fehlerzeit: Endzeit: Client: Server: Testhandlung: Zeitzone: Bearbeiter: ```
---
45. Sichere Aufbewahrung und Weitergabe Vor einer Weitergabe: 1. Originaldatei geschützt aufbewahren. 2. Nur relevanten Zeitbereich extrahieren. 3. Nur benötigte Pakete übernehmen. 4. Nutzdaten auf sensible Inhalte prüfen. 5. DNS-Namen, Adressen und Identitäten bewerten. 6. Unternehmensrichtlinien beachten. 7. Empfänger und Übertragungsweg festlegen. 8. Aufbewahrungsfrist dokumentieren. 9. Nicht mehr benötigte Kopien kontrolliert löschen. Eine PCAP-Datei ist kein harmloser Screenshot. Sie kann vollständige Kommunikationsinhalte enthalten.
---
46. Systematischer Ablauf einer Paketaufzeichnung | Schritt | Aufgabe | Leitfrage | |---:|---|---| | 1 | Fehlerhypothese formulieren | Welches Paketmuster wird erwartet? | | 2 | Datenfluss dokumentieren | Welche Quelle kommuniziert mit welchem Ziel? | | 3 | Messpunkt auswählen | Wo muss das Paket sichtbar sein? | | 4 | Schnittstelle bestimmen | Über welches Interface führt die Route? | | 5 | Zeit synchronisieren | Können mehrere Datenquellen verglichen werden? | | 6 | Datenschutzumfang festlegen | Welche Daten dürfen aufgezeichnet werden? | | 7 | Capture Filter wählen | Welche Pakete werden wirklich benötigt? | | 8 | Speicherbegrenzung planen | Dauer, Größe oder Ringspeicher? | | 9 | Aufzeichnung starten | Läuft sie auf der richtigen Schnittstelle? | | 10 | Fehler einmal reproduzieren | Ist der Zeitpunkt exakt dokumentiert? | | 11 | Aufzeichnung beenden | Wurde unnötige weitere Erfassung vermieden? | | 12 | Capture-Verluste prüfen | Hat das Messsystem Pakete verworfen? | | 13 | Display Filter anwenden | Welcher einzelne Datenfluss ist relevant? | | 14 | Protokollablauf untersuchen | Wo weicht Ist vom Soll ab? | | 15 | Gegenstelle vergleichen | Ist Verlust oder Verzögerung lokalisierbar? | | 16 | Systemprotokolle abgleichen | Warum wurde das Paket abgelehnt? | | 17 | Ergebnis dokumentieren | Welche Frames belegen die Ursache? | | 18 | Daten sichern oder bereinigen | Welche Aufbewahrung ist erforderlich? |
---
47. Kompakte Befehlstabelle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Schnittstellen anzeigen | `[RO] dumpcap -D` | `[RO] tcpdump -D` | `[RO] tcpdump -D` | | Route zum Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | Gesamte Aufzeichnung | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | | Hostfilter | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "host IP" -w host.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'host IP' -w host.pcap` | | Portfilter | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -f "tcp port 443" -w https.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn 'tcp port 443' -w https.pcap` | | 60 Sekunden | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -a duration:60 -w test.pcapng` | `[TEST][PRIV][FILE][SENS] timeout 60 sudo tcpdump -i INTERFACE -nn -w test.pcap` – Verfügbarkeit von `timeout` prüfen | Beendigung kontrolliert per Tastatur oder Werkzeugoption planen | | Ringspeicher | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -b duration:300 -b files:12 -w ring.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -C 100 -W 10 -w ring.pcap` | | PCAP lesen | `[RO][SENS] tshark -r capture.pcapng` | `[RO][SENS] tcpdump -nn -r capture.pcap` | `[RO][SENS] tcpdump -nn -r capture.pcap` | | Display Filter | `[RO][SENS] tshark -r capture.pcapng -Y "tcp.port == 443"` | `[RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443"` | `[RO][SENS] tshark -r capture.pcap -Y "tcp.port == 443"` | | Dateiinformationen | `[RO][SENS] capinfos capture.pcapng` | `[RO][SENS] capinfos capture.pcap` | `[RO][SENS] capinfos capture.pcap` | | Windows-Inbox-Capture | `[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl` | Nicht zutreffend | Nicht zutreffend | | Pktmon beenden | `[TEST][PRIV][FILE][SENS] pktmon stop` | Nicht zutreffend | Nicht zutreffend | | Pktmon konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng` | Nicht zutreffend | Nicht zutreffend | `NUMMER`, `INTERFACE` und `IP` müssen durch die zuvor ermittelten Werte ersetzt werden.
---
48. Dokumentationsvorlage für Paketmitschnitte ```text Störung: Hypothese: Erwartetes Paketmuster: Zeitpunkt: Zeitzone: Clienthostname: Client-IP: Client-MAC: Serverhostname: Server-IP: Serverport: Transportprotokoll: Anwendungsprotokoll: IPv4 oder IPv6: Messpunkt 1: Messsystem 1: Schnittstelle 1: Capture Filter 1: Dateiname 1: Startzeit 1: Endzeit 1: Verworfene Capture-Pakete 1: Messpunkt 2: Messsystem 2: Schnittstelle 2: Capture Filter 2: Dateiname 2: Startzeit 2: Endzeit 2: Verworfene Capture-Pakete 2: Fehler ausgelöst um: Auslösende Handlung: Beobachtete Fehlermeldung: Relevanter Datenstrom: Relevante Frame-Nummern: Relevante Zeitstempel: TCP-Handshake: DNS-Ablauf: TLS-Handshake: HTTP-Status: ICMP-Fehler: Wiederholungen: Verbindungsabbau: Paket verlässt Client: Paket erreicht Server: Server antwortet: Antwort erreicht Client: Festgestellte Verluststelle: Zusätzliche Systemprotokolle: Festgestellte Ursache: Datenschutzprüfung: Originaldatei geschützt gespeichert: Reduzierte Weitergabedatei: Aufbewahrungsfrist: Ergebnis der Nachprüfung: ```
---
49. Kontrollfragen nach der Analyse - Wurde vorab eine konkrete Hypothese formuliert? - Sind Quelle, Ziel, Protokoll und Port bekannt? - Wurde die richtige Schnittstelle gewählt? - Führt die Route tatsächlich über diese Schnittstelle? - Ist der Messpunkt für die untersuchte Verbindung geeignet? - Wurde zwischen Capture Filter und Display Filter unterschieden? - Wurde der Aufzeichnungsumfang begrenzt? - Wurde der Fehlerzeitpunkt exakt dokumentiert? - Sind die Uhren der Messsysteme synchronisiert? - Hat der Capture-Prozess selbst Pakete verworfen? - Wurden NIC-Offloading-Effekte berücksichtigt? - Wurde Zwischenhop- beziehungsweise Mirror-Port-Verlust berücksichtigt? - Wurde ein Mitschnitt der Gegenstelle erstellt? - Wurden IPv4 und IPv6 unterschieden? - Wurden DNS, ARP und ICMP als Begleitprotokolle berücksichtigt? - Wurde ein fehlendes Paket nicht vorschnell als Netzwerkverlust bewertet? - Wurde ein Wireshark-Analyseflag als Interpretation und nicht als Beweis behandelt? - Wurden System-, Firewall- und Anwendungsprotokolle abgeglichen? - Enthält die Datei sensible Daten? - Wurde nur der erforderliche Ausschnitt weitergegeben? - Wurde die Originaldatei unverändert geschützt? - Belegen konkrete Pakete beziehungsweise Zeitstempel die festgestellte Ursache?
---
50. Quellen und weiterführende Dokumentation - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - Wireshark – Capture Filters: https://wiki.wireshark.org/CaptureFilters - Wireshark – Display Filters: https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html - Wireshark – Display Filter Reference: https://www.wireshark.org/docs/dfref/ - Wireshark – Kommandozeilen-Handbücher: https://www.wireshark.org/docs/man-pages/ - Wireshark – Dumpcap-Handbuch: https://www.wireshark.org/docs/man-pages/dumpcap.html - Wireshark – TShark-Handbuch: https://www.wireshark.org/docs/man-pages/tshark.html - Wireshark – Capinfos-Handbuch: https://www.wireshark.org/docs/man-pages/capinfos.html - Wireshark – Mergecap-Handbuch: https://www.wireshark.org/docs/man-pages/mergecap.html - Wireshark – Editcap-Handbuch: https://www.wireshark.org/docs/man-pages/editcap.html - tcpdump – Projektseite und Dokumentation: https://www.tcpdump.org/ - libpcap – Capture-Filter-Syntax: https://www.tcpdump.org/manpages/pcap-filter.7.html - Microsoft Learn – Packet Monitor Pktmon: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon - Microsoft Learn – Pktmon-Übersicht: https://learn.microsoft.com/windows-server/networking/technologies/pktmon/pktmon - Microsoft Learn – Pktmon ETL nach PCAPNG konvertieren: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon-etl2pcap - RFC 9293 – Transmission Control Protocol: https://www.rfc-editor.org/rfc/rfc9293.html - RFC 8200 – Internet Protocol Version 6: https://www.rfc-editor.org/rfc/rfc8200.html
# 3.17 Befehlsübersicht – Netzwerkdiagnose unter Windows, Linux und macOS Diese Seite dient als schnelle Befehlsreferenz für die systematische Netzwerkdiagnose. Die ausführliche Interpretation, Fehlerbilder und Sicherheitsregeln stehen auf den vorherigen Seiten dieses Kapitels. ---
1. Kennzeichnungen | Kennzeichnung | Bedeutung | |---|---| | `[RO]` | Rein lesender Befehl | | `[TEST]` | Aktiver Test, der Netzwerkverkehr erzeugt | | `[PRIV]` | Administrator- oder Root-Rechte können erforderlich sein | | `[FILE]` | Ausgabe wird in eine Datei geschrieben | | `[SENS]` | Ausgabe kann sensible Informationen enthalten | | `[CHANGE]` | Befehl verändert eine Konfiguration | | `[DISRUPT]` | Befehl kann Verbindungen oder Dienste beeinträchtigen | **Platzhalter:** | Platzhalter | Ersetzen durch | |---|---| | `INTERFACE` | Tatsächlicher Schnittstellenname | | `HOST` | Hostname des Zielsystems | | `IP` | IP-Adresse | | `PORT` | TCP- oder UDP-Port | | `DNS_SERVER` | IP-Adresse des DNS-Servers | | `CONTAINER` | Tatsächlicher Containername | | `ZONE` | Tatsächliche firewalld-Zone | | `DIENST` | Tatsächlicher Dienstname | | `DATEI` | Gewünschter Dateiname beziehungsweise Pfad | Befehle mit Platzhaltern dürfen nicht unverändert ausgeführt werden.
---
2. Empfohlene Kurzreihenfolge | Schritt | Prüfung | Leitfrage | |---:|---|---| | 1 | Schnittstellenstatus | Ist der Adapter aktiv und verbunden? | | 2 | IP-Konfiguration | Stimmen Adresse, Präfix, Gateway und DNS? | | 3 | Loopback | Funktioniert der lokale TCP/IP-Stack? | | 4 | Eigene Adresse | Ist die lokale Schnittstelle erreichbar? | | 5 | Gateway | Funktioniert das lokale Netz? | | 6 | Entfernte IP | Funktionieren Routing und Rückweg? | | 7 | DNS | Wird der richtige Name aufgelöst? | | 8 | Route | Welcher Pfad und welche Schnittstelle werden verwendet? | | 9 | Port | Ist der benötigte Transportdienst erreichbar? | | 10 | Anwendung | Antwortet das tatsächliche Protokoll? | | 11 | Firewall, NAT, VPN oder Proxy | Wo wird der Datenfluss beeinflusst? | | 12 | Paketmitschnitt | Welches Paketmuster belegt die Ursache? |
---
3. Betriebssystem, Hostname, Zeit und Benutzer | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Betriebssystem | `[RO] Get-ComputerInfo` | `[RO] cat /etc/os-release` | `[RO] sw_vers` | | Kernel beziehungsweise Systemversion | `[RO] systeminfo` | `[RO] uname -a` | `[RO] uname -a` | | Hostname | `[RO] hostname` | `[RO] hostnamectl` | `[RO] scutil --get ComputerName` | | Aktueller Benutzer | `[RO] whoami` | `[RO] id` | `[RO] id` | | Lokale Zeit | `[RO] Get-Date -Format o` | `[RO] date --iso-8601=seconds` | `[RO] date "+%Y-%m-%dT%H:%M:%S%z"` | | UTC-Zeit | `[RO] (Get-Date).ToUniversalTime().ToString("o")` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | `[RO] date -u "+%Y-%m-%dT%H:%M:%SZ"` | | Zeitzone | `[RO] Get-TimeZone` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -gettimezone` | | Zeitstatus | `[RO] w32tm /query /status` | `[RO] timedatectl status` | `[RO][PRIV] sudo systemsetup -getusingnetworktime` |
---
4. Netzwerkadapter und Schnittstellen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapterübersicht | `[RO] Get-NetAdapter` | `[RO] ip -br link` | `[RO] ifconfig` | | Versteckte Adapter | `[RO] Get-NetAdapter -IncludeHidden` | Nicht direkt vergleichbar | `[RO] ifconfig -a` | | Aktive Adapter | `[RO] Get-NetAdapter \| Where-Object Status -eq "Up"` | `[RO] ip link show up` | `[RO] ifconfig -u` | | MAC-Adressen | `[RO] Get-NetAdapter \| Format-Table Name,MacAddress` | `[RO] ip link show` | `[RO] ifconfig` | | Linkgeschwindigkeit | `[RO] Get-NetAdapter \| Format-Table Name,Status,LinkSpeed` | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | Adapterstatistik | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Treiberinformationen | `[RO][SENS] Get-CimInstance Win32_PnPSignedDriver \| Where-Object DeviceClass -eq "NET"` | `[RO][SENS] lspci -k` | `[RO][SENS] system_profiler SPNetworkDataType` | | USB-Netzwerkadapter | Geräte-Manager beziehungsweise PnP-Geräte prüfen | `[RO][SENS] lsusb` | `[RO][SENS] system_profiler SPUSBDataType` | | Schnittstellenzuordnung | `[RO] Get-NetIPInterface` | `[RO] ip address show` | `[RO] networksetup -listallhardwareports` | **Windows kompakt:** ```powershell [RO] Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed, MacAddress ``` **Linux kompakt:** ```bash [RO] ip -br link [RO] ip -br address ``` **macOS – Hardwareport und Gerätename zuordnen:** ```bash [RO] networksetup -listallhardwareports ```
---
5. IPv4- und IPv6-Konfiguration | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Gesamte IP-Konfiguration | `[RO][SENS] Get-NetIPConfiguration -All` | `[RO][SENS] ip address show` | `[RO][SENS] ifconfig` | | Klassische Ausgabe | `[RO][SENS] ipconfig /all` | Nicht zutreffend | Nicht zutreffend | | Kompakte Adressen | `[RO][SENS] Get-NetIPAddress` | `[RO][SENS] ip -br address` | `[RO][SENS] ifconfig` | | Nur IPv4 | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address show` | `[RO] ifconfig` | | Nur IPv6 | `[RO] Get-NetIPAddress -AddressFamily IPv6` | `[RO] ip -6 address show` | `[RO] ifconfig` | | Schnittstellen-MTU | `[RO] Get-NetIPInterface` | `[RO] ip link show` | `[RO] ifconfig` | | Netzwerkdienstinformationen | Nicht direkt vergleichbar | NetworkManager: `[RO] nmcli device show` | `[RO][SENS] networksetup -getinfo "Wi-Fi"` | **Windows nach Schnittstelle sortiert:** ```powershell [RO][SENS] Get-NetIPAddress | Sort-Object InterfaceAlias, AddressFamily | Format-Table InterfaceAlias, AddressFamily, IPAddress, PrefixLength, AddressState ```
---
6. DHCP prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DHCP-Konfiguration | `[RO][SENS] ipconfig /all` | `[RO][SENS] nmcli device show` | `[RO][SENS] ipconfig getpacket INTERFACE` | | IPv4-Adresse | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address show` | `[RO] ipconfig getifaddr INTERFACE` | | DHCP-Paketmitschnitt | Dumpcap: `udp port 67 or udp port 68` | tcpdump: `udp port 67 or udp port 68` | tcpdump: `udp port 67 or udp port 68` | | DHCPv6-Mitschnitt | Dumpcap: `udp port 546 or udp port 547` | tcpdump: `udp port 546 or udp port 547` | tcpdump: `udp port 546 or udp port 547` | **Windows – Lease erneuern:** ```cmd [CHANGE][DISRUPT] ipconfig /renew ``` **Windows – Lease freigeben und neu beziehen:** ```cmd [CHANGE][DISRUPT] ipconfig /release [CHANGE][DISRUPT] ipconfig /renew ``` **macOS – DHCP für einen Netzwerkdienst erneuern:** ```bash [CHANGE][DISRUPT][PRIV] sudo ipconfig set INTERFACE DHCP ``` Unter Linux hängt das sichere Erneuern vom verwendeten Netzwerkmanager ab. Zuerst prüfen: ```bash [RO] nmcli device status [RO] systemctl is-active NetworkManager [RO] systemctl is-active systemd-networkd ``` DHCP-Erneuerungen können bestehende Verbindungen unterbrechen und dürfen nicht unkontrolliert auf Remote-Systemen ausgeführt werden.
---
7. ARP und IPv6 Neighbor Discovery | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Nachbarn | `[RO][SENS] Get-NetNeighbor -AddressFamily IPv4` | `[RO][SENS] ip -4 neigh show` | `[RO][SENS] arp -an` | | IPv6-Nachbarn | `[RO][SENS] Get-NetNeighbor -AddressFamily IPv6` | `[RO][SENS] ip -6 neigh show` | `[RO][SENS] ndp -an` | | Klassische ARP-Tabelle | `[RO][SENS] arp -a` | `[RO][SENS] ip neigh show` | `[RO][SENS] arp -a` | | Bestimmte Adresse | `[RO] Get-NetNeighbor -IPAddress IP` | `[RO] ip neigh show IP` | `[RO] arp -n IP` | | ARP-Mitschnitt | Capture Filter `arp` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn arp` | | NDP-Mitschnitt | Capture Filter `icmp6` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6` | `[TEST][PRIV][SENS] sudo tcpdump -i INTERFACE -nn icmp6` | Nachbartabellen dürfen nicht unkontrolliert geleert werden. Dadurch können bestehende Verbindungen kurzfristig beeinflusst werden.
---
8. VLAN und Layer 2 | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Adapter und MAC | `[RO] Get-NetAdapter` | `[RO] ip link show` | `[RO] ifconfig` | | VLAN-Schnittstellen | Abhängig vom Adaptertreiber und Hyper-V | `[RO] ip -d link show type vlan` | `[RO] networksetup -listVLANs` | | Bridge | `[RO] Get-NetAdapterBinding` beziehungsweise Hyper-V prüfen | `[RO] bridge link show` | `[RO] ifconfig bridge0` | | Linkstatistik | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | | Ethernetdetails | Adaptereigenschaften und Switch prüfen | `[RO][PRIV] sudo ethtool INTERFACE` | `[RO] ifconfig INTERFACE` | | LLDP-Nachbarn | Abhängig von installiertem Werkzeug | Falls installiert: `[RO] lldpcli show neighbors` | Abhängig von installiertem Werkzeug | VLAN-Zuordnung wird häufig auf Switch, Access Point, Hypervisor oder Controller festgelegt und ist am Client nicht vollständig sichtbar.
---
9. Routing und Standardgateway | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Routingtabelle | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | IPv4-Routen | `[RO] route print -4` | `[RO] ip -4 route show` | `[RO] netstat -rn -f inet` | | IPv6-Routen | `[RO] route print -6` | `[RO] ip -6 route show` | `[RO] netstat -rn -f inet6` | | IPv4-Standardroute | `[RO] Get-NetRoute -DestinationPrefix "0.0.0.0/0"` | `[RO] ip route show default` | `[RO] route -n get default` | | IPv6-Standardroute | `[RO] Get-NetRoute -DestinationPrefix "::/0"` | `[RO] ip -6 route show default` | `[RO] route -n get -inet6 default` | | Route zu einem Ziel | `[RO] Find-NetRoute -RemoteIPAddress IP` | `[RO] ip route get IP` | `[RO] route -n get IP` | | Policy Routing | Abhängig von Windows-Richtlinien | `[RO] ip rule show` | `[RO] netstat -rn` | | Alle Linux-Tabellen | Nicht zutreffend | `[RO][SENS] ip route show table all` | Nicht zutreffend | **Windows übersichtlich:** ```powershell [RO] Get-NetRoute | Sort-Object AddressFamily, DestinationPrefix, RouteMetric | Format-Table AddressFamily, DestinationPrefix, NextHop, InterfaceAlias, RouteMetric ```
---
10. Ping und grundlegende Erreichbarkeit | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | IPv4-Ping | `[TEST] ping -4 -n 4 IP` | `[TEST] ping -4 -c 4 IP` | `[TEST] ping -c 4 IPV4` | | IPv6-Ping | `[TEST] ping -6 -n 4 IP` | `[TEST] ping -6 -c 4 IP` | `[TEST] ping6 -c 4 IPV6` | | 20 Messungen | `[TEST] ping -n 20 IP` | `[TEST] ping -c 20 IP` | `[TEST] ping -c 20 IP` | | Fortlaufender Ping | `[TEST] ping -t IP` | `[TEST] ping IP` | `[TEST] ping IP` | | PowerShell-Test | `[TEST] Test-Connection IP -Count 4` | Nicht zutreffend | Nicht zutreffend | | Größere Nutzlast | `[TEST] ping -n 4 -l 1400 IP` | `[TEST] ping -c 4 -s 1400 IP` | `[TEST] ping -c 4 -s 1400 IP` | | Don't Fragment | `[TEST] ping -4 -f -l 1400 IP` | `[TEST] ping -4 -M do -s 1400 IP` | `[TEST] ping -D -s 1400 IP` | **Empfohlene Reihenfolge:** ```text Loopback → eigene Adresse → Standardgateway → internes Ziel → externes Ziel → Hostname ```
---
11. Netzwerkpfad untersuchen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Pfad mit DNS | `[TEST] tracert HOST` | `[TEST] traceroute HOST` | `[TEST] traceroute HOST` | | Pfad ohne DNS | `[TEST] tracert -d IP` | `[TEST] traceroute -n IP` | `[TEST] traceroute -n IP` | | IPv4-Pfad | `[TEST] tracert -4 -d HOST` | `[TEST] traceroute -4 -n HOST` | `[TEST] traceroute -4 -n HOST` | | IPv6-Pfad | `[TEST] tracert -6 -d HOST` | `[TEST] traceroute -6 -n HOST` | `[TEST] traceroute -6 -n HOST` | | Pfad und Verlust | `[TEST] pathping /n IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | | Path-MTU-Hinweis | Nicht direkt vergleichbar | `[TEST] tracepath -n IP` | MTU mit Ping und Route prüfen | Zwischenhops können ICMP-Antworten begrenzen. Verlust an einem einzelnen Zwischenhop ist kein Beweis für weitergeleiteten Paketverlust, wenn nachfolgende Hops und das Ziel keinen entsprechenden Verlust zeigen.
---
12. DNS-Konfiguration prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | DNS-Server | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | DNS-Suffixe | `[RO] Get-DnsClient` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` | | Klassische Konfiguration | `[RO][SENS] ipconfig /all` | `[RO][SENS] cat /etc/resolv.conf` | `[RO][SENS] scutil --dns` | | Hosts-Datei | `[RO][SENS] Get-Content "$env:SystemRoot\System32\drivers\etc\hosts"` | `[RO][SENS] cat /etc/hosts` | `[RO][SENS] cat /etc/hosts` | | DNS-Cache | `[RO][SENS] Get-DnsClientCache` | Resolverabhängig | `[RO][SENS] dscacheutil -cachedump -entries Host` – Ausgabe abhängig von macOS-Version | `/etc/resolv.conf` kann unter Linux automatisch erzeugt sein und bildet bei lokalen Stub-Resolvern nicht zwingend die vollständige Resolverlogik ab.
---
13. DNS-Abfragen durchführen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Standardabfrage | `[TEST] Resolve-DnsName HOST` | `[TEST] dig HOST` | `[TEST] dig HOST` | | A-Record | `[TEST] Resolve-DnsName HOST -Type A` | `[TEST] dig HOST A` | `[TEST] dig HOST A` | | AAAA-Record | `[TEST] Resolve-DnsName HOST -Type AAAA` | `[TEST] dig HOST AAAA` | `[TEST] dig HOST AAAA` | | PTR-Record | `[TEST] Resolve-DnsName IP -Type PTR` | `[TEST] dig -x IP` | `[TEST] dig -x IP` | | Bestimmter DNS-Server | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER` | `[TEST] dig @DNS_SERVER HOST` | `[TEST] dig @DNS_SERVER HOST` | | DNS über TCP | `[TEST] Resolve-DnsName HOST -Server DNS_SERVER -TcpOnly` | `[TEST] dig +tcp @DNS_SERVER HOST` | `[TEST] dig +tcp @DNS_SERVER HOST` | | Kurze Ausgabe | `[TEST] (Resolve-DnsName HOST -Type A).IPAddress` | `[TEST] dig +short HOST` | `[TEST] dig +short HOST` | | Vollständige Ablaufverfolgung | Nicht direkt vergleichbar | `[TEST] dig +trace HOST` | `[TEST] dig +trace HOST` | | Klassischer Test | `[TEST] nslookup HOST DNS_SERVER` | `[TEST] nslookup HOST DNS_SERVER` | `[TEST] nslookup HOST DNS_SERVER` | `dig +trace` fragt mehrere DNS-Server ab und darf nur verwendet werden, wenn direkte externe DNS-Abfragen erlaubt sind.
---
14. DNS-Cache kontrolliert leeren Diese Befehle verändern den lokalen Cache und können die Reproduzierbarkeit beeinflussen. | Betriebssystem | Befehl | |---|---| | Windows | `[CHANGE] ipconfig /flushdns` | | Linux mit systemd-resolved | `[CHANGE][PRIV] sudo resolvectl flush-caches` | | macOS | `[CHANGE][PRIV] sudo dscacheutil -flushcache` | Unter Linux hängt der Befehl vom tatsächlich verwendeten Resolver ab. Vorher prüfen: ```bash [RO] systemctl is-active systemd-resolved ``` Das Leeren eines DNS-Caches behebt keine fehlerhafte DNS-Zone, falsche Delegierung oder falsche Serverkonfiguration.
---
15. TCP-Listener, UDP-Endpunkte und Verbindungen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Verbindungen | `[RO] Get-NetTCPConnection` | `[RO] ss -tan` | `[RO] netstat -anv -p tcp` | | TCP-Listener | `[RO] Get-NetTCPConnection -State Listen` | `[RO] ss -ltn` | `[RO] lsof -nP -iTCP -sTCP:LISTEN` | | UDP-Endpunkte | `[RO] Get-NetUDPEndpoint` | `[RO] ss -lun` | `[RO] lsof -nP -iUDP` | | Listener mit Prozess | Prozess-ID über `OwningProcess` | `[RO][PRIV] sudo ss -ltnp` | `[RO][PRIV] sudo lsof -nP -iTCP -sTCP:LISTEN` | | Bestehende TCP-Verbindungen | `[RO] Get-NetTCPConnection -State Established` | `[RO] ss -tn state established` | `[RO] netstat -anv -p tcp` | | Klassische Übersicht | `[RO] netstat -ano` | `[RO] ss -tuln` | `[RO] netstat -anv` | | TCP-Statistik | `[RO] netstat -s -p tcp` | `[RO] nstat` beziehungsweise `[RO] netstat -s` | `[RO] netstat -s -p tcp` | **Bestimmten TCP-Port prüfen:** Windows: ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort PORT ` -ErrorAction SilentlyContinue ``` Linux: ```bash [RO] ss -ltn 'sport = :PORT' ``` macOS: ```bash [RO] lsof -nP -iTCP:PORT -sTCP:LISTEN ```
---
16. Prozess zu einem Port ermitteln **Windows:** ```powershell [RO] Get-NetTCPConnection -State Listen -LocalPort PORT | Select-Object LocalAddress, LocalPort, State, OwningProcess ``` Anschließend: ```powershell [RO] Get-Process -Id PID ``` Alternativ: ```cmd [RO] netstat -ano [RO] tasklist /FI "PID eq PID" ``` **Linux:** ```bash [RO][PRIV] sudo ss -ltnp 'sport = :PORT' ``` ```bash [RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN ``` **macOS:** ```bash [RO][PRIV] sudo lsof -nP -iTCP:PORT -sTCP:LISTEN ``` ```bash [RO] ps -p PID -o pid,ppid,user,command ```
---
17. TCP- und UDP-Porttests | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | TCP-Port | `[TEST] Test-NetConnection HOST -Port PORT` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | Detaillierter TCP-Test | `[TEST] Test-NetConnection HOST -Port PORT -InformationLevel Detailed` | `[TEST] nc -vz -w 5 HOST PORT` | `[TEST] nc -vz -w 5 HOST PORT` | | Nmap TCP Connect | `[TEST] nmap -sT -p PORT HOST` | `[TEST] nmap -sT -p PORT HOST` | `[TEST] nmap -sT -p PORT HOST` | | Nmap UDP | Administrator-Konsole: `[TEST][PRIV] nmap -sU -p PORT HOST` | `[TEST][PRIV] sudo nmap -sU -p PORT HOST` | `[TEST][PRIV] sudo nmap -sU -p PORT HOST` | | Netcat UDP | Falls Netcat installiert: `[TEST] nc -vzu HOST PORT` | `[TEST] nc -vzu -w 3 HOST PORT` | `[TEST] nc -vzu -w 3 HOST PORT` | UDP-Tests sind ohne gültige Anfrage des Anwendungsprotokolls häufig nicht eindeutig. `Test-NetConnection -Port` ist ein TCP-Test. Nmap und Portscans dürfen nur gegen ausdrücklich freigegebene Systeme verwendet werden.
---
18. HTTP, HTTPS und TLS prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | HTTP-Header | `[TEST] curl.exe -I http://HOST/` | `[TEST] curl -I http://HOST/` | `[TEST] curl -I http://HOST/` | | HTTPS-Header | `[TEST] curl.exe -I https://HOST/` | `[TEST] curl -I https://HOST/` | `[TEST] curl -I https://HOST/` | | Ausführlicher Test | `[TEST][SENS] curl.exe -v https://HOST/` | `[TEST][SENS] curl -v https://HOST/` | `[TEST][SENS] curl -v https://HOST/` | | Nur IPv4 | `[TEST] curl.exe -4 -I https://HOST/` | `[TEST] curl -4 -I https://HOST/` | `[TEST] curl -4 -I https://HOST/` | | Nur IPv6 | `[TEST] curl.exe -6 -I https://HOST/` | `[TEST] curl -6 -I https://HOST/` | `[TEST] curl -6 -I https://HOST/` | | TLS-Handshake | Falls OpenSSL installiert: `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | `[TEST][SENS] openssl s_client -connect HOST:443 -servername HOST` | **HTTP-Zeitanteile:** ```bash [TEST][SENS] curl -sS -o /dev/null \ -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nStartTransfer: %{time_starttransfer}\nTotal: %{time_total}\nHTTP: %{http_code}\n' \ https://HOST/ ``` `curl -k` deaktiviert die Zertifikatsprüfung und darf nicht als dauerhafte Lösung verwendet werden.
---
19. Windows-Firewall prüfen | Aufgabe | Befehl | |---|---| | Aktives Netzwerkprofil | `[RO] Get-NetConnectionProfile` | | Firewallprofile | `[RO] Get-NetFirewallProfile` | | Ausführliche Profile | `[RO] Get-NetFirewallProfile \| Format-List *` | | Aktivierte Regeln | `[RO][SENS] Get-NetFirewallRule -Enabled True` | | Blockierungsregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Action Block` | | Eingehende Erlaubnisregeln | `[RO][SENS] Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow` | | Portfilter | `[RO][SENS] Get-NetFirewallPortFilter` | | Adressfilter einer Regel | `[RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" \| Get-NetFirewallAddressFilter` | | Programmfilter | `[RO][SENS] Get-NetFirewallRule -DisplayName "REGEL" \| Get-NetFirewallApplicationFilter` | | Aktiver Richtlinienspeicher | `[RO][SENS] Get-NetFirewallRule -PolicyStore ActiveStore` | | Klassische Übersicht | `[RO] netsh advfirewall show allprofiles` | **Regeln für TCP-Port 443 suchen:** ```powershell [RO][SENS] Get-NetFirewallPortFilter -Protocol TCP | Where-Object LocalPort -eq "443" | Get-NetFirewallRule | Format-Table DisplayName, Enabled, Direction, Action, Profile ```
---
20. Linux-Firewall prüfen | System | Aufgabe | Befehl | |---|---|---| | firewalld | Status | `[RO] firewall-cmd --state` | | firewalld | Aktive Zonen | `[RO] firewall-cmd --get-active-zones` | | firewalld | Zone einer Schnittstelle | `[RO] firewall-cmd --get-zone-of-interface=INTERFACE` | | firewalld | Zonenkonfiguration | `[RO][SENS] firewall-cmd --zone=ZONE --list-all` | | firewalld | TCP-Port prüfen | `[RO] firewall-cmd --zone=ZONE --query-port=443/tcp` | | firewalld | Dienste | `[RO] firewall-cmd --zone=ZONE --list-services` | | firewalld | Permanente Konfiguration | `[RO][SENS] firewall-cmd --permanent --zone=ZONE --list-all` | | nftables | Regelwerk | `[RO][PRIV][SENS] sudo nft list ruleset` | | nftables | Regeln mit Handles | `[RO][PRIV][SENS] sudo nft -a list ruleset` | | iptables | IPv4-Regeln | `[RO][PRIV][SENS] sudo iptables -L -n -v --line-numbers` | | iptables | IPv6-Regeln | `[RO][PRIV][SENS] sudo ip6tables -L -n -v --line-numbers` | | ufw | Status | `[RO][PRIV][SENS] sudo ufw status verbose` | | ufw | Nummerierte Regeln | `[RO][PRIV][SENS] sudo ufw status numbered` | Runtime- und permanente firewalld-Konfiguration müssen getrennt verglichen werden.
---
21. macOS-Firewall und pf prüfen | Aufgabe | Befehl | |---|---| | Anwendungsfirewallstatus | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate` | | Alle eingehenden Verbindungen blockieren | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall` | | Stealth-Modus | `[RO] /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode` | | Konfigurierte Anwendungen | `[RO][PRIV][SENS] sudo /usr/libexec/ApplicationFirewall/socketfilterfw --listapps` | | pf-Status | `[RO][PRIV] sudo pfctl -s info` | | pf-Regeln | `[RO][PRIV][SENS] sudo pfctl -s rules` | | pf-NAT | `[RO][PRIV][SENS] sudo pfctl -s nat` | | pf-Zustände | `[RO][PRIV][SENS] sudo pfctl -s states` | | Regeln mit Zählern | `[RO][PRIV][SENS] sudo pfctl -vvs rules` | Die macOS-Anwendungsfirewall und `pf` sind getrennte Filterebenen.
---
22. NAT und Portweiterleitung | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Windows-NAT | `[RO][PRIV][SENS] Get-NetNat` | Nicht zutreffend | Nicht zutreffend | | Statische Zuordnungen | `[RO][PRIV][SENS] Get-NetNatStaticMapping` | Nicht zutreffend | Nicht zutreffend | | NAT-Sitzungen | `[RO][PRIV][SENS] Get-NetNatSession` | Conntrack verwenden | pf-Zustände verwenden | | nftables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo nft -a list ruleset` | Nicht zutreffend | | iptables-NAT | Nicht zutreffend | `[RO][PRIV][SENS] sudo iptables -t nat -L -n -v --line-numbers` | Nicht zutreffend | | pf-NAT | Nicht zutreffend | Nicht standardmäßig allgemein vorhanden | `[RO][PRIV][SENS] sudo pfctl -vvs nat` | | IPv4-Forwarding | Rollenabhängig | `[RO] sysctl net.ipv4.ip_forward` | `[RO] sysctl net.inet.ip.forwarding` | | Conntrack | Windows-NAT-Sitzungen | `[RO][PRIV][SENS] sudo conntrack -L` | `[RO][PRIV][SENS] sudo pfctl -s states` | **Öffentlich sichtbare IPv4-Adresse:** Windows: ```powershell [TEST][SENS] Invoke-RestMethod -Uri "https://api.ipify.org" ``` Linux und macOS: ```bash [TEST][SENS] curl -4 https://api.ipify.org ``` Dabei wird die öffentliche Quelladresse an einen externen Dienst übermittelt.
---
23. Proxy prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Proxyvariablen | `[RO][SENS] Get-ChildItem Env: \| Where-Object Name -Match 'proxy'` | `[RO][SENS] env \| grep -i proxy` | `[RO][SENS] env \| grep -i proxy` | | WinHTTP-Proxy | `[RO][SENS] netsh winhttp show proxy` | Nicht zutreffend | Nicht zutreffend | | Erweiterter WinHTTP-Proxy | `[RO][SENS] netsh winhttp show advproxy` | Nicht zutreffend | Nicht zutreffend | | Benutzerproxy | Registry `Internet Settings` prüfen | Desktop- und anwendungsabhängig | `[RO][SENS] scutil --proxy` | | HTTP-Proxy | Anwendungsspezifisch | Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getwebproxy "Wi-Fi"` | | HTTPS-Proxy | Anwendungsspezifisch | Umgebungs- oder Anwendungskonfiguration | `[RO][SENS] networksetup -getsecurewebproxy "Wi-Fi"` | | PAC-URL | Registry beziehungsweise WinHTTP | Desktop- und anwendungsabhängig | `[RO][SENS] networksetup -getautoproxyurl "Wi-Fi"` | | Proxy-Ausnahmen | Registry beziehungsweise WinHTTP | `NO_PROXY` prüfen | `[RO][SENS] networksetup -getproxybypassdomains "Wi-Fi"` | **Windows-Benutzereinstellungen:** ```powershell [RO][SENS] Get-ItemProperty ` "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL, AutoDetect ``` **Expliziter Proxytest:** ```bash [TEST][SENS] curl -v \ --proxy http://PROXY:PORT \ https://HOST/ ``` **Proxy ausdrücklich umgehen:** ```bash [TEST][SENS] curl -v --noproxy "*" https://HOST/ ``` Ein Proxy-Bypass darf nur ausgeführt werden, wenn die Sicherheitsrichtlinie dies erlaubt.
---
24. VPN prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | VPN-Profile | `[RO][SENS] Get-VpnConnection` | `[RO][SENS] nmcli connection show` | `[RO][SENS] scutil --nc list` | | Geräteweite Profile | `[RO][PRIV][SENS] Get-VpnConnection -AllUserConnection` | Clientabhängig | MDM- und clientabhängig | | Aktive RAS-Verbindung | `[RO] rasdial` | `[RO][SENS] nmcli connection show --active` | `[RO][SENS] scutil --nc status "VPN-NAME"` | | Virtuelle Schnittstellen | `[RO] Get-NetAdapter -IncludeHidden` | `[RO] ip -br link` | `[RO] ifconfig` | | VPN-Routen | `[RO] Get-NetRoute` | `[RO] ip route show` | `[RO] netstat -rn` | | DNS über VPN | `[RO][SENS] Get-DnsClientServerAddress` | `[RO][SENS] resolvectl status` | `[RO][SENS] scutil --dns` | | WireGuard | Falls installiert: `[RO][PRIV][SENS] wg show` | `[RO][PRIV][SENS] sudo wg show` | Falls installiert: `[RO][PRIV][SENS] sudo wg show` | | RAS-Protokoll | `[RO][PRIV][SENS] Get-WinEvent -LogName "Microsoft-Windows-RasClient/Operational"` | Clientabhängig | Clientabhängig | | NetworkManager-Protokoll | Nicht zutreffend | `[RO][PRIV][SENS] sudo journalctl -u NetworkManager --since "-30 minutes"` | Nicht zutreffend | **Windows – Split Tunneling prüfen:** ```powershell [RO][SENS] Get-VpnConnection | Select-Object Name, ConnectionStatus, SplitTunneling, TunnelType, ServerAddress ```
---
25. WLAN prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Aktuelle Verbindung | `[RO][SENS] netsh wlan show interfaces` | `[RO][SENS] iw dev INTERFACE link` | `[RO][SENS] networksetup -getairportnetwork INTERFACE` | | Sichtbare Netze | `[RO][SENS] netsh wlan show networks mode=bssid` | `[TEST][SENS] nmcli device wifi list` | Wireless Diagnostics beziehungsweise `wdutil`, falls unterstützt | | WLAN-Schnittstellen | `[RO] Get-NetAdapter` | `[RO] iw dev` | `[RO] networksetup -listallhardwareports` | | Treiber | `[RO][SENS] netsh wlan show drivers` | `[RO][SENS] lspci -k` beziehungsweise `lsusb` | `[RO][SENS] system_profiler SPAirPortDataType` | | Fähigkeiten | `[RO][SENS] netsh wlan show wirelesscapabilities` | `[RO][SENS] iw list` | `[RO][SENS] system_profiler SPAirPortDataType` | | Gespeicherte Profile | `[RO][SENS] netsh wlan show profiles` | `[RO][SENS] nmcli connection show` | WLAN-Einstellungen beziehungsweise MDM | | Stationsstatistik | Informationen unter `show interfaces` | `[RO][SENS] iw dev INTERFACE station dump` | Falls unterstützt: `[RO][PRIV][SENS] sudo wdutil info` | | Regulierungsdomäne | Treiber- und Regionseinstellungen | `[RO] iw reg get` | Systemverwaltet | | WLAN-Protokoll | WLAN-AutoConfig-Ereignisse | NetworkManager und Kernel | Wireless Diagnostics | | WLAN-Bericht | `[RO][PRIV][FILE][SENS] netsh wlan show wlanreport` | Protokolle getrennt sichern | Wireless Diagnostics erzeugt ein Diagnosearchiv | **Windows-Ereignisse:** ```powershell [RO][PRIV][SENS] Get-WinEvent ` -LogName "Microsoft-Windows-WLAN-AutoConfig/Operational" ` -MaxEvents 100 ```
---
26. Leistung, Paketverlust und Bandbreite | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | 100 Pingtests | `[TEST] ping -n 100 IP` | `[TEST] ping -c 100 IP` | `[TEST] ping -c 100 IP` | | Pfad und Verlust | `[TEST] pathping /n IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | Falls installiert: `[TEST] mtr -n -r -c 100 IP` | | TCP-Durchsatz | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | `[TEST] iperf3 -c SERVER_IP` | | Gegenrichtung | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | `[TEST] iperf3 -c SERVER_IP -R` | | 30 Sekunden | `[TEST] iperf3 -c SERVER_IP -t 30` | `[TEST] iperf3 -c SERVER_IP -t 30` | `[TEST] iperf3 -c SERVER_IP -t 30` | | Parallele Streams | `[TEST] iperf3 -c SERVER_IP -P 4` | `[TEST] iperf3 -c SERVER_IP -P 4` | `[TEST] iperf3 -c SERVER_IP -P 4` | | UDP 10 Mbit/s | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | `[TEST] iperf3 -c SERVER_IP -u -b 10M -t 30` | | JSON-Ausgabe | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | `[TEST][FILE][SENS] iperf3 -c SERVER_IP -J > test.json` | | Schnittstellenfehler | `[RO] Get-NetAdapterStatistics` | `[RO] ip -s link` | `[RO] netstat -ib` | Lasttests dürfen nur auf freigegebenen Systemen und mit kontrollierter Datenrate durchgeführt werden.
---
27. Docker- und Containernetzwerke | Aufgabe | Befehl | |---|---| | Laufende Container und Ports | `[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'` | | Portzuordnung | `[RO] docker port CONTAINER` | | Netzwerke | `[RO] docker network ls` | | Netzwerkdetails | `[RO][SENS] docker network inspect NETZWERK` | | Containerdetails | `[RO][SENS] docker inspect CONTAINER` | | Containerprotokoll | `[RO][SENS] docker logs --tail 100 CONTAINER` | | Containerprozesse | `[RO] docker top CONTAINER` | | Container-IP-Konfiguration | Über `docker inspect` und Netzwerkdefinition prüfen | | Veröffentlichte Hostports | `[RO] docker ps --format 'table {{.Names}}\t{{.Ports}}'` | **Typische Portzuordnung:** ```text 0.0.0.0:8080->80/tcp ``` **Nur Loopback:** ```text 127.0.0.1:8080->80/tcp ``` `EXPOSE` im Dockerfile veröffentlicht einen Port nicht automatisch auf dem Host.
---
28. Prozesse und Dienste prüfen | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Prozesse | `[RO] Get-Process` | `[RO] ps aux` | `[RO] ps aux` | | Prozess per PID | `[RO] Get-Process -Id PID` | `[RO] ps -fp PID` | `[RO] ps -p PID -o pid,ppid,user,command` | | Dienste | `[RO] Get-Service` | `[RO] systemctl --type=service` | `[RO] launchctl list` | | Bestimmter Dienst | `[RO] Get-Service -Name DIENST` | `[RO] systemctl status DIENST` | Dienstabhängig | | Aktuelle Logs | Ereignisprotokoll beziehungsweise Anwendung | `[RO][PRIV][SENS] sudo journalctl -u DIENST --since "-30 minutes"` | Unified Logging beziehungsweise Anwendung | | CPU-Prozesse | `[RO] Get-Process \| Sort-Object CPU -Descending` | `[RO] top` | `[RO] top -l 1` | **Linux-Dienstkonfiguration:** ```bash [RO][PRIV][SENS] sudo systemctl cat DIENST ``` **Linux-Dienstumgebung:** ```bash [RO][PRIV][SENS] sudo systemctl show DIENST \ --property=Environment \ --property=EnvironmentFiles ```
---
29. Paketmitschnitt – Schnittstellen und Basisbefehle | Aufgabe | Windows | Linux | macOS | |---|---|---|---| | Capture-Schnittstellen | `[RO] dumpcap -D` | `[RO] tcpdump -D` | `[RO] tcpdump -D` | | Vollständige Aufzeichnung | `[TEST][PRIV][FILE][SENS] dumpcap -i NUMMER -w capture.pcapng` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | `[TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn -w capture.pcap` | | Bestimmter Host | Dumpcap mit `-f "host IP"` | tcpdump mit `'host IP'` | tcpdump mit `'host IP'` | | TCP-Port 443 | Dumpcap mit `-f "tcp port 443"` | tcpdump mit `'tcp port 443'` | tcpdump mit `'tcp port 443'` | | DNS | Dumpcap mit `-f "port 53"` | tcpdump mit `'port 53'` | tcpdump mit `'port 53'` | | DHCPv4 | Dumpcap mit `-f "udp port 67 or udp port 68"` | tcpdump mit entsprechendem Filter | tcpdump mit entsprechendem Filter | | PCAP lesen | `[RO][SENS] tshark -r capture.pcapng` | `[RO][SENS] tcpdump -nn -r capture.pcap` | `[RO][SENS] tcpdump -nn -r capture.pcap` | | Dateiinformationen | `[RO][SENS] capinfos capture.pcapng` | `[RO][SENS] capinfos capture.pcap` | `[RO][SENS] capinfos capture.pcap` | **Windows – 60 Sekunden:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER ` -a duration:60 ` -w capture.pcapng ``` **Linux oder macOS – bestimmter Datenfluss:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ 'host CLIENT_IP and host SERVER_IP and tcp port PORT' \ -w capture.pcap ```
---
30. Paketmitschnitt – Ringspeicher **Dumpcap – alle fünf Minuten wechseln, zwölf Dateien:** ```powershell [TEST][PRIV][FILE][SENS] dumpcap -i NUMMER ` -b duration:300 ` -b files:12 ` -w ringbuffer.pcapng ``` **tcpdump – größenbasiert, maximal zehn Dateien:** ```bash [TEST][PRIV][FILE][SENS] sudo tcpdump -i INTERFACE -nn \ -C 100 \ -W 10 \ -w ringbuffer.pcap ``` Vor einer Langzeitaufzeichnung prüfen: - verfügbaren Speicherplatz, - Datenschutz, - Dateiberechtigungen, - Rotationsverhalten der installierten Version, - erwartete Datenrate, - Aufbewahrungsdauer.
---
31. Windows Pktmon | Aufgabe | Befehl | |---|---| | Hilfe | `[RO] pktmon help` | | Status | `[RO][PRIV] pktmon status` | | Komponenten | `[RO][PRIV][SENS] pktmon list` | | Aufzeichnung starten | `[TEST][PRIV][FILE][SENS] pktmon start --capture --pkt-size 0 --file-name pktmon.etl` | | Aufzeichnung beenden | `[TEST][PRIV][FILE][SENS] pktmon stop` | | Zähler | `[RO][PRIV][SENS] pktmon counters` | | Nach PCAPNG konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --out pktmon.pcapng` | | Nur Drops konvertieren | `[RO][FILE][SENS] pktmon etl2pcap pktmon.etl --drop-only --out pktmon-drops.pcapng` | Pktmon kann Pakete an mehreren Stellen des Windows-Netzwerkstacks erfassen. Die ursprüngliche ETL-Datei enthält Informationen, die bei der PCAPNG-Konvertierung teilweise verloren gehen können.
---
32. Wichtige Wireshark Display Filter | Aufgabe | Display Filter | |---|---| | IPv4-Adresse | `ip.addr == 192.0.2.20` | | IPv6-Adresse | `ipv6.addr == 2001:db8::20` | | Zwei Systeme | `ip.addr == 192.0.2.20 && ip.addr == 192.0.2.53` | | TCP-Port | `tcp.port == 443` | | UDP-Port | `udp.port == 53` | | ARP | `arp` | | IPv6 Neighbor Discovery | `icmpv6` | | DHCPv4 | `dhcp` | | DHCPv6 | `dhcpv6` | | DNS | `dns` | | DNS-Anfrage | `dns.flags.response == 0` | | DNS-Antwort | `dns.flags.response == 1` | | HTTP-Anfrage | `http.request` | | HTTP-Antwort | `http.response` | | TLS-Handshake | `tls.handshake` | | TCP-SYN | `tcp.flags.syn == 1` | | Erstes SYN | `tcp.flags.syn == 1 && tcp.flags.ack == 0` | | TCP-Reset | `tcp.flags.reset == 1` | | TCP-FIN | `tcp.flags.fin == 1` | | Wiederholung | `tcp.analysis.retransmission` | | Doppelte ACKs | `tcp.analysis.duplicate_ack` | | Out-of-Order | `tcp.analysis.out_of_order` | | Zero Window | `tcp.analysis.zero_window` | | ICMP | `icmp` | | ICMPv6 | `icmpv6` | | IKE | `isakmp` | | IPsec NAT-T | `udp.port == 4500` | | ESP | `esp` |
---
33. TShark-Auswertung **Datei mit Display Filter lesen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.port == 443' ``` **DNS-Anfragen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'dns.flags.response == 0' \ -T fields \ -e frame.time \ -e ip.src \ -e dns.qry.name ``` **HTTP-Statuscodes:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'http.response' \ -T fields \ -e frame.time \ -e ip.src \ -e ip.dst \ -e http.response.code ``` **TCP-Wiederholungen:** ```bash [RO][SENS] tshark -r capture.pcapng \ -Y 'tcp.analysis.retransmission' ``` **Mitschnitte zusammenführen:** ```bash [RO][FILE][SENS] mergecap \ -w combined.pcapng \ client.pcapng \ server.pcapng ```
---
34. Typische Symptom-zu-Befehl-Zuordnung | Symptom | Erste sinnvolle Prüfungen | |---|---| | Kein Netzwerk | Adapterstatus, IP-Konfiguration, Gateway | | Adresse `169.254.x.x` | DHCP, VLAN, DHCP-Paketmitschnitt | | Gateway nicht erreichbar | ARP/NDP, Subnetz, WLAN, Kabel, Switchport | | IP funktioniert, Hostname nicht | DNS-Server, `Resolve-DnsName`, `dig` | | Host antwortet, Dienst nicht | Listener, Porttest, Firewall | | `Connection refused` | Listener und Prozess prüfen | | Timeout | Route, Firewall, Rückweg und Paketmitschnitt | | Nur ein Client betroffen | Clientkonfiguration mit Vergleichssystem vergleichen | | Nur ein VLAN betroffen | VLAN, Gateway, DHCP-Relay und ACL | | Nur extern nicht erreichbar | NAT, Firewall, öffentliche Adresse und CGNAT | | Nur intern über öffentlichen Namen fehlerhaft | Hairpin NAT oder Split DNS | | Browser funktioniert, Dienst nicht | WinHTTP, Proxyvariablen und Benutzerkontext | | VPN verbunden, internes Ziel nicht erreichbar | Tunneladresse, Route, DNS und Netzüberlappung | | WLAN verbunden, kein Internet | DHCP, Gateway, DNS und Captive Portal | | Verbindung langsam | Gatewayping, Fehlerzähler, iperf3 und Auslastung | | Kleine Pakete funktionieren, große nicht | MTU, ICMP und Path-MTU-Discovery | | Sporadische Abbrüche | Langzeitmessung, Logs, Link-Flaps und Paketmitschnitt | | TCP funktioniert, UDP nicht | UDP-spezifischen Diensttest, Firewall und Mitschnitt | | IPv4 funktioniert, IPv6 nicht | IPv6-Adresse, Route, DNS-AAAA und ICMPv6 | | Container lokal erreichbar, extern nicht | Port Publishing, Bind-Adresse, Host-Firewall und NAT |
---
35. Kompakter Diagnoseblock pro Betriebssystem **Windows – rein lesender Basisblock:** ```powershell [RO] Get-Date -Format o [RO] hostname [RO] Get-NetAdapter [RO][SENS] Get-NetIPConfiguration -All [RO] Get-NetRoute [RO][SENS] Get-DnsClientServerAddress [RO][SENS] Get-NetNeighbor [RO] Get-NetTCPConnection [RO] Get-NetUDPEndpoint [RO] Get-NetAdapterStatistics [RO] Get-NetConnectionProfile [RO] Get-NetFirewallProfile ``` **Linux – rein lesender Basisblock:** ```bash [RO] date --iso-8601=seconds [RO] hostnamectl [RO] ip -br link [RO][SENS] ip -br address [RO] ip route show [RO] ip -6 route show [RO][SENS] ip neigh show [RO][SENS] resolvectl status [RO] ss -tuln [RO] ip -s link ``` Falls `resolvectl` nicht vorhanden ist: ```bash [RO][SENS] cat /etc/resolv.conf ``` **macOS – rein lesender Basisblock:** ```bash [RO] date "+%Y-%m-%dT%H:%M:%S%z" [RO] sw_vers [RO] scutil --get ComputerName [RO] networksetup -listallhardwareports [RO][SENS] ifconfig [RO] netstat -rn [RO][SENS] arp -an [RO][SENS] ndp -an [RO][SENS] scutil --dns [RO] netstat -anv [RO] netstat -ib ``` Die Kennzeichnungen `[RO]` und `[SENS]` sind Dokumentationsmarkierungen und werden beim tatsächlichen Kopieren eines Befehls nicht mit eingegeben.
---
36. Dokumentationsvorlage für eine Netzwerkdiagnose ```text Störung: Zeitpunkt: Zeitzone: Benutzer: Standort: Client: Betriebssystem: Schnittstelle: MAC-Adresse: Linkstatus: Linkgeschwindigkeit: WLAN-SSID: WLAN-BSSID: VLAN: IPv4-Adresse: IPv4-Präfix: IPv4-Gateway: IPv6-Adresse: IPv6-Präfix: IPv6-Gateway: DHCP-Server: DNS-Server: DNS-Suffixe: Zielhostname: Aufgelöste Zieladresse: Transportprotokoll: Zielport: Anwendung: Loopbacktest: Gatewaytest: Interner IP-Test: Externer IP-Test: DNS-Test: Routenergebnis: Porttest: Anwendungstest: Listener vorhanden: Zugehöriger Prozess: Firewallstatus: Passende Firewallregel: NAT beteiligt: Proxy beteiligt: VPN beteiligt: Container beteiligt: Paketverlust: Latenz: Jitter: TCP-Durchsatz: UDP-Verlust: Schnittstellenfehler: Paketmitschnitt: Messpunkt: Capture Filter: Relevante Frames: Systemprotokolle: Festgestellte Ursache: Genehmigte Änderung: Rückfallplan: Ergebnis der Nachprüfung: ```
---
37. Abschließende Kontrollfragen - Wurde die richtige Schnittstelle geprüft? - Sind IPv4 und IPv6 getrennt betrachtet worden? - Stimmen Adresse, Präfix, Gateway und DNS? - Ist das Ziel über IP-Adresse erreichbar? - Wird der Hostname korrekt aufgelöst? - Führt die Route über die erwartete Schnittstelle? - Ist der benötigte Port geöffnet? - Lauscht der richtige Prozess? - Funktioniert das eigentliche Anwendungsprotokoll? - Wurde TCP nicht mit UDP verwechselt? - Wurden Firewall, NAT, Proxy und VPN berücksichtigt? - Wurde bei Containern zwischen Host- und Containerport unterschieden? - Wurde ein Timeout nicht automatisch als Firewallfehler bewertet? - Wurde Paketverlust an Zwischenhops korrekt interpretiert? - Wurden Hin- und Rückrichtung geprüft? - Wurde die Messung mit einem funktionierenden System verglichen? - Wurde vor einer Änderung der Istzustand dokumentiert? - Wurde nach der Änderung mit derselben Methode erneut geprüft? - Enthalten Ausgaben oder Paketmitschnitte sensible Daten? - Ist die festgestellte Ursache durch konkrete Messwerte belegt?
---
38. Quellen und Befehlsreferenzen - Microsoft Learn – Windows-Netzwerk-Cmdlets: https://learn.microsoft.com/powershell/module/nettcpip/ - Microsoft Learn – Windows-Firewall-Cmdlets: https://learn.microsoft.com/powershell/module/netsecurity/ - Microsoft Learn – `netsh wlan`: https://learn.microsoft.com/windows-server/administration/windows-commands/netsh-wlan - Microsoft Learn – `ping`: https://learn.microsoft.com/windows-server/administration/windows-commands/ping - Microsoft Learn – `tracert`: https://learn.microsoft.com/windows-server/administration/windows-commands/tracert - Microsoft Learn – `pathping`: https://learn.microsoft.com/windows-server/administration/windows-commands/pathping - Microsoft Learn – Pktmon: https://learn.microsoft.com/windows-server/administration/windows-commands/pktmon - Linux-Handbuch – iproute2: https://man7.org/linux/man-pages/man8/ip.8.html - Linux-Handbuch – `ss`: https://man7.org/linux/man-pages/man8/ss.8.html - NetworkManager – `nmcli`: https://networkmanager.dev/docs/api/latest/nmcli.html - firewalld – Dokumentation: https://firewalld.org/documentation/ - Netfilter – nftables: https://netfilter.org/projects/nftables/manpage.html - Apple – `networksetup`: Auf dem Mac lokal mit `man networksetup` - Apple – Netzwerk- und WLAN-Diagnose: https://support.apple.com/de-de/guide/mac-help/mchlf4de377f/mac - Wireshark – Benutzerhandbuch: https://www.wireshark.org/docs/wsug_html_chunked/ - Wireshark – Befehlsreferenzen: https://www.wireshark.org/docs/man-pages/ - curl – Handbuch: https://curl.se/docs/manpage.html - ESnet – iperf3: https://software.es.net/iperf/ - WireGuard – Dokumentation: https://www.wireguard.com/quickstart/ - OpenVPN – Referenzhandbuch: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/ - Docker – Networking: https://docs.docker.com/engine/network/