Netzwerk und Remoteverwaltung

„Der Server ist nicht erreichbar“ ist keine Diagnose, sondern eine Sammelmeldung für drei verschiedene Zustände — und der häufigste Reflex, die Firewall abzuschalten, beantwortet keinen davon. Dieses Modul trennt Erreichbarkeit, Name und Berechtigung und zeigt die Stellen, an denen die Erwartung nicht stimmt: eine Verwaltungskarte, die im öffentlichen Profil landet, weil dort kein Domänencontroller antwortet; ein Verwaltungskanal über HTTP, der trotzdem verschlüsselt ist; und eine IP-Adresse statt eines Namens, die Kerberos still abschaltet.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Drei Achsen, die getrennt gehören

„Der Server ist nicht erreichbar“ ist keine Diagnose, sondern eine Sammelmeldung für mindestens drei verschiedene Zustände. Wer sie nicht trennt, probiert Maßnahmen aus einer Achse gegen ein Problem aus einer anderen — und die häufigste davon ist, die Firewall abzuschalten, weil sie am schnellsten abzuschalten ist.

Erreichbarkeit: Kommt ein Paket bis zum Zielport? Sache von Routing, Firewall und dem lauschenden Prozess.
Name: Löst der Name auf die richtige Adresse auf? Sache des DNS-Clients, seiner Serverliste und seines Zwischenspeichers.
Berechtigung: Darf dieses Konto sich anmelden und diesen Dienst benutzen? Sache von Authentifizierung und Rechten.

Warum die Reihenfolge zähltDie drei bauen aufeinander auf: Ohne Erreichbarkeit sagt ein Namensproblem nichts, ohne aufgelösten Namen kommt keine Kerberos-Anmeldung zustande. Eine Diagnose, die bei der Berechtigung anfängt, weil die Fehlermeldung von Zugriff spricht, arbeitet von oben nach unten gegen die Abhängigkeit — und findet die Ursache zufällig oder gar nicht.

Der Nachbartrack network-services behandelt die Netzwerkseite als eigene Disziplin — Adressierung, Segmentierung, DNS- und DHCP-Betrieb, Routing. Hier geht es um die Sicht vom Server aus: seine Netzwerkkonfiguration, seine Firewall, seine Verwaltungszugänge. Die Grenze verläuft an der Netzwerkkarte: Was auf dem Server konfiguriert ist, steht hier; was im Netz dazwischen passiert, steht dort.

Was ein Verbindungstest beantwortet

Test-NetConnection ist das Standardwerkzeug für die erste Achse. Es kann mehrere Dinge, und die Ergebnisse haben unterschiedliche Aussagekraft — was es misst, hängt davon ab, wie man es aufruft.

Test-NetConnection <Host>: ICMP-Echo. Sagt etwas über Erreichbarkeit auf Netzebene, nichts über einen Dienst.
Test-NetConnection <Host> -Port 445: Baut eine TCP-Verbindung auf. Das ist die aussagekräftige Form.
-CommonTCPPort: Kürzel für die üblichen Verdächtigen wie HTTP, RDP, SMB, WINRM.
-TraceRoute: Zeigt den Weg — nützlich, wenn eine Zwischenstation im Verdacht steht.
-InformationLevel Detailed: Ergänzt Quelladresse, Schnittstelle und die zugehörige Route.

Was ein offener Port nicht beweistEine erfolgreiche TCP-Verbindung sagt: Es lauscht etwas, und der Weg dorthin ist frei. Sie sagt nicht, dass der richtige Dienst antwortet, dass er die richtige Anwendung bedient oder dass er über den Namen erreichbar ist, den die Clients benutzen. Und umgekehrt: Ein fehlgeschlagener ICMP-Test beweist gar nichts, weil ICMP auf vielen Servern gesperrt ist. Wer mit dem einfachen Aufruf ohne Port testet, misst regelmäßig eine Regel und nicht einen Dienst.

Die zweite Hälfte der Antwort steht auf dem Zielserver. Get-NetTCPConnection -State Listen zeigt, welche Ports dort tatsächlich bedient werden und von welchem Prozess — die Zuordnung zum Prozess ist der Teil, der die Frage „lauscht der richtige Dienst“ beantwortet. Vom Client aus sind ein blockierter Port und ein Port ohne lauschenden Prozess nicht zu unterscheiden; auf dem Server sind es zwei völlig verschiedene Befunde mit verschiedenen Maßnahmen.

