Antisèche PowerShell réseau pour Windows

Cette antisèche PowerShell réseau met tout en haut la cmdlet que la plupart des gens cherchent vraiment, Test-NetConnection, parce qu'elle fait un ping, un test de port TCP et un traceroute dans une seule commande. Vous ouvrez PowerShell pour voir si un port répond, et vos doigts tapent ping tout seuls. Les vieux outils CMD tournent encore, mais le réseau Windows ne vit plus là. Il vit dans les cmdlets. Elles viennent de modules intégrés, surtout NetTCPIP et DnsClient, livrés avec tout Windows moderne, et renvoient de vrais objets au lieu d'un mur de texte à déchiffrer à l'oeil. Copiez, changez l'hôte, c'est parti.

Vous ouvrez PowerShell pour voir si un port répond, et vos doigts tapent ping tout seuls. Ça m'arrive aussi. Les vieux outils CMD tournent encore, d'accord, mais le réseau Windows ne vit plus là. Il vit dans les cmdlets. Et celle que tout le monde cherche vraiment, Test-NetConnection, fait le ping, le test de port et le traceroute dans une seule commande. Alors elle est tout en haut. Copiez, changez l'hôte, c'est parti.

Une chose à savoir avant de défiler. Ces cmdlets viennent de deux modules intégrés, surtout NetTCPIP et DnsClient, livrés avec tout Windows moderne. Rien à installer. Et elles renvoient de vrais objets, pas un mur de texte à déchiffrer à l'oeil, ce qui est tout l'intérêt de faire ça dans PowerShell plutôt que dans CMD.

Tester un port et la joignabilité avec Test-NetConnection

C'est elle. Si vous ne retenez qu'une chose, retenez Test-NetConnection. Elle pingue, elle teste un port TCP, elle trace une route, et elle fait chacun de ces trucs sans changer d'outil. Vous voulez savoir si un serveur web répond vraiment sur le 443 ? Ne le pinguez pas (le ping ne vous dira pas si le port est ouvert). Lancez Test-NetConnection hote -Port 443 et lisez la ligne TcpTestSucceeded. True, le port a répondu. C'est la réponse que vous étiez venu chercher.

La sortie est un peu bavarde par défaut, elle affiche l'adresse source, la distante, les résultats du ping, tout le bazar. Quand je veux juste le oui-ou-non, j'accroche la propriété qui m'intéresse : (Test-NetConnection hote -Port 443).TcpTestSucceeded renvoie un True ou False tout sec, et rien d'autre. Franchement, ce one-liner a remplacé telnet chez moi pour de bon, et bon débarras, telnet n'était même pas installé par défaut une fois sur deux.

Voir IP, passerelle et DNS d'un coup d'oeil

Deux cmdlets couvrent presque tout ce pour quoi vous utilisiez ipconfig. Get-NetIPConfiguration, c'est le résumé sympa : il réunit votre adresse, la passerelle par défaut et les serveurs DNS par carte. Get-NetIPAddress va plus loin et liste chaque IP de la machine, IPv4 et IPv6, ce qui est plus que vous ne voulez d'habitude mais pile ce qu'il faut quand vous traquez un truc bizarre en link-local.

Cette dernière ligne est la discrète sur laquelle je m'appuie le plus. Get-NetRoute, c'est la table de routage, et filtrer sur 0.0.0.0/0 montre la route par défaut, là où part vraiment votre trafic quand la destination n'est pas locale. Quand un poste atteint le LAN mais pas internet, la passerelle dans cette ligne est le premier endroit que je regarde. Neuf fois sur dix, elle est fausse ou absente.

Trouver qui écoute (le remplaçant de netstat)

Vous devez savoir qui tient un port. Peut-être qu'un service refuse de démarrer parce que le 8080 est déjà pris. Get-NetTCPConnection, c'est le netstat moderne, et -State Listen le réduit aux sockets qui attendent vraiment des connexions. Mieux : il vous donne le OwningProcess sous forme de vrai PID, que vous balancez direct dans Get-Process pour mettre un nom sur le coupable.

