# 3.3 IP-Konfiguration und Subnetz prüfen

Nachdem die physische Verbindung und der Netzwerkadapter geprüft wurden, wird die logische IP-Konfiguration untersucht. Ein aktiver Link reicht nicht aus: Das Endgerät benötigt eine zum Netzwerk passende IPv4- oder IPv6-Adresse, eine korrekte Präfixlänge, geeignete Routen sowie gegebenenfalls ein Standardgateway und DNS-Server.

> **Grundregel:** Die angezeigte IP-Konfiguration muss mit der vorgesehenen Netzwerkdokumentation verglichen werden. Eine formal gültige Adresse kann trotzdem für den konkreten Standort oder das zugewiesene VLAN falsch sein.

---

<details>
<summary><strong>1. Welche Angaben gehören zu einer vollständigen IP-Konfiguration?</strong></summary>

**IPv4**

- IPv4-Adresse,
- Präfixlänge beziehungsweise Subnetzmaske,
- Netzwerkadresse,
- Broadcastadresse,
- Standardgateway,
- DNS-Server,
- DHCP aktiviert oder statisch,
- DHCP-Server,
- Leasebeginn und Leaseende,
- Schnittstelle,
- Schnittstellenmetrik,
- zusätzliche Routen.

**IPv6**

- globale oder organisationsinterne IPv6-Adresse,
- Link-Local-Adresse,
- Präfixlänge,
- Standardrouter,
- DNS-Server,
- Adressquelle,
- Gültigkeits- und Bevorzugungsdauer,
- temporäre Adressen,
- Schnittstellenindex beziehungsweise Scope-ID,
- zusätzliche Routen.

**Beispieldokumentation**

```text
Schnittstelle: Ethernet
MAC-Adresse: 00-11-22-33-44-55
VLAN: 20

IPv4-Adresse: 192.0.2.23
Präfixlänge: /24
Subnetzmaske: 255.255.255.0
Netzwerkadresse: 192.0.2.0
Broadcastadresse: 192.0.2.255
Standardgateway: 192.0.2.1
DNS-Server: 192.0.2.53, 192.0.2.54
Adressquelle: DHCP
```

</details>

<details>
<summary><strong>2. Welche Symptome sprechen für eine fehlerhafte IP-Konfiguration?</strong></summary>

- 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.

</details>

<details>
<summary><strong>3. Wie wird die IP-Konfiguration unter Windows angezeigt?</strong></summary>

**Kompakte PowerShell-Übersicht**

```powershell
[RO] Get-NetIPConfiguration
```

**Vollständige klassische Ausgabe**

```cmd
[RO][SENS] ipconfig /all
```

Die Ausgabe kann Hostname, MAC-Adressen, DNS-Suffixe, DHCP-Server und interne Netzwerkadressen enthalten.

**Nur aktive Adapter mit IPv4-Konfiguration**

```powershell
[RO] Get-NetIPConfiguration |
    Where-Object NetAdapter.Status -eq 'Up' |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  IPv4Address,
                  IPv4DefaultGateway,
                  DNSServer
```

**Alle IP-Adressen anzeigen**

```powershell
[RO] Get-NetIPAddress |
    Sort-Object InterfaceIndex, AddressFamily, IPAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 SuffixOrigin,
                 AddressState
```

**Nur IPv4-Adressen**

```powershell
[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState
```

**Nur IPv6-Adressen**

```powershell
[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 PrefixOrigin,
                 AddressState
```

**Standardrouten anzeigen**

```powershell
[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric
```

IPv6-Standardrouten:

```powershell
[RO] Get-NetRoute -DestinationPrefix '::/0' |
    Sort-Object RouteMetric |
    Format-Table InterfaceAlias,
                 ifIndex,
                 DestinationPrefix,
                 NextHop,
                 RouteMetric,
                 InterfaceMetric
```

</details>

<details>
<summary><strong>4. Wie wird die IP-Konfiguration unter Linux angezeigt?</strong></summary>

**Kompakte Adressübersicht**

```bash
[RO] ip -brief address
```

**Ausführliche Adressübersicht**

```bash
[RO] ip address show
```

**Bestimmte Schnittstelle**

```bash
[RO] ip address show dev eth0
```

**Nur IPv4**

```bash
[RO] ip -4 address show
```

**Nur IPv6**

```bash
[RO] ip -6 address show
```

**IPv4-Routingtabelle**

```bash
[RO] ip -4 route
```

**IPv6-Routingtabelle**

```bash
[RO] ip -6 route
```

**Route und ausgewählte Quelladresse zu einem Ziel**

```bash
[RO] ip route get 198.51.100.20
```

IPv6:

```bash
[RO] ip -6 route get 2001:db8:20::20
```

**NetworkManager-Verbindungen**

Falls NetworkManager verwendet wird:

```bash
[RO] nmcli connection show
```

Aktive Verbindungen:

```bash
[RO] nmcli connection show --active
```

Geräteinformationen:

```bash
[RO] nmcli device show
```

**systemd-networkd**

Falls systemd-networkd verwendet wird:

```bash
[RO] networkctl status
```

```bash
[RO] networkctl status eth0
```

Nicht jede Linux-Installation verwendet NetworkManager oder systemd-networkd. Zuerst muss bestimmt werden, welche Komponente die Netzwerkkonfiguration verwaltet.

</details>

<details>
<summary><strong>5. Wie wird die IP-Konfiguration unter macOS angezeigt?</strong></summary>

**Hardwareports und Gerätenamen**

```bash
[RO] networksetup -listallhardwareports
```

**Alle Schnittstellen**

```bash
[RO] ifconfig
```

**Bestimmte Schnittstelle**

```bash
[RO] ifconfig en0
```

**IPv4-Konfiguration eines Netzwerkdienstes**

```bash
[RO] networksetup -getinfo "Ethernet"
```

Der tatsächliche Dienstname muss vorher ermittelt werden:

```bash
[RO] networksetup -listallnetworkservices
```

**IPv4-Konfigurationsmethode**

```bash
[RO] networksetup -getinfo "Wi-Fi"
```

**DNS-Konfiguration**

```bash
[RO][SENS] scutil --dns
```

**IPv4-Routingtabelle**

```bash
[RO] netstat -rn -f inet
```

**IPv6-Routingtabelle**

```bash
[RO] netstat -rn -f inet6
```

**Ausgewählte Route zu einem IPv4-Ziel**

```bash
[RO] route -n get 198.51.100.20
```

**Ausgewählte Route zu einem IPv6-Ziel**

```bash
[RO] route -n get -inet6 2001:db8:20::20
```

Die Dienstbezeichnung `Ethernet` oder `Wi-Fi` darf nicht ungeprüft übernommen werden. Sie kann auf einem konkreten Mac anders benannt sein.

</details>

<details>
<summary><strong>6. Wie wird eine IPv4-Adresse einem Subnetz zugeordnet?</strong></summary>

**Beispiel**

```text
IPv4-Adresse: 192.0.2.23
Präfix:        /24
Subnetzmaske:  255.255.255.0
```

Daraus ergibt sich:

| Bestandteil | Wert |
|---|---|
| Netzwerkadresse | `192.0.2.0` |
| erster typischer Host | `192.0.2.1` |
| letzter typischer Host | `192.0.2.254` |
| Broadcastadresse | `192.0.2.255` |
| Gesamtzahl Adressen | 256 |
| klassisch nutzbare Hostadressen | 254 |

**Vergleich zweier Ziele**

```text
Client: 192.0.2.23/24
Ziel A: 192.0.2.80
Ziel B: 198.51.100.20
```

- Ziel A liegt im selben `/24`-Subnetz.
- Ziel B liegt außerhalb dieses Subnetzes.
- Ziel A wird normalerweise direkt über Layer 2 angesprochen.
- Ziel B benötigt normalerweise eine passende Route beziehungsweise ein Gateway.

**Wichtig**

Die erste und letzte Adresse eines Subnetzes werden bei klassischer IPv4-Subnetznutzung als Netzwerk- und Broadcastadresse verwendet. Sonderfälle wie `/31` für Punkt-zu-Punkt-Verbindungen und `/32` für einzelne Hostrouten müssen gesondert betrachtet werden.

</details>

<details>
<summary><strong>7. Wie werden Präfixlänge und Subnetzmaske umgerechnet?</strong></summary>

| Präfix | Subnetzmaske | Adressen insgesamt | klassisch nutzbare Hosts |
|---:|---|---:|---:|
| `/16` | `255.255.0.0` | 65.536 | 65.534 |
| `/17` | `255.255.128.0` | 32.768 | 32.766 |
| `/18` | `255.255.192.0` | 16.384 | 16.382 |
| `/19` | `255.255.224.0` | 8.192 | 8.190 |
| `/20` | `255.255.240.0` | 4.096 | 4.094 |
| `/21` | `255.255.248.0` | 2.048 | 2.046 |
| `/22` | `255.255.252.0` | 1.024 | 1.022 |
| `/23` | `255.255.254.0` | 512 | 510 |
| `/24` | `255.255.255.0` | 256 | 254 |
| `/25` | `255.255.255.128` | 128 | 126 |
| `/26` | `255.255.255.192` | 64 | 62 |
| `/27` | `255.255.255.224` | 32 | 30 |
| `/28` | `255.255.255.240` | 16 | 14 |
| `/29` | `255.255.255.248` | 8 | 6 |
| `/30` | `255.255.255.252` | 4 | 2 |
| `/31` | `255.255.255.254` | 2 | Sonderfall für Punkt-zu-Punkt |
| `/32` | `255.255.255.255` | 1 | einzelne Hostadresse |

**Berechnung der Gesamtzahl**

```text
2 hoch (32 − Präfixlänge)
```

Beispiel `/27`:

```text
2 hoch (32 − 27)
= 2 hoch 5
= 32 Adressen
```

Für gewöhnliche IPv4-Subnetze werden Netzwerk- und Broadcastadresse abgezogen:

```text
32 − 2 = 30 klassische Hostadressen
```

</details>

<details>
<summary><strong>8. Wie wird eine falsche Subnetzmaske erkannt?</strong></summary>

**Vorgesehene Konfiguration**

```text
Client: 192.0.2.130/25
Gateway: 192.0.2.129
```

Das vorgesehene Subnetz lautet:

```text
192.0.2.128/25
```

Adressbereich:

```text
192.0.2.128 bis 192.0.2.255
```

**Fehlerhafte Konfiguration**

```text
Client: 192.0.2.130/24
```

Der Client hält nun den gesamten Bereich `192.0.2.0/24` für lokal. Ein Ziel wie `192.0.2.50` wird deshalb direkt per ARP gesucht, obwohl es nach der vorgesehenen Netzplanung in einem anderen Subnetz liegen kann.

**Mögliche Symptome**

- einzelne Ziele sind nicht erreichbar,
- Gateway funktioniert, andere Subnetze jedoch nicht erwartungsgemäß,
- ARP-Anfragen erscheinen für eigentlich entfernte Ziele,
- Kommunikation funktioniert nur in eine Richtung,
- ein Client verhält sich anders als Vergleichsclients,
- Routing auf dem Client wirkt korrekt, die lokale Subnetzentscheidung ist aber falsch.

Die Präfixlänge muss mit DHCP-Konfiguration, VLAN-Plan und Referenzsystemen verglichen werden.

</details>

<details>
<summary><strong>9. Was bedeutet eine IPv4-Adresse aus 169.254.0.0/16?</strong></summary>

Windows und andere Betriebssysteme können eine IPv4-Link-Local-Adresse aus folgendem Bereich verwenden:

```text
169.254.0.0/16
```

Unter Windows wird dies häufig als APIPA bezeichnet.

Beispiel:

```text
169.254.73.22/16
```

Das ist ein Hinweis darauf, dass keine reguläre IPv4-Konfiguration vorliegt beziehungsweise keine gewünschte DHCP-Konfiguration bezogen werden konnte. Die Adresse ermöglicht nur eingeschränkte lokale Kommunikation mit kompatibel konfigurierten Geräten im selben Link-Local-Bereich.

**Mögliche Ursachen**

- DHCP-Server nicht erreichbar,
- falsches VLAN,
- Switchport nicht korrekt konfiguriert,
- DHCP-Relay fehlt oder funktioniert nicht,
- DHCP-Bereich erschöpft,
- DHCP-Verkehr wird gefiltert,
- Netzwerkkabel wurde erst nach dem Start verbunden,
- DHCP-Clientdienst arbeitet nicht,
- Adapter oder Treiber ist fehlerhaft.

**Windows-Prüfung**

```powershell
[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Where-Object IPAddress -Like '169.254.*'
```

**Linux-Prüfung**

```bash
[RO] ip -4 address show |
    grep '169\.254\.'
```

**macOS-Prüfung**

```bash
[RO] ifconfig |
    grep '169\.254\.'
```

Eine Link-Local-Adresse sollte nicht durch eine willkürlich gewählte statische Adresse ersetzt werden. Zuerst muss die vorgesehene Adressvergabe geklärt werden.

</details>

<details>
<summary><strong>10. Welche besonderen IPv4-Adressbereiche müssen erkannt werden?</strong></summary>

| Bereich | Zweck |
|---|---|
| `0.0.0.0` | nicht spezifizierte IPv4-Adresse |
| `0.0.0.0/0` | Standardroute beziehungsweise alle IPv4-Ziele |
| `127.0.0.0/8` | Loopback |
| `169.254.0.0/16` | IPv4 Link-Local |
| `10.0.0.0/8` | privater IPv4-Adressraum |
| `172.16.0.0/12` | privater IPv4-Adressraum |
| `192.168.0.0/16` | privater IPv4-Adressraum |
| `100.64.0.0/10` | Shared Address Space, häufig für Carrier-Grade NAT |
| `224.0.0.0/4` | Multicast |
| `255.255.255.255` | Limited Broadcast |

Die in diesem Buch verwendeten Bereiche `192.0.2.0/24`, `198.51.100.0/24` und `203.0.113.0/24` sind für Dokumentationsbeispiele vorgesehen und sollten nicht als produktive Adressplanung übernommen werden.

</details>

<details>
<summary><strong>11. Wie werden Standardgateway und lokale Erreichbarkeit geprüft?</strong></summary>

Zuerst muss das konfigurierte Gateway ausgelesen werden. Es darf nicht angenommen werden, dass es immer auf `.1` endet.

**Windows**

```powershell
[RO] Get-NetIPConfiguration |
    Select-Object InterfaceAlias,
                  IPv4Address,
                  IPv4DefaultGateway
```

Gateway testen:

```powershell
[TEST] Test-Connection 192.0.2.1 -Count 4
```

**Linux**

```bash
[RO] ip route show default
```

Gateway testen:

```bash
[TEST] ping -c 4 192.0.2.1
```

**macOS**

```bash
[RO] route -n get default
```

Gateway testen:

```bash
[TEST] ping -c 4 192.0.2.1
```

**Interpretation**

| Ergebnis | Aussage |
|---|---|
| Gateway antwortet | ICMP-Kommunikation zum Gateway funktioniert |
| Gateway antwortet nicht | keine ICMP-Antwort; Ursache noch offen |
| Nachbartabelle enthält Gateway | Layer-2-Zuordnung wurde ermittelt |
| keine Nachbarzuordnung | VLAN-, ARP-, NDP- oder Linkproblem möglich |
| andere Clients erreichen Gateway | clientbezogene Ursache wahrscheinlicher |
| Gateway blockiert ICMP | Ping ist als Nachweis ungeeignet |

Ein fehlgeschlagener Ping beweist nicht, dass das Gateway vollständig unerreichbar ist. Manche Gateways beantworten ICMP nicht oder nur eingeschränkt.

</details>

<details>
<summary><strong>12. Wie wird erkannt, welche Quelladresse für ein Ziel verwendet wird?</strong></summary>

Bei mehreren Adressen und Schnittstellen ist nicht automatisch die erwartete Quelladresse aktiv.

**Windows**

```powershell
[RO] Find-NetRoute -RemoteIPAddress 198.51.100.20
```

Die Ausgabe zeigt unter anderem:

- verwendete Schnittstelle,
- Next Hop,
- ausgewählte lokale IP-Adresse,
- passende Route.

**Linux**

```bash
[RO] ip route get 198.51.100.20
```

Beispiel:

```text
198.51.100.20 via 192.0.2.1 dev eth0 src 192.0.2.23
```

**macOS**

```bash
[RO] route -n get 198.51.100.20
```

Zu kontrollieren sind:

| Feld | Prüffrage |
|---|---|
| Interface | Wird der erwartete Adapter verwendet? |
| Source | Wird die richtige Quelladresse gewählt? |
| Gateway | Wird der erwartete Router verwendet? |
| Route | Ist das Ziel als lokal, spezifisch oder über Default geroutet? |
| Metrik | Gibt es eine bevorzugte konkurrierende Route? |

Eine unerwartete Quelladresse kann zu Firewall-, Rückweg-, NAT- oder Berechtigungsproblemen führen.

</details>

<details>
<summary><strong>13. Wie werden mehrere Standardgateways bewertet?</strong></summary>

Mehrere Standardrouten können beabsichtigt sein, beispielsweise bei:

- mehreren Internetanbindungen,
- VPN,
- Redundanz,
- Policy-Based Routing,
- getrennten Netzwerkdiensten,
- virtuellen Umgebungen.

Sie können aber auch zu unerwarteten Wegen führen.

**Windows**

```powershell
[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0' |
    Sort-Object RouteMetric, InterfaceMetric
```

**Linux**

```bash
[RO] ip route show default
```

```bash
[RO] ip rule show
```

**macOS**

```bash
[RO] netstat -rn -f inet |
    grep '^default'
```

**Zu prüfen**

- welche Standardroute bevorzugt wird,
- welche Schnittstelle zu dieser Route gehört,
- ob ein VPN eine neue Route angelegt hat,
- ob der Rückweg zur verwendeten Quelladresse passt,
- ob die Metrik beabsichtigt ist,
- ob eine spezifischere Route die Standardroute übersteuert.

```text
Längstes passendes Präfix hat grundsätzlich Vorrang vor einer weniger
spezifischen Route. Die Metrik entscheidet erst zwischen geeigneten
konkurrierenden Routen nach den Regeln des jeweiligen Betriebssystems.
```

</details>

<details>
<summary><strong>14. Wie werden IPv6-Adressen unterschieden?</strong></summary>

| IPv6-Typ | Typischer Bereich beziehungsweise Merkmal | Zweck |
|---|---|---|
| Unspecified | `::` | keine bestimmte Adresse |
| Loopback | `::1` | lokaler Host |
| Link-Local | `fe80::/10` | Kommunikation auf dem lokalen Link |
| Unique Local | `fc00::/7` | interne IPv6-Adressierung |
| Global Unicast | typischerweise aus `2000::/3` | global routbare Kommunikation |
| Multicast | `ff00::/8` | Gruppenkommunikation |

**Link-Local-Adresse**

Beispiel:

```text
fe80::1234:5678:9abc:def0%12
```

Die Scope-ID `%12` beziehungsweise ein Interfacebezug ist erforderlich, weil derselbe Link-Local-Bereich auf mehreren Schnittstellen existieren kann.

**Windows**

```powershell
[RO] Get-NetIPAddress -AddressFamily IPv6 |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 IPAddress,
                 PrefixLength,
                 AddressState,
                 PrefixOrigin,
                 SuffixOrigin
```

**Linux**

```bash
[RO] ip -6 address show
```

**macOS**

```bash
[RO] ifconfig |
    grep -E '^[a-z0-9]+:|inet6'
```

Eine vorhandene Link-Local-Adresse beweist nicht, dass globales oder standortübergreifendes IPv6-Routing funktioniert.

</details>

<details>
<summary><strong>15. Was bedeuten bevorzugte, veraltete und vorläufige Adresszustände?</strong></summary>

Eine IP-Adresse kann vorhanden sein, aber noch nicht vollständig verwendbar sein.

**Windows-Feld `AddressState`**

| Zustand | Bedeutung |
|---|---|
| `Tentative` | Prüfung auf Adresskonflikt noch nicht abgeschlossen |
| `Duplicate` | doppelte Adresse erkannt |
| `Deprecated` | Adresse soll nicht mehr für neue Verbindungen bevorzugt werden |
| `Preferred` | Adresse kann normal verwendet werden |
| `Invalid` | Adresse ist nicht gültig |

**Linux-Ausgabe kann unter anderem zeigen**

| Kennzeichnung | Bedeutung |
|---|---|
| `tentative` | Duplicate Address Detection läuft |
| `dadfailed` | Duplicate Address Detection ist fehlgeschlagen |
| `deprecated` | Adresse wird für neue Verbindungen nicht bevorzugt |
| `temporary` | temporäre IPv6-Adresse |
| `dynamic` | dynamisch zugewiesen |

**Prüfung unter Linux**

```bash
[RO] ip address show
```

Eine Adresse im Zustand `Duplicate` oder `dadfailed` darf nicht als normal funktionsfähig betrachtet werden.

</details>

<details>
<summary><strong>16. Wie wird ein IP-Adresskonflikt erkannt?</strong></summary>

Mögliche Symptome:

- Warnmeldung über doppelte IP-Adresse,
- Verbindung funktioniert wechselweise,
- ARP-Eintrag ändert seine MAC-Adresse,
- ein anderes Gerät ist unter der eigenen Adresse erreichbar,
- Verbindungen brechen sporadisch ab,
- Switch lernt dieselbe IP-Zuordnung über wechselnde MAC-Adressen,
- Windows meldet `Duplicate`,
- IPv6 Duplicate Address Detection schlägt fehl.

**Windows**

```powershell
[RO] Get-NetIPAddress |
    Where-Object AddressState -ne 'Preferred' |
    Format-Table InterfaceAlias,
                 IPAddress,
                 AddressFamily,
                 AddressState
```

Systemereignisse untersuchen:

```powershell
[RO] Get-WinEvent -LogName System -MaxEvents 1000 |
    Where-Object {
        $_.Message -match 'duplicate|conflict|Adressenkonflikt'
    } |
    Select-Object TimeCreated,
                  Id,
                  ProviderName,
                  Message
```

**Linux**

```bash
[RO] ip address show |
    grep -E 'tentative|dadfailed|deprecated'
```

Kernel- und Netzwerkprotokolle:

```bash
[RO][PRIV] sudo journalctl -b |
    grep -Ei 'duplicate|conflict|dadfailed'
```

**macOS**

```bash
[RO] log show --last 1h --style compact \
    --predicate 'eventMessage CONTAINS[c] "duplicate" OR eventMessage CONTAINS[c] "conflict"'
```

**Wichtig**

Das absichtliche Senden von ARP-Probes mit zusätzlichen Werkzeugen ist ein aktiver Test und kann Sicherheitsüberwachung auslösen. Solche Werkzeuge dürfen nur im autorisierten Netz eingesetzt werden.

Bei einem bestätigten Konflikt müssen DHCP-Leases, statische Zuweisungen, Reservierungen, Dokumentation und die MAC-Adressen beider Geräte geprüft werden.

</details>

<details>
<summary><strong>17. Wie werden DNS-Server innerhalb der IP-Konfiguration geprüft?</strong></summary>

An dieser Stelle wird nur geprüft, **welche DNS-Server konfiguriert sind**. Die eigentliche DNS-Fehleranalyse erfolgt auf Seite 3.8.

**Windows**

```powershell
[RO] Get-DnsClientServerAddress |
    Format-Table InterfaceAlias,
                 InterfaceIndex,
                 AddressFamily,
                 ServerAddresses
```

**Linux mit systemd-resolved**

```bash
[RO] resolvectl status
```

Klassische Resolverdatei:

```bash
[RO] cat /etc/resolv.conf
```

Die Datei `/etc/resolv.conf` kann automatisch generiert oder ein symbolischer Link sein:

```bash
[RO] ls -l /etc/resolv.conf
```

**macOS**

```bash
[RO][SENS] scutil --dns
```

Dienstbezogene DNS-Server:

```bash
[RO] networksetup -getdnsservers "Wi-Fi"
```

**Zu prüfen**

- gehören die Server zur vorgesehenen Umgebung?
- sind interne und externe Resolver korrekt getrennt?
- hat ein VPN andere DNS-Server eingetragen?
- existieren schnittstellen- oder domänenspezifische Resolver?
- wird eine lokale Filterlösung verwendet?
- ist die Reihenfolge beabsichtigt?

Ein Eintrag in der Konfiguration beweist noch nicht, dass der DNS-Server erreichbar ist oder korrekte Antworten liefert.

</details>

<details>
<summary><strong>18. Wie wird DHCP von statischer Adressierung unterschieden?</strong></summary>

**Windows**

```powershell
[RO] Get-NetIPInterface -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  InterfaceIndex,
                  Dhcp,
                  ConnectionState
```

Adressursprung:

```powershell
[RO] Get-NetIPAddress -AddressFamily IPv4 |
    Select-Object InterfaceAlias,
                  IPAddress,
                  PrefixLength,
                  PrefixOrigin,
                  SuffixOrigin
```

Vollständige Leaseinformationen:

```cmd
[RO][SENS] ipconfig /all
```

**Linux mit NetworkManager**

```bash
[RO] nmcli device show
```

Verbindungsprofil:

```bash
[RO][SENS] nmcli connection show
```

Die genaue Verbindung kann anschließend gezielt abgefragt werden:

```bash
[RO][SENS] nmcli connection show "VERBINDUNGSNAME"
```

**macOS**

```bash
[RO] networksetup -getinfo "Ethernet"
```

**Mögliche Zustände**

| Zustand | Bewertung |
|---|---|
| DHCP vorgesehen und DHCP aktiv | grundsätzlich passend |
| DHCP vorgesehen, aber statische Adresse | Fehlkonfiguration möglich |
| statische Adresse vorgesehen, aber DHCP aktiv | falsche Adresse möglich |
| DHCP-Adresse aus falschem Subnetz | falsches VLAN oder falscher DHCP-Server möglich |
| DHCP-Lease abgelaufen | Erneuerung und DHCP-Erreichbarkeit prüfen |
| Link-Local-Adresse | reguläre DHCP-Konfiguration vermutlich nicht erhalten |

Die detaillierte DHCP-Analyse folgt auf Seite 3.4.

</details>

<details>
<summary><strong>19. Welche lokalen Tests sind nach der Konfigurationsprüfung sinnvoll?</strong></summary>

Die Adressen müssen durch die tatsächlichen Werte des untersuchten Systems ersetzt werden.

| Reihenfolge | Test | Aussage |
|---:|---|---|
| 1 | Loopback testen | lokaler TCP/IP-Stack reagiert |
| 2 | eigene Adresse testen | eigene konfigurierte Adresse reagiert lokal |
| 3 | Gateway testen | Kommunikation bis zum lokalen Router |
| 4 | Ziel im selben Subnetz testen | lokale Layer-2-Kommunikation |
| 5 | entferntes Ziel per IP testen | Routing grundsätzlich möglich |
| 6 | Ziel per Name testen | Namensauflösung zusätzlich beteiligt |

**Windows**

```powershell
[TEST] Test-Connection 127.0.0.1 -Count 4
```

```powershell
[TEST] Test-Connection 192.0.2.23 -Count 4
```

```powershell
[TEST] Test-Connection 192.0.2.1 -Count 4
```

**Linux und macOS**

```bash
[TEST] ping -c 4 127.0.0.1
```

```bash
[TEST] ping -c 4 192.0.2.23
```

```bash
[TEST] ping -c 4 192.0.2.1
```

**IPv6-Loopback**

Windows:

```powershell
[TEST] Test-Connection ::1 -Count 4
```

Linux und macOS:

```bash
[TEST] ping -c 4 ::1
```

Ein erfolgreicher Test zur eigenen IP-Adresse durchläuft nicht zwangsläufig den vollständigen physischen Netzwerkweg.

</details>

<details>
<summary><strong>20. Warum sollten IP-Einstellungen nicht vorschnell verändert werden?</strong></summary>

Mögliche Risiken:

- Verlust des Remotezugriffs,
- doppelter IP-Adresskonflikt,
- falsches VLAN wird verdeckt,
- DHCP-Fehler bleibt unentdeckt,
- bestehende Verbindungen brechen ab,
- falsche DNS- oder Gatewaywerte werden eingetragen,
- ursprünglicher Diagnosezustand geht verloren,
- statische Serverkonfiguration wird überschrieben.

**Vor jeder Änderung sichern**

**Windows**

```powershell
[RO][FILE][SENS] Get-NetIPConfiguration |
    Format-List * |
    Out-File 'C:\Temp\NetIPConfiguration-vorher.txt'
```

```powershell
[RO][FILE][SENS] Get-NetIPAddress |
    Format-List * |
    Out-File 'C:\Temp\NetIPAddress-vorher.txt'
```

```powershell
[RO][FILE][SENS] Get-NetRoute |
    Format-Table -AutoSize |
    Out-File 'C:\Temp\NetRoute-vorher.txt' -Width 300
```

**Linux**

```bash
[RO][FILE][SENS] ip address show > /tmp/ip-address-vorher.txt
```

```bash
[RO][FILE][SENS] ip route show table all > /tmp/ip-route-vorher.txt
```

**macOS**

```bash
[RO][FILE][SENS] ifconfig > /tmp/ifconfig-vorher.txt
```

```bash
[RO][FILE][SENS] netstat -rn > /tmp/netstat-route-vorher.txt
```

Die verwendeten Speicherorte müssen zur betrieblichen Umgebung und deren Datenschutzvorgaben passen.

</details>

<details>
<summary><strong>21. Welche eingreifenden Befehle existieren und warum sind sie riskant?</strong></summary>

**Windows – DHCP-Lease freigeben**

```cmd
[PRIV][CHANGE][DISRUPT] ipconfig /release
```

Lease erneut anfordern:

```cmd
[PRIV][CHANGE][DISRUPT] ipconfig /renew
```

**Linux mit NetworkManager – Verbindung neu aktivieren**

```bash
[PRIV][CHANGE][DISRUPT] sudo nmcli connection down "VERBINDUNGSNAME"
```

```bash
[PRIV][CHANGE][DISRUPT] sudo nmcli connection up "VERBINDUNGSNAME"
```

**macOS – DHCP-Lease erneuern**

```bash
[PRIV][CHANGE][DISRUPT] sudo ipconfig set en0 DHCP
```

Der macOS-Befehl setzt die betreffende Schnittstelle auf DHCP und ist deshalb nicht für ein System geeignet, das statisch konfiguriert sein soll.

> Diese Befehle dürfen erst verwendet werden, nachdem die vorhandene Konfiguration, der vorgesehene Adressierungsmodus und ein Rückweg dokumentiert wurden. Bei einer Remoteverbindung kann der eigene Zugriff sofort verloren gehen.

</details>

<details>
<summary><strong>22. Wie wird eine Referenzkonfiguration verglichen?</strong></summary>

Ein funktionierendes Vergleichssystem sollte möglichst folgende Merkmale teilen:

- gleicher Standort,
- gleiches VLAN,
- gleiche Verbindungsart,
- gleiche Geräteklasse,
- gleiche Betriebssystemversion,
- gleiche Netzwerkrolle.

**Vergleichstabelle**

| Eigenschaft | Betroffener Client | Referenzclient | Bewertung |
|---|---|---|---|
| VLAN | 20 | 20 | gleich |
| IPv4-Adresse | `192.0.2.23` | `192.0.2.24` | plausibel |
| Präfix | `/24` | `/24` | gleich |
| Gateway | `192.0.2.1` | `192.0.2.1` | gleich |
| DNS 1 | `192.0.2.53` | `192.0.2.53` | gleich |
| DNS 2 | fehlt | `192.0.2.54` | Abweichung |
| DHCP | aktiv | aktiv | gleich |
| IPv6 | nur Link-Local | globale Adresse | Abweichung |
| Standardroute | Ethernet | Ethernet | gleich |
| VPN-Route | vorhanden | nicht vorhanden | relevante Abweichung |

Eine Abweichung ist zunächst ein Untersuchungshinweis. Sie ist erst dann eine belegte Ursache, wenn sie zum Fehlerbild passt und durch einen kontrollierten Test bestätigt wird.

</details>

<details>
<summary><strong>23. Welche typischen Fehlinterpretationen müssen vermieden werden?</strong></summary>

| Beobachtung | Falscher Schluss | Richtige Einordnung |
|---|---|---|
| IP-Adresse ist vorhanden | Konfiguration ist korrekt | Subnetz, Gateway und Adressquelle vergleichen |
| Adresse beginnt mit `192.168` | Adresse gehört zum richtigen Netz | privater Bereich umfasst viele unterschiedliche Netze |
| Gateway endet auf `.1` | Gateway ist automatisch korrekt | vorgesehenes Gateway dokumentiert prüfen |
| `169.254.x.x` ist vorhanden | Netzwerkkarte ist defekt | reguläre IPv4-Konfiguration fehlt vermutlich |
| Ping zur eigenen IP funktioniert | Netzwerkkabel funktioniert | Test kann lokal beantwortet werden |
| Gateway antwortet nicht | Gateway ist ausgefallen | ICMP kann blockiert sein |
| mehrere Adressen vorhanden | zwingend Fehlkonfiguration | bei IPv6 und mehreren Interfaces normal möglich |
| IPv6 ist vorhanden | IPv6-Internet funktioniert | Link-Local-Adresse reicht dafür nicht |
| DNS-Server ist eingetragen | DNS funktioniert | Erreichbarkeit und Antwort separat prüfen |
| DHCP ist aktiviert | korrekte Lease wurde empfangen | Leasewerte und DHCP-Server prüfen |
| `/24` sieht üblich aus | Präfix ist korrekt | Netzplan und Referenzsystem vergleichen |
| eine Default Route existiert | richtiger Weg wird verwendet | spezifischere Routen und Metriken prüfen |

</details>

<details>
<summary><strong>24. Wie sieht der systematische Prüfablauf aus?</strong></summary>

| Schritt | Prüfung |
|---:|---|
| 1 | tatsächlich verwendete Schnittstelle bestimmen |
| 2 | vollständige IPv4- und IPv6-Konfiguration erfassen |
| 3 | Adressquelle DHCP, statisch, SLAAC oder andere bestimmen |
| 4 | Adresse und Präfix mit dem Netzplan vergleichen |
| 5 | Netzwerk- und Broadcastadresse bei IPv4 bestimmen |
| 6 | Gateway und DNS-Server vergleichen |
| 7 | Adresszustand auf Duplicate, Tentative oder Deprecated prüfen |
| 8 | Standardrouten und spezifische Routen untersuchen |
| 9 | ausgewählte Route und Quelladresse zum Ziel prüfen |
| 10 | Loopback, eigene Adresse und Gateway kontrolliert testen |
| 11 | mit funktionierendem Referenzclient vergleichen |
| 12 | erst danach DHCP, ARP/NDP oder Routing vertieft untersuchen |
| 13 | Änderungen nur mit Sicherung und Rückweg durchführen |
| 14 | Ergebnis dokumentieren |

**Merksatz**

```text
Schnittstelle → Adresse → Präfix → Gateway → DNS
→ Route → Quelladresse → Vergleich
```

</details>

<details>
<summary><strong>25. Kompakte Befehlsübersicht für Windows, Linux und macOS</strong></summary>

| Aufgabe | Windows | Linux | macOS |
|---|---|---|---|
| vollständige Konfiguration | `[RO][SENS] ipconfig /all` | `[RO] ip address show` | `[RO] ifconfig` |
| kompakte Übersicht | `[RO] Get-NetIPConfiguration` | `[RO] ip -brief address` | `[RO] networksetup -getinfo "DIENST"` |
| IPv4-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv4` | `[RO] ip -4 address` | `[RO] ifconfig` |
| IPv6-Adressen | `[RO] Get-NetIPAddress -AddressFamily IPv6` | `[RO] ip -6 address` | `[RO] ifconfig` |
| IPv4-Routen | `[RO] Get-NetRoute -AddressFamily IPv4` | `[RO] ip -4 route` | `[RO] netstat -rn -f inet` |
| IPv6-Routen | `[RO] Get-NetRoute -AddressFamily IPv6` | `[RO] ip -6 route` | `[RO] netstat -rn -f inet6` |
| Standardroute IPv4 | `[RO] Get-NetRoute -DestinationPrefix '0.0.0.0/0'` | `[RO] ip route show default` | `[RO] route -n get default` |
| Route zu Ziel | `[RO] Find-NetRoute -RemoteIPAddress ZIEL-IP` | `[RO] ip route get ZIEL-IP` | `[RO] route -n get ZIEL-IP` |
| DNS-Server | `[RO] Get-DnsClientServerAddress` | `[RO] resolvectl status` | `[RO][SENS] scutil --dns` |
| DHCP-Status | `[RO] Get-NetIPInterface -AddressFamily IPv4` | `[RO] nmcli device show` | `[RO] networksetup -getinfo "DIENST"` |
| Loopback testen | `[TEST] Test-Connection 127.0.0.1 -Count 4` | `[TEST] ping -c 4 127.0.0.1` | `[TEST] ping -c 4 127.0.0.1` |
| Gateway testen | `[TEST] Test-Connection GATEWAY -Count 4` | `[TEST] ping -c 4 GATEWAY` | `[TEST] ping -c 4 GATEWAY` |
| Lease freigeben | `[PRIV][CHANGE][DISRUPT] ipconfig /release` | abhängig vom Netzwerkmanager | nicht direkt gleichwertig |
| Lease erneuern | `[PRIV][CHANGE][DISRUPT] ipconfig /renew` | abhängig vom Netzwerkmanager | `[PRIV][CHANGE][DISRUPT] sudo ipconfig set INTERFACE DHCP` |

Die Platzhalter `DIENST`, `INTERFACE`, `GATEWAY` und `ZIEL-IP` müssen durch zuvor eindeutig ermittelte Werte ersetzt werden.

</details>

<details>
<summary><strong>26. Dokumentationsvorlage</strong></summary>

```text
Ticketnummer:
Prüfzeitpunkt:
Zeitzone:
Betroffenes Gerät:
Betriebssystem:
Benutzer:
Standort:
VLAN:
Verbindungsart:

SCHNITTSTELLE

Schnittstellenname:
Schnittstellenindex:
MAC-Adresse:
Status:
Linkgeschwindigkeit:
MTU:

IPV4

IPv4-Adresse:
Präfixlänge:
Subnetzmaske:
Netzwerkadresse:
Broadcastadresse:
Adresszustand:
Adressquelle:
DHCP aktiviert:
DHCP-Server:
Leasebeginn:
Leaseende:
Standardgateway:
DNS-Server:
Ausgewählte Quelladresse zum Ziel:
Ausgewählte Route:
Next Hop:

IPV6

Link-Local-Adresse:
Globale beziehungsweise interne IPv6-Adresse:
Präfixlänge:
Adresszustand:
Adressquelle:
Standardrouter:
DNS-Server:
Ausgewählte Quelladresse zum Ziel:
Ausgewählte Route:
Next Hop:

LOKALE TESTS

Loopback IPv4:
Loopback IPv6:
Eigene IPv4-Adresse:
Eigene IPv6-Adresse:
IPv4-Gateway:
IPv6-Router:
Ziel im lokalen Subnetz:
Entferntes Ziel per IP:

REFERENZVERGLEICH

Referenzgerät:
Gleiches VLAN:
IPv4-Präfix:
Gateway:
DNS-Server:
Adressquelle:
Relevante Abweichungen:

AUFFÄLLIGKEITEN

-
-
-

Arbeitshypothese:
Nächster Prüfschritt:
Gesicherter Ausgangszustand:
Durchgeführte Änderung:
Rückweg:
Abschlussprüfung:
Ermittelte Ursache:
```

</details>

<details>
<summary><strong>27. Offizielle Quellen und weiterführende Dokumentation</strong></summary>

**Microsoft**

- [Get-NetIPConfiguration](https://learn.microsoft.com/powershell/module/nettcpip/get-netipconfiguration)
- [Get-NetIPAddress](https://learn.microsoft.com/powershell/module/nettcpip/get-netipaddress)
- [Get-NetIPInterface](https://learn.microsoft.com/powershell/module/nettcpip/get-netipinterface)
- [Get-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/get-netroute)
- [Find-NetRoute](https://learn.microsoft.com/powershell/module/nettcpip/find-netroute)
- [Get-DnsClientServerAddress](https://learn.microsoft.com/powershell/module/dnsclient/get-dnsclientserveraddress)
- [TCP/IP-Adressierung und Subnetting](https://learn.microsoft.com/troubleshoot/windows-client/networking/tcpip-addressing-and-subnetting)

**Linux**

- [ip-address – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-address.8.html)
- [ip-route – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-route.8.html)
- [ip-rule – Linux Manual Page](https://man7.org/linux/man-pages/man8/ip-rule.8.html)
- [NetworkManager nmcli](https://networkmanager.dev/docs/api/latest/nmcli.html)
- [systemd networkctl](https://www.freedesktop.org/software/systemd/man/latest/networkctl.html)

**Apple**

- Lokale Befehlsreferenzen: `man ifconfig`, `man route`, `man netstat`, `man scutil`, `man networksetup` und `man ipconfig`
- [Ändern der TCP/IP-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-tcp-ip-settings-mac-mh14129/mac)
- [Ändern der DNS-Einstellungen auf dem Mac](https://support.apple.com/guide/mac-help/change-dns-settings-on-mac-mh14127/mac)

**Standards**

- [RFC 1918 – Private Address Space](https://www.rfc-editor.org/rfc/rfc1918)
- [RFC 3927 – IPv4 Link-Local Addresses](https://www.rfc-editor.org/rfc/rfc3927)
- [RFC 4291 – IPv6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291)
- [RFC 6164 – IPv6 Prefix Length for Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc6164)
- [RFC 3021 – IPv4 /31 Point-to-Point Links](https://www.rfc-editor.org/rfc/rfc3021)
- [RFC 5737 – IPv4 Documentation Address Blocks](https://www.rfc-editor.org/rfc/rfc5737)

> Adressen, Präfixe, Gateways und DNS-Server müssen immer mit der tatsächlichen Netzwerkdokumentation verglichen werden. Die Beispielwerte auf dieser Seite sind keine Vorgabe für produktive Netze.

</details>