Risolvere i problemi di esaurimento delle porte

Si applica a: Windows 10

I protocolli TCP e UDP funzionano in base ai numeri di porta usati per stabilire la connessione. Qualsiasi applicazione o servizio che deve stabilire una connessione TCP/UDP richiederà una porta sul lato.

Esistono due tipi di porte:

  • Le porte temporanee, che sono porte dinamiche, sono il set di porte che ogni computer dovrà per impostazione predefinita stabilire una connessione in uscita.
  • Le porte note sono le porte definite per un'applicazione o un servizio specifico. Ad esempio, il servizio file server si trova sulla porta 445, HTTPS è 443, HTTP è 80 e RPC è 135. Le applicazioni personalizzate avranno anche i propri numeri di porta definiti.

Quando viene stabilita una connessione con un'applicazione o un servizio, i dispositivi client usano una porta temporanea dal dispositivo per connettersi a una porta nota definita per tale applicazione o servizio. Un browser in un computer client userà una porta temporanea a cui connettersi https://www.microsoft.com sulla porta 443.

In uno scenario in cui lo stesso browser crea molte connessioni a più siti Web, per qualsiasi nuova connessione che il browser sta tentando, viene usata una porta temporanea. Dopo un certo periodo di tempo, si noterà che le connessioni inizieranno a non riuscire e una possibilità elevata per questo errore è dovuta al fatto che il browser ha usato tutte le porte disponibili per stabilire connessioni all'esterno e qualsiasi nuovo tentativo di stabilire una connessione avrà esito negativo in quanto non sono disponibili altre porte. Quando vengono usate tutte le porte di un computer, viene definito esaurimento delle porte.

Intervallo di porte dinamiche predefinito per TCP/IP

Per rispettare le raccomandazioni IANA (Internet Assigned Numbers Authority), Microsoft ha aumentato l'intervallo di porte client dinamiche per le connessioni in uscita. La nuova porta di avvio predefinita è 49152 e la nuova porta finale predefinita è 65535. Questo aumento è una modifica rispetto alla configurazione delle versioni precedenti di Windows che usavano un intervallo di porte predefinito compreso tra 1025 e 5000.

È possibile visualizzare l'intervallo di porte dinamiche in un computer usando i comandi seguenti netsh :

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

L'intervallo viene impostato separatamente per ogni trasporto (TCP o UDP). L'intervallo di porte è ora un intervallo con un punto iniziale e un punto finale. I clienti Microsoft che distribuiscono server che eseguono Windows Server possono avere problemi che influiscono sulla comunicazione RPC tra server se i firewall vengono usati nella rete interna. In queste situazioni è consigliabile riconfigurare i firewall per consentire il traffico tra i server nell'intervallo di porte dinamiche compreso tra 49152 e 65535. Questo intervallo si aggiunge alle porte note usate da servizi e applicazioni. In alternativa, l'intervallo di porte utilizzato dai server può essere modificato in ogni server. È possibile modificare questo intervallo usando il comando netsh, come indicato di seguito. Il comando precedente imposta l'intervallo di porte dinamiche per TCP.

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

La porta iniziale è il numero e il numero totale di porte è compreso nell'intervallo. Di seguito sono riportati i comandi di esempio:

  • 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
    

Questi comandi di esempio impostano l'intervallo di porte dinamico in modo che inizi dalla porta 10000 e termini alla porta 10999 (1000 porte). L'intervallo minimo di porte che è possibile impostare è 255. La porta di avvio minima che può essere impostata è 1025. La porta finale massima (in base all'intervallo configurato) non può superare 65535. Per duplicare il comportamento predefinito di Windows Server 2003, usare 1025 come porta di avvio e quindi usare 3976 come intervallo per TCP e UDP. Questo modello di utilizzo genera una porta di avvio 1025 e una porta finale di 5000.

In particolare, per le connessioni in uscita perché le connessioni in ingresso non richiedono una porta temporanea per accettare le connessioni.

Poiché le connessioni in uscita iniziano a non riuscire, verranno visualizzate molte istanze dei comportamenti seguenti:

  • Non è possibile accedere al computer con credenziali di dominio, tuttavia l'accesso con l'account locale funziona. L'accesso al dominio richiederà di contattare il controller di dominio per l'autenticazione, che è di nuovo una connessione in uscita. Se sono state impostate le credenziali della cache, l'accesso al dominio potrebbe comunque funzionare.

    Screenshot dell'errore per NETLOGON in Visualizzatore eventi.

  • Criteri di gruppo errori di aggiornamento:

    Screenshot delle proprietà dell'evento per Criteri di gruppo errore.

  • Le condivisioni file non sono accessibili:

    Screenshot del messaggio di errore a cui Windows non può accedere.

  • Errore di RDP dal server interessato:

    Screenshot dell'errore quando Desktop remoto non è in grado di connettersi.

  • Qualsiasi altra applicazione in esecuzione nel computer inizierà a fornire errori

Il riavvio del server risolverà temporaneamente il problema, ma tutti i sintomi verranno visualizzati dopo un periodo di tempo.

Se si sospetta che il computer si trova in uno stato di esaurimento delle porte:

  1. Provare a creare una connessione in uscita. Dal server/computer accedere a una condivisione remota o provare un RDP a un altro server o telnet a un server su una porta. Se la connessione in uscita non riesce per tutte queste opzioni, passare al passaggio successivo.

  2. Aprire il Visualizzatore eventi e nei log di sistema cercare gli eventi che indicano chiaramente lo stato corrente:

    1. ID evento 4227

      Screenshot dell'ID evento 4227 in Visualizzatore eventi.

    2. ID evento 4231

      Screenshot dell'ID evento 4231 in Visualizzatore eventi.

  3. Raccogliere un netstat -anob output dal server. L'output netstat mostrerà un numero enorme di voci per TIME_WAIT stato per un singolo PID.

    Screenshot dell'output del comando netstate.

    Dopo una chiusura normale o una chiusura improvvisa di una sessione, dopo un periodo di 4 minuti (impostazione predefinita), la porta usata dal processo o dall'applicazione verrà rilasciata di nuovo nel pool disponibile. Durante questi 4 minuti, lo stato di connessione TCP sarà TIME_WAIT stato. In una situazione in cui si sospetta l'esaurimento delle porte, un'applicazione o un processo non sarà in grado di rilasciare tutte le porte utilizzate e rimarrà nello stato TIME_WAIT.

    È anche possibile che nello stesso output vengano visualizzate connessioni CLOSE_WAIT stato. tuttavia, CLOSE_WAIT stato è uno stato quando un lato del peer TCP non ha più dati da inviare (FIN inviato), ma è in grado di ricevere dati dall'altra estremità. Questo stato non indica necessariamente l'esaurimento delle porte.

    Nota

    La presenza di connessioni enormi in TIME_WAIT stato non indica sempre che il server è attualmente fuori dalle porte a meno che non vengano verificati i primi due punti. La presenza di molte connessioni TIME_WAIT indica che il processo sta creando molte connessioni TCP e potrebbe causare l'esaurimento delle porte.

    Netstat è stato aggiornato in Windows 10 con l'aggiunta del -Q commutatore per visualizzare le porte che hanno superato il tempo di attesa come nello stato BOUND. È stato rilasciato un aggiornamento per Windows 8.1 e Windows Server 2012 R2 che contiene questa funzionalità. Il cmdlet di Get-NetTCPConnection PowerShell in Windows 10 mostra anche queste porte BOUND.

    Fino al 10/2016 netstat non era accurato. Correzioni per netstat, con back-porting in 2012 R2, consentiteNetstat.exe e Get-NetTcpConnection per segnalare correttamente l'utilizzo delle porte TCP o UDP in Windows Server 2012 R2. Per altre informazioni, vedere Windows Server 2012 R2: Hotfix delle porte temporanee.

  4. Aprire un prompt dei comandi in modalità amministratore ed eseguire il comando seguente.

    Netsh trace start scenario=netconnection capture=yes tracefile=c:\Server.etl
    
  5. Aprire il file server.etl con Monitoraggio rete e nella sezione filtro applicare il filtro Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209. Verranno visualizzate voci che dicono STATUS_TOO_MANY_ADDRESSES. Se non si trovano voci, il server non è ancora fuori dalle porte. Se vengono trovate, è possibile verificare che il server sia in esaurimento delle porte.

Risolvere i problemi di esaurimento delle porte

La chiave consiste nell'identificare il processo o l'applicazione che usa tutte le porte. Di seguito sono riportati alcuni degli strumenti che è possibile usare per isolare un singolo processo

Metodo 1

Per iniziare, esaminare l'output netstat. Se si usa Windows 10 o Windows Server 2016, è possibile eseguire il comando netstat -anobq e verificare la presenza dell'ID processo con il numero massimo di voci come BOUND. In alternativa, è anche possibile eseguire il comando di PowerShell seguente per identificare il processo:

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 

La maggior parte delle perdite di porte è causata da processi in modalità utente che non chiudono correttamente le porte quando si è verificato un errore. A livello di modalità utente, le porte (in realtà socket) sono handle. Sia TaskManager che ProcessExplorer sono in grado di visualizzare i conteggi degli handle, consentendo di identificare il processo che utilizza tutte le porte.

Per Windows 7 e Windows Server 2008 R2, è possibile aggiornare la versione di PowerShell per includere il cmdlet precedente.

Metodo 2

Se il metodo 1 non consente di identificare il processo (prima di Windows 10 e Windows Server 2012 R2), vedere Gestione attività:

  1. Aggiungere una colonna denominata "handle" in dettagli/processi.

  2. Ordinare gli handle di colonna per identificare il processo con il numero massimo di handle. In genere il processo con handle maggiori di 3000 può essere il responsabile, ad eccezione di processi come System, lsass.exe, store.exe, sqlsvr.exe.

    Screenshot della colonna handle in Gestione attività Windows.

  3. Se un processo diverso da questi processi ha un numero superiore, arrestare tale processo e quindi provare ad accedere usando le credenziali di dominio e verificare se ha esito positivo.

Metodo 3

Se Gestione attività non ha aiutato a identificare il processo, usare Esplora processi per analizzare il problema.

Procedura per usare Esplora processi:

  1. Scaricare Esplora processi ed eseguirlo con privilegi elevati.

  2. ALT + selezionare l'intestazione di colonna, selezionare Scegli colonne e nella scheda Prestazioni processo aggiungere Conteggio handle.

  3. Selezionare Visualizza>mostra riquadro inferiore.

  4. Selezionare Visualizza>handlevisualizzazione> riquadro inferiore.

  5. Selezionare la colonna Handle per eseguire l'ordinamento in base a tale valore.

  6. Esaminare i processi con un numero di handle più elevato rispetto al resto (probabilmente sarà superiore a 10.000 se non è possibile stabilire connessioni in uscita).

  7. Fare clic per evidenziare uno dei processi con un numero elevato di handle.

  8. Nel riquadro inferiore, gli handle elencati di seguito sono socket. (I socket sono tecnicamente handle di file).

    File \Device\AFD

    Screenshot di Process Explorer con i processi ordinati per handle.

  9. Alcuni sono normali, ma un numero elevato di loro non lo sono (da centinaia a migliaia). Chiudere il processo in questione. Se viene ripristinata la connettività in uscita, si è ulteriormente dimostrato che l'app è la causa. Contattare il fornitore dell'app.

Infine, se i metodi precedenti non consentono di isolare il processo, è consigliabile raccogliere un dump completo della memoria del computer nello stato del problema. Il dump indicherà quale processo ha gli handle massimi.

Come soluzione alternativa, il riavvio del computer lo otterrà di nuovo nello stato normale e ti aiuterà a risolvere il problema per il momento. Tuttavia, quando un riavvio non è pratico, è anche possibile prendere in considerazione l'aumento del numero di porte nel computer usando i comandi seguenti:

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

Questo comando imposterà l'intervallo di porte dinamico in modo che inizi dalla porta 10000 e termini alla porta 10999 (1000 porte). L'intervallo minimo di porte che è possibile impostare è 255. La porta di avvio minima che può essere impostata è 1025. La porta finale massima (in base all'intervallo configurato) non può superare 65535.

Nota

Si noti che l'aumento dell'intervallo di porte dinamiche non è una soluzione permanente, ma solo temporanea. Sarà necessario individuare il processo o i processori che utilizzano il numero massimo di porte e risolvere i problemi dal punto di vista del processo in relazione al motivo per cui sta consumando un numero così elevato di porte.

Per Windows 7 e Windows Server 2008 R2, è possibile usare lo script seguente per raccogliere l'output netstat a una frequenza definita. Dagli output è possibile visualizzare la tendenza di utilizzo delle porte.

@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

Ulteriori informazioni

  • Esaurimento porta e tu! - Questo articolo fornisce informazioni dettagliate sugli stati netstat e su come usare l'output netstat per determinare lo stato della porta
  • Rilevamento dell'esaurimento temporaneo delle porte: questo articolo include uno script che verrà eseguito in un ciclo per segnalare lo stato della porta. (Applicabile per Windows 2012 R2, Windows 8, Windows 10 e Windows 11)