Felsöka problem med brist på portar

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 en tjänst 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å 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 några fler tillgängliga portar. När alla portar på en dator används benämner vi det som portöverbelastning.

Standardintervall för dynamiska portar 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 ett standardportintervall på 1025 till 5000.

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 med 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 portintervall som kan anges är 255. Den minsta startport som kan anges är 1 025. Den maximala slutporten (baserat på det intervall 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 beteendet nedan:

• Det går inte att logga in på datorn med domänautentiseringsuppgifter, men inloggning med ett 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.

  

• Uppdateringsfel för grupprincip:

  

• Det går inte att komma åt filresurserna:

  

• 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 symtom kommer tillbaka efter en viss tid.

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

1. Prova att upprätta en utgående anslutning. Från servern/datorn kan du komma åt en fjärrresurs 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.

2. Öppna loggboken och under systemloggarna letar du efter de händelser som tydligt anger aktuellt tillstånd:

   1. Händelse-ID 4227

      

   2. Händelse-ID 4231

      

3. 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 respitfull 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 de här fyra minuterna är TCP-anslutningstillståndet TIME_WAIT. I en situation där du misstänker portöverbelastning kommer ett program eller en process inte att kunna släppa alla portar som det 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-peern 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.

   Kommentar

   Att ha stora anslutningar i TIME_WAIT tillstånd tyder inte alltid på att servern för närvarande är slut på portar om inte de två första punkterna verifieras. Att ha många TIME_WAIT-anslutningar tyder på att processen skapar många TCP-anslutningar, vilket så småningom kan leda till en 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 bound-tillståndet. En uppdatering av Windows 8.1 och Windows Server 2012 R2 har släppts med den här funktionen. PowerShell-cmdleten Get-NetTCPConnection i Windows 10 visar även dessa BOUND-portar.

   Fram till oktober 2016 var netstat felaktig. Korrigeringar för netstat, bakåtporterade 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 Snabbkorrigeringar för Windows Server 2012 R2: Tillfälliga portar .

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

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

5. Ö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 kontrollera om servern är utsatt för portöverbelastning.

Felsöka portöverbelastning

Det viktiga är att ta reda på vilken process eller vilket program som använder alla portarna. 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-utdatan. 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. Du kan 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 användarlägesprocesserna inte stängde portarna när ett fel uppstod. På användarlägesnivå är portar (faktiskt sockets) handtag. Både TaskManager och ProcessExplorer kan visa antal handtag, vilket gör att du kan identifiera vilken process som förbrukar alla portar.

I Windows 7 och Windows Server 2008 R2 kan du uppdatera PowerShell-versionen så att den inkluderar cmdleten ovan.

Metod 2

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

1. Lägg till en kolumn med namnet "referenser" under information/processer.

2. Sortera kolumnhandtagen för att hitta processen med det högsta antalet handtag. 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.

   

3. 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 Process Explorer för att undersöka problemet.

Steg för att använda Processutforskaren:

1. Ladda ned Process Explorer och kör den Upphöjd.

2. Alt + välj kolumnrubriken, välj Välj kolumner och lägg till Antal handtag på fliken Processprestanda.

3. Välj Visa>visa nedre fönsterruta.

4. Välj Visa>handtag för vy i>nedre fönstret.

5. Välj kolumnen Referenser för att sortera efter det värdet.

6. Granska processerna med högre antal än resten (troligen över 10 000 om du inte kan göra utgående anslutningar).

7. Klicka för att markera en av processerna med ett högt antal handtag.

8. I den nedre rutan är handtagen som anges nedan sockets. (Sockets är tekniskt sett filhandtag).

   Fil\Enhet\AFD

   

9. Vissa är normala, men ett stort antal av dem är inte (hundratals till tusentals). Stäng processen. 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 flest handtag.

Som en lösning kommer omstarten av datorn att få tillbaka den i normalt tillstånd och hjälper dig att lösa problemet tills vidare. När det är opraktiskt med en omstart kan du dock ö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 portintervall som kan anges är 255. Den minsta startport som kan anges är 1 025. Den maximala slutporten (baserat på det intervall som konfigureras) får inte överstiga 65535.

Kommentar

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 portstatusen
• 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)