Résoudre les problèmes d’épuisement des ports

S’applique à : Windows 10

Les protocoles TCP et UDP fonctionnent en fonction des numéros de port utilisés pour établir la connexion. Toute application ou service qui a besoin d’établir une connexion TCP/UDP nécessite un port de son côté.

Il existe deux types de ports :

• Les ports éphémères, qui sont des ports dynamiques, sont l’ensemble de ports que chaque ordinateur devra par défaut établir une connexion sortante.
• Les ports connus sont les ports définis pour une application ou un service particulier. Par exemple, le service de serveur de fichiers est sur le port 445, HTTPS est 443, HTTP est 80 et RPC est 135. Les applications personnalisées auront également leurs propres numéros de port définis.

Lorsqu’une connexion est établie avec une application ou un service, les appareils clients utilisent un port éphémère à partir de l’appareil pour se connecter à un port bien connu défini pour cette application ou ce service. Un navigateur sur un ordinateur client utilise un port éphémère pour se connecter au https://www.microsoft.com port 443.

Dans un scénario où le même navigateur crée de nombreuses connexions à plusieurs sites web, pour toute nouvelle connexion tentée par le navigateur, un port éphémère est utilisé. Après un certain temps, vous remarquerez que les connexions commenceront à échouer et que l’un des risques élevés de cet échec serait que le navigateur a utilisé tous les ports disponibles pour établir des connexions en dehors et que toute nouvelle tentative d’établissement d’une connexion échouera, car il n’y a plus de ports disponibles. Lorsque tous les ports d’une machine sont utilisés, nous l’élisons comme épuisement des ports.

Plage de ports dynamiques par défaut pour TCP/IP

Pour se conformer aux recommandations de l’IANA (Internet Assigned Numbers Authority), Microsoft a augmenté la plage de ports clients dynamiques pour les connexions sortantes. Le nouveau port de début par défaut est 49152 et le nouveau port de fin par défaut est 65535. Cette augmentation est un changement par rapport à la configuration des versions antérieures de Windows qui utilisaient une plage de ports par défaut comprise entre 1025 et 5 000.

Vous pouvez afficher la plage de ports dynamiques sur un ordinateur à l’aide des commandes suivantes 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
  

La plage est définie séparément pour chaque transport (TCP ou UDP). La plage de ports est désormais une plage qui a un point de départ et un point de fin. Les clients Microsoft qui déploient des serveurs exécutant Windows Server peuvent rencontrer des problèmes qui affectent la communication RPC entre les serveurs si des pare-feu sont utilisés sur le réseau interne. Dans ces situations, nous vous recommandons de reconfigurer les pare-feu pour autoriser le trafic entre les serveurs dans la plage de ports dynamiques comprise entre 49152 et 65535. Cette plage s’ajoute aux ports connus utilisés par les services et les applications. Ou bien, la plage de ports utilisée par les serveurs peut être modifiée sur chaque serveur. Vous ajustez cette plage à l’aide de la commande netsh, comme suit. La commande ci-dessus définit la plage de ports dynamiques pour TCP.

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

Le port de début est number et le nombre total de ports est range. Voici des exemples de commandes :

• 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
  

Ces exemples de commandes définissent la plage de ports dynamiques pour qu’elle commence au port 10000 et se termine au port 10999 (1 000 ports). La plage minimale de ports pouvant être définie est de 255. Le port de démarrage minimal qui peut être défini est 1025. Le port de fin maximal (en fonction de la plage configurée) ne peut pas dépasser 65535. Pour dupliquer le comportement par défaut de Windows Server 2003, utilisez 1025 comme port de départ, puis utilisez 3976 comme plage pour TCP et UDP. Ce modèle d’utilisation entraîne un port de début 1025 et un port de fin de 5 000.

Plus précisément, les connexions sortantes en tant que connexions entrantes ne nécessitent pas de port éphémère pour accepter les connexions.

Étant donné que les connexions sortantes commencent à échouer, vous verrez de nombreuses instances des comportements ci-dessous :

• Impossible de se connecter à l’ordinateur avec des informations d’identification de domaine, mais la connexion avec un compte local fonctionne. La connexion au domaine vous oblige à contacter le contrôleur de domaine pour l’authentification, qui est à nouveau une connexion sortante. Si vous avez défini des informations d’identification de cache, la connexion au domaine peut toujours fonctionner.

  

• stratégie de groupe échecs de mise à jour :

  

• Les partages de fichiers sont inaccessibles :

  

• Le protocole RDP à partir du serveur affecté échoue :

  

• Toute autre application en cours d’exécution sur l’ordinateur commence à donner des erreurs

Le redémarrage du serveur résout temporairement le problème, mais vous verrez tous les symptômes revenir après un certain temps.

Si vous pensez que la machine est dans un état d’épuisement des ports :

1. Essayez d’établir une connexion sortante. À partir du serveur/ordinateur, accédez à un partage distant ou essayez un protocole RDP vers un autre serveur ou telnet vers un serveur sur un port. Si la connexion sortante échoue pour toutes ces options, passez à l’étape suivante.

2. Ouvrez l’observateur d’événements et, sous les journaux système, recherchez les événements qui indiquent clairement l’état actuel :

   1. ID d’événement 4227

      

   2. ID d’événement 4231

      

3. Collectez une netstat -anob sortie du serveur. La sortie netstat affiche un grand nombre d’entrées pour TIME_WAIT’état d’un seul PID.

   

   Après une fermeture normale ou une fermeture abrupte d’une session, après une période de 4 minutes (par défaut), le port utilisé par le processus ou l’application est relâché dans le pool disponible. Pendant ces 4 minutes, l’état de la connexion TCP sera TIME_WAIT état. Dans une situation où vous soupçonnez l’épuisement des ports, une application ou un processus ne peut pas libérer tous les ports qu’il a consommés et reste dans l’état TIME_WAIT.

   Vous pouvez également voir CLOSE_WAIT connexions d’état dans la même sortie ; toutefois, CLOSE_WAIT’état est un état lorsqu’un côté de l’homologue TCP n’a plus de données à envoyer (FIN envoyée) mais est en mesure de recevoir des données de l’autre extrémité. Cet état n’indique pas nécessairement l’épuisement des ports.

   Remarque

   Le fait d’avoir d’énormes connexions dans TIME_WAIT’état n’indique pas toujours que le serveur est actuellement hors des ports, sauf si les deux premiers points sont vérifiés. Le fait d’avoir beaucoup de connexions TIME_WAIT indique que le processus crée un grand nombre de connexions TCP et peut éventuellement entraîner un épuisement des ports.

   Netstat a été mis à jour dans Windows 10 avec l’ajout du commutateur pour afficher les -Q ports qui sont passés hors délai d’attente comme dans l’état BOUND. Une mise à jour pour Windows 8.1 et Windows Server 2012 R2 a été publiée qui contient cette fonctionnalité. L’applet de commande Get-NetTCPConnection PowerShell dans Windows 10 affiche également ces ports BOUND.

   Jusqu’au 10/2016, netstat était inexact. Correctifs pour netstat, rétro-portage vers 2012 R2, autorisésNetstat.exe et Get-NetTcpConnection à signaler correctement l’utilisation des ports TCP ou UDP dans Windows Server 2012 R2. Pour en savoir plus, consultez Windows Server 2012 R2 : Correctifs logiciels pour les ports éphémères.

4. Ouvrez une invite de commandes en mode administrateur et exécutez la commande ci-dessous.

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

5. Ouvrez le fichier server.etl avec le Moniteur réseau et dans la section filtre, appliquez le filtre Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209. Vous devriez voir les entrées qui indiquent STATUS_TOO_MANY_ADDRESSES. Si vous ne trouvez aucune entrée, le serveur n’est toujours pas en dehors des ports. Si vous les trouvez, vous pouvez confirmer que le serveur est en état d’épuisement des ports.

Résoudre les problèmes d’épuisement des ports

La clé consiste à identifier le processus ou l’application qui utilise tous les ports. Voici quelques-uns des outils que vous pouvez utiliser pour isoler en un seul processus

Méthode 1

Commencez par examiner la sortie netstat. Si vous utilisez Windows 10 ou Windows Server 2016, vous pouvez exécuter la commande netstat -anobq et case activée pour l’ID de processus dont le nombre maximal d’entrées est BOUND. Vous pouvez également exécuter la commande PowerShell ci-dessous pour identifier le processus :

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 plupart des fuites de port sont dues à des processus en mode utilisateur qui ne ferment pas correctement les ports lorsqu’une erreur s’est produite. Au niveau du mode utilisateur, les ports (en fait des sockets) sont des handles. TaskManager et ProcessExplorer sont en mesure d’afficher les nombres de handles, ce qui vous permet d’identifier le processus qui consomme tous les ports.

Pour Windows 7 et Windows Server 2008 R2, vous pouvez mettre à jour votre version de PowerShell pour inclure l’applet de commande ci-dessus.

Méthode 2

Si la méthode 1 ne vous aide pas à identifier le processus (avant Windows 10 et Windows Server 2012 R2), consultez gestionnaire des tâches :

1. Ajoutez une colonne appelée « handles » sous détails/processus.

2. Triez les handles de colonne pour identifier le processus avec le plus grand nombre de handles. En règle générale, le processus avec des handles supérieurs à 3 000 peut être le coupable, à l’exception des processus tels que System, lsass.exe, store.exe ,sqlsvr.exe.

   

3. Si un autre processus que ces processus a un nombre plus élevé, arrêtez ce processus, puis essayez de vous connecter à l’aide des informations d’identification de domaine et vérifiez s’il réussit.

Méthode 3

Si le Gestionnaire des tâches ne vous a pas aidé à identifier le processus, utilisez process Explorer pour examiner le problème.

Étapes d’utilisation de l’Explorateur de processus :

1. Téléchargez le processus Explorer et exécutez-le avec élévation de privilèges.

2. Alt + sélectionnez l’en-tête de colonne, sélectionnez Choisir des colonnes, puis sous l’onglet Performances du processus , ajoutez Nombre de handles.

3. Sélectionnez Afficher>afficher le volet inférieur.

4. Sélectionnez Afficher les>poignéesd’affichage> du volet inférieur.

5. Sélectionnez la colonne Handles pour trier selon cette valeur.

6. Examinez les processus avec un nombre de handles plus élevé que le reste (sera probablement supérieur à 10 000 si vous ne pouvez pas établir de connexions sortantes).

7. Cliquez pour mettre en surbrillance l’un des processus avec un nombre élevé de handles.

8. Dans le volet inférieur, les descripteurs répertoriés comme ci-dessous sont des sockets. (Les sockets sont techniquement des handles de fichier).

   Fichier \Device\AFD

   

9. Certains sont normaux, mais un grand nombre d’entre eux ne le sont pas (des centaines à des milliers). Fermez le processus en question. Si cela restaure la connectivité sortante, vous avez prouvé que l’application en est la cause. Contactez le fournisseur de cette application.

Enfin, si les méthodes ci-dessus ne vous ont pas aidé à isoler le processus, nous vous suggérons de collecter une image mémoire complète de l’ordinateur dans l’état du problème. Le vidage vous indique quel processus a le nombre maximal de handles.

En guise de solution de contournement, le redémarrage de l’ordinateur rétablit son état normal et vous aidera à résoudre le problème pour le moment. Toutefois, quand un redémarrage n’est pas pratique, vous pouvez également envisager d’augmenter le nombre de ports sur l’ordinateur à l’aide des commandes ci-dessous :

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

Cette commande définit la plage de ports dynamique pour qu’elle commence au port 10000 et se termine au port 10999 (1000 ports). La plage minimale de ports pouvant être définie est de 255. Le port de démarrage minimal qui peut être défini est 1025. Le port de fin maximal (en fonction de la plage configurée) ne peut pas dépasser 65535.

Pour Windows 7 et Windows Server 2008 R2, vous pouvez utiliser le script ci-dessous pour collecter la sortie netstat à une fréquence définie. Dans les sorties, vous pouvez voir la tendance d’utilisation des ports.

@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

Plus d’informations

• L’épuisement des ports et vous ! - Cet article fournit des détails sur les états netstat et la façon dont vous pouvez utiliser la sortie netstat pour déterminer le port status
• Détection de l’épuisement des ports éphémères : cet article contient un script qui s’exécute dans une boucle pour signaler le port status. (Applicable à Windows 2012 R2, Windows 8, Windows 10 et Windows 11)