Felsöka problem med portöverbelastning

Artikel
12/26/2023

Gäller för: Windows 10

TCP- och UDP-protokoll fungerar baserat på portnummer som används för att upprätta anslutningen. Alla program eller tjänster som behöver upprätta en TCP/UDP-anslutning kräver en port på dess sida.

Det finns två typer av portar:

Tillfälliga portar, som är dynamiska portar, är den uppsättning portar som varje dator som standard måste upprätta en utgående anslutning.
Välkända portar är de definierade portarna för ett visst program eller en viss tjänst. Filservertjänsten finns till exempel på port 445, HTTPS är 443, HTTP är 80 och RPC är 135. Anpassade program har också sina egna definierade portnummer.

När en anslutning upprättas med ett program eller en tjänst använder klientenheter en tillfällig port från enheten för att ansluta till en välkänd port som definierats för programmet eller tjänsten. En webbläsare på en klientdator använder en tillfällig port för att ansluta till https://www.microsoft.com på port 443.

I ett scenario där samma webbläsare skapar många anslutningar till flera webbplatser används en tillfällig port för alla nya anslutningar som webbläsaren försöker använda. Efter en tid kommer du att märka att anslutningarna börjar misslyckas och en stor risk för det här felet är att webbläsaren har använt alla tillgängliga portar för att göra anslutningar utanför och alla nya försök att upprätta en anslutning misslyckas eftersom det inte finns fler tillgängliga portar. När alla portar på en dator används kallas det portöverbelastning.

Standardintervall för dynamisk port för TCP/IP

För att uppfylla IANA-rekommendationerna (Internet Assigned Numbers Authority) har Microsoft ökat det dynamiska klientportintervallet för utgående anslutningar. Den nya standardstartporten är 49152 och den nya standardslutporten är 65535. Den här ökningen är en ändring från konfigurationen av tidigare versioner av Windows som använde standardportintervallet 1025 till 5 000.

Du kan visa det dynamiska portintervallet på en dator med hjälp av följande netsh kommandon:

```
netsh int ipv4 show dynamicport tcp
```
```
netsh int ipv4 show dynamicport udp
```
```
netsh int ipv6 show dynamicport tcp
```
```
netsh int ipv6 show dynamicport udp
```

Intervallet anges separat för varje transport (TCP eller UDP). Portintervallet är nu ett intervall som har en startpunkt och en slutpunkt. Microsoft-kunder som distribuerar servrar som kör Windows Server kan ha problem som påverkar RPC-kommunikationen mellan servrar om brandväggar används i det interna nätverket. I dessa situationer rekommenderar vi att du konfigurerar om brandväggarna för att tillåta trafik mellan servrar i det dynamiska portintervallet 49152 till 65535. Det här intervallet är utöver välkända portar som används av tjänster och program. Eller så kan portintervallet som används av servrarna ändras på varje server. Du justerar det här intervallet med hjälp av netsh-kommandot enligt följande. Kommandot ovan anger det dynamiska portintervallet för TCP.

netsh int <ipv4|ipv6> set dynamic <tcp|udp> start=number num=range

Startporten är tal och det totala antalet portar är intervall. Följande är exempelkommandon:

netsh int ipv4 set dynamicport tcp start=10000 num=1000

netsh int ipv4 set dynamicport udp start=10000 num=1000

netsh int ipv6 set dynamicport tcp start=10000 num=1000

netsh int ipv6 set dynamicport udp start=10000 num=1000

Dessa exempelkommandon anger att det dynamiska portintervallet ska starta vid port 10000 och att sluta vid port 10999 (1 000 portar). Det minsta portintervallet som kan anges är 255. Den minsta startport som kan anges är 1025. Den maximala slutporten (baserat på intervallet som konfigureras) får inte överstiga 65535. Om du vill duplicera standardbeteendet för Windows Server 2003 använder du 1025 som startport och använder sedan 3976 som intervall för både TCP och UDP. Det här användningsmönstret resulterar i en startport på 1025 och en slutport på 5 000.

Mer specifikt kräver inte utgående anslutningar som inkommande anslutningar någon tillfällig port för att acceptera anslutningar.

Eftersom utgående anslutningar börjar misslyckas visas många instanser av beteendena nedan:

Det går inte att logga in på datorn med domänautentiseringsuppgifter, men inloggning med lokalt konto fungerar. Domäninloggning kräver att du kontaktar domänkontrollanten för autentisering, vilket återigen är en utgående anslutning. Om du har angett cacheautentiseringsuppgifter kan domäninloggning fortfarande fungera.
grupprincip uppdateringsfel:
Filresurser är inte tillgängliga:
RDP från den berörda servern misslyckas:
Alla andra program som körs på datorn börjar ge ut fel

Omstart av servern löser problemet tillfälligt, men du ser att alla symptom kommer tillbaka efter en viss tid.

Om du misstänker att datorn är i ett tillstånd av portöverbelastning:

Prova att upprätta en utgående anslutning. Gå till en fjärrresurs från servern/datorn eller prova en RDP till en annan server eller telnet till en server på en port. Om den utgående anslutningen misslyckas för alla dessa alternativ går du till nästa steg.
Öppna loggboken och leta efter de händelser som tydligt anger aktuellt tillstånd under systemloggarna:
1. Händelse-ID 4227
2. Händelse-ID 4231
Samla in utdata netstat -anob från servern. Netstat-utdata visar ett stort antal poster för TIME_WAIT tillstånd för en enda PID.

Efter en korrekt stängning eller en plötslig stängning av en session efter en period på 4 minuter (standard) kommer porten som används av processen eller programmet att släppas tillbaka till den tillgängliga poolen. Under dessa 4 minuter är TCP-anslutningstillståndet TIME_WAIT tillstånd. I en situation där du misstänker portöverbelastning kan ett program eller en process inte släppa alla portar som den har förbrukat och förblir i TIME_WAIT tillstånd.

Du kan också se CLOSE_WAIT tillståndsanslutningar i samma utdata. men CLOSE_WAIT tillstånd är ett tillstånd när ena sidan av TCP-peer inte har fler data att skicka (FIN skickat) men kan ta emot data från den andra änden. Det här tillståndet indikerar inte nödvändigtvis portöverbelastning.

Obs!

Att ha stora anslutningar i TIME_WAIT tillstånd indikerar inte alltid att servern för närvarande har slut på portar om inte de två första punkterna har verifierats. Att ha många TIME_WAIT anslutningar indikerar att processen skapar många TCP-anslutningar och så småningom kan leda till portöverbelastning.

Netstat har uppdaterats i Windows 10 med tillägget av växeln -Q för att visa portar som har övergått i väntetid som i tillståndet BIND. En uppdatering för Windows 8.1 och Windows Server 2012 R2 har släppts som innehåller den här funktionen. PowerShell-cmdleten Get-NetTCPConnection i Windows 10 visar även dessa BUNDNA portar.

Fram till den 10/2016 var netstat felaktig. Korrigeringar för netstat, bakåtporterad till 2012 R2, tillåtna Netstat.exe och Get-NetTcpConnection korrekt rapportera TCP- eller UDP-portanvändning i Windows Server 2012 R2. Mer information finns i Windows Server 2012 R2: Snabbkorrigeringar för tillfälliga portar.

Öppna en kommandotolk i administratörsläge och kör kommandot nedan.

Netsh trace start scenario=netconnection capture=yes tracefile=c:\Server.etl

Öppna filen server.etl med Network Monitor och använd filtret Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209i filteravsnittet . Du bör se poster som säger STATUS_TOO_MANY_ADDRESSES. Om du inte hittar några poster är servern fortfarande inte ute från portarna. Om du hittar dem kan du bekräfta att servern är portöverbelastning.

Felsöka portöverbelastning

Nyckeln är att identifiera vilken process eller vilket program som använder alla portar. Nedan visas några av de verktyg som du kan använda för att isolera till en enda process

Metod 1

Börja med att titta på netstat-utdata. Om du använder Windows 10 eller Windows Server 2016 kan du köra kommandot netstat -anobq och söka efter det process-ID som har maximalt antal poster som BOUND. Alternativt kan du också köra powershell-kommandot nedan för att identifiera processen:

Get-NetTCPConnection | Group-Object -Property State, OwningProcess | Select -Property Count, Name, @{Name="ProcessName";Expression={(Get-Process -PID ($_.Name.Split(',')[-1].Trim(' '))).Name}}, Group | Sort Count -Descending

De flesta portläckor orsakas av att processer i användarläge inte stänger portarna korrekt när ett fel påträffades. På användarlägesnivå är portar (faktiskt socketar) handtag. Både TaskManager och ProcessExplorer kan visa antal handtag, vilket gör att du kan identifiera vilken process som använder alla portar.

För Windows 7 och Windows Server 2008 R2 kan du uppdatera PowerShell-versionen så att den innehåller ovanstående cmdlet.

Metod 2

Om metod 1 inte hjälper dig att identifiera processen (före Windows 10 och Windows Server 2012 R2) kan du ta en titt på Aktivitetshanteraren:

Lägg till en kolumn med namnet "handles" under information/processer.
Sortera kolumnreferenserna för att identifiera processen med det högsta antalet referenser. Vanligtvis kan processen med handtag som är större än 3000 vara den skyldige förutom processer som System, lsass.exe, store.exe, sqlsvr.exe.
Om någon annan process än dessa processer har ett högre antal stoppar du den processen och försöker sedan logga in med domänautentiseringsuppgifter och se om den lyckas.

Metod 3

Om Aktivitetshanteraren inte hjälpte dig att identifiera processen använder du ProcessUtforskaren för att undersöka problemet.

Steg för att använda Processutforskaren:

Ladda ned Process Explorer och kör det Förhöjt.
Alt + välj kolumnrubriken, välj Välj kolumner och lägg till Antal handtag på fliken Processprestanda.
Välj Visa>Visa nedre fönsterruta.
Välj Visa>handtag förvy i nedre fönstret>.
Välj kolumnen Referenser för att sortera efter det värdet.
Granska processerna med högre antal handtag än resten (sannolikt över 10 000 om du inte kan upprätta utgående anslutningar).
Klicka här om du vill markera en av processerna med ett högt antal referenser.
I den nedre rutan är handtagen som anges nedan socketar. (Sockets är tekniskt filhandtag).

Fil \Device\AFD
Vissa är normala, men ett stort antal av dem är inte (hundratusentals). Stäng processen i fråga. Om det återställer utgående anslutning har du ytterligare bevisat att appen är orsaken. Kontakta leverantören av appen.

Om metoderna ovan inte hjälpte dig att isolera processen föreslår vi att du samlar in en fullständig minnesdump av datorn i problemtillståndet. Dumpen visar vilken process som har maximalt antal referenser.

Som en tillfällig lösning kommer omstarten av datorn att få tillbaka den i normalt tillstånd och hjälpa dig att lösa problemet tills vidare. Men när en omstart är opraktisk kan du också överväga att öka antalet portar på datorn med hjälp av kommandona nedan:

netsh int ipv4 set dynamicport tcp start=10000 num=1000

Det här kommandot anger att det dynamiska portintervallet ska starta vid port 10000 och avslutas vid port 10999 (1 000 portar). Det minsta portintervallet som kan anges är 255. Den minsta startport som kan anges är 1025. Den maximala slutporten (baserat på intervallet som konfigureras) får inte överstiga 65535.

Obs!

Observera att en ökning av det dynamiska portintervallet inte är en permanent lösning utan bara tillfällig. Du måste spåra vilken process/processor som förbrukar maximalt antal portar och felsöka från den processsynpunkten om varför den förbrukar så många portar.

För Windows 7 och Windows Server 2008 R2 kan du använda skriptet nedan för att samla in netstat-utdata med definierad frekvens. Från utdata kan du se trenden för portanvändning.

@ECHO ON
set v=%1
:loop
set /a v+=1
ECHO %date% %time% >> netstat.txt
netstat -ano >> netstat.txt
 
PING 1.1.1.1 -n 1 -w 60000 >NUL
 
goto loop

Mer information

Portöverbelastning och du! – den här artikeln ger en detaljerad information om netstat-tillstånd och hur du kan använda netstat-utdata för att fastställa portstatus
Identifiera tillfällig portöverbelastning: Den här artikeln har ett skript som körs i en loop för att rapportera portstatusen. (Gäller för Windows 2012 R2, Windows 8, Windows 10 och Windows 11)