Namensauflösung ist eine eigene Schicht

Der DNS-Client eines Servers hat eine eigene Konfiguration, einen eigenen Zwischenspeicher und eine eigene Reihenfolge. Er ist nicht dasselbe wie der DNS-Serverdienst, der auf demselben Server laufen kann — eine Verwechslung, die bei Domänencontrollern ständig passiert.

Get-DnsClientServerAddress — welche Server fragt dieser Rechner, je Schnittstelle?
Resolve-DnsName <Name> — was kommt zurück, und von welchem Server?
Resolve-DnsName <Name> -Server <IP> — dasselbe gezielt gegen einen bestimmten Server, am Zwischenspeicher vorbei.
Get-DnsClientCache und Clear-DnsClientCache — was liegt lokal, und wie wird es losgeworden.

Der Fall, der Stunden kostetEin Server zeigt auf einen öffentlichen Resolver, weil das bei der Einrichtung „einfach funktioniert hat“. Interne Namen löst er dann nicht auf — und weil der Domänenbeitritt zu einem Zeitpunkt stattfand, als die Konfiguration noch stimmte, sieht der Server ansonsten unauffällig aus. Der Befund ist eine Zeile in Get-DnsClientServerAddress, und man findet ihn nur, wenn man die Achse überhaupt getrennt betrachtet.

Ein zweiter Punkt betrifft die Reihenfolge innerhalb der Auflösung. Bevor DNS überhaupt gefragt wird, greift der lokale Zwischenspeicher, und vor dem Zwischenspeicher die Datei %SystemRoot%\System32\drivers\etc\hosts. Ein Eintrag dort, den vor drei Jahren jemand für einen Test gesetzt hat, überstimmt jede noch so korrekte DNS-Zone — und er taucht in keiner DNS-Abfrage auf, weil er vorher greift. Bei einem Namen, der auf einem einzelnen Server anders auflöst als überall sonst, ist diese Datei der erste Ort, an dem man nachsieht.

Die Firewall hat drei Profile

Die Windows-Firewall wendet Regeln je nach Netzwerkprofil an. Welches Profil gilt, entscheidet die Netzwerkerkennung — und zwar je Netzwerkverbindung, nicht je Server.

Domäne: Wird automatisch angewendet, wenn ein Domänencontroller erreichbar ist. Laut Doku nicht manuell setzbar.
Privat: Für vertrauenswürdige Netze. Kann von einem Administrator manuell gesetzt werden.
Öffentlich: Die strengste Einstellung — und laut Doku das Standardprofil für nicht identifizierte Netze.

Der Server mit zwei NetzwerkkartenEin Server mit einer Produktions- und einer Verwaltungskarte kann zwei aktive Profile gleichzeitig haben. Die Verwaltungskarte hängt oft in einem isolierten Segment ohne erreichbaren Domänencontroller — sie landet damit im öffentlichen Profil, während die andere Karte im Domänenprofil ist. Eine Regel, die nur für das Domänenprofil freigegeben wurde, greift auf dem Verwaltungsweg dann nicht. Get-NetConnectionProfile beantwortet die Frage in einer Zeile; Set-NetConnectionProfile kann zwischen privat und öffentlich umstellen, das Domänenprofil aber nicht erzwingen.

Warum „Firewall aus“ der falsche Handgriff ist

Wenn etwas nicht durchkommt, ist der Dienst der Windows-Firewall der erste Verdächtige und das Anhalten des Dienstes der schnellste Test. Die Dokumentation widerspricht diesem Vorgehen ausdrücklich.

Der dokumentierte WegDie richtige Methode, die Windows-Firewall abzuschalten, ist, die Profile zu deaktivieren und den Dienst laufen zu lassen. Der Dienst trägt mehr als die Paketfilterung — andere Netzwerkkomponenten hängen an ihm. Ihn anzuhalten erzeugt Fehlerbilder, die mit der eigentlichen Frage nichts zu tun haben, und der Test beweist danach nichts mehr, weil zwei Dinge gleichzeitig verändert wurden.

Der bessere Test kommt ohnehin ohne Abschalten aus. Wer wissen will, ob eine Regel greift, prüft die Regel: Get-NetFirewallRule zusammen mit Get-NetFirewallPortFilter und Get-NetFirewallAddressFilter zeigt, welche Regel für welchen Port, welche Richtung, welches Profil und welchen Adressbereich gilt. Das ist mehr Tipparbeit und liefert eine Antwort statt einer Vermutung.

Und selbst wenn das Abschalten sauber gemacht wird, bleibt es ein schlechter Test: Es beantwortet die Frage „liegt es an der Firewall“ mit ja oder nein, aber nicht die Frage, welche Regel gefehlt hat. Man weiß danach, dass man eine Regel braucht, und steht vor derselben Aufgabe wie vorher — nur mit einem Server, der zwischenzeitlich ungeschützt war. Der Blick in die Regeln kostet zwei Minuten mehr und liefert die Antwort statt der Richtung.

Eine Regel hat vier Eigenschaften

Eine Firewallregel wird oft auf ihren Port reduziert. Sie hat aber vier Achsen, und drei davon sind die üblichen Fehlerquellen.

Richtung: Eingehend oder ausgehend. Eingehende Regeln sind der Regelfall auf einem Server; ausgehende Sperren sind selten und dann besonders schwer zu finden.
Profil: Für welche Profile gilt die Regel? Eine Regel nur für Domäne wirkt auf einer öffentlich eingestuften Karte nicht.
Bereich: Von welchen Quelladressen aus gilt sie? Der Unterschied zwischen einer Freigabe für ein Verwaltungsnetz und einer für alle.
Programm oder Dienst: Für welchen Prozess gilt sie? Eine portbasierte Regel ohne Programmbindung ist weiter, als sie aussieht.

Die dritte Zeile ist die, die im Betrieb am meisten kostet. Eine Regel, die einen Verwaltungsport für alle Quelladressen öffnet, funktioniert einwandfrei und ist genau die Art von Konfiguration, die bei einer Prüfung auffällt — Monate, nachdem sie unter Zeitdruck entstanden ist.

Die Regel, die im Verwaltungsnetz nicht greift

Szenario

Auf einem neuen Server soll PowerShell-Remoting aus dem Verwaltungsnetz funktionieren. Die Regel für Port 5985 ist angelegt und aktiv, der Dienst läuft, ein Verbindungstest vom Arbeitsplatz aus scheitert trotzdem.

Anforderungen

Der Zugang soll auf das Verwaltungsnetz begrenzt bleiben.
Die Firewall soll nicht abgeschaltet werden.

Schritte

Get-NetConnectionProfile auf dem Server ausführen — welche Karte trägt welches Profil?
Ergebnis: Die Verwaltungskarte steht auf Öffentlich, weil in ihrem Segment kein Domänencontroller erreichbar ist.
Get-NetFirewallRule -DisplayName '*WinRM*' | Select-Object DisplayName, Enabled, Profile — für welche Profile gilt die Regel?
Ergebnis: nur für Domäne. Auf der öffentlich eingestuften Karte greift sie nicht.
Regel um das öffentliche Profil erweitern und gleichzeitig ihren Adressbereich auf das Verwaltungsnetz einschränken.

Merksatz: Zwei Einstellungen mussten zusammenpassen, und keine der beiden war für sich falsch. Wer stattdessen die Firewall abgeschaltet hätte, hätte den Zugang bekommen — und zwar aus jedem Netz.

Der Verwaltungsweg ist eine privilegierte Oberfläche

PowerShell-Remoting über WinRM ist auf einem Server-Core-System der Hauptzugang. Wer dort hineinkommt, arbeitet mit den Rechten seines Kontos auf dem Server — der Kanal ist damit selbst ein hochwertiges Ziel und keine Nebensache der Netzkonfiguration.

WinRM — Der Dienst, der WS-Management auf Windows umsetzt. Er hört auf einem HTTP- und optional einem HTTPS-Listener und unterstützt laut Dokumentation mehrere Standardverfahren für Authentifizierung und Nachrichtenverschlüsselung.

Kerberos: Voreinstellung, wenn Client und Ziel in einer Domäne sind und das Ziel über seinen Namen angesprochen wird.
Negotiate: Entscheidet zwischen Kerberos und NTLM. Voreinstellung, sobald ausdrückliche Anmeldeinformationen übergeben werden.
Basic: Laut Dokumentation in der Voreinstellung auf Client und Server deaktiviert. Wer sie einschaltet, sollte wissen, warum.

