Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Bei der Untersuchung von Paketablageereignissen können Sie das Feld Filter Run-Time ID von Windows-Filterplattformüberwachungen 5157 (WFP) oder verwenden 5152.
Die Filter-ID identifiziert eindeutig den Filter, der den Paketverlust verursacht hat. Die Filter-ID kann in der Ausgabe des WFP-Zustandsdumps durchsucht werden, um die Ablaufverfolgung zu der Firewallregel durchzuführen, aus der der Filter stammt. Die Filter-ID ist jedoch keine zuverlässige Quelle für die Rückverfolgung zum Filter oder zur Regel, da sich die Filter-ID aus vielen Gründen ändern kann, obwohl sich die Regel überhaupt nicht ändert. Die Änderung der ID macht den Diagnoseprozess fehleranfällig und schwierig.
Um Paketlöschereignisse ordnungsgemäß und effizient zu debuggen, benötigen Sie mehr Kontext zum blockierenden Filter, z. B. seinen Ursprung. Die blockierenden Filter können unter den folgenden Filterherkunftn kategorisiert werden:
- Firewallregeln
- Standardmäßige Blockfilter der Firewall
- AppContainer-Loopback
- Startzeit standard
- Quarantänestandard
- Standardeinstellung des Abfragebenutzers
- Heimlichkeit
- standard für Universelle Windows-Plattform (UWP)
- WSH-Standard (Windows Service Hardening, Windows Service Hardening, WSH)
Im nächsten Abschnitt werden die Verbesserungen beschrieben, die an Überwachungen 5157 und 5152 in Windows 11 und Windows Server 2022 vorgenommen wurden, und wie die Filterherkunft in diesen Ereignissen verwendet wird.
Verbesserte Firewallüberwachung
Ab Windows 11 und Windows Server 2022 wurden der Überwachung 5157 und 5152 den Ereignissen zwei neue Felder hinzugefügt: Filterursprung und Schnittstellenindex:
- Das Feld Filterursprung hilft dabei, die Ursache des Abbruchs zu identifizieren. Paketabbrüche aus der Firewall werden explizit durch standardmäßige Blockfilter gelöscht, die vom Windows-Firewalldienst oder einer Firewallregel erstellt werden, die von Benutzern, Richtlinien, Diensten, Apps usw. erstellt werden kann. Filterursprung' gibt entweder die Regel-ID (ein eindeutiger Bezeichner einer Firewallregel) oder den Namen eines der Standardblockfilter an.
- Das Feld Schnittstellenindex gibt die Netzwerkschnittstelle an, in der das Paket verworfen wurde. Dieses Feld hilft bei der Identifizierung, welche Schnittstelle unter Quarantäne gesetzt wurde, wenn der Filterursprung ein Quarantänestandard ist.
Um ein bestimmtes Überwachungsereignis zu aktivieren, führen Sie den entsprechenden Befehl an einer Administratoreingabeaufforderung aus:
| Rechnungsprüfung # | Befehl "Aktivieren" | Link |
|---|---|---|
| 5157 | Auditpol /set /category:"System" /SubCategory:"Filtering Platform Connection" /success:enable /failure:enable |
5157(F): Die Windows-Filterplattform hat eine Verbindung blockiert. |
| 5152 | Auditpol /set /category:"System" /SubCategory:"Filtering Platform Packet Drop" /success:enable /failure:enable |
5152(F): Die Windows-Filterplattform hat ein Paket blockiert. |
Beispielfluss für das Debuggen von Paketabbrüchen mit Filterursprung
Wenn die Überwachung Filterursprung und Schnittstellenindex anzeigt, kann der Netzwerkadministrator die Grundursache des Netzwerkpaketverlusts und die Schnittstelle ermitteln, auf der es aufgetreten ist.
Die nächsten Abschnitte werden durch den Filterursprungtyp geteilt. Der Wert ist entweder ein Regelname oder der Name eines der Standardblockfilter. Wenn der Filterursprung einer der Standardblockfilter ist, fahren Sie mit dem Abschnitt Firewallstandardblockfilter fort.
Firewallregeln
Führen Sie den folgenden PowerShell-Befehl aus, um die Regelinformationen mithilfe von Filter Originzu generieren.
Get-NetFirewallRule -Name "<Filter Origin>"
Get-NetFirewallRule -Name " {A549B7CF-0542-4B67-93F9-EEBCDD584377} "
Nachdem er die Regel identifiziert hat, die den Abbruch verursacht hat, kann der Netzwerkadministrator die Regel ändern oder deaktivieren, um den gewünschten Datenverkehr über eines der verfügbaren Tools zuzulassen. Der Netzwerkadministrator kann die Regel auf der Benutzeroberfläche mit dem DisplayName der Regel finden.
Hinweis
Firewallregeln aus mobilem Geräteverwaltung-Speicher (MDM) können nicht über die Windows-Firewall-Benutzeroberfläche durchsucht werden. Darüber hinaus funktioniert die obige Methode nicht, wenn der Filterursprung einer der Standardblockfilter ist, da sie keinen Firewallregeln entsprechen.
Standardmäßige Blockfilter der Firewall
AppContainer-Loopback
Netzwerklöschereignisse vom Ursprung des AppContainer-Loopbackblockfilters treten auf, wenn das localhost-Loopback für die Universelle Windows-Plattform-App (UWP) nicht ordnungsgemäß aktiviert ist:
- Informationen zum Aktivieren des localhost-Loopbacks in einer lokalen Debugumgebung finden Sie unter Kommunizieren mit localhost.
- Informationen zum Aktivieren des localhost-Loopbacks für eine veröffentlichte App, die Loopbackzugriff für die Kommunikation mit einer anderen UWP- oder gepackten Win32-App erfordert, finden Sie unter uap4:LoopbackAccessRules
Startzeit standard
Netzwerklöschereignisse aus dem Standard-Blockfilterursprung zur Startzeit treten auf, wenn der Computer gestartet wird und der Firewalldienst noch nicht ausgeführt wird. Dienste müssen einen Startzeit-Allow-Filter erstellen, um den Datenverkehr zuzulassen. Beachten Sie, dass es nicht möglich ist, Startzeitfilter über Firewallregeln hinzuzufügen.
Quarantänestandard
Netzwerkverluste aus dem Standardblockfilter der Quarantäne treten auf, wenn die Schnittstelle vom Firewalldienst vorübergehend unter Quarantäne gesetzt wird. Der Firewalldienst isoliert eine Schnittstelle unter Quarantäne, wenn er eine Änderung im Netzwerk erkennt. Basierend auf mehreren anderen Faktoren kann der Firewalldienst die Schnittstelle als Schutzmaßnahme unter Quarantäne stellen. Wenn eine Schnittstelle unter Quarantäne gesetzt wird, blockiert der Standardblockfilter unter Quarantäne alle neuen eingehenden Verbindungen ohne Loopback.
Führen Sie den folgenden PowerShell-Befehl aus, um weitere Informationen zur Schnittstelle zu generieren:
Get-NetIPInterface -InterfaceIndex <Interface Index>
Weitere Informationen zum Quarantänefeature finden Sie unter Quarantäneverhalten.
Hinweis
Quarantänebedingte Paketverknappungen sind häufig vorübergehend und bedeuten nichts anderes als eine Netzwerkänderung an der Schnittstelle.
Standardeinstellung des Abfragebenutzers
Netzwerkpaketverluste von Standardblockfiltern für Abfragebenutzer treten auf, wenn keine explizite Regel erstellt wurde, um eine eingehende Verbindung für das Paket zuzulassen. Wenn eine Anwendung an einen Socket gebunden ist, aber keine entsprechende Eingangsregel zum Zulassen von Paketen an diesem Port aufweist, generiert Windows ein Popupfenster, damit der Benutzer der App den Empfang von Paketen für die verfügbaren Netzwerkkategorien erlaubt oder verweigert. Wenn der Benutzer die Verbindung im Popupfenster verweigert, werden nachfolgende eingehende Pakete an die App gelöscht. So beheben Sie die Abbrüche:
- Erstellen Sie eine Firewallregel für eingehenden Datenverkehr, um das Paket für diese Anwendung zuzulassen. Die Regel ermöglicht es dem Paket, alle Standardblockfilter von Abfragebenutzern zu umgehen.
- Löschen aller Benutzerregeln für Blockabfragen, die möglicherweise automatisch vom Firewalldienst generiert wurden
Um eine Liste aller Abfragebenutzerblockregeln zu generieren, können Sie den folgenden PowerShell-Befehl ausführen:
Get-NetFirewallRule | Where {$_.Name -like "*Query User*"}
Das Popupfeature für Abfragebenutzer ist standardmäßig aktiviert. Um das Abfragebenutzer-Popupfenster zu deaktivieren, können Sie den folgenden Befehl in der administrativen Eingabeaufforderung ausführen:
Netsh set allprofiles inboundusernotification disable
Oder in PowerShell:
Set-NetFirewallProfile -NotifyOnListen False
Heimlichkeit
Netzwerkabbrüche durch Stealth-Filter werden in der Regel durchgeführt, um die Portüberprüfung zu verhindern.
Informationen zum Deaktivieren des Stealth-Modus finden Sie unter Deaktivieren des stealth-Modus in Windows.
UWP-Standard
Netzwerkverluste von Universelle Windows-Plattform (UWP)-Standardblockfiltern für eingehenden/ausgehenden Datenverkehr werden häufig dadurch verursacht, dass die UWP-App nicht ordnungsgemäß konfiguriert ist (d. h. der UWP-App fehlen die richtigen Funktionstoken, oder Loopback ist nicht aktiviert) oder der private Bereich falsch konfiguriert ist.
Weitere Informationen zum Debuggen von Ausfällen, die durch UWP-Standardblockfilter verursacht werden, finden Sie unter Problembehandlung bei UWP-App-Konnektivitätsproblemen.
WSH-Standard
Netzwerkverfalle von WSH-Standardfiltern (Windows Service Hardening) deuten darauf hin, dass es keine explizite Zulassungsregel für die Windows-Diensthärtung gab, um Netzwerkdatenverkehr für den geschützten Dienst zuzulassen. Der Dienstbesitzer muss Zulassungsregeln für den Dienst konfigurieren, wenn der Block nicht erwartet wird.