L'astuce qui rend ça vraiment utile : le pipe. Get-NetTCPConnection -State Listen | Select-Object LocalPort, OwningProcess vous donne un tableau propre, et de là Get-Process -Id <pid> vous dit que c'était Docker, ou un process Node oublié qui traîne. Essayez de faire ça proprement avec netstat. Vous pouvez, avec -ano, mais vous revoilà à scruter des colonnes à l'oeil.

Résolutions DNS et vidage du cache

Pour les noms, Resolve-DnsName est votre outil. C'est nslookup, sauf qu'il renvoie des objets, donc vous demandez juste les enregistrements voulus au lieu de lire un paragraphe. Et quand un enregistrement est clairement périmé, quand un site a déménagé et que votre machine pointe encore sur l'ancienne adresse, Clear-DnsClientCache efface le cache du résolveur local d'un seul coup.

Petit piège. Resolve-DnsName peut lire votre cache local aussi, donc si vous venez de vider et que vous voulez une réponse vraiment fraîche depuis le serveur, l'option -Server court-circuite les bizarreries locales. Je sors -Server 1.1.1.1 quand je soupçonne que ce sont les réglages DNS du poste qui posent problème et que je veux un deuxième avis qui les ignore complètement.

Cartes réseau et changement d'IP ou de DNS

Parfois vous ne diagnostiquez pas, vous configurez. Get-NetAdapter liste vos interfaces réseau avec leur nom et leur état de lien, et ce nom d'interface (souvent "Ethernet" ou "Wi-Fi") est ce sur quoi s'appuient les commandes de modif. De là vous pointez une carte vers un nouveau serveur DNS ou vous figez une IP statique, sans cliquer dans cinq fenêtres du Panneau de configuration pour y arriver.

Deux avertissements, parce que ces commandes-là changent vraiment votre config. Elles exigent un PowerShell élevé (en tant qu'admin), sinon elles refusent net. Et si vous fixez une IP statique sur le poste même où vous êtes connecté à distance, vous pouvez couper votre propre lien en pleine commande, alors celle-là faites-la à la console, pas en RDP, sauf si une marche jusqu'à la salle serveur vous tente. Pour annuler le DNS après et repasser en automatique, Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddresses rend la main au DHCP.

Mon avis : Test-NetConnection a remplacé ping, telnet et tracert en douce

Trois habitudes séparées, pliées dans une seule cmdlet. La joignabilité, le test de port ouvert que telnet vous bricolait, et un traceroute, le tout depuis Test-NetConnection avec une option différente. C'est une vraie consolidation, et le test -Port à lui seul justifie de ranger telnet, que Windows n'installait plus par défaut de toute façon. Le bémol honnête quand même : c'est plus lent qu'un ping brut, la sortie verbeuse est de trop quand vous voulez juste True ou False, et sur une session distante serrée les vieux outils chargent plus vite. Alors je garde ping dans les doigts pour un contrôle "y a quelqu'un" de cinq secondes. Pour littéralement tout le reste, c'est tnc. Peut-être que je m'appuie trop dessus parce que taper une commande bat en retenir trois, mais le temps que ça m'a fait gagner n'est pas mince.

Et après

Voilà le jeu de base. Tester un port, lire sa config, lister qui écoute, résoudre un nom, vider le cache, voir ses cartes, poser une IP. Ça couvre franchement presque tout ce que je touche en une semaine normale de réseau Windows, et le rare truc bizarre, je le cherche comme tout le monde.

Si vous naviguez entre deux mondes, la mémoire des doigts suit. Besoin des outils CMD classiques pour une vieille machine ou un script ? L'antisèche des commandes réseau Windows (CMD) garde ipconfig, ping et netstat regroupés pareil. Vous jonglez avec les profils Wi-Fi et les mots de passe enregistrés ? C'est le terrain des commandes netsh wlan. Et quand vous préféreriez ne pas ouvrir de shell du tout, notre vérificateur de ports TCP teste un hôte et un port depuis le navigateur, pendant que l'outil de recherche DNS résout un nom sans que vous tapiez quoi que ce soit.

Sources et lectures complémentaires

• Microsoft Learn : module NetTCPIP (Test-NetConnection, Get-NetIPAddress, Get-NetTCPConnection, Get-NetRoute)
• Microsoft Learn : module DnsClient (Resolve-DnsName, Clear-DnsClientCache)

Questions fréquentes