# 6.4 Host erreichbar, Dienst nicht – Ports, Firewall und Anwendungen systematisch prüfen

Ein Zielsystem kann per IP-Adresse erreichbar sein, während der benötigte Dienst trotzdem nicht funktioniert.

Typische Beispiele:

- Ping auf den Server funktioniert, die Website öffnet sich jedoch nicht.
- Der Servername wird korrekt aufgelöst, eine SSH-Verbindung scheitert aber.
- Eine Dateifreigabe ist nicht erreichbar, obwohl der Server antwortet.
- Die Anwendung meldet eine Zeitüberschreitung.
- Ein TCP-Port ist erreichbar, die Anwendung liefert dennoch einen Fehler.
- Der Dienst funktioniert lokal auf dem Server, aber nicht von anderen Geräten.
- Einige Clients erreichen den Dienst, andere nicht.
- Eine Verbindung funktioniert intern, über VPN oder Internet jedoch nicht.

Die Erreichbarkeit eines Hosts und die Erreichbarkeit eines Dienstes sind getrennte Prüfungen.

```text
Host erreichbar
      ↓
Zielport erreichbar
      ↓
TCP- oder UDP-Kommunikation funktioniert
      ↓
Dienst nimmt Anfragen an
      ↓
Anwendungsprotokoll funktioniert
      ↓
Authentifizierung und Berechtigung funktionieren
```

Ein erfolgreicher Ping bestätigt deshalb weder einen offenen Port noch einen funktionsfähigen Dienst.

---

**1. Fehlerbild exakt erfassen**

Vor der technischen Prüfung müssen die betroffene Verbindung und der erwartete Dienst eindeutig bestimmt werden.

Zu dokumentieren sind:

- Quellgerät,
- Quell-IP-Adresse,
- Zielname,
- Ziel-IP-Adresse,
- Zielport,
- Transportprotokoll TCP oder UDP,
- verwendete Anwendung,
- Zeitpunkt des Fehlers,
- genaue Fehlermeldung,
- betroffene Benutzer oder Standorte,
- funktionierende Vergleichsverbindungen,
- letzte bekannte Funktionsfähigkeit,
- kürzlich vorgenommene Änderungen.

Beispiel:

```text
Quelle: Client-17, 192.0.2.117
Ziel: appserver.example.test, 192.0.2.50
Dienst: HTTPS
Transport: TCP
Zielport: 443
Fehler: Verbindung nach etwa 20 Sekunden abgebrochen
Betroffen: Clients im VLAN 30
Nicht betroffen: Clients im VLAN 20
```

Die Aussage „Der Server geht nicht“ reicht nicht aus. Benötigt wird eine genaue Beschreibung der betroffenen Kommunikationsbeziehung.

---

**2. Host-Erreichbarkeit und Dienst-Erreichbarkeit unterscheiden**

Ein Ping verwendet ICMP. Anwendungsdienste verwenden dagegen meistens TCP oder UDP.

Beispiel:

```text
ping appserver.example.test
```

Ein erfolgreicher Ping kann bestätigen:

- Namensauflösung liefert eine Adresse,
- ICMP-Anfrage erreicht das Ziel,
- ICMP-Antwort gelangt zurück.

Er beweist nicht:

- dass TCP Port 443 geöffnet ist,
- dass eine Firewall den Anwendungsverkehr erlaubt,
- dass der Webserver läuft,
- dass TLS funktioniert,
- dass die Anwendung eine gültige Antwort liefert,
- dass der Benutzer zugriffsberechtigt ist.

Umgekehrt kann ein Dienst funktionieren, obwohl Ping scheitert. ICMP kann gezielt blockiert sein, während der benötigte TCP- oder UDP-Port erlaubt bleibt.

---

**3. Den tatsächlich benötigten Port bestimmen**

Vor einem Porttest muss bekannt sein, welchen Zielport und welches Transportprotokoll die Anwendung verwendet.

Beispiele:

| Dienst | Transport | typischer Port |
|---|---:|---:|
| HTTP | TCP | 80 |
| HTTPS | TCP | 443 |
| SSH | TCP | 22 |
| RDP | TCP und UDP | 3389 |
| SMB | TCP | 445 |
| DNS | UDP und TCP | 53 |
| SMTP | TCP | 25 |
| IMAP mit TLS | TCP | 993 |
| PostgreSQL | TCP | 5432 |
| MySQL | TCP | 3306 |
| LDAP | TCP und teilweise UDP | 389 |
| LDAPS | TCP | 636 |
| NTP | UDP | 123 |
| DHCP | UDP | 67 und 68 |

Diese Ports sind typische Standardwerte. Anwendungen können abweichend konfiguriert sein.

Zu prüfen sind daher:

- Herstellerdokumentation,
- Serverkonfiguration,
- Reverse-Proxy-Konfiguration,
- Container-Portzuordnung,
- Load-Balancer-Konfiguration,
- Firewallregeln,
- tatsächlich geöffnete Sockets,
- eventuell verwendete dynamische Ports.

Ein Test des falschen Ports liefert keine verwertbare Aussage über den benötigten Dienst.

---

**4. Zieladresse und Zielport gemeinsam prüfen**

Ein Port gehört immer zu einer konkreten IP-Adresse und einem Transportprotokoll.

```text
192.0.2.50:443/TCP
```

Bei mehreren IP-Adressen muss geprüft werden, welche Adresse die Anwendung tatsächlich verwendet.

Mögliche Fehler:

- DNS liefert eine alte Adresse,
- IPv6 wird gegenüber IPv4 bevorzugt,
- der Dienst lauscht nur auf einer bestimmten Schnittstelle,
- ein Load Balancer verwendet eine andere Adresse,
- NAT leitet auf ein falsches Ziel weiter,
- ein Client verwendet einen Proxy,
- die Anwendung greift auf einen anderen Hostnamen zurück.

Vor der Bewertung eines Porttests sollten deshalb Zielname und aufgelöste Adressen dokumentiert werden.

**Windows**

```powershell
Resolve-DnsName <zielname>
```

**Linux und macOS**

```bash
dig <zielname>
```

---

**5. TCP-Port vom Client aus testen**

**Windows**

```powershell
Test-NetConnection <zielname> -Port <port>
```

Kurzform:

```powershell
tnc <zielname> -Port <port>
```

Beispiel:

```powershell
Test-NetConnection appserver.example.test -Port 443
```

Wichtig ist insbesondere:

```text
TcpTestSucceeded : True
```

oder:

```text
TcpTestSucceeded : False
```

**PowerShell 7**

```powershell
Test-Connection <zielname> -TcpPort <port>
```

**Linux und macOS**

```bash
nc -vz <zielname> <port>
```

Beispiel:

```bash
nc -vz appserver.example.test 443
```

Alternativ kann bei bestimmten Diensten ein protokollspezifischer Test sinnvoller sein:

```bash
curl -v http://<zielname>:<port>/
curl -vk https://<zielname>:<port>/
```

> Ein erfolgreicher TCP-Porttest bestätigt zunächst nur, dass eine TCP-Verbindung aufgebaut werden konnte. Er beweist nicht, dass die Anwendung fachlich korrekt arbeitet.

---

**6. TCP-Ergebnisse richtig einordnen**

| Beobachtung | technische Bedeutung | möglicher Untersuchungsbereich |
|---|---|---|
| Verbindung erfolgreich | TCP-Verbindungsaufbau abgeschlossen | Anwendung, Protokoll, TLS, Authentifizierung oder Inhalt prüfen |
| sofort abgelehnt | Ziel oder Zwischenkomponente sendet aktiv eine Ablehnung | kein Listener, falscher Port, Firewall mit Reject oder Dienst beendet |
| Zeitüberschreitung | keine verwertbare Antwort innerhalb der Wartezeit | Firewall-Drop, Routing, Rückweg, NAT, Zielsystem oder Paketverlust |
| Verbindung wird sofort zurückgesetzt | TCP-RST beendet die Verbindung | Dienst, Proxy, Firewall, Protokollfehler oder Anwendung |
| Verbindung beginnt und bleibt hängen | TCP besteht, Anwendung antwortet nicht vollständig | Dienst, Backend, Überlastung, TLS, MTU oder Abhängigkeit |
| Verbindung funktioniert nur per IP | Namensauflösung, Zertifikat, virtueller Host oder Proxy |
| Verbindung funktioniert nur per Name | Anwendung benötigt Hostnamen, SNI oder virtuellen Host |
| Port ist offen, Anwendung meldet Fehler | kein reiner Portfehler | Protokoll, Anwendung, Backend, Authentifizierung oder Berechtigung |

Eine Zeitüberschreitung beweist nicht automatisch, dass eine Firewall die Verbindung blockiert. Auch ein fehlender Rückweg, ein falsches NAT-Ziel oder ein nicht reagierendes System kann dasselbe Verhalten verursachen.

---

**7. TCP-Verbindungsaufbau verstehen**

Der normale TCP-Verbindungsaufbau verwendet drei Schritte:

```text
Client → Server: SYN
Server → Client: SYN, ACK
Client → Server: ACK
```

Danach kann die Anwendungsübertragung beginnen.

Mögliche Abweichungen:

| Paketfolge | mögliche Einordnung |
|---|---|
| SYN, SYN/ACK, ACK | TCP-Verbindung wurde aufgebaut |
| wiederholte SYN-Pakete ohne Antwort | Paketverlust, Firewall-Drop, Routing, Ziel oder Rückweg |
| SYN, danach RST/ACK | Port geschlossen oder Verbindung aktiv abgelehnt |
| SYN, SYN/ACK, danach kein ACK | Rückweg zum Client, Client-Firewall oder asymmetrischer Pfad |
| vollständiger Handshake, danach RST | Anwendung, Proxy oder Protokoll beendet die Verbindung |
| vollständiger Handshake, keine Nutzdatenantwort | Dienst hängt, Backend wartet oder Anwendungsproblem |
| wiederholte Übertragungen | Paketverlust, Überlastung, MTU oder instabiler Datenpfad |

Diese Unterscheidung ist mit einer Paketaufzeichnung möglich.

---

**8. UDP-Dienste getrennt betrachten**

UDP besitzt keinen TCP-Handshake. Deshalb lässt sich ein UDP-Port nicht genauso zuverlässig wie ein TCP-Port mit einem einfachen Verbindungsversuch bewerten.

Beispiel:

```bash
nc -vzu <zielname> <port>
```

Ein solcher Test kann Pakete senden. Eine Erfolgsmeldung beweist jedoch nicht zwingend, dass:

- der UDP-Dienst läuft,
- das Paket den Server erreicht,
- der Dienst die Anfrage verarbeitet,
- eine Antwort zurückkommt,
- die Anwendung das richtige Protokoll gesendet hat.

Für UDP sollte möglichst ein protokollspezifisches Werkzeug verwendet werden.

Beispiele:

**DNS**

```bash
dig @<dns-server> <name>
```

**NTP**

```bash
ntpdate -q <ntp-server>
```

Je nach System können andere Werkzeuge erforderlich sein.

Mögliche UDP-Ergebnisse:

| Beobachtung | mögliche Einordnung |
|---|---|
| gültige Anwendungsantwort | Hin- und Rückweg sowie Dienst grundsätzlich funktionsfähig |
| ICMP Port Unreachable | am Zielport lauscht wahrscheinlich kein UDP-Dienst |
| keine Antwort | Dienst antwortet nicht, Firewall, Paketverlust, falsche Anfrage oder Protokollverhalten |
| Antwort nur bei kleinen Anfragen | Fragmentierung, MTU, EDNS oder Filter |
| lokal funktioniert, entfernt nicht | Bind-Adresse, Firewall, Routing oder Zugriffsliste |

Keine UDP-Antwort ist deshalb weniger eindeutig als eine erfolgreiche oder abgelehnte TCP-Verbindung.

---

**9. Auf dem Server prüfen, ob der Dienst lauscht**

Ein Dienst muss einen Socket auf der vorgesehenen Adresse und dem vorgesehenen Port geöffnet haben.

**Windows**

```powershell
Get-NetTCPConnection -State Listen
Get-NetTCPConnection -LocalPort <port>
Get-NetUDPEndpoint -LocalPort <port>
```

Alternativ:

```powershell
netstat -ano
netstat -ano | findstr :<port>
```

Die zugehörige Prozess-ID kann geprüft werden mit:

```powershell
Get-Process -Id <prozess-id>
```

oder:

```cmd
tasklist /FI "PID eq <prozess-id>"
```

**Linux**

```bash
ss -lntp
ss -lntp 'sport = :<port>'
ss -lnup
```

Alternativ:

```bash
sudo lsof -nP -iTCP:<port> -sTCP:LISTEN
sudo lsof -nP -iUDP:<port>
```

**macOS**

```bash
sudo lsof -nP -iTCP:<port> -sTCP:LISTEN
sudo lsof -nP -iUDP:<port>
```

Zu prüfen sind:

- ist ein Listener vorhanden?
- ist es der erwartete Prozess?
- verwendet er TCP oder UDP?
- lauscht er auf dem erwarteten Port?
- lauscht er auf der richtigen IP-Adresse?
- verwendet er IPv4, IPv6 oder beides?
- läuft möglicherweise ein anderer Prozess auf dem Port?
- wurde die Konfiguration nach einer Änderung neu geladen?

---

**10. Bind-Adresse richtig bewerten**

Ein Dienst kann auf unterschiedlichen Adressen lauschen.

Beispiele:

```text
127.0.0.1:8080
0.0.0.0:8080
192.0.2.50:8080
[::1]:8080
[::]:8080
```

Typische Bedeutung:

| Bind-Adresse | Bedeutung |
|---|---|
| `127.0.0.1` | nur lokales IPv4-Loopback |
| `0.0.0.0` | grundsätzlich alle IPv4-Schnittstellen |
| konkrete IPv4-Adresse | nur diese IPv4-Adresse |
| `::1` | nur lokales IPv6-Loopback |
| `::` | grundsätzlich IPv6 und abhängig vom System eventuell zusätzlich IPv4 |

Ein Dienst, der ausschließlich auf `127.0.0.1` lauscht, kann lokal funktionieren und von entfernten Clients trotzdem nicht erreichbar sein.

Nach Änderungen an Netzwerkschnittstellen oder IP-Adressen kann ein Dienst weiterhin an eine nicht mehr vorhandene oder falsche Adresse gebunden sein.

---

**11. Dienststatus und Protokolle prüfen**

Ein vorhandener Prozess bedeutet nicht automatisch, dass der Dienst betriebsbereit ist.

**Windows**

```powershell
Get-Service
Get-Service -Name <dienstname>
```

**Linux mit systemd**

```bash
systemctl status <dienstname>
journalctl -u <dienstname>
```

**macOS**

Je nach Installationsart können `launchctl`, anwendungseigene Werkzeuge oder Protokolldateien verwendet werden.

Zu prüfen sind:

- Dienststatus,
- Startzeitpunkt,
- wiederholte Neustarts,
- Konfigurationsfehler,
- fehlende Zertifikate,
- belegter Port,
- fehlende Berechtigungen,
- nicht erreichbare Datenbank,
- nicht erreichbarer Verzeichnisdienst,
- Speicher- oder Datenträgerprobleme,
- abgelaufene Lizenzen,
- erschöpfte Verbindungen,
- interne Warteschlangen,
- Fehler unmittelbar zum Störungszeitpunkt.

Ein Dienst kann als „running“ angezeigt werden und dennoch keine funktionsfähigen Anfragen bearbeiten.

---

**12. Dienst lokal auf dem Server testen**

Der lokale Test trennt die Anwendung vom entfernten Netzwerkpfad.

Beispiele:

```bash
curl -v http://127.0.0.1:<port>/
curl -vk https://127.0.0.1:<port>/
```

Oder:

```bash
nc -vz 127.0.0.1 <port>
nc -vz <server-ip> <port>
```

Sinnvolle Vergleichstests:

1. Verbindung über `localhost`,
2. Verbindung über Loopback-Adresse,
3. Verbindung über die Server-IP,
4. Verbindung über den vollständigen Namen,
5. Verbindung von einem Client im selben Netz,
6. Verbindung aus dem betroffenen Netz.

| Ergebnis | mögliche Einordnung |
|---|---|
| lokal und entfernt scheitern | Dienst, Listener oder lokale Konfiguration |
| Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall |
| lokal funktioniert, entfernt nicht | Firewall, Routing, ACL, NAT oder Netzwerkpfad |
| IP funktioniert, Name nicht | DNS, virtueller Host, SNI oder Zertifikat |
| Porttest funktioniert, Protokolltest nicht | Anwendung oder Protokoll |
| ein Netz funktioniert, anderes nicht | Firewallregel, Routing, Segmentierung oder Rückweg |

---

**13. Lokale Firewall des Servers prüfen**

Auch wenn der Dienst lauscht, kann die lokale Firewall eingehende Verbindungen blockieren.

Zu prüfen sind:

- richtige Richtung der Regel,
- richtiges Transportprotokoll,
- richtiger lokaler Port,
- richtige Quellnetze,
- richtiges Netzwerkprofil,
- richtige Anwendung oder Dienstzuordnung,
- IPv4 und IPv6,
- aktive Firewallzone,
- Priorität und Reihenfolge der Regeln,
- protokollierte Ablehnungen,
- zentrale Richtlinien.

**Windows**

```powershell
Get-NetFirewallProfile
Get-NetFirewallRule -Enabled True
Get-NetFirewallPortFilter
Get-NetFirewallAddressFilter
```

Eine genauere Zuordnung kann über gemeinsame Filter- und Regelobjekte erforderlich sein.

**Linux mit firewalld**

```bash
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
```

**Linux mit nftables**

```bash
sudo nft list ruleset
```

**Linux mit iptables**

```bash
sudo iptables -L -n -v
sudo ip6tables -L -n -v
```

Firewallregeln sollten nicht pauschal deaktiviert werden. Eine kontrollierte, auf Quelle, Ziel, Port und Protokoll begrenzte Prüfung ist vorzuziehen.

---

**14. Client-Firewall und Ausgangsregeln**

Nicht nur der Server kann Verbindungen blockieren. Auch auf dem Client können ausgehende Regeln, Sicherheitssoftware oder Endpoint-Richtlinien wirken.

Mögliche Ursachen:

- ausgehender Zielport gesperrt,
- Anwendung darf keine Verbindung herstellen,
- Netzwerkprofil wurde geändert,
- Sicherheitssoftware blockiert den Prozess,
- TLS-Inspection greift ein,
- lokale Proxyrichtlinie erzwingt einen anderen Pfad,
- Host-Firewall verwirft Rückpakete,
- EDR-System beendet die Verbindung.

Wenn andere Anwendungen denselben Zielport erreichen, die betroffene Anwendung aber nicht, sollte zusätzlich eine prozessbezogene Einschränkung untersucht werden.

---

**15. Netzwerk-Firewalls und ACLs**

Zwischen Client und Server können mehrere Kontrollstellen liegen:

```text
Client
  ↓
Client-Firewall
  ↓
VLAN- oder Router-ACL
  ↓
zentrale Firewall
  ↓
VPN-Gateway oder NAT
  ↓
Server-Firewall
  ↓
Dienst
```

Zu prüfen sind:

- Quell-IP-Adresse,
- Ziel-IP-Adresse,
- Zielport,
- Transportprotokoll,
- Sicherheitszone,
- Regelreihenfolge,
- Zeitplan der Regel,
- Benutzer- oder Anwendungsabhängigkeit,
- NAT vor oder nach der Regelprüfung,
- Sitzungsstatus,
- Trefferzähler,
- Protokolleinträge,
- Rückweg.

Eine Regel für TCP Port 443 erlaubt nicht automatisch UDP Port 443. Ebenso erlaubt eine Regel für IPv4 nicht zwingend IPv6-Verkehr.

---

**16. Stateful Firewall und Rückverkehr**

Stateful Firewalls verfolgen den Zustand einer Verbindung. Bei einer erlaubten ausgehenden TCP-Verbindung wird der passende Rückverkehr normalerweise über den Verbindungszustand zugeordnet.

Fehler können entstehen durch:

- asymmetrisches Routing,
- Rückpakete passieren eine andere Firewall,
- Firewallzustand ist abgelaufen,
- NAT-Zuordnung fehlt,
- Clusterknoten teilen Zustände nicht korrekt,
- Quelladresse wird unerwartet geändert,
- Verbindung bleibt länger inaktiv als der Session-Timeout,
- Rückverkehr entspricht nicht der gespeicherten Sitzung.

Typisches Symptom:

```text
Client sendet SYN.
Server antwortet mit SYN/ACK.
Client erhält die Antwort nicht.
```

In diesem Fall ist der Dienst erreichbar, aber der Rückweg oder eine zustandsabhängige Verarbeitung ist gestört.

---

**17. Routing und Rückweg prüfen**

Ein erreichbarer Host über ICMP bedeutet nicht, dass jeder Anwendungsverkehr denselben Pfad nimmt oder gleich behandelt wird.

**Windows**

```powershell
tracert <ziel>
Test-NetConnection <ziel> -TraceRoute
Get-NetRoute
```

**Linux**

```bash
traceroute <ziel>
tracepath <ziel>
ip route
ip route get <ziel>
```

**macOS**

```bash
traceroute <ziel>
netstat -rn
route -n get <ziel>
```

Zu prüfen sind:

- Route vom Client zum Server,
- Rückroute vom Server zum Client,
- Quell-IP-Auswahl,
- mehrere Standardgateways,
- Policy-Based Routing,
- VPN-Routen,
- überlappende Netze,
- asymmetrische Wege,
- segmentabhängige Firewallregeln.

Die Rückroute muss vom Server oder seinem Gateway zum tatsächlichen Quellnetz führen.

---

**18. NAT und Portweiterleitung**

Bei Verbindungen über Netzgrenzen kann NAT die Ziel- oder Quelladresse verändern.

Beispiel:

```text
öffentliche Adresse:
198.51.100.20:443

NAT-Ziel:
192.0.2.50:8443
```

Zu prüfen sind:

- richtige öffentliche Zieladresse,
- richtiger externer Port,
- richtiges internes Ziel,
- richtiger interner Port,
- TCP oder UDP,
- Quell-NAT,
- Rückroute,
- Firewallregel passend zur NAT-Verarbeitung,
- konkurrierende Portweiterleitung,
- Hairpin-NAT bei Zugriff von intern,
- Ablauf der NAT-Sitzung.

Ein lokal erreichbarer Dienst beweist nicht, dass die Portweiterleitung korrekt ist.

---

**19. Container und virtuelle Maschinen**

Bei containerisierten oder virtualisierten Diensten existieren zusätzliche Netzwerkschichten.

Mögliche Fehler:

- Container läuft, Port wurde aber nicht veröffentlicht,
- Host-Port zeigt auf den falschen Container-Port,
- Dienst lauscht im Container nur auf Loopback,
- Container-Netzwerk fehlt,
- Firewall auf dem Host blockiert,
- Reverse Proxy erreicht den Container nicht,
- falscher DNS-Name im internen Netzwerk,
- virtuelle Maschine besitzt eine andere IP-Adresse,
- Sicherheitsgruppe erlaubt den Port nicht,
- Dienst wurde auf einen anderen Host verschoben.

**Docker**

```bash
docker ps
docker port <container>
docker inspect <container>
```

Beispiel einer Portzuordnung:

```text
0.0.0.0:8443 → Container:443/TCP
```

Ein Test auf Host-Port 443 wäre in diesem Beispiel ungeeignet, wenn der Dienst ausschließlich über Host-Port 8443 veröffentlicht wurde.

---

**20. Reverse Proxy und Load Balancer**

Zwischen Client und Anwendung können Reverse Proxy oder Load Balancer liegen.

```text
Client
  ↓
Reverse Proxy oder Load Balancer
  ↓
Backend-Anwendung
```

Mögliche Fehlerbilder:

- Frontend-Port ist erreichbar, Backend jedoch nicht,
- falscher Hostname wird weitergeleitet,
- Health Check schlägt fehl,
- Backend-Port wurde geändert,
- Zertifikat passt nicht,
- virtuelle Hostkonfiguration fehlt,
- Proxy-Zeitüberschreitung ist zu kurz,
- ein einzelner Backend-Server ist fehlerhaft,
- Sitzungspersistenz führt zu einem defekten Knoten,
- Proxy liefert `502`, `503` oder `504`.

Typische HTTP-Ergebnisse:

| Ergebnis | mögliche Einordnung |
|---|---|
| `200` | Anfrage grundsätzlich erfolgreich |
| `301` oder `302` | Weiterleitung prüfen |
| `400` | Anfrage oder Hostheader ungeeignet |
| `401` | Authentifizierung erforderlich oder fehlgeschlagen |
| `403` | Zugriff durch Anwendung oder Richtlinie verweigert |
| `404` | Pfad, virtueller Host oder Routingregel |
| `502` | Proxy erhält keine gültige Backend-Antwort |
| `503` | Dienst oder Backend nicht verfügbar |
| `504` | Zeitüberschreitung zum Backend |

Ein erreichbarer Proxy-Port beweist nicht, dass das Backend funktioniert.

---

**21. TLS und Zertifikate prüfen**

Bei verschlüsselten Diensten folgt nach dem TCP-Verbindungsaufbau der TLS-Handshake.

Mögliche Fehler:

- Zertifikat abgelaufen,
- Zertifikatsname passt nicht zum Hostnamen,
- Zertifikatskette unvollständig,
- unbekannte Zertifizierungsstelle,
- Client- und Serverprotokolle nicht kompatibel,
- keine gemeinsame Cipher Suite,
- Server Name Indication fehlt oder ist falsch,
- Clientzertifikat erforderlich,
- TLS-Inspection verändert die Verbindung,
- Systemzeit ist falsch.

**curl**

```bash
curl -vk https://<zielname>:<port>/
```

**OpenSSL**

```bash
openssl s_client -connect <zielname>:<port> -servername <zielname>
```

Dabei können geprüft werden:

- ausgehandeltes TLS-Protokoll,
- präsentierte Zertifikatskette,
- Zertifikatsname,
- Gültigkeitszeitraum,
- Serverantwort,
- Abbruchstelle.

Die Option `-k` bei `curl` überspringt die Zertifikatsprüfung und darf nur zur Eingrenzung verwendet werden. Sie ist keine dauerhafte Lösung für Zertifikatsfehler.

---

**22. Hostname, SNI und virtuelle Hosts**

Mehrere Webanwendungen können dieselbe IP-Adresse und denselben Port verwenden. Der richtige Dienst wird dann anhand des Hostnamens ausgewählt.

Beispiel:

```text
portal.example.test → 192.0.2.50
wiki.example.test   → 192.0.2.50
```

Ein Test ausschließlich gegen die IP-Adresse kann deshalb:

- die falsche Website liefern,
- einen Zertifikatsfehler erzeugen,
- die Standardseite des Proxys anzeigen,
- mit einem HTTP-Fehler enden,
- den falschen virtuellen Host verwenden.

Geeigneter Test:

```bash
curl -vk https://portal.example.test/
```

Soll eine bestimmte IP-Adresse mit dem korrekten Hostnamen getestet werden:

```bash
curl -vk --resolve portal.example.test:443:192.0.2.50 https://portal.example.test/
```

Damit werden DNS, Ziel-IP, Hostheader und SNI kontrolliert voneinander getrennt.

---

**23. Anwendung und Abhängigkeiten prüfen**

Ein Dienst kann den Port öffnen, aber intern von weiteren Komponenten abhängig sein.

Beispiele:

- Datenbank,
- Verzeichnisdienst,
- DNS,
- Dateispeicher,
- Nachrichtenwarteschlange,
- API,
- Lizenzserver,
- externer Identitätsanbieter,
- Zertifikatsdienst,
- weiterer Microservice.

Mögliche Symptome:

- TCP-Verbindung wird aufgebaut,
- Loginseite erscheint,
- Anmeldung scheitert,
- Anfrage endet mit `500`,
- Antwort dauert sehr lange,
- nur bestimmte Funktionen sind betroffen,
- Health Check meldet Fehler,
- Dienst startet, wird aber nicht „ready“.

Die Prüfung muss deshalb vom Frontend bis zu den tatsächlich benötigten Abhängigkeiten fortgesetzt werden.

---

**24. Authentifizierung und Berechtigung abgrenzen**

Eine erfolgreiche Netzwerkverbindung beweist nicht, dass der Benutzer oder Client den Dienst verwenden darf.

Zu unterscheiden sind:

- Zielport nicht erreichbar,
- TLS-Verbindung fehlerhaft,
- Benutzer nicht authentifiziert,
- falsche Anmeldedaten,
- Konto gesperrt,
- fehlende Gruppenmitgliedschaft,
- Zugriff durch Anwendung verweigert,
- Zugriff durch Netzwerkregel verweigert,
- Kerberos- oder Zertifikatsfehler,
- Mandanten- oder Rollenproblem.

Beispiele:

```text
Connection timed out
```

weist eher auf Transport oder fehlende Antwort hin.

```text
401 Unauthorized
```

zeigt dagegen, dass eine HTTP-Antwort des Dienstes empfangen wurde und die Untersuchung auf Anwendungsebene fortgesetzt werden muss.

---

**25. IPv4 und IPv6 getrennt prüfen**

Ein Dienst kann für IPv4 und IPv6 unterschiedlich erreichbar sein.

**Windows**

```powershell
Resolve-DnsName <zielname> -Type A
Resolve-DnsName <zielname> -Type AAAA
Test-NetConnection <ipv4-adresse> -Port <port>
Test-NetConnection <ipv6-adresse> -Port <port>
```

**Linux und macOS**

```bash
curl -4 -v https://<zielname>/
curl -6 -v https://<zielname>/
nc -4 -vz <zielname> <port>
nc -6 -vz <zielname> <port>
```

Mögliche Ursachen:

- Dienst lauscht nur auf IPv4,
- Dienst lauscht nur auf IPv6,
- AAAA-Record zeigt auf eine falsche Adresse,
- IPv6-Firewallregel fehlt,
- IPv6-Rückroute fehlt,
- Client bevorzugt einen nicht funktionsfähigen IPv6-Pfad.

IPv6 sollte nicht pauschal deaktiviert werden. Zuerst ist nachzuweisen, welche Adressfamilie den Fehler verursacht.

---

**26. MTU, Fragmentierung und große Datenmengen**

Ein TCP-Handshake kann funktionieren, während größere Datenübertragungen scheitern.

Mögliche Symptome:

- Porttest erfolgreich,
- kleine Anfragen funktionieren,
- TLS-Handshake bleibt hängen,
- Dateiübertragung bricht ab,
- bestimmte Webseiten laden nur teilweise,
- Verbindung über VPN scheitert bei größeren Paketen,
- wiederholte TCP-Übertragungen treten auf.

Mögliche Ursachen:

- ungeeignete MTU,
- blockierte ICMP-Meldungen für Path MTU Discovery,
- Fragmentierung,
- Tunnel-Overhead,
- fehlerhafte MSS-Anpassung,
- Paketverlust,
- Sicherheitskomponente verwirft größere Pakete.

**Linux**

```bash
tracepath <ziel>
```

**Windows**

```powershell
ping <ziel> -f -l <paketgröße>
```

Der verwendbare Wert hängt von Protokoll-Headern und Datenpfad ab. Ein einzelner Pingwert darf deshalb nicht ungeprüft als endgültige MTU übernommen werden.

---

**27. Proxys und anwendungsspezifische Netzwerkwege**

Eine Anwendung kann einen anderen Netzwerkpfad verwenden als ein einfacher Porttest.

Mögliche Unterschiede:

- HTTP-Proxy,
- SOCKS-Proxy,
- automatische Proxykonfiguration,
- VPN-Tunnel,
- DNS over HTTPS,
- anwendungseigener Resolver,
- Service Mesh,
- TLS-Inspection,
- Cloud-Gateway,
- Zero-Trust-Zugriff.

Zu prüfen sind:

- verwendet die Anwendung einen Proxy?
- umgeht das Testwerkzeug den Proxy?
- wird der Zielname durch den Proxy aufgelöst?
- ist der Proxy selbst erreichbar?
- erlaubt der Proxy den Zielport?
- existiert eine Ausnahmeliste?
- wird die Verbindung durch Benutzer- oder Gerätestatus gesteuert?

Ein erfolgreicher direkter Test beweist nicht, dass der von der Anwendung verwendete Proxyweg funktioniert.

---

**28. Sporadische und lastabhängige Fehler**

Nicht jeder Dienstfehler besteht dauerhaft.

Mögliche Ursachen:

- Verbindungsgrenze erreicht,
- Quellports erschöpft,
- überlasteter Server,
- Load Balancer verteilt auf einen defekten Knoten,
- Firewall-Sitzungstabelle ausgelastet,
- Paketverlust,
- Dienst startet wiederholt neu,
- Datenbankverbindungen erschöpft,
- Timeouts zwischen Proxy und Backend,
- DNS liefert wechselnde Ziele,
- automatische Skalierung reagiert zu langsam.

**Windows**

```powershell
Get-NetTCPConnection
Get-Counter '\TCPv4\Connections Established'
```

**Linux**

```bash
ss -s
ss -ant
```

Wiederholte Tests sollten mit Zeitstempel durchgeführt werden.

**PowerShell**

```powershell
1..10 | ForEach-Object {
    Get-Date
    Test-NetConnection <ziel> -Port <port>
    Start-Sleep -Seconds 2
}
```

**Bash**

```bash
for i in {1..10}; do
    date
    nc -vz <ziel> <port>
    sleep 2
done
```

Zu vergleichen sind:

- Erfolg oder Fehler,
- Antwortzeit,
- Zieladresse,
- betroffener Backend-Server,
- Zeitpunkt,
- gleichzeitige Last,
- Firewall- und Anwendungsprotokolle.

---

**29. Paketaufzeichnung einsetzen**

Eine Paketaufzeichnung kann zeigen:

- ob der Client ein SYN sendet,
- ob das Ziel mit SYN/ACK oder RST antwortet,
- ob Pakete erneut übertragen werden,
- ob die Verbindung nach dem Handshake abbricht,
- ob TLS beginnt,
- ob eine Anwendungsantwort zurückkommt,
- ob ICMP-Fehlermeldungen auftreten,
- ob IPv4 oder IPv6 verwendet wird,
- ob die tatsächliche Zieladresse stimmt,
- ob Hin- und Rückweg vollständig sind.

**Wireshark-Filter**

```text
ip.addr == <ziel-ip>
tcp.port == <port>
udp.port == <port>
tcp.flags.syn == 1
tcp.flags.reset == 1
tcp.analysis.retransmission
icmp
icmpv6
tls
http
```

Für eine einzelne TCP-Verbindung kann nach Auswahl eines Pakets zusätzlich der zugehörige TCP-Stream gefiltert werden.

**Typische Beobachtungen**

| Paketaufzeichnung | mögliche Einordnung |
|---|---|
| kein Verbindungsversuch sichtbar | Anwendung, Proxy, Cache oder falsche Schnittstelle |
| SYN verlässt Client, keine Antwort | Firewall-Drop, Routing, Ziel oder Rückweg |
| SYN wird mit RST beantwortet | kein Listener oder aktive Ablehnung |
| SYN/ACK erreicht Client, Client antwortet nicht | Client-Firewall, lokaler Stack oder falscher Zustand |
| TCP-Handshake vollständig, danach TLS-Fehler | Zertifikat, SNI, Protokoll oder Cipher |
| TCP-Handshake vollständig, HTTP `401` | Authentifizierung |
| TCP-Handshake vollständig, HTTP `403` | Berechtigung oder Richtlinie |
| TCP-Handshake vollständig, HTTP `502` | Proxy- oder Backend-Problem |
| viele Wiederholungen | Paketverlust, Überlastung, MTU oder Datenpfad |
| Verbindung wird durch RST beendet | Anwendung, Firewall, Proxy oder Betriebssystem |

Paketaufzeichnungen dürfen nur mit entsprechender Berechtigung erstellt und müssen geschützt gespeichert werden.

---

**30. Vergleichstests systematisch verwenden**

Vergleichstests helfen, die fehlerhafte Grenze einzugrenzen.

Sinnvolle Vergleiche:

| Vergleich | mögliche Erkenntnis |
|---|---|
| betroffener und funktionierender Client | Clientkonfiguration oder Netzsegment |
| Zielname und Ziel-IP | DNS, SNI oder virtueller Host |
| IPv4 und IPv6 | Adressfamilie oder Datenpfad |
| lokaler und entfernter Zugriff | Dienst oder Netzwerk |
| gleiches VLAN und anderes VLAN | Routing, ACL oder Firewall |
| internes Netz und VPN | VPN-Regel, Route oder DNS |
| Frontend und Backend direkt | Proxy oder Load Balancer |
| erster und zweiter Server | einzelnes Zielsystem oder zentraler Pfad |
| kleiner und großer Datentransfer | MTU, Paketverlust oder Überlastung |
| TCP-Porttest und Protokolltest | Transport oder Anwendung |

Dabei sollte jeweils nur eine Variable verändert werden.

---

**31. Praxisfall A: Ping funktioniert, HTTPS-Port nicht**

**Symptom**

- Server antwortet auf Ping,
- Name wird korrekt aufgelöst,
- TCP Port 443 läuft in eine Zeitüberschreitung,
- andere Server im selben Netz sind erreichbar.

**Prüfung**

1. Zieladresse dokumentieren.
2. TCP Port 443 vom Client testen.
3. Listener auf dem Server prüfen.
4. lokalen HTTPS-Test auf dem Server durchführen.
5. Server-Firewall kontrollieren.
6. Netzwerk-Firewall und Trefferprotokolle prüfen.
7. Paketaufzeichnung auf Client und Server vergleichen.

**Mögliche Ursache**

Der Webserver läuft und lauscht auf Port 443. Nach einer Netzsegmentierung fehlt jedoch die Freigabe vom neuen Client-VLAN zum Server.

**Nachprüfung**

- TCP Port 443 ist aus dem vorgesehenen VLAN erreichbar,
- HTTPS liefert eine gültige Antwort,
- nicht vorgesehene Quellnetze bleiben gesperrt,
- Firewallregel ist dokumentiert,
- ursprüngliche Anwendung funktioniert.

---

**32. Praxisfall B: Dienst funktioniert lokal, aber nicht entfernt**

**Symptom**

- lokaler Aufruf über `localhost` funktioniert,
- entfernter Porttest wird abgelehnt,
- der Prozess läuft,
- auf dem Server ist kein allgemeiner Listener sichtbar.

**Prüfung**

1. Listener und Bind-Adresse feststellen.
2. Loopback und Server-IP lokal vergleichen.
3. Dienstkonfiguration prüfen.
4. nach einer Änderung den Dienst kontrolliert neu laden.
5. lokale Firewall berücksichtigen.
6. entfernten Test wiederholen.

**Mögliche Ursache**

Der Dienst lauscht ausschließlich auf `127.0.0.1`.

**Nachprüfung**

- Dienst lauscht auf der vorgesehenen Serveradresse,
- lokaler Zugriff funktioniert,
- entfernter Zugriff aus erlaubten Netzen funktioniert,
- Firewall begrenzt den Zugriff weiterhin,
- keine unnötige öffentliche Freigabe wurde geschaffen.

---

**33. Praxisfall C: Port 443 ist offen, Website liefert 502**

**Symptom**

- TCP Port 443 ist erreichbar,
- TLS-Verbindung wird aufgebaut,
- Reverse Proxy antwortet mit `502 Bad Gateway`,
- Backend-Anwendung ist nicht direkt erreichbar.

**Prüfung**

1. Proxy-Antwort dokumentieren.
2. Proxy-Protokolle prüfen.
3. Backend-Ziel und Backend-Port feststellen.
4. Verbindung vom Proxy zum Backend testen.
5. Listener der Backend-Anwendung prüfen.
6. Container- oder Dienststatus kontrollieren.
7. Namensauflösung innerhalb des Proxy-Netzes prüfen.

**Mögliche Ursache**

Nach einer Änderung verwendet die Backend-Anwendung einen neuen Port. Die Proxy-Konfiguration zeigt weiterhin auf den alten Port.

**Nachprüfung**

- Proxy erreicht das richtige Backend,
- Backend-Health-Check ist erfolgreich,
- HTTPS-Aufruf liefert die erwartete Anwendung,
- weitere virtuelle Hosts funktionieren,
- Konfigurationsänderung ist dokumentiert.

---

**34. Praxisfall D: Einige Clients erreichen den Dienst, andere nicht**

**Symptom**

- Clients im VLAN 20 können eine Anwendung öffnen,
- Clients im VLAN 30 erhalten eine Zeitüberschreitung,
- beide Gruppen lösen denselben Namen zur selben IP-Adresse auf,
- der Dienst funktioniert lokal.

**Prüfung**

1. Quell-IP-Adressen beider Clients erfassen.
2. Route und Gateway vergleichen.
3. Porttest aus beiden Netzen durchführen.
4. Firewallregeln und Trefferzähler prüfen.
5. Server-Firewall auf Quellnetzbegrenzungen untersuchen.
6. Paketaufzeichnung am Server durchführen.

**Mögliche Ursache**

Die Server-Firewall erlaubt Port 8443 nur aus dem alten VLAN 20.

**Nachprüfung**

- vorgesehene Clients aus VLAN 30 erreichen den Dienst,
- VLAN 20 funktioniert weiterhin,
- andere Netze bleiben gesperrt,
- Quellnetze in der Regel sind korrekt dokumentiert.

---

**35. Praxisfall E: TCP-Verbindung funktioniert, Anmeldung scheitert**

**Symptom**

- Zielname wird korrekt aufgelöst,
- TCP-Port ist erreichbar,
- TLS funktioniert,
- Anwendung zeigt eine Anmeldeseite,
- Benutzer erhält `401 Unauthorized`.

**Prüfung**

1. erfolgreichen Transport dokumentieren.
2. Anwendungsprotokoll und Statuscode auswerten.
3. Benutzerkonto und Authentifizierungsquelle prüfen.
4. Uhrzeit, Zertifikate und gegebenenfalls Kerberos berücksichtigen.
5. funktionierendes Vergleichskonto verwenden.
6. Anwendungs- und Authentifizierungsprotokolle prüfen.

**Mögliche Ursache**

Der Benutzer ist nicht mehr Mitglied der für die Anwendung berechtigten Gruppe.

**Nachprüfung**

- Benutzer kann sich nach genehmigter Berechtigungskorrektur anmelden,
- TCP- und TLS-Verbindung bleiben unverändert,
- Zugriff ist auf vorgesehene Benutzer begrenzt,
- Ursache und Berechtigungsänderung sind dokumentiert.

---

**36. Ungeeignete Sofortmaßnahmen**

Problematisch sind insbesondere:

- Firewall vollständig deaktivieren,
- beliebige Ports pauschal freigeben,
- einen Dienst ungeprüft neu starten,
- Server neu starten, ohne den Zustand zu dokumentieren,
- Anwendung als Ursache festlegen, nur weil Ping funktioniert,
- Netzwerk als Ursache festlegen, obwohl der Dienst keinen Listener besitzt,
- Zertifikatsprüfung dauerhaft deaktivieren,
- IPv6 pauschal abschalten,
- NAT-Regeln ohne Sicherung verändern,
- mehrere Firewalls gleichzeitig ändern,
- Sicherheitssoftware ungeprüft entfernen,
- Container neu erstellen, ohne Volumes und Konfiguration zu prüfen,
- produktive Paketaufzeichnungen ungeschützt speichern,
- Testzugänge oder temporäre Freigaben dauerhaft bestehen lassen.

Vor Änderungen sollten dokumentiert werden:

- Quell- und Zieladresse,
- Zielport und Transportprotokoll,
- DNS-Ergebnis,
- Porttestergebnis,
- Listener,
- Dienststatus,
- Firewallregeln,
- NAT-Regeln,
- Routen,
- Protokolle,
- Paketbeobachtungen,
- Zeitpunkt und Umfang der Störung.

---

**37. Vollständige Prüfreihenfolge**

1. betroffene Anwendung und genaue Fehlermeldung erfassen.
2. Quelle, Zielname und Ziel-IP-Adresse dokumentieren.
3. benötigten Zielport bestimmen.
4. TCP oder UDP unterscheiden.
5. Namensauflösung prüfen.
6. Host-Erreichbarkeit nur als Teilprüfung verwenden.
7. Zielport vom betroffenen Client testen.
8. Ergebnis als Erfolg, Ablehnung, Reset oder Zeitüberschreitung einordnen.
9. funktionierenden Vergleichsclient prüfen.
10. IPv4 und IPv6 getrennt betrachten.
11. auf dem Server den Listener prüfen.
12. Prozess zum Listener bestimmen.
13. Bind-Adresse kontrollieren.
14. Dienststatus und Protokolle auswerten.
15. Dienst über Loopback lokal testen.
16. Dienst über die Server-IP lokal testen.
17. protokollspezifischen Test durchführen.
18. lokale Server-Firewall prüfen.
19. Client-Firewall und Sicherheitssoftware berücksichtigen.
20. Netzwerk-Firewalls und ACLs prüfen.
21. Route vom Client zum Server untersuchen.
22. Rückweg vom Server zum Client prüfen.
23. NAT und Portweiterleitungen berücksichtigen.
24. VPN- und Segmentierungsregeln prüfen.
25. Container-, VM- oder Host-Portzuordnungen prüfen.
26. Reverse Proxy oder Load Balancer untersuchen.
27. Backend-Verbindungen testen.
28. TLS, Zertifikat, SNI und Hostnamen prüfen.
29. Anwendung, Authentifizierung und Berechtigung abgrenzen.
30. bei sporadischen Fehlern wiederholte Tests durchführen.
31. bei Bedarf autorisierte Paketaufzeichnung erstellen.
32. konkrete Hypothese formulieren.
33. genau eine kontrollierbare Änderung durchführen.
34. Listener und Dienststatus erneut prüfen.
35. Porttest wiederholen.
36. protokollspezifischen Test wiederholen.
37. ursprüngliche Anwendung erneut testen.
38. funktionierende und nicht vorgesehene Netze kontrollieren.
39. temporäre Freigaben entfernen.
40. Ursache, Maßnahme und Ergebnis dokumentieren.
41. Monitoring oder Präventionsmaßnahme festlegen.

---

**38. Dokumentationsbeispiel**

```text
Ticket: INC-20644
Beginn: 02.08.2026, etwa 14:20 Uhr
Umfang: Clients im VLAN 30
Betroffen: HTTPS-Anwendung auf appserver.example.test
Nicht betroffen: Clients im VLAN 20

Verbindung:
Quelle: 192.0.2.117
Ziel: appserver.example.test
Ziel-IP: 192.0.2.50
Transport: TCP
Zielport: 443

Symptom:
Der Server antwortet auf ICMP.
Die Namensauflösung liefert die korrekte IP-Adresse.
Der HTTPS-Aufruf läuft aus VLAN 30 in eine Zeitüberschreitung.

Ausgangszustand:
- DNS-Auflösung korrekt
- ICMP-Antwort vorhanden
- TCP Port 443 aus VLAN 30 nicht erreichbar
- TCP Port 443 aus VLAN 20 erreichbar
- Webserver lauscht auf 0.0.0.0:443
- lokaler HTTPS-Test auf dem Server erfolgreich
- Server-Firewall erlaubt beide internen Netze
- zentrale Firewall protokolliert verworfene SYN-Pakete aus VLAN 30

Hypothese:
Bei der Einrichtung des neuen VLANs wurde die Freigabe zu TCP Port 443
auf dem Anwendungsserver nicht ergänzt.

Prüfung:
- Quell-IP und Ziel-IP bestätigt
- Route zum Server vorhanden
- Listener und Dienststatus korrekt
- funktionierenden Client aus VLAN 20 verglichen
- Firewallregel enthält nur das Quellnetz von VLAN 20
- keine SYN-Pakete aus VLAN 30 erreichen den Server

Ursache:
Die zentrale Firewallregel erlaubte den HTTPS-Zugriff nur aus VLAN 20.

Maßnahme:
Das freigegebene Quellobjekt wurde nach Genehmigung um das vorgesehene
Clientnetz aus VLAN 30 ergänzt. Ziel und Port blieben unverändert.

Nachprüfung:
- TCP Port 443 aus VLAN 30 erreichbar
- TLS-Handshake erfolgreich
- Anwendung liefert HTTP 200
- Anmeldung funktioniert
- VLAN 20 funktioniert weiterhin
- Zugriff aus nicht freigegebenen Netzen bleibt blockiert
- Firewallprotokoll und Trefferzähler geprüft

Prävention:
- Firewallfreigaben in die VLAN-Abnahme aufnehmen
- automatisierten HTTPS-Health-Check aus beiden Clientnetzen einrichten
- Änderungen an Netzsegmenten mit einer Kommunikationsmatrix prüfen
```

---

**39. Checkliste „Host erreichbar, Dienst nicht“**

- [ ] die betroffene Anwendung wurde eindeutig benannt.
- [ ] die genaue Fehlermeldung wurde dokumentiert.
- [ ] Quellgerät und Quell-IP-Adresse wurden erfasst.
- [ ] Zielname und Ziel-IP-Adresse wurden erfasst.
- [ ] der benötigte Zielport wurde bestätigt.
- [ ] TCP und UDP wurden unterschieden.
- [ ] die Namensauflösung wurde geprüft.
- [ ] Ping wurde nicht mit einem Diensttest gleichgesetzt.
- [ ] der Zielport wurde vom betroffenen Client getestet.
- [ ] Erfolg, Ablehnung, Reset oder Zeitüberschreitung wurden unterschieden.
- [ ] ein funktionierender Vergleichsclient wurde geprüft.
- [ ] IPv4 und IPv6 wurden getrennt betrachtet.
- [ ] ein Listener auf dem Server wurde nachgewiesen.
- [ ] der zugehörige Prozess wurde bestimmt.
- [ ] die Bind-Adresse wurde kontrolliert.
- [ ] der Dienststatus wurde geprüft.
- [ ] Dienstprotokolle wurden ausgewertet.
- [ ] der Dienst wurde lokal über Loopback getestet.
- [ ] der Dienst wurde lokal über die Server-IP getestet.
- [ ] ein protokollspezifischer Test wurde durchgeführt.
- [ ] die lokale Server-Firewall wurde geprüft.
- [ ] die Client-Firewall wurde berücksichtigt.
- [ ] Netzwerk-Firewalls und ACLs wurden geprüft.
- [ ] Firewallregeln wurden auf Quelle, Ziel, Port und Protokoll geprüft.
- [ ] Hin- und Rückroute wurden berücksichtigt.
- [ ] asymmetrisches Routing wurde bei Bedarf geprüft.
- [ ] NAT und Portweiterleitungen wurden berücksichtigt.
- [ ] VPN- und Segmentierungsregeln wurden geprüft.
- [ ] Container- oder VM-Portzuordnungen wurden berücksichtigt.
- [ ] Reverse Proxy oder Load Balancer wurde geprüft.
- [ ] die Verbindung zum Backend wurde getestet.
- [ ] TLS und Zertifikate wurden berücksichtigt.
- [ ] Hostname, SNI und virtuelle Hosts wurden berücksichtigt.
- [ ] Anwendung, Authentifizierung und Berechtigung wurden abgegrenzt.
- [ ] MTU und Paketverlust wurden bei passenden Symptomen berücksichtigt.
- [ ] anwendungsspezifische Proxys wurden geprüft.
- [ ] bei sporadischen Fehlern wurden zeitgestempelte Tests durchgeführt.
- [ ] eine Paketaufzeichnung erfolgte nur mit Berechtigung.
- [ ] der Ausgangszustand wurde vor Änderungen dokumentiert.
- [ ] es wurde nur eine kontrollierbare Änderung durchgeführt.
- [ ] der Porttest wurde nach der Änderung wiederholt.
- [ ] das Anwendungsprotokoll wurde erneut getestet.
- [ ] die ursprüngliche Anwendung wurde erneut geprüft.
- [ ] unzulässige Quellnetze bleiben weiterhin gesperrt.
- [ ] temporäre Testfreigaben wurden entfernt.
- [ ] Ursache, Maßnahme und Nachweis wurden dokumentiert.

---

**40. Schnellreferenz**

| Fehlerbild | wahrscheinlicher Untersuchungsbereich |
|---|---|
| Ping funktioniert, TCP-Port nicht | Listener, Firewall, Routing, NAT oder Rückweg |
| TCP-Verbindung wird sofort abgelehnt | kein Listener, falscher Port oder aktive Ablehnung |
| TCP-Verbindung läuft in Zeitüberschreitung | Firewall-Drop, Routing, NAT, Rückweg oder Ziel |
| Port funktioniert lokal, entfernt nicht | Bind-Adresse, Firewall, ACL oder Netzwerkpfad |
| Loopback funktioniert, Server-IP lokal nicht | Bind-Adresse oder lokale Firewall |
| Port ist offen, Anwendung antwortet nicht | Dienst, Protokoll, Backend oder Überlastung |
| TCP funktioniert, TLS scheitert | Zertifikat, SNI, Protokoll oder Cipher |
| HTTPS liefert `401` | Authentifizierung |
| HTTPS liefert `403` | Berechtigung oder Richtlinie |
| HTTPS liefert `502` | Proxy erreicht Backend nicht korrekt |
| HTTPS liefert `503` | Dienst oder Backend nicht verfügbar |
| HTTPS liefert `504` | Zeitüberschreitung zwischen Proxy und Backend |
| nur ein Client betroffen | Client-Firewall, Proxy, Route oder lokale Anwendung |
| nur ein Netz betroffen | ACL, Firewall, Routing oder Quellnetzregel |
| nur VPN-Clients betroffen | VPN-Route, VPN-Firewall, MTU oder DNS |
| intern erreichbar, extern nicht | NAT, Portweiterleitung, externe Firewall oder Provider |
| extern erreichbar, intern nicht | Hairpin-NAT, Split-DNS oder interne Firewall |
| IP funktioniert, Hostname nicht | DNS, SNI, virtueller Host oder Zertifikat |
| IPv4 funktioniert, IPv6 nicht | IPv6-Listener, Firewall, Route oder AAAA-Record |
| kleine Anfragen funktionieren, große nicht | MTU, Fragmentierung, Paketverlust oder Timeout |
| Verbindung scheitert sporadisch | Last, Porterschöpfung, defektes Backend oder Paketverlust |
| UDP-Test bleibt ohne Antwort | Dienst, Firewall, falsche Anfrage oder normales Protokollverhalten |
| SYN ohne Antwort | Drop, Routing, Ziel oder Rückweg |
| SYN gefolgt von RST | Port geschlossen oder aktive Ablehnung |
| Handshake vollständig, danach RST | Anwendung, Proxy, Firewall oder Protokoll |
| Handshake vollständig, keine Antwort | Dienst hängt, Backend wartet oder Überlastung |

---

**Merksatz**

> Ein erreichbarer Host ist nicht automatisch ein erreichbarer Dienst. Geprüft werden müssen die vollständige Kommunikationsbeziehung aus Quelle, Zieladresse, Transportprotokoll und Zielport sowie anschließend Listener, Firewall, Rückweg und Anwendung. Ein erfolgreicher Porttest beweist den TCP-Verbindungsaufbau, aber noch nicht die Funktionsfähigkeit des Anwendungsprotokolls.

---

**Quellen und weiterführende Dokumentation**

- [Microsoft Learn – Guidance for troubleshooting TCP/IP communication](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-tcp-ip-communication-guidance)
- [Microsoft Learn – Troubleshoot TCP/IP connectivity](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-connectivity-issues-troubleshooting)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn – Test-Connection](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection)
- [Microsoft Learn – Get-NetTCPConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-nettcpconnection)
- [Microsoft Learn – Get-NetUDPEndpoint](https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netudpendpoint)
- [Microsoft Learn – Windows Defender Firewall with Advanced Security administration](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/)
- [RFC 9293 – Transmission Control Protocol](https://www.rfc-editor.org/rfc/rfc9293)
- [RFC 768 – User Datagram Protocol](https://www.rfc-editor.org/rfc/rfc768)
- [RFC 792 – Internet Control Message Protocol](https://www.rfc-editor.org/rfc/rfc792)
- [RFC 8201 – Path MTU Discovery for IPv6](https://www.rfc-editor.org/rfc/rfc8201)
- [Wireshark – Display Filter Reference: TCP](https://www.wireshark.org/docs/dfref/t/tcp.html)
- [Wireshark – Display Filter Reference: UDP](https://www.wireshark.org/docs/dfref/u/udp.html)
- [Wireshark User’s Guide – Building display filter expressions](https://www.wireshark.org/docs/wsug_html_chunked/ChWorkBuildDisplayFilterSection.html)