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.

Beispiele

[RO] Get-NetIPConfiguration

Der Befehl zeigt die vorhandene Windows-Netzwerkkonfiguration an.

[TEST] ping -c 4 192.0.2.1

Der Befehl sendet aktiv ICMP-Echo-Anfragen.

[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.

Vor der technischen Analyse sollte der erwartete Kommunikationsweg gezeichnet werden.

Beispiel: Zugriff auf eine interne Anwendung

Client
  → Netzwerkschnittstelle
    → Access Switch
      → VLAN
        → Standardgateway
          → Firewall
            → Reverse Proxy
              → Anwendungsserver
                → Datenbankserver

Beispiel: Internetzugriff

Client
  → Switch oder Access Point
    → lokales Gateway
      → Firewall
        → NAT
          → Internetprovider
            → externes Zielsystem

Beispiel: VPN-Zugriff

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.

Die Untersuchung sollte vom Allgemeinen zum Spezifischen erfolgen.

Beispiel

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.

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.

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

Link vorhanden?
  ↓
gültige IP-Konfiguration?
  ↓
lokales Gateway erreichbar?
  ↓
Route zum Ziel vorhanden?
  ↓
Name korrekt aufgelöst?
  ↓
Port erreichbar?
  ↓
Anwendungsprotokoll funktioniert?

Bottom-up

Die Untersuchung beginnt auf der untersten Ebene:

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:

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:

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.

Ein Vergleich ist besonders aussagekräftig, wenn dabei nur ein relevanter Faktor verändert wird.

Die Platzhalter GATEWAY und ZIEL müssen durch vorher eindeutig bestimmte Adressen oder Namen ersetzt werden.

Jeder Test beantwortet nur eine begrenzte technische Frage. Die Aussage darf nicht weiter ausgedehnt werden, als das Testergebnis tatsächlich belegt.

Hilfreiche Eingrenzungsfragen

Funktioniert derselbe Zugriff von einem anderen Client?

Kann der betroffene Client ein anderes Ziel erreichen?

Funktioniert der Zugriff über die IP-Adresse?

Ist nur ein Port oder sind alle Dienste des Zielsystems betroffen?

Tritt der Fehler per LAN und WLAN auf?

Tritt der Fehler nur bei aktivem VPN auf?

• Ä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.

Vor einer Änderung sollten der Ausgangszustand, die Hypothese, die erwartete Wirkung und der Rückweg dokumentiert werden.

Ungeeignete Vermutung

„Bestimmt ist die Firewall schuld.“

Prüfbare Hypothese

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.

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:

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.

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

Umfang → Link → IP → Gateway → Route → DNS → Port → Anwendung

Microsoft

• Grundlagen von TCP/IP
• Get-NetAdapter
• Get-NetIPConfiguration
• Get-NetRoute
• Get-NetNeighbor
• Test-NetConnection
• Resolve-DnsName

Linux

• ip-address – Linux Manual Page
• ip-link – Linux Manual Page
• ip-route – Linux Manual Page
• ip-neighbour – Linux Manual Page
• ss – Linux Manual Page

Apple

• Lokale Befehlsreferenzen: man ifconfig, man route, man netstat, man arp, man ping und man traceroute
• Apple Platform Deployment – Network Services

Wireshark und tcpdump

• Wireshark User’s Guide
• Wireshark Display Filter Reference
• tcpdump Manual Page
• pcap-filter Manual Page

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.

Ungeeignete Fehlerbeschreibung

„Das Internet funktioniert nicht.“

Geeignete Fehlerbeschreibung

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.

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.

Ungenau:
„Ist das Netzwerk langsam?“

Besser:
„Wie lange dauert der Aufruf normalerweise und wie lange dauert er jetzt?“

Mögliche Umfangsebenen

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.

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.

Die funktionierenden Bereiche sind für die Eingrenzung genauso wichtig wie der eigentliche Fehler.

Beispiel

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

Eine belastbare Eingrenzung verwendet möglichst alle drei Testarten.

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

[RO] hostname

[RO] Get-ComputerInfo |
    Select-Object CsName,
                  WindowsProductName,
                  WindowsVersion,
                  OsBuildNumber

[RO] Get-NetIPConfiguration

[RO] Get-NetAdapter |
    Select-Object Name,
                  InterfaceDescription,
                  Status,
                  LinkSpeed,
                  MacAddress,
                  ifIndex

Linux

[RO] hostnamectl

[RO] ip -brief address

[RO] ip route

[RO] ip -brief link

macOS

[RO] scutil --get ComputerName

[RO] sw_vers

[RO] ifconfig

[RO] netstat -rn

[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.

Ein Dienstname oder eine URL muss in seine technischen Bestandteile zerlegt werden.

Beispiel-URL

https://app.example.intern:8443/login

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

[RO] Resolve-DnsName app.example.intern

[TEST] Test-NetConnection app.example.intern -Port 443

Linux

[RO] getent ahosts app.example.intern

[TEST] nc -vz app.example.intern 443

macOS

[RO] dscacheutil -q host -a name app.example.intern

[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.

Direkter Zugriff im lokalen Netz

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

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

Browser
  → DNS-Auflösung
    → Reverse Proxy TCP 443
      → TLS-Verarbeitung
        → Backend TCP 8080
          → Anwendung
            → Datenbank

Zugriff über VPN

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.

Windows – Route zu einem Ziel untersuchen

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Routingtabelle anzeigen:

[RO] Get-NetRoute -AddressFamily IPv4 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric

Pfad verfolgen:

[TEST] tracert -d 198.51.100.20

Linux – ausgewählte Route anzeigen

[RO] ip route get 198.51.100.20

Beispielausgabe:

198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.10

Pfad verfolgen:

[TEST] traceroute -n 198.51.100.20

macOS – ausgewählte Route anzeigen

[RO] route -n get 198.51.100.20

Pfad verfolgen:

[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.

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:

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Schnittstellenmetriken:

[RO] Get-NetIPInterface |
    Sort-Object AddressFamily, InterfaceMetric |
    Select-Object ifIndex,
                  InterfaceAlias,
                  AddressFamily,
                  ConnectionState,
                  InterfaceMetric

Linux

[RO] ip route get 198.51.100.20

Richtlinienregeln anzeigen:

[RO] ip rule show

Alle wichtigen Routingtabellen anzeigen:

[RO] ip route show table all

macOS

[RO] route -n get 198.51.100.20

Netzwerkdienstreihenfolge grafisch prüfen:

Systemeinstellungen
→ Netzwerk
→ Aktionsmenü
→ Reihenfolge der Dienste festlegen

Die sichtbare Dienstreihenfolge allein ersetzt nicht die Prüfung der tatsächlich ausgewählten Route.

Das Endgerät entscheidet anhand von IP-Adresse und Präfix beziehungsweise Subnetzmaske, ob das Ziel lokal erreichbar sein sollte.

Lokales Ziel

Quelle: 192.0.2.10/24
Ziel:   192.0.2.20

Beide Adressen gehören zum Netz:

192.0.2.0/24

Der Client versucht normalerweise, die MAC-Adresse des Zielsystems direkt zu ermitteln.

Entferntes Ziel

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

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.

Ein Hostname kann IPv4- und IPv6-Adressen besitzen.

Windows

[RO] Resolve-DnsName app.example.intern -Type A

[RO] Resolve-DnsName app.example.intern -Type AAAA

Bestehende TCP-Verbindung prüfen:

[RO] Get-NetTCPConnection |
    Where-Object RemotePort -eq 443 |
    Select-Object LocalAddress,
                  LocalPort,
                  RemoteAddress,
                  RemotePort,
                  State,
                  OwningProcess

Linux

[RO] getent ahosts app.example.intern

IPv4 gezielt testen:

[TEST] curl -4 -I https://app.example.intern/

IPv6 gezielt testen:

[TEST] curl -6 -I https://app.example.intern/

macOS

[RO] dscacheutil -q host -a name app.example.intern

[TEST] curl -4 -I https://app.example.intern/

[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.

Der im DNS eingetragene Endpunkt ist möglicherweise nicht der eigentliche Anwendungsserver.

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

Ein erfolgreicher Test gegen ein einzelnes Backend beweist nicht, dass der vollständige produktive Weg über den Load Balancer funktioniert.

Windows – WinHTTP-Proxy

[RO] netsh winhttp show proxy

Benutzerbezogene Windows-Proxyeinstellungen:

[RO] Get-ItemProperty `
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable,
                  ProxyServer,
                  AutoConfigURL

Linux

[RO][SENS] env |
    grep -iE '^(http|https|all|no)_proxy='

macOS

[RO] scutil --proxy

Proxykonfiguration eines bestimmten Netzwerkdienstes:

[RO] networksetup -getwebproxy "Wi-Fi"

[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.

Eine Störungsmatrix macht Muster sichtbar.

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.

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.

Nach der ersten Eingrenzung sollten folgende Ergebnisse vorliegen:

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:

3.2 Physische Verbindung und Netzwerkschnittstelle prüfen

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

Microsoft

• Get-NetIPConfiguration
• Get-NetAdapter
• Get-NetRoute
• Find-NetRoute
• Get-NetIPInterface
• Get-NetTCPConnection
• Resolve-DnsName
• Test-NetConnection
• netsh winhttp

Linux

• ip-address – Linux Manual Page
• ip-link – Linux Manual Page
• ip-route – Linux Manual Page
• ip-rule – Linux Manual Page
• getent – Linux Manual Page

Apple

• Lokale Befehlsreferenzen: man ifconfig, man route, man netstat, man scutil und man networksetup
• Apple Platform Deployment – Network Services

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.

Kupfer-Ethernet

Endgerät
  → Netzwerkkarte
    → RJ45-Stecker
      → Patchkabel
        → Netzwerkdose
          → Gebäudeverkabelung
            → Patchpanel
              → Patchkabel
                → Switchport

Glasfaserverbindung

Gerät
  → Netzwerkkarte
    → Transceiver
      → Glasfaserkabel
        → Patchfeld
          → Glasfaserstrecke
            → Transceiver
              → Switchport

WLAN-Verbindung

Client
  → WLAN-Adapter
    → Funkverbindung
      → Access Point
        → Ethernet-Uplink
          → Switchport

Jede Komponente kann vollständig ausfallen oder die Verbindung nur zeitweise beeinträchtigen.

• 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.

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.

[CHANGE][DISRUPT] Das Entfernen eines Kabels oder Transceivers unterbricht die Verbindung.

Linux-Beispiel

<UP,BROADCAST,RUNNING,MULTICAST,LOWER_UP>

Eine Schnittstelle kann administrativ UP sein, obwohl kein Kabel angeschlossen und kein physischer Link vorhanden ist.

Alle sichtbaren Netzwerkadapter

[RO] Get-NetAdapter |
    Sort-Object Name |
    Format-Table Name,
                 InterfaceDescription,
                 ifIndex,
                 Status,
                 LinkSpeed,
                 MacAddress

Auch ausgeblendete Adapter anzeigen

[RO] Get-NetAdapter -IncludeHidden |
    Sort-Object Name |
    Format-Table Name,
                 InterfaceDescription,
                 ifIndex,
                 Status,
                 LinkSpeed,
                 MacAddress

Bestimmten Adapter vollständig anzeigen

[RO] Get-NetAdapter -Name 'Ethernet' |
    Format-List *

Physische Adapter anzeigen

[RO] Get-NetAdapter -Physical |
    Format-Table Name,
                 InterfaceDescription,
                 Status,
                 LinkSpeed,
                 MacAddress

Grafische Adapterübersicht öffnen

[RO] ncpa.cpl

Wichtige Felder

Virtuelle Adapter, VPN-Adapter und Hypervisorinterfaces müssen von der tatsächlich verwendeten physischen Schnittstelle unterschieden werden.

Grundlegende Statistiken

[RO] Get-NetAdapterStatistics

Bestimmten Adapter vollständig anzeigen

[RO] Get-NetAdapterStatistics -Name 'Ethernet' |
    Format-List *

Kompakte Übersicht

[RO] Get-NetAdapterStatistics -Name 'Ethernet' |
    Select-Object Name,
                  ReceivedBytes,
                  ReceivedUnicastPackets,
                  ReceivedDiscardedPackets,
                  ReceivedPacketErrors,
                  SentBytes,
                  SentUnicastPackets,
                  OutboundDiscardedPackets,
                  OutboundPacketErrors

Zähler zu zwei Zeitpunkten vergleichen

[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

Die genaue Herkunft einzelner Zähler hängt vom Netzwerktreiber und Adapter ab.

Treiberinformationen des Adapters

[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:

[RO] Get-CimInstance Win32_PnPSignedDriver |
    Where-Object DeviceClass -eq 'NET' |
    Select-Object DeviceName,
                  Manufacturer,
                  DriverProviderName,
                  DriverVersion,
                  DriverDate,
                  IsSigned

Erweiterte Eigenschaften anzeigen

[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'

Energiespareinstellungen anzeigen

[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'

Hardwarestatus über den Geräte-Manager

[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.

[CHANGE][DISRUPT] Änderungen an Geschwindigkeit, Duplex, Offloading,
Puffern oder Energieverwaltung können die Verbindung unterbrechen
oder die Leistung verschlechtern.

Kurzübersicht aller Schnittstellen

[RO] ip -brief link

Bestimmte Schnittstelle

[RO] ip link show dev eth0

Linkstatus aus sysfs

[RO] cat /sys/class/net/eth0/operstate

[RO] cat /sys/class/net/eth0/carrier

Typische Ausgabe von carrier:

Der Zugriff kann abhängig von Treiber, Interfacezustand und Berechtigungen fehlschlagen.

Schnittstellenereignisse live beobachten

[RO] ip monitor link

Beenden mit:

Strg+C

Damit können Link-Up-, Link-Down- und andere Schnittstellenänderungen während der Fehlerreproduktion beobachtet werden.

Falls ethtool installiert ist:

[RO][PRIV] sudo ethtool eth0

Typische relevante Felder:

Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

Treiber- und Firmwareinformationen

[RO][PRIV] sudo ethtool -i eth0

Treiberstatistiken

[RO][PRIV] sudo ethtool -S eth0

Pause-Frame-Einstellungen anzeigen

[RO][PRIV] sudo ethtool -a eth0

Energy Efficient Ethernet anzeigen

[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.

Standardstatistiken anzeigen

[RO] ip -s link show dev eth0

Detailliertere Standardstatistiken:

[RO] ip -s -s link show dev eth0

Beispielstruktur:

RX: bytes  packets  errors  dropped  missed  mcast
TX: bytes  packets  errors  dropped  carrier collsns

Zähler aus sysfs

[RO] grep . /sys/class/net/eth0/statistics/*

Ausgewählte Zähler:

[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

[RO] ip -s link show dev eth0

Fehler reproduzieren oder einen definierten Zeitraum abwarten:

[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.

Kernelmeldungen des aktuellen Starts

[RO][PRIV] sudo journalctl -k -b

Nach typischen Netzwerkmeldungen suchen:

[RO][PRIV] sudo journalctl -k -b |
    grep -Ei 'link.*(up|down)|carrier|duplex|firmware|eth|network|reset|timeout'

Meldungen einer bestimmten Schnittstelle

[RO][PRIV] sudo journalctl -k -b |
    grep -F 'eth0'

NetworkManager-Protokoll

[RO][PRIV] sudo journalctl -b -u NetworkManager

systemd-networkd-Protokoll

[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.

Hardwareports und Gerätenamen zuordnen

[RO] networksetup -listallhardwareports

Beispiel:

Hardware Port: Ethernet
Device: en0
Ethernet Address: 00:11:22:33:44:55

Alle Schnittstellen anzeigen

[RO] ifconfig

Bestimmte Schnittstelle anzeigen

[RO] ifconfig en0

Wichtige Felder:

Status eines Netzwerkdienstes

[RO] networksetup -getinfo "Ethernet"

Der Dienstname muss vorher mit folgendem Befehl ermittelt werden:

[RO] networksetup -listallnetworkservices

Medienstatus

[RO] networksetup -getMedia "Ethernet"

Die Verfügbarkeit und Ausgabe von -getMedia hängen vom Adapter, Treiber und Netzwerkdienst ab.

Interfaceübersicht mit Zählern

[RO] netstat -ib

Nur eine bestimmte Schnittstelle:

[RO] netstat -ib -I en0

Regelmäßig aktualisierte Anzeige:

[RO] netstat -w 1 -I en0

Beenden mit:

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

[RO][SENS] system_profiler SPNetworkDataType

Der Systembericht kann interne Netzwerk-, Geräte- und Dienstinformationen enthalten und sollte bei einer Weitergabe entsprechend behandelt werden.

Beispiel einer erwarteten Verbindung

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.

[CHANGE][DISRUPT] Geschwindigkeit und Duplex nicht einseitig und nicht
ohne dokumentierten Rückweg verändern.

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

1. Ausgangswerte notieren.
2. Fehler reproduzieren.
3. Zähler erneut erfassen.
4. Differenz berechnen.
5. Gegenseite im selben Zeitraum prüfen.

Eine Verbindung besitzt zwei Enden:

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:

Die konkreten Switchbefehle unterscheiden sich je nach Hersteller und Betriebssystem. Sie dürfen nicht aus Beispielen anderer Plattformen übernommen werden.

Ausgangslage

CLIENT-023 verliert wiederholt den Link.

Kontrollierter Vergleich

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.

[CHANGE][DISRUPT] Kabel- und Portwechsel unterbrechen bestehende Verbindungen.

Zusätzliche mögliche Fehlerstellen:

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.

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

[RO] Get-NetAdapterPowerManagement -Name 'Ethernet'

Windows-Ereignisse des Netzwerkadapters suchen

[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

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'suspend|resume|link.*(up|down)|network|firmware'

macOS

[RO] pmset -g log |
    grep -Ei 'sleep|wake'

Energiesparfunktionen sollten nicht dauerhaft deaktiviert werden, solange der Zusammenhang nicht belegt ist.

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.

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.

[CHANGE][DISRUPT] Offloading-Funktionen nicht pauschal als
„Problemlösung“ deaktivieren.

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

[PRIV][CHANGE][DISRUPT] Restart-NetAdapter -Name 'Ethernet'

Linux

[PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 down

[PRIV][CHANGE][DISRUPT] sudo ip link set dev eth0 up

macOS

[PRIV][CHANGE][DISRUPT] sudo ifconfig en0 down

[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.

Merksatz

Ansehen → Status lesen → Zähler vergleichen → Gegenseite prüfen
→ kontrolliert tauschen → erneut messen

Die Beispielnamen Ethernet, eth0 und en0 müssen durch die zuvor eindeutig ermittelte Schnittstelle ersetzt werden.

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:

Microsoft

• Get-NetAdapter
• Get-NetAdapterStatistics
• Get-NetAdapterAdvancedProperty
• Get-NetAdapterPowerManagement
• Restart-NetAdapter
• Erweiterte NIC-Eigenschaften

Linux

• Linux Interface Statistics – Kernel-Dokumentation
• ethtool-Netlink – Kernel-Dokumentation
• ip-link – Linux Manual Page
• Lokale Befehlsreferenz: man ethtool

Apple

• Netzwerkstatus auf dem Mac prüfen
• Netzwerkumgebungen auf dem Mac verwenden
• 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.

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

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

• 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.

Kompakte PowerShell-Übersicht

[RO] Get-NetIPConfiguration

Vollständige klassische Ausgabe

[RO][SENS] ipconfig /all

Die Ausgabe kann Hostname, MAC-Adressen, DNS-Suffixe, DHCP-Server und interne Netzwerkadressen enthalten.

Nur aktive Adapter mit IPv4-Konfiguration

[RO] Get-NetIPConfiguration |
    Where-Object NetAdapter.Status -eq 'Up' |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  IPv4Address,
                  IPv4DefaultGateway,
                  DNSServer

Alle IP-Adressen anzeigen

[RO] Get-NetIPAddress |
    Sort-Object InterfaceIndex, AddressFamily, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 SuffixOrigin,
                 AddressState

Nur IPv4-Adressen

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState

Nur IPv6-Adressen

[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState

Standardrouten anzeigen

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric

IPv6-Standardrouten:

[RO] Get-NetRoute -DestinationPrefix '::/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric

Kompakte Adressübersicht

[RO] ip -brief address

Ausführliche Adressübersicht

[RO] ip address show

Bestimmte Schnittstelle

[RO] ip address show dev eth0

Nur IPv4

[RO] ip -4 address show

Nur IPv6

[RO] ip -6 address show

IPv4-Routingtabelle

[RO] ip -4 route

IPv6-Routingtabelle

[RO] ip -6 route

Route und ausgewählte Quelladresse zu einem Ziel

[RO] ip route get 198.51.100.20

IPv6:

[RO] ip -6 route get 2001:db8:20::20

NetworkManager-Verbindungen

Falls NetworkManager verwendet wird:

[RO] nmcli connection show

Aktive Verbindungen:

[RO] nmcli connection show --active

Geräteinformationen:

[RO] nmcli device show

systemd-networkd

Falls systemd-networkd verwendet wird:

[RO] networkctl status

[RO] networkctl status eth0

Nicht jede Linux-Installation verwendet NetworkManager oder systemd-networkd. Zuerst muss bestimmt werden, welche Komponente die Netzwerkkonfiguration verwaltet.

Hardwareports und Gerätenamen

[RO] networksetup -listallhardwareports

Alle Schnittstellen

[RO] ifconfig

Bestimmte Schnittstelle

[RO] ifconfig en0

IPv4-Konfiguration eines Netzwerkdienstes

[RO] networksetup -getinfo "Ethernet"

Der tatsächliche Dienstname muss vorher ermittelt werden:

[RO] networksetup -listallnetworkservices

IPv4-Konfigurationsmethode

[RO] networksetup -getinfo "Wi-Fi"

DNS-Konfiguration

[RO][SENS] scutil --dns

IPv4-Routingtabelle

[RO] netstat -rn -f inet

IPv6-Routingtabelle

[RO] netstat -rn -f inet6

Ausgewählte Route zu einem IPv4-Ziel

[RO] route -n get 198.51.100.20

Ausgewählte Route zu einem IPv6-Ziel

[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.

Beispiel

IPv4-Adresse: 192.0.2.23
Präfix:        /24
Subnetzmaske:  255.255.255.0

Daraus ergibt sich:

Vergleich zweier Ziele

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.

Berechnung der Gesamtzahl

2 hoch (32 − Präfixlänge)

Beispiel /27:

2 hoch (32 − 27)
= 2 hoch 5
= 32 Adressen

Für gewöhnliche IPv4-Subnetze werden Netzwerk- und Broadcastadresse abgezogen:

32 − 2 = 30 klassische Hostadressen

Vorgesehene Konfiguration

Client: 192.0.2.130/25
Gateway: 192.0.2.129

Das vorgesehene Subnetz lautet:

192.0.2.128/25

Adressbereich:

192.0.2.128 bis 192.0.2.255

Fehlerhafte Konfiguration

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.

Windows und andere Betriebssysteme können eine IPv4-Link-Local-Adresse aus folgendem Bereich verwenden:

169.254.0.0/16

Unter Windows wird dies häufig als APIPA bezeichnet.

Beispiel:

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

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Where-Object IPAddress -Like '169.254.*'

Linux-Prüfung

[RO] ip -4 address show |
    grep '169\.254\.'

macOS-Prüfung

[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.

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.

Zuerst muss das konfigurierte Gateway ausgelesen werden. Es darf nicht angenommen werden, dass es immer auf .1 endet.

Windows

[RO] Get-NetIPConfiguration |
    Select-Object InterfaceAlias,
                  IPv4Address,
                  IPv4DefaultGateway

Gateway testen:

[TEST] Test-Connection 192.0.2.1 -Count 4

Linux

[RO] ip route show default

Gateway testen:

[TEST] ping -c 4 192.0.2.1

macOS

[RO] route -n get default

Gateway testen:

[TEST] ping -c 4 192.0.2.1

Interpretation

Ein fehlgeschlagener Ping beweist nicht, dass das Gateway vollständig unerreichbar ist. Manche Gateways beantworten ICMP nicht oder nur eingeschränkt.

Bei mehreren Adressen und Schnittstellen ist nicht automatisch die erwartete Quelladresse aktiv.

Windows

[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

[RO] ip route get 198.51.100.20

Beispiel:

198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23

macOS

[RO] route -n get 198.51.100.20

Zu kontrollieren sind:

Eine unerwartete Quelladresse kann zu Firewall-, Rückweg-, NAT- oder Berechtigungsproblemen führen.

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

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric, InterfaceMetric

Linux

[RO] ip route show default

[RO] ip rule show

macOS

[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.

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.

Link-Local-Adresse

Beispiel:

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

[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 AddressState,
                 PrefixOrigin,
                 SuffixOrigin

Linux

[RO] ip -6 address show

macOS

[RO] ifconfig |
    grep -E '^[a-z0-9]+:|inet6'

Eine vorhandene Link-Local-Adresse beweist nicht, dass globales oder standortübergreifendes IPv6-Routing funktioniert.

Eine IP-Adresse kann vorhanden sein, aber noch nicht vollständig verwendbar sein.

Windows-Feld AddressState

Linux-Ausgabe kann unter anderem zeigen

Prüfung unter Linux

[RO] ip address show

Eine Adresse im Zustand Duplicate oder dadfailed darf nicht als normal funktionsfähig betrachtet werden.

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

[RO] Get-NetIPAddress |
    Where-Object AddressState -ne 'Preferred' |
    Format-Table InterfaceAlias,
                 IPAddress,
                 AddressFamily,
                 AddressState

Systemereignisse untersuchen:

[RO] Get-WinEvent -LogName System -MaxEvents 1000 |
    Where-Object {
        $_.Message -match 'duplicate|conflict|Adressenkonflikt'
    } |
    Select-Object TimeCreated,
                  Id,
                  ProviderName,
                  Message

Linux

[RO] ip address show |
    grep -E 'tentative|dadfailed|deprecated'

Kernel- und Netzwerkprotokolle:

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'duplicate|conflict|dadfailed'

macOS

[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.

An dieser Stelle wird nur geprüft, welche DNS-Server konfiguriert sind. Die eigentliche DNS-Fehleranalyse erfolgt auf Seite 3.8.

Windows

[RO] Get-DnsClientServerAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 ServerAddresses

Linux mit systemd-resolved

[RO] resolvectl status

Klassische Resolverdatei:

[RO] cat /etc/resolv.conf

Die Datei /etc/resolv.conf kann automatisch generiert oder ein symbolischer Link sein:

[RO] ls -l /etc/resolv.conf

macOS

[RO][SENS] scutil --dns

Dienstbezogene DNS-Server:

[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.

Windows

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  Dhcp,
                  ConnectionState

Adressursprung:

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  IPAddress,
                  PrefixLength,
                  PrefixOrigin,
                  SuffixOrigin

Vollständige Leaseinformationen:

[RO][SENS] ipconfig /all

Linux mit NetworkManager

[RO] nmcli device show

Verbindungsprofil:

[RO][SENS] nmcli connection show

Die genaue Verbindung kann anschließend gezielt abgefragt werden:

[RO][SENS] nmcli connection show "VERBINDUNGSNAME"

macOS

[RO] networksetup -getinfo "Ethernet"

Mögliche Zustände

Die detaillierte DHCP-Analyse folgt auf Seite 3.4.

Die Adressen müssen durch die tatsächlichen Werte des untersuchten Systems ersetzt werden.

Windows

[TEST] Test-Connection 127.0.0.1 -Count 4

[TEST] Test-Connection 192.0.2.23 -Count 4

[TEST] Test-Connection 192.0.2.1 -Count 4

Linux und macOS

[TEST] ping -c 4 127.0.0.1

[TEST] ping -c 4 192.0.2.23

[TEST] ping -c 4 192.0.2.1

IPv6-Loopback

Windows:

[TEST] Test-Connection ::1 -Count 4

Linux und macOS:

[TEST] ping -c 4 ::1

Ein erfolgreicher Test zur eigenen IP-Adresse durchläuft nicht zwangsläufig den vollständigen physischen Netzwerkweg.

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

[RO][FILE][SENS] Get-NetIPConfiguration |
    Format-List * |
    Out-File 'C:\Temp\NetIPConfiguration-vorher.txt'

[RO][FILE][SENS] Get-NetIPAddress |
    Format-List * |
    Out-File 'C:\Temp\NetIPAddress-vorher.txt'

[RO][FILE][SENS] Get-NetRoute |
    Format-Table -AutoSize |
    Out-File 'C:\Temp\NetRoute-vorher.txt' -Width 300

Linux

[RO][FILE][SENS] ip address show > /tmp/ip-address-vorher.txt

[RO][FILE][SENS] ip route show table all > /tmp/ip-route-vorher.txt

macOS

[RO][FILE][SENS] ifconfig > /tmp/ifconfig-vorher.txt

[RO][FILE][SENS] netstat -rn > /tmp/netstat-route-vorher.txt

Die verwendeten Speicherorte müssen zur betrieblichen Umgebung und deren Datenschutzvorgaben passen.

Windows – DHCP-Lease freigeben

[PRIV][CHANGE][DISRUPT] ipconfig /release

Lease erneut anfordern:

[PRIV][CHANGE][DISRUPT] ipconfig /renew

Linux mit NetworkManager – Verbindung neu aktivieren

[PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME"

[PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME"

macOS – DHCP-Lease erneuern

[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.

Ein funktionierendes Vergleichssystem sollte möglichst folgende Merkmale teilen:

• gleicher Standort,
• gleiches VLAN,
• gleiche Verbindungsart,
• gleiche Geräteklasse,
• gleiche Betriebssystemversion,
• gleiche Netzwerkrolle.

Vergleichstabelle

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.

Merksatz

Schnittstelle → Adresse → Präfix → Gateway → DNS
→ Route → Quelladresse → Vergleich

Die Platzhalter DIENST, INTERFACE, GATEWAY und ZIEL-IP müssen durch zuvor eindeutig ermittelte Werte ersetzt werden.

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:

Microsoft

• Get-NetIPConfiguration
• Get-NetIPAddress
• Get-NetIPInterface
• Get-NetRoute
• Find-NetRoute
• Get-DnsClientServerAddress
• TCP/IP-Adressierung und Subnetting

Linux

• ip-address – Linux Manual Page
• ip-route – Linux Manual Page
• ip-rule – Linux Manual Page
• NetworkManager nmcli
• systemd networkctl

Apple

• Lokale Befehlsreferenzen: man ifconfig, man route, man netstat, man scutil, man networksetup und man ipconfig
• Ändern der TCP/IP-Einstellungen auf dem Mac
• Ändern der DNS-Einstellungen auf dem Mac

Standards

• RFC 1918 – Private Address Space
• RFC 3927 – IPv4 Link-Local Addresses
• RFC 4291 – IPv6 Addressing Architecture
• RFC 6164 – IPv6 Prefix Length for Point-to-Point Links
• RFC 3021 – IPv4 /31 Point-to-Point Links
• RFC 5737 – IPv4 Documentation Address Blocks

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.

• 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.

Vor einer Lease-Erneuerung sollten zusätzlich gespeichert werden:

• vollständige IP-Konfiguration,
• Routingtabelle,
• DNS-Konfiguration,
• DHCP-Clientprotokolle,
• relevante Netzwerkereignisse,
• Vergleichsdaten eines funktionierenden Clients.

Der klassische erstmalige DHCPv4-Ablauf wird häufig als DORA bezeichnet:

Client                                   DHCP-Server
  │                                           │
  │──── DHCPDISCOVER ────────────────────────>│
  │<─── DHCPOFFER ────────────────────────────│
  │──── DHCPREQUEST ─────────────────────────>│
  │<─── DHCPACK ──────────────────────────────│
  │                                           │

DHCPv4 verwendet grundsätzlich:

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.

Vollständige Konfiguration

[RO][SENS] ipconfig /all

Zu prüfen sind insbesondere:

DHCP aktiviert
IPv4-Adresse
Subnetzmaske
Lease erhalten
Lease läuft ab
Standardgateway
DHCP-Server
DNS-Server
Verbindungsspezifisches DNS-Suffix

DHCP-Status der Schnittstellen

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  Dhcp,
                  ConnectionState,
                  InterfaceMetric

Adressursprung

[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  IPAddress,
                  PrefixLength,
                  PrefixOrigin,
                  SuffixOrigin,
                  AddressState

Konfiguration sichern

[RO][FILE][SENS] ipconfig /all |
    Out-File 'C:\Temp\ipconfig-vor-dhcp-test.txt'

[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.

Verfügbare DHCP-bezogene Protokolle suchen

[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:

Anwendungs- und Dienstprotokolle
→ Microsoft
  → Windows
    → Dhcp-Client

Aktivierte DHCP-Protokolle auslesen

[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

[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.

Grundlegende IP-Konfiguration

[RO] ip -4 address

[RO] ip -4 route

Mit NetworkManager

Gerätestatus:

[RO] nmcli device status

Ausführliche Gerätedaten:

[RO][SENS] nmcli device show eth0

Aktive Verbindungen:

[RO] nmcli connection show --active

Verbindungsprofil:

[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

[RO] networkctl status eth0

[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:

[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.

NetworkManager

[RO][PRIV] sudo journalctl -b -u NetworkManager

Nach DHCP-Meldungen filtern:

[RO][PRIV] sudo journalctl -b -u NetworkManager |
    grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout'

systemd-networkd

[RO][PRIV] sudo journalctl -b -u systemd-networkd

Nach DHCP-Meldungen filtern:

[RO][PRIV] sudo journalctl -b -u systemd-networkd |
    grep -Ei 'dhcp|lease|offer|request|ack|nak|timeout'

Allgemeine Protokollsuche

[RO][PRIV] sudo journalctl -b |
    grep -Ei 'dhcp|lease|dhclient|NetworkManager|systemd-networkd'

Kernelmeldungen zur Schnittstelle

[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.

Netzwerkdienste auflisten

[RO] networksetup -listallnetworkservices

Hardwareports zuordnen

[RO] networksetup -listallhardwareports

Konfiguration eines Dienstes

[RO] networksetup -getinfo "Ethernet"

DHCP-Paketinformationen einer Schnittstelle

[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

[RO] ipconfig getifaddr en0

DNS-Konfiguration

[RO][SENS] scutil --dns

Systemprotokolle nach DHCP durchsuchen

[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.

Ein Client kann eine statische Adresse besitzen und deshalb keine reguläre DHCP-Lease anfordern.

Windows

[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  Dhcp,
                  ConnectionState

Linux mit NetworkManager

[RO] nmcli connection show "VERBINDUNGSNAME" |
    grep -E '^ipv4\.method'

Typische Werte:

macOS

[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?

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.

Wireshark-Display-Filter für DHCPv4

dhcp

Je nach Wireshark-Version wird auch weiterhin der ältere Protokollname bootp in Feldern oder Filtern verwendet. Der folgende Filter ist deshalb ebenfalls verbreitet:

bootp

Nur DHCPv4-Ports

udp.port == 67 || udp.port == 68

TShark-Liveanzeige

[TEST][PRIV][SENS] tshark \
  -i INTERFACE \
  -f "udp port 67 or udp port 68"

Zeitlich begrenzte Aufnahme mit dumpcap

[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

[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:

[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.

Wenn der Client DHCPDISCOVER sendet, aber kein Angebot erhält, wird der Kommunikationsweg geprüft:

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.

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.

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

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.

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

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.

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

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.

Eine Lease kann erfolgreich bestätigt werden und trotzdem falsche Parameter enthalten.

Typische DHCP-Optionen:

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.

Eine DHCP-Lease besitzt eine begrenzte Gültigkeitsdauer.

Vereinfacht:

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:

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

Erst nachdem der Ausgangszustand dokumentiert wurde und geklärt ist, dass die Schnittstelle DHCP verwenden soll.

Windows

Lease freigeben:

[PRIV][CHANGE][DISRUPT] ipconfig /release

Lease erneuern:

[PRIV][CHANGE][DISRUPT] ipconfig /renew

Nur einen benannten Adapter ansprechen:

[PRIV][CHANGE][DISRUPT] ipconfig /release "Ethernet"

[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:

[PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME"

[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:

[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:

[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.

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:

[RO] ps -ef |
    grep -E '[d]hclient|[N]etworkManager|[s]ystemd-networkd'

[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.

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:

Vereinfachter DHCPv6-Ablauf:

Client                                   DHCPv6-Server
  │                                           │
  │──── SOLICIT ─────────────────────────────>│
  │<─── ADVERTISE ────────────────────────────│
  │──── REQUEST ─────────────────────────────>│
  │<─── REPLY ────────────────────────────────│

Typische Nachrichten:

• SOLICIT,
• ADVERTISE,
• REQUEST,
• REPLY,
• RENEW,
• REBIND,
• RELEASE,
• INFORMATION-REQUEST.

Wireshark-Filter

dhcpv6

Capture-Filter:

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.

Diese Zuordnung bildet eine Arbeitshypothese und muss durch Logs, Paketmitschnitte und Vergleichstests bestätigt werden.

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.

Merksatz

Lease lesen → Clientlog prüfen → DORA verfolgen
→ Relay prüfen → Server und Scope prüfen → kontrolliert erneuern

Die Platzhalter DIENST, NAME, INTERFACE und en0 müssen durch die tatsächlich ermittelten Bezeichnungen ersetzt werden.

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:

Microsoft

• DHCP – technische Übersicht
• DHCP-Bereitstellung und -Verwaltung
• Get-NetIPInterface
• Get-NetIPAddress
• Get-WinEvent
• ipconfig

Linux

• NetworkManager nmcli
• systemd-networkd
• networkctl
• ip-address – Linux Manual Page

Apple

• Lokale Befehlsreferenzen: man ipconfig, man networksetup, man scutil und man log
• Ändern der TCP/IP-Einstellungen auf dem Mac

Wireshark

• Wireshark DHCP Display Filter Reference
• dumpcap Manual Page
• tshark Manual Page

Standards

• RFC 2131 – Dynamic Host Configuration Protocol
• RFC 2132 – DHCP Options
• RFC 3046 – DHCP Relay Agent Information Option
• RFC 8415 – DHCP for IPv6

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.

ARP ordnet eine lokale IPv4-Adresse einer MAC-Adresse zu.

Beispiel im selben Subnetz

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:

Wer hat 192.0.2.80?
Antwort bitte an 192.0.2.23.

Die Anfrage wird als Ethernet-Broadcast gesendet:

FF:FF:FF:FF:FF:FF

Der Server antwortet normalerweise per Unicast:

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.

Ausgangslage

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:

ARP-Anfrage:
Wer hat 192.0.2.1?

Anschließend entsteht vereinfacht folgender Frame:

Ethernet-Ziel-MAC: MAC-Adresse des Gateways
IP-Zieladresse:    198.51.100.20

Die Ethernetadressen können sich an jedem gerouteten Abschnitt ändern. Die IP-Zieladresse bleibt ohne NAT normalerweise bis zum Ziel bestehen.

• 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.

Zuerst wird die ausgewählte Route geprüft.

Windows

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Linux

[RO] ip route get 198.51.100.20

macOS

[RO] route -n get 198.51.100.20

Bewertung

Eine falsche Subnetzmaske kann dazu führen, dass ein Client ARP-Anfragen für ein eigentlich entferntes Ziel sendet.

PowerShell

[RO] Get-NetNeighbor -AddressFamily IPv4

Übersichtliche Darstellung

[RO] Get-NetNeighbor -AddressFamily IPv4 |
    Sort-Object InterfaceIndex, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 LinkLayerAddress,
                 State,
                 PolicyStore

Ein bestimmter Nachbar

[RO] Get-NetNeighbor `
    -InterfaceAlias 'Ethernet' `
    -IPAddress '192.0.2.1'

Klassischer Befehl

[RO] arp -a

Bestimmte IP-Adresse suchen:

[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.

Mögliche Zustände von Get-NetNeighbor:

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.

Alle IPv4-Nachbarn

[RO] ip -4 neighbour show

Kurzform:

[RO] ip -4 neigh

Bestimmte Schnittstelle

[RO] ip -4 neighbour show dev eth0

Bestimmte IP-Adresse

[RO] ip -4 neighbour show 192.0.2.1

Änderungen live beobachten

[RO] ip monitor neigh

Beenden mit:

Strg+C

Klassischer ARP-Befehl

[RO] arp -an

Der ältere Befehl arp ist nicht auf jeder Linux-Installation standardmäßig vorhanden. Für moderne Systeme ist ip neighbour vorzuziehen.

Beispiel

192.0.2.1 dev eth0 lladdr 00:11:22:33:44:01 REACHABLE

Fehlgeschlagener Eintrag

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.

Alle ARP-Einträge

[RO] arp -an

Bestimmte IP-Adresse

[RO] arp -n 192.0.2.1

Routingtabelle mit Link-Layer-Einträgen

[RO] netstat -rn -f inet

Beispiel eines vollständigen Eintrags:

? (192.0.2.1) at 00:11:22:33:44:01 on en0 ifscope [ethernet]

Beispiel eines unvollständigen Eintrags:

? (192.0.2.80) at (incomplete) on en0 ifscope [ethernet]

Ein unvollständiger Eintrag bedeutet, dass keine verwendbare MAC-Adresse ermittelt wurde.

Wenn noch kein Eintrag vorhanden ist, kann eine normale Kommunikation zum direkten Nachbarn die Auflösung auslösen.

Windows

[TEST] Test-Connection 192.0.2.1 -Count 1

Danach:

[RO] Get-NetNeighbor `
    -InterfaceAlias 'Ethernet' `
    -IPAddress '192.0.2.1'

Linux

[TEST] ping -c 1 192.0.2.1

Danach:

[RO] ip neighbour show 192.0.2.1

macOS

[TEST] ping -c 1 192.0.2.1

Danach:

[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.

arping sendet aktive ARP-Anfragen auf einer lokalen Ethernetverbindung. Das Werkzeug ist nicht unter jedem Betriebssystem standardmäßig vorhanden.

Linux-Beispiel

[TEST][PRIV] sudo arping \
    -I eth0 \
    -c 4 \
    192.0.2.1

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:

[RO] arping --help

oder:

[RO] man arping

Wireshark-Display-Filter

arp

Nur Anfragen:

arp.opcode == 1

Nur Antworten:

arp.opcode == 2

Bestimmte IPv4-Adresse:

arp.src.proto_ipv4 == 192.0.2.1 || arp.dst.proto_ipv4 == 192.0.2.1

Capture-Filter

arp

TShark-Liveanzeige

[TEST][PRIV][SENS] tshark \
  -i INTERFACE \
  -f "arp"

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "arp" \
  -a duration:30 \
  -w arp-diagnose.pcapng

ARP-Felder anzeigen

[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:

[RO] tshark -G fields |
    grep -E $'\tarp\.'

Typisches Muster:

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.

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

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.

Beim Proxy ARP antwortet ein Gerät auf eine ARP-Anfrage für eine andere IPv4-Adresse mit seiner eigenen MAC-Adresse.

Vereinfacht:

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.

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:

NDP verwendet Multicast statt des aus IPv4 bekannten Broadcasts.

Vereinfachter Ablauf:

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

ICMPv6 darf nicht pauschal blockiert werden. Viele ICMPv6-Nachrichten sind für die grundlegende IPv6-Funktion erforderlich.

[RO] Get-NetNeighbor -AddressFamily IPv6

Übersicht:

[RO] Get-NetNeighbor -AddressFamily IPv6 |
    Sort-Object InterfaceIndex, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 LinkLayerAddress,
                 State

Bestimmte Link-Local-Adresse:

[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

[RO] netsh interface ipv6 show neighbors

Alle IPv6-Nachbarn

[RO] ip -6 neighbour show

Bestimmte Schnittstelle

[RO] ip -6 neighbour show dev eth0

Bestimmte Adresse

[RO] ip -6 neighbour show 2001:db8:20::20

Änderungen beobachten

[RO] ip monitor neigh

Router und Standardroute

[RO] ip -6 route show default

IPv6-Adressen und deren Zustand

[RO] ip -6 address show dev eth0

Auf folgende Zustände achten:

tentative
dadfailed
deprecated

dadfailed weist darauf hin, dass Duplicate Address Detection für diese Adresse fehlgeschlagen ist.

IPv6-Nachbartabelle

[RO] ndp -an

Bestimmten Nachbarn anzeigen

[RO] ndp -n fe80::1%en0

Die Schnittstellenangabe %en0 ist bei Link-Local-Adressen häufig erforderlich.

IPv6-Routingtabelle

[RO] netstat -rn -f inet6

IPv6-Konfiguration einer Schnittstelle

[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.

Alle Neighbor-Discovery-Nachrichten

icmpv6.type >= 133 && icmpv6.type <= 137

Router Solicitation

icmpv6.type == 133

Router Advertisement

icmpv6.type == 134

Neighbor Solicitation

icmpv6.type == 135

Neighbor Advertisement

icmpv6.type == 136

Redirect

icmpv6.type == 137

Bestimmte IPv6-Adresse

ipv6.addr == 2001:db8:20::20

Capture-Filter für relevante ICMPv6-Nachrichten

icmp6

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "icmp6" \
  -a duration:30 \
  -w ipv6-nd.pcapng

TShark-Auswertung

[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

Bevor eine neue IPv6-Adresse regulär verwendet wird, prüft der Host normalerweise, ob sie bereits auf dem lokalen Link verwendet wird.

Vereinfacht:

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

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.

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

[RO] Get-NetRoute -AddressFamily IPv6

Linux

[RO] ip -6 route

macOS

[RO] netstat -rn -f inet6

Ein vorhandener DHCPv6-Server ersetzt nicht automatisch die Router Advertisements für die Standardrouterinformation.

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

[RO][FILE][SENS] Get-NetNeighbor |
    Export-Csv 'C:\Temp\nachbartabelle-vorher.csv' `
    -NoTypeInformation `
    -Encoding UTF8

Linux

[RO][FILE][SENS] ip neighbour show \
    > /tmp/nachbartabelle-vorher.txt

macOS

[RO][FILE][SENS] arp -an \
    > /tmp/arp-vorher.txt

[RO][FILE][SENS] ndp -an \
    > /tmp/ndp-vorher.txt

Die Speicherorte müssen den betrieblichen Datenschutz- und Sicherheitsvorgaben entsprechen.

Windows – IPv4-Nachbartabelle leeren

[PRIV][CHANGE][DISRUPT] netsh interface ip delete arpcache

Linux – dynamische IPv4-Nachbarn einer Schnittstelle leeren

[PRIV][CHANGE][DISRUPT] sudo ip -4 neighbour flush dev eth0

Linux – IPv6-Nachbarn einer Schnittstelle leeren

[PRIV][CHANGE][DISRUPT] sudo ip -6 neighbour flush dev eth0

macOS – einzelnen ARP-Eintrag entfernen

[PRIV][CHANGE][DISRUPT] sudo arp -d 192.0.2.1

macOS – einzelnen IPv6-Nachbareintrag entfernen

[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.

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

[RO] Get-NetNeighbor |
    Where-Object State -eq 'Permanent'

Linux

[RO] ip neighbour show nud permanent

macOS

[RO] arp -an

Statische Einträge dürfen nicht gelöscht werden, bevor Eigentümer, Zweck, Konfigurationsquelle und Rückweg geklärt sind.

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.

Merksatz

Route bestimmen → direkten Nachbarn bestimmen
→ Tabelle prüfen → Anfrage verfolgen → Antwort verfolgen

Die Platzhalter ZIEL und INTERFACE müssen durch vorher eindeutig bestimmte Werte ersetzt werden.

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

Microsoft

• Get-NetNeighbor
• Find-NetRoute
• netsh interface
• IPv6 Neighbor Discovery

Linux

• ip-neighbour – Linux Manual Page
• ip-monitor – Linux Manual Page
• ip-route – Linux Manual Page
• Lokale Befehlsreferenz: man arping

Apple

• Lokale Befehlsreferenzen: man arp, man ndp, man route, man netstat und man ifconfig

Wireshark

• ARP Display Filter Reference
• ICMPv6 Display Filter Reference
• dumpcap Manual Page
• tshark Manual Page

Standards

• RFC 826 – Address Resolution Protocol
• RFC 5227 – IPv4 Address Conflict Detection
• RFC 4861 – Neighbor Discovery for IPv6
• RFC 4862 – IPv6 Stateless Address Autoconfiguration
• RFC 6980 – Security Implications of IPv6 Fragmentation with NDP

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.

Ein VLAN bildet eine eigene Layer-2-Broadcast-Domain.

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

CLIENT-023 in VLAN 20
192.0.2.23/24

SERVER-01 in VLAN 40
198.51.100.20/24

Die Kommunikation benötigt:

VLAN 20
  → Gateway für VLAN 20
    → Layer-3-Routing und mögliche Firewallregeln
      → Gateway beziehungsweise Interface für VLAN 40
        → VLAN 40

Access-Port

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

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.

Ein 802.1Q-Tag enthält unter anderem:

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

Ohne VLAN-Tag:

Ziel-MAC
Quell-MAC
EtherType
Nutzdaten
FCS

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.

• 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.

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.

Auf der Switchseite sollten mindestens folgende Eigenschaften geprüft werden:

Erwartetes Muster

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.

Prüfpunkte auf beiden Seiten

Typischer Fehler

Switch A erlaubt:
VLAN 10, 20, 40

Switch B erlaubt:
VLAN 10, 40

Auswirkung:

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.

Auf manchen Trunks wird ein definiertes VLAN ungetaggt übertragen. Die genaue Bezeichnung und das Verhalten sind hersteller- und konfigurationsabhängig.

Fehlkonfiguration

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.

PVID steht für Port VLAN Identifier. Sie bestimmt bei vielen Switchplattformen, welchem VLAN ein ungetaggt eingehender Frame zugeordnet wird.

Vereinfacht:

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.

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

[RO] Get-NetAdapter |
    Format-Table Name,
                 InterfaceDescription,
                 Status,
                 LinkSpeed,
                 MacAddress

[RO] Get-NetAdapterAdvancedProperty -Name 'Ethernet'

Nach VLAN-bezogenen Eigenschaften suchen:

[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:

[RO][PRIV] Get-VMNetworkAdapterVlan -ManagementOS

VLAN-Konfiguration virtueller Maschinen:

[RO][PRIV] Get-VM |
    Get-VMNetworkAdapter |
    Get-VMNetworkAdapterVlan

Die Hyper-V-Cmdlets sind nur verfügbar, wenn die entsprechenden Hyper-V-Komponenten installiert sind.

Detaillierte Linkinformationen

[RO] ip -d link show

Bestimmte Schnittstelle

[RO] ip -d link show dev eth0.20

Beispiel einer VLAN-Schnittstelle:

eth0.20@eth0
    vlan protocol 802.1Q id 20

VLAN-Schnittstellen übersichtlich suchen

[RO] ip -d -o link show |
    grep -i 'vlan'

Linux-Bridge-VLANs

Falls Linux Bridging mit VLAN-Filtering verwendet wird:

[RO][PRIV] sudo bridge vlan show

Detaillierte Bridge-Links:

[RO][PRIV] sudo bridge -d link show

Forwarding-Datenbank beziehungsweise MAC-Tabelle:

[RO][PRIV] sudo bridge fdb show

NetworkManager-Verbindungen

[RO] nmcli connection show

Nur VLAN-Verbindungen:

[RO] nmcli -f NAME,TYPE,DEVICE connection show |
    grep -i vlan

Vollständiges Profil:

[RO][SENS] nmcli connection show "VLAN-VERBINDUNGSNAME"

Alle Schnittstellen

[RO] ifconfig

VLAN-Schnittstellen suchen

[RO] ifconfig -a |
    grep -E '^[[:alnum:]].*:|vlan:'

Eine VLAN-Schnittstelle kann abhängig von Konfiguration und macOS-Version beispielsweise als vlan0 erscheinen.

Netzwerkdienste

[RO] networksetup -listallnetworkservices

Hardwareports

[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.

Der Client sieht die VLAN-ID an einem gewöhnlichen Access-Port normalerweise nicht direkt. Deshalb werden mehrere Informationen kombiniert.

Beispiel

Vorgesehen:

VLAN 20
Subnetz 192.0.2.0/24
Gateway 192.0.2.1

Tatsächlich:

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.

Ein Switch lernt Quell-MAC-Adressen eingehender Frames und ordnet sie normalerweise einem Port und VLAN zu.

Zu prüfende Zuordnung

MAC-Adresse: 00:11:22:33:44:55
VLAN: 20
Port: 17

Mögliche Auffälligkeiten

Die konkreten Befehle zur MAC-Tabelle sind herstellerabhängig. Suchkriterium sollte die zuvor eindeutig ermittelte Client-MAC-Adresse sein.

Ein IP-Telefon kann zwei logische Verbindungen bereitstellen:

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.

Bei portbasierter Netzwerkzugangskontrolle kann ein Gerät abhängig von seiner Authentifizierung einem VLAN zugewiesen werden.

Vereinfachter Ablauf:

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.

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

Ist der Port für das betroffene VLAN im Zustand Forwarding?

Ein physisch aktiver Port kann durch Spanning Tree logisch blockiert sein.

Warnung

[CHANGE][DISRUPT] Spanning Tree darf nicht als schnelle Fehlerbehebung
deaktiviert werden. Dadurch können Layer-2-Schleifen und großflächige
Netzwerkausfälle entstehen.

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.

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.

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.

Wireshark-Display-Filter für VLAN-Tags

vlan

Bestimmte VLAN-ID:

vlan.id == 20

Mehrere VLAN-IDs:

vlan.id == 20 || vlan.id == 40

Nur DHCP in VLAN 20:

vlan.id == 20 && (udp.port == 67 || udp.port == 68)

Capture-Filter

vlan

Bestimmtes VLAN:

vlan 20

Bestimmtes VLAN und Host:

vlan 20 and host 192.0.2.23

Zeitlich begrenzte Aufnahme

[TEST][PRIV][FILE][SENS] dumpcap \
  -i INTERFACE \
  -f "vlan 20" \
  -a duration:30 \
  -w vlan20.pcapng

TShark-Auswertung

[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:

[RO] tshark -G fields |
    grep -E $'\tvlan\.'

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.

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.

Mögliche Modelle:

VLAN-Zuordnung am virtuellen Switch

VM sendet ungetaggt
  → virtueller Switch ordnet VLAN 40 zu
    → physischer Uplink überträgt VLAN 40 getaggt

VLAN-Zuordnung in der VM

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.

Vereinfachter Pfad:

Container oder VM
  → virtuelle Schnittstelle
    → Linux-Bridge
      → VLAN-Filterung
        → physische Schnittstelle
          → Switch-Trunk

Bridge-Übersicht

[RO][PRIV] sudo bridge link show

VLAN-Zuordnungen

[RO][PRIV] sudo bridge vlan show

MAC-Tabelle der Bridge

[RO][PRIV] sudo bridge fdb show

Detaillierte Links

[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.

Beispielpfad

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:

Methode

Die Client-MAC-Adresse wird vom Access-Port in Richtung Core verfolgt. Die Gateway-MAC-Adresse wird in Gegenrichtung geprüft.

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

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.

Ein Fehler kann mehrere Ebenen gleichzeitig betreffen. Beispielsweise kann ein falsches Access-VLAN zu einer falschen DHCP-Konfiguration führen.

Vor jeder Änderung müssen dokumentiert werden:

• Ausgangskonfiguration,
• betroffener Port,
• abhängige Geräte,
• vorgesehener Sollzustand,
• erwartete Wirkung,
• Rückweg,
• Wartungs- und Kommunikationsplan.

Merksatz

Client-MAC → Access-Port → VLAN → Uplink → Trunk
→ Spanning Tree → Gateway

Switchbefehle sind hersteller- und betriebssystemspezifisch. Für produktive Switches müssen ausschließlich die offiziellen Befehle der tatsächlich eingesetzten Plattform verwendet werden.

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:

Microsoft

• Get-NetAdapterAdvancedProperty
• Get-VMNetworkAdapterVlan
• Hyper-V Virtual Switch
• Hyper-V-Netzwerkvirtualisierung

Linux

• ip-link – Linux Manual Page
• bridge – Linux Manual Page
• Linux Bridge VLAN Filtering
• NetworkManager nm-settings

Apple

• Lokale Befehlsreferenzen: man ifconfig und man networksetup
• Netzwerkstatus auf dem Mac prüfen

Wireshark

• IEEE 802.1Q VLAN Display Filter Reference
• Wireshark Capture Filters
• dumpcap Manual Page
• tshark Manual Page

Standards

• IEEE 802.1Q – Bridges and Bridged Networks

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.

Ein Router verbindet unterschiedliche IP-Netze.

Beispiel

Clientnetz:
192.0.2.0/24

Servernetz:
198.51.100.0/24

Kommunikationsweg:

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.

Die IPv4-Standardroute lautet:

0.0.0.0/0

Die IPv6-Standardroute lautet:

::/0

Sie passen grundsätzlich auf jedes Ziel der jeweiligen Adressfamilie. Spezifischere Routen werden jedoch bevorzugt.

Beispielroutingtabelle

Für das Ziel 198.51.100.20 wird die spezifische /24-Route verwendet und nicht die Standardroute.

Wenn mehrere Routen zu einem Ziel passen, wird grundsätzlich die Route mit dem längsten passenden Präfix bevorzugt.

Beispiel

Ausgewählt wird:

198.51.100.20/32

Reihenfolge:

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.

Beispiel

198.51.100.0/24 via 192.0.2.254 dev eth0 metric 100

• 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.

IPv4-Routen

[RO] Get-NetRoute -AddressFamily IPv4 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol,
                 State

IPv6-Routen

[RO] Get-NetRoute -AddressFamily IPv6 |
    Sort-Object DestinationPrefix, RouteMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol,
                 State

Klassische Gesamtausgabe

[RO] route print

Nur IPv4:

[RO] route print -4

Nur IPv6:

[RO] route print -6

Standardrouten

[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Format-Table InterfaceAlias,
                 ifIndex,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric,
                 Protocol

IPv6:

[RO] Get-NetRoute -DestinationPrefix '::/0'

[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20

Die Ausgabe enthält typischerweise:

• passende Route,
• Ausgangsschnittstelle,
• Next Hop,
• lokale Quelladresse.

Zusätzliche Schnittstelleninformationen

[RO] Get-NetIPInterface |
    Sort-Object AddressFamily, InterfaceMetric |
    Format-Table ifIndex,
                 InterfaceAlias,
                 AddressFamily,
                 ConnectionState,
                 InterfaceMetric,
                 AutomaticMetric

Konkrete Zielprüfung

[TEST] Test-NetConnection 198.51.100.20 -InformationLevel Detailed

Mit Traceroute: