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

S’applique à : Windows 10

Les protocoles TCP et UDP fonctionnent en fonction des numéros de port utilisés pour établir une connexion. Toute application ou service qui doit établir une connexion TCP/UDP nécessite un port 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 doit 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 se trouve sur le port 445, HTTPS sur le port 443, HTTP sur le port 80 et RPC sur le port 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 de l’appareil pour se connecter à un port connu défini pour cette application ou ce service. Un navigateur sur une machine cliente 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 que le navigateur tente, un port éphémère est utilisé. Après un certain temps, vous remarquerez que les connexions commencent à échouer et une possibilité élevée pour cet échec est que le navigateur a utilisé tous les ports disponibles pour établir des connexions en dehors et 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’utilisent 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 client dynamique pour les connexions sortantes. Le nouveau port de démarrage par défaut est le port 49152 et le nouveau port de fin par défaut est le port 65535. Cette augmentation est une modification de la configuration des versions antérieures de Windows qui utilisaient une plage de ports par défaut de 1025 à 5000.

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 maintenant une plage qui a un point de départ et un point d’arrivée. 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 de 49152 à 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 numérique et le nombre total de ports est de plage. 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 démarrer au port 10000 et se terminer au port 10999 (1 000 ports). La plage de ports minimale pouvant être définie s’élève à 255. Le port de démarrage minimal pouvant être défini est le port 1025. Le port final maximal (basé sur 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émarrage, puis utilisez 3976 comme plage pour TCP et UDP. Ce modèle d’utilisation entraîne un port de début de 1025 et un port de fin de 5 000.

Plus précisément, concernant les connexions sortantes, car les 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, alors qu’une 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.

  

• Échecs de mise à jour d’une stratégie de groupe :

  

• Les partages de fichiers sont inaccessibles :

  

• Le protocole RDP du serveur concerné échoue :

  

• Toute autre application s’exécutant sur l’ordinateur commence à signaler des erreurs

Le redémarrage du serveur résout temporairement le problème, mais vous verrez tous les symptômes revenir après une période de 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 à partir du serveur. La sortie netstat vous montre 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 renvoyé au pool disponible. Pendant ces 4 minutes, l’état de la connexion TCP est TIME_WAIT. Dans un cas où vous soupçonnez l’épuisement des ports, une application ou un processus ne pourra pas libérer tous les ports qu’il a consommés et restera 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 peut recevoir des données de l’autre extrémité. Cet état n’indique pas nécessairement l’épuisement des ports.

   Note

   La présence de connexions énormes 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. En revanche, un nombre élevé de connexions TIME_WAIT indique que le processus crée beaucoup de connexions TCP, ce qui peut finir par mener à un épuisement des ports.

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

   Jusqu’en octobre 2016, netstat n’était pas correct. Correctifs pour netstat, back-ported vers 2012 R2, autorisés Netstat.exe et Get-NetTcpConnection pour signaler correctement l’utilisation du port TCP ou UDP dans Windows Server 2012 R2. Pour en savoir plus, consultez Windows Server 2012 R2 : correctifs logiciels de 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 Moniteur réseau et dans la section filtre, appliquez le filtre Wscore_MicrosoftWindowsWinsockAFD.AFD_EVENT_BIND.Status.LENTStatus.Code == 0x209. Vous devez voir des entrées qui disent STATUS_TOO_MANY_ADDRESSES. Si vous ne trouvez aucune entrée, le serveur n’est toujours pas hors ports. Si vous en trouvez, vous pouvez alors confirmer que le serveur subit un épuisement des ports.

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

Le principe consiste à identifier le processus ou l’application qui utilise tous les ports. Voici quelques-uns des outils que vous pouvez utiliser pour isoler un processus unique.

Méthode 1

Commencez par examiner la sortie de netstat. Si vous utilisez Windows 10 ou Windows Server 2016, vous pouvez exécuter la commande netstat -anobq et rechercher l’ID de processus qui contient le nombre maximal d’entrées limitées. 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 causées par des processus en mode utilisateur qui ne ferment pas correctement les ports quand une erreur s’est produite. Au niveau du mode utilisateur, les ports (en fait les sockets) sont des handles. TaskManager et ProcessExplorer peuvent 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 le 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 qui en présente le plus grand nombre. En règle générale, le processus avec des poignées supérieures à 3000 peut être le coupable, à l’exception des processus comme 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 d’informations d’identification de domaine et voyez s’il réussit.

Méthode 3

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

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

1. Téléchargez l’Explorateur de processus 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 le nombre de handles.

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

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

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

6. Examinez les processus dont le nombre de handles est supérieur aux autres (il 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 présentant un nombre de handles élevé.

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

   Fichier\Appareil\AFD

   

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

Enfin, si les méthodes ci-dessus n’ont pas vous aider à isoler le processus, nous vous suggérons de collecter un vidage de mémoire complet de l’ordinateur dans l’état du problème. Cette image mémoire va vous indiquer quel processus présente le maximum de handles.

Pour contourner ce problème, le redémarrage de l’ordinateur revient dans un état normal et vous aidera à résoudre le problème pour le moment. Toutefois, lorsqu’un redémarrage est impossible, 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 à démarrer au port 10000 et à se terminer au port 10999 (1 000 ports). La plage de ports minimale pouvant être définie s’élève à 255. Le port de démarrage minimal pouvant être défini est le port 1025. Le port final maximal (basé sur la plage configurée) ne peut pas dépasser 65535.

Note

Notez que l’augmentation de la plage de ports dynamiques n’est pas une solution permanente, mais uniquement temporaire. Vous devez suivre les processus/processeurs qui consomment le nombre maximal de ports et résoudre les problèmes du point de vue de ce processus quant à la raison pour laquelle il consomme un tel nombre de ports.

Pour Windows 7 et Windows Server 2008 R2, vous pouvez utiliser le script ci-dessous pour collecter la sortie netstat à la fréquence définie. À partir des sorties, vous pouvez voir la tendance de l’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

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