Standardmäßig hört WinRM auf Port 5985 für HTTP und auf 5986 für HTTPS. Diese beiden Zahlen gehören zum Grundwissen, weil sie in jeder Firewallregel und in jedem Verbindungstest auftauchen — und weil ein Verbindungstest gegen Port 5985, der gelingt, bereits die halbe Diagnose erledigt: Der Weg steht, der Dienst lauscht, und was danach scheitert, ist eine Frage der Authentifizierung.

HTTP heißt hier nicht unverschlüsselt

Der WinRM-Listener spricht standardmäßig HTTP, und daraus wird regelmäßig geschlossen, die Verwaltung laufe im Klartext über das Netz. Das ist ein Missverständnis über die Ebene, auf der die Verschlüsselung stattfindet.

Was tatsächlich passiertWinRM verschlüsselt die Nutzlast auf Nachrichtenebene, sobald Kerberos oder Negotiate zum Zug kommen. Der HTTP-Listener transportiert dann bereits verschlüsselte Nachrichten. HTTPS fügt Transportverschlüsselung und ein Serverzertifikat hinzu — der Gewinn liegt vor allem in der Serveridentität, nicht darin, dass vorher nichts verschlüsselt gewesen wäre. Wer HTTPS einführt, sollte das mit dem richtigen Argument tun, sonst wird bei der nächsten Gelegenheit das falsche Problem gelöst.

Wirklich im Klartext wird es dort, wo die Authentifizierung wegfällt: Bei Basic-Authentifizierung über einen HTTP-Listener gehen Anmeldeinformationen ungeschützt über das Netz. Genau deshalb ist Basic in der Voreinstellung auf beiden Seiten abgeschaltet.

Die IP-Adresse, die Kerberos ausschaltet

Ein Detail mit großer Wirkung: Kerberos arbeitet mit Dienstnamen. Wer einen Server über seine IP-Adresse anspricht, kann deshalb keine Kerberos-Authentifizierung bekommen — es gibt keinen Namen, für den ein Ticket ausgestellt werden könnte.

Was daraus folgtDie Dokumentation nennt die Konsequenz direkt: Weicht das Authentifizierungsverfahren von Kerberos ab, oder ist der Client nicht Mitglied der Domäne, muss HTTPS benutzt oder das Ziel in die TrustedHosts-Liste des Clients eingetragen werden. Der Eintrag in TrustedHosts ist dabei kein Komfortschalter, sondern ein Verzicht: Der Client authentifiziert den Server danach nicht mehr. Ein TrustedHosts-Wert von * gibt diese Prüfung für jedes Ziel auf, und die Einstellung gilt laut Doku für alle Benutzer des Rechners.

Praktisch heißt das: Der Griff zur IP-Adresse, weil der Name gerade nicht auflöst, verschiebt die Verbindung stillschweigend auf einen schwächeren Pfad. Wenn der Name nicht auflöst, ist das die Ursache — nicht ein Hindernis, das man umgeht.

RDP und die Frage, wann geprüft wird

Der zweite große Verwaltungsweg ist Remotedesktop. Der entscheidende Schalter dort heißt Authentifizierung auf Netzwerkebene und bestimmt, wann der Server den Benutzer prüft.

Mit Authentifizierung auf Netzwerkebene: Die Anmeldeinformationen werden geprüft, bevor eine Sitzung aufgebaut wird.
Ohne: Der Server baut zuerst eine Sitzung samt Anmeldebildschirm auf und prüft danach.
Der Unterschied: Ohne die Vorprüfung kostet jeder Verbindungsversuch Ressourcen auf dem Server — auch die von jemandem, der gar keine gültigen Anmeldeinformationen hat.

Damit ist die Abschaltung dieser Vorprüfung kein Komfortthema. Sie öffnet einen Weg, auf dem ein Unbefugter ohne jede Anmeldung Arbeit auf dem Server auslöst — und sie wird meistens abgeschaltet, weil ein einzelner alter Client sie nicht beherrscht. Die verhältnismäßige Antwort ist, diesen Client zu ersetzen, nicht die Prüfung für alle aufzugeben.

Für den Betrieb kommt eine zweite Überlegung dazu: Remotedesktop öffnet eine interaktive Sitzung, in der Anmeldeinformationen auf dem Zielserver landen. Wer sich mit einem hoch berechtigten Konto per Remotedesktop auf einem beliebigen Server anmeldet, hinterlässt dort Spuren dieses Kontos. Deshalb ist die Frage, mit welchem Konto man sich wohin verbindet, keine reine Bequemlichkeitsfrage — und deshalb ist PowerShell-Remoting für wiederkehrende Aufgaben nicht nur skalierbarer, sondern auch der zurückhaltendere Weg.

Diagnose folgt der Schichtung

Aus den drei Achsen ergibt sich eine Reihenfolge, in der jeder Schritt den nächsten sinnvoll macht. Sie kostet ein paar Minuten und ersetzt das Raten.

Name, Transport, Listener, Autorisierung — die erste Schicht, die nicht antwortet, ist die Grenze.

Namensauflösung prüfen: Löst der Name auf die erwartete Adresse auf, und von welchem Server kommt die Antwort?→Erreichbarkeit auf den Zielport prüfen, nicht per ICMP.→Auf dem Zielserver prüfen, ob dort tatsächlich etwas auf diesem Port lauscht.→Firewallprofil der beteiligten Karte und die zutreffende Regel lesen — Richtung, Profil, Bereich.→Erst danach die Authentifizierung betrachten: Verfahren, Konto, Anmelderecht.→Das Ergebnis über den Weg prüfen, den die Clients benutzen — Name, Port, Konto.

Schritt 3 trennt „die Firewall blockiert“ von „es lauscht gar nichts“ — zwei Befunde, die vom Client aus identisch aussehen.

Wann man die Reihenfolge verlässtWenn ein starker Verdacht besteht — der Server wurde gerade in ein anderes Segment verschoben, oder eine Firewallregel wurde heute geändert —, ist es vernünftig, dort anzufangen. Der Unterschied ist, dass man diesen Sprung als Abkürzung benennt: Bestätigt er sich nicht, geht es zurück an den Anfang der Kette, statt weiter in derselben Richtung zu raten. Eine Abkürzung, die man nicht als solche kennzeichnet, wird zur neuen Reihenfolge.

Einen Verwaltungsweg freigeben

Einen neuen Zugang zu öffnen ist der Fall, in dem Zeitdruck und Sicherheitsfolgen am weitesten auseinanderliegen. Der Weg ist in fünf Minuten offen und in zwei Jahren immer noch offen.

Die drei Fragen vor der FreigabeErstens: Von wo aus muss der Zugang funktionieren — ein Verwaltungsnetz, ein einzelner Sprungserver, oder wirklich von überall? Zweitens: Für wen — welche Gruppe, und ist sie eng genug? Drittens: Wie lange — ist das ein Dauerzustand oder eine befristete Ausnahme, und wo steht das Ablaufdatum? Eine Freigabe ohne Antwort auf die dritte Frage ist dauerhaft, auch wenn alle Beteiligten etwas anderes annehmen.

Der Preis der Sorgfalt ist ehrlich zu benennen: Ein eng gefasster Zugang bricht, wenn sich das Verwaltungsnetz ändert, und erzeugt dann eine Störung genau dann, wenn jemand dringend auf den Server will. Wer eng freigibt, braucht deshalb einen zweiten, dokumentierten Weg — die Konsole über die Virtualisierung oder die Fernwartungskarte. Ohne diesen zweiten Weg ist die enge Freigabe kein Sicherheitsgewinn, sondern ein Risiko mit anderem Vorzeichen.

Zum Verfahren gehört außerdem, dass die Freigabe dokumentiert entsteht und nicht als Handgriff. Eine Regel, die jemand über die Oberfläche anlegt, unterscheidet sich äußerlich nicht von einer, die aus einem abgestimmten Runbook stammt — beide stehen später gleichberechtigt in derselben Liste. Der Unterschied liegt darin, ob jemand nach zwei Jahren noch sagen kann, wofür sie da war. Regeln, deren Zweck niemand mehr kennt, werden nicht entfernt, weil niemand das Risiko übernehmen will.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität17 Primärquellen · zuletzt geprüft: 2026-09-04