PuTTY…..à la recherche du port disponible

Avec un titre comme ça il faut qu’on vous plante le décor au préalable ; nous avons un cluster de deux hosts dont un est en maintenance, les deux serveurs d’admin (RDSH)  qui sont hébergés sur l’autre host commence à être chargés, sur un de nos serveur d’administration nous avions déjà une session en mode déconnecté depuis une vingtaine heures environ. La reconnection à notre session s’est faite sans problème (une chance car l’autre serveur refuse toute connexion) cependant lorsque nous avons essayé de lancer une connection distante (SSH) via PuTTY nous avons rencontré l’erreur ci-dessous  :

Network error : No buffer space available

Notre premier bug PuTTY 🙂

Dans le journal system nous  avons  trouvé l’Event ID 4227 qui visiblement a un lien direct avec notre problème.

TCP/IP failed to establish an outgoing connection because the selected local endpoint was recently used to connect to the same remote endpoint. This error typically occurs when outgoing connections are opened and closed at a high rate, causing all available local ports to be used and forcing TCP/IP to reuse a local port for an outgoing connection.
To minimize the risk of data corruption, the TCP/IP standard requires a minimum time period to elapse between successive
connections from a given local endpoint to a given remote endpoint.

Outre le problème rencontré avec PuTTY, nous ne pouvons plus “sortir” du serveur, que ce soit via l’accès à un partage distant, un telnet, un rdp, AD etc.. etc….. . Un google plus loin nous comprenons qu’il se pourrait que notre serveur ait un problème de port dynamique (AKA “Ephemeral Port“).  Afin d’afficher la liste et l’état des connexions (ce qui nous intéresses ce sont les connexions en TIME_WAIT) sur notre serveur nous avons utilisé la cmdlet “Get-NetTCPConnection” comme ci-dessous : 

Get-NetTCPConnection -state timewait

Nous avons constaté un nombre conséquent (environ 200) de connexions en TIME_WAIT (malheureusement nous n’avons pas eu le temps de faire un screenshot, juste le temps de noter les PID coupables, et comme c’est de la prod on ne kill pas les PID sans savoir), on comprend mieux pourquoi PuTTY ne trouve pas un port dynamique de libre. Afin de connaître la plage des ports dynamiques il faut lancer la commande ci-dessous :

netsh int ipv4 show dynamicport tcp
Notre server a une une plage par défaut pour un Windows 2019

La solution de facilité serait de rebooter le serveur (mais nous avons toujours des utilisateurs connectés sur le serveur), nous optons pour agrandir la plage des ports dynamiques (sans redémarrer le serveur) . Afin d’agrandir la plage des ports dynamiques et réduire le temps de libération d’un port qui passe en TIME_WAIT de quatre minutes (valeur par défaut) à 30 secondes nous avons passé les clés de registre ci-dessous (qu’on expliquera plus bas) via une console PowerShell.

Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name MaxUserPort -Value 65534 -Force | Out-Null
Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name TcpTimedWaitDelay -Value 30 -Force | Out-Null
Get-Item 'HKLM:\System\CurrentControlSet\Services\Tcpip\Parameters' | New-ItemProperty -Name TcpNumConnections -Value 16777214 -Force | Out-Null

Nous relançons un “netsh int ipv4 show dynamicport tcp” afin de vérifier que la plage des ports dynamique a bien été agrandie.

Notre plage est désormais agrandie

On teste si PuTTY se lance bien avec la plage des ports dynamiques agrandie.

Nickel (ça passe sans reboot)

Quelques explications sur les trois clés passées plus haut.

  1. MaxUserPort : Permet de fixer la plage des ports dynamiques, par défaut la plage sur Windows 2019 commence à 49152 et se termine à 65535
  2. TcpTimedWaitDelay : détermine la durée pendant laquelle une connexion TCP reste dans l’état TIME_WAIT (ou 2MSL) lorsqu’elle est fermée. La valeur par défaut d’un TIME_WAIT est de 240 secondes (4 mn) soit 120 secondes pour MSL qu’on double pour avoir deux MSL (2MSL).
  3. TcpNumConnections : nombre de connexions TCP ouvertes simultanées

    Un peu de littérature  autour des ports dynamiques :

    On s’égare, mais le titre du post était en rapport avec ça 🙂

    Post to Twitter

    La KB à lire jusqu’au bout… mais vraiment jusqu’au bout

    Juste un petit warning, si vous faîtes un update d’un infra Horizon View (dans notre cas 7.1 vers 7.10 avec des replica server) n’oubliez pas d’ouvrir le port TCP 32111 entre vos Connection Server et les Réplica. Si vous lisez la la KB1027217,  notamment la section “TCP Ports for View Connection Server and Replica Server Instances” vous remarquez l’absence du port TCP 32111.

    Donc pas besoin du port TCP 32111 ? 🙂


    Par contre si on lit la KB1027217 jusqu’au bout (notamment les notes en bas de la KB ) on tombe sur :

    In Horizon 7.2 and later, TCP 32111 is required between Connection Servers in a replica group

    On avait remonté ça à VMware il y a quelques mois.. mais ils préfèrent les KB type “Escape Game” 🙂



    L’attribut alt de cette image est vide, son nom de fichier est EscapeGame.jpg.
    Bienvenu dans la KB1027217 🙂

    Post to Twitter

    Qualys : TdIca.sys consommation excesive de cpu

    Lors de vague Qualys certains de nos serveurs XenApp (W2K8 Us sp2 et Vda 7.6.1000) affichaient une consommation cpu de 100 % (une fois le scan terminé), bien sûr seul les serveurs XenApp étaient impactés par cette consommation cpu.

    La consommation cpu était répartie entre deux process TdIca.sys (50 % pour chacun des process).

     


    Autant vous dire que les scan Qualys ont les a senti passer 🙂

     

    En redemarrant le service “Remote Desktop Services” la consomation cpu resdescendait quasi instantanément.

    Après plusieurs recherches et tests nous avons constaté qu’une fois le scan terminé sur un serveur XenApp nous avions les ports  TCP 2598 et 8008 (Session Reliability et HTML5) en attente de fermeture (malheuresement nous n’avons pas eu le temps de faire un screnshoot  🙁  ).

    En testant les mêmes scan Qualys avec des serveurs W2k8 sp2 Us en Vda 7.6.2000 ou 7.6.4000 nous n’avons jamais  pusreproduire le problème de consommation cpu.

    Notre premier bug depuis notre migration en 7.6 LTSR il y a bientôt un an 😉 .

     

    On sait pas pourquoi…  Surement le soleil du sud… Mais on a penser a Cyrix durant ce billet 🙂

     

    Post to Twitter

    MAJ TestPort : Script permettant de tester les ports Tcp

    Il ya quelque temps nous avions mis en ligne test_port qui permettait de tester les port Tcp Xenapp afin de vérifier les ouvertures réseau sur l’ICA par exemple.

    Après un peu plus de deux ans, nous avons mis à jour test_port 🙂 .

    Outre la correction des divers bug et la simplification du code,  il est possible désormais de tester les ports sur plusieurs serveurs.

    Cliquez sur le bouton “Ouvrir le fichier serveur cible” (le fichier est crée automatiquement)
    Renseignez les Ip des serveurs à tester et enregistrez le fichier
    Cliquez sur le bouton “Lancer le test


    Test_Port V1.3

    MAJ : 03/04/2012
    Test_Port V1.3
    Correction bug : lors clic sur le bouton Ouvrir le fichier serveur Cible  le fichier servers.txt ne gardait pas les informations enregistrées.

    Post to Twitter

    Ouverture de ports sur un DataStore SQL

    Si vous rencontrez des erreurs lors d’un CHFARM pointant sur un DataStore SQL, ou des erreurs du service IMA suite à une migration dans un nouveau VLAN (par exemple).

    Le problème pourrait venir d’un port non ouvert.

    Erreur lors du CHFARM (erreur classique lors d’un problème de connexion avec une base SQL)

    Dans notre cas le port TCP 1201 était bien ouvert, il manquait juste le port UDP 1434.

    Lorsque des clients SQL Server 2000 et SQL Server 2005 demandent des ressources SQL Server, la bibliothèque réseau client envoie un message UDP au serveur en utilisant le port 1434. SQL Server Browser répond avec le port TCP/IP ou le canal de communication nommé de l’instance demandée. La bibliothèque réseau de l’application cliente établit alors la connexion en envoyant une demande au serveur en utilisant le port ou le canal de communication nommé de l’instance souhaitée.


    Une trace Wireshark au démarrage du service IMA d’un de nos serveur pour qui le port UDP 1434 était ouvert :


    Post to Twitter

    CurrPorts : logiciel de surveillance réseau

    Par pur hasard nous sommes tombés sur le logiciel CurrPort.

    CurrPorts permet d’afficher dans une GUI, tout les ports TCP/IP et UDP ouverts localement sur un serveur, avec des informations comme :

    • processus qui a ouvert le port
    • Chemin du processus
    • Temps d’ouverture du processus
    • L’IP local
    • l’IP Distante + le nom du Host
    • Le local Port et le Remote port (cette info que l’on recherche souvent 😉 ).
    • Le process ID
    • Version du processus
    • l’utilisateur qui utilise le processus

     

    Un CurrPorts sur un serveur XenApp.
     

     
    Un double clique sur le process ImaSrv.exe d’un serveur XenApp, et l’on obtient dans le cas présent des infos sur la connexion au DataStore de la ferme.

    CurrPorts permet de killer un processus, faire un export Html du CurrPorts en cours, sauvegarder les informations d’un process au format .txt, de filtrer les process et ports.

    Syntaxe pour faire un filtre :

    • include:remote:tcp:80
    • include:both:udp:53-139
    • exclude:both:tcpudp:192.168.0.1-192.168.0.100
    • include:process:imasrv.exe

    En bref un outil graphique, pratique pour commencer un  troubleshooting sur des problématiques d’ouverture de ports par exemple 🙂 .

    CurrPorts est un outil de chez NirSoft et est disponible ici.

    Post to Twitter

    TestPort : Script testeur de port

    Si comme nous vous avez été confronté à des restrictions de ports inter-VLAN (par exemple), il est pratique lors de l’ajout d’un serveur XenApp dans un nouveau VLAN de pouvoir s’assurer que les ports nécessaires au serveur XenApp sont ouverts.

    Si comme nous vous avez été confronté à des restrictions de ports inter-VLAN (par exemple), il est pratique lors de l’ajout d’un serveur XenApp dans un nouveau VLAN de pouvoir s’assurer que les ports nécessaires au serveur XenApp sont ouverts.

    Continue reading “TestPort : Script testeur de port”

    Post to Twitter

    liste des ports Citrix

    ——
    MAJ 03/01/12
    La  CTX101810 vient d’être mise à jour
     ——

    ——
    MAJ 30/08/09
    La CTX101810 a été mise à jour le 28/08/09, un tout nouveau pdf est disponible (les ports XenApp,  XenServer, XenDesktop, EdgSight, Access Gateway, etc… y sont traités)
    enjoy 🙂
    ——-

    Il est de moins en moins simple de trouver un listing simple des ports utilisés sous Citrix.

    Si en plus, vous cherchez des détails et exemples sur la mise en place, vous cherchez presque l’impossible. Heureusement, un petit guide récapitulatif existe chez l’éditeur.
    Tout est la (les ports sont en page 6 et7) et la
    A apprendre par cœur, interro écrite demain :)

    Post to Twitter