Hoe controleer je met PowerShell of een TCP-poort open is? – Valkuilen en details
Als je ooit netwerkproblemen hebt geprobeerd op te lossen, weet je hoe frustrerend het kan zijn als een service gewoon niet reageert. Misschien blokkeert de firewall van een server een poort, of misschien verbergt een netwerkbeleid de open poorten. De PowerShell-functie Test-NetConnection is hierbij een redder in nood – het is eigenlijk het Zwitserse zakmes voor het testen van poorten. Maar voor sommigen is het niet altijd duidelijk wat het precies doet of hoe de resultaten te interpreteren, vooral als er iets misgaat. Het gaat hier niet alleen om pingen of controleren of een poort open is; het gaat erom de uitvoer te begrijpen en te weten wanneer je specifieke opties moet gebruiken.
Die nieuwe functie – het controleren van TCP-poorten – klinkt simpel genoeg, maar ik ben gevallen tegengekomen waarbij een poort open lijkt te staan, maar de service toch geen verbinding maakt. Of waarbij de opdracht zelf stilzwijgend mislukt. Het begrijpen van de nuances helpt dus om frustraties te voorkomen, vooral op dagen dat netwerkproblemen zich gewoon niet voordoen.
Controleer open TCP-poorten met PowerShell.
Test-NetConnection gebruiken voor snelle controles
Dit is de standaardmethode om te testen of een specifieke poort open staat op een externe host. Het is een beetje vreemd, maar het commando is:
Test-NetConnection -ComputerName ny-msg01 -Port 25
… laat je zowel weten of de server überhaupt bereikbaar is als of de poort verbindingen accepteert. Het probeert eerst de server te pingen en controleert vervolgens de TCP-poort. De uitvoer ziet er als volgt uit:
ComputerName : ny-msg01 RemoteAddress : 10.20.1.7 RemotePort : 25 InterfaceAlias : CORP SourceAddress : 10.20.1.79 PingSucceeded : True PingReplyDetails (RTT) : 0 ms TcpTestSucceeded : True
Als je TcpTestSucceeded = True ziet, is de poort open en zal de server je verbinding waarschijnlijk accepteren. Aan de andere kant, als PingSucceeded false is maar TcpTestSucceeded true, komt dat meestal doordat ICMP-echoverzoeken (ping) zijn geblokkeerd, maar de TCP-poort nog steeds luistert. Soms is dat het geval op servers met een firewall.
Tip: Bij sommige systemen werkt dit de eerste keer niet, maar wel na een snelle herstart of een korte wachttijd. Windows kan soms wat onvoorspelbaar zijn.
Meer informatie en verschillende poorten toevoegen
Wil je wat meer details? Je kunt de parameter -InformationLevel Detailed toevoegen om extra informatie te zien, zoals hieronder:
TNC 192.168.32.101 -Port 3389 -InformationLevel Detailed
En als je bekende protocollen test in plaats van poortnummers, kun je de parameter -CommonTCPPort gebruiken. Bijvoorbeeld om te controleren of een webserver actief is via HTTP:
Test-NetConnection -ComputerName woshub.com -CommonTCPPort HTTP
Of controleer of RDP (poort 3389) open is:
Test-NetConnection ny-rds1 -CommonTCPPort RDP
Dit is handig omdat het het testen van veelgebruikte services vereenvoudigt, zonder dat je poortnummers hoeft te onthouden. Want, natuurlijk, Windows moet het ingewikkelder maken dan nodig is.
Snelle controle of de poort open is
Als u alleen een eenvoudig waar/onwaar-resultaat wilt, kunt u de schakelaar -InformationLevel Quiet toevoegen, waarmee uitgaande informatie wordt onderdrukt:
TNC ny-msg1 -Port 25 -InformationLevel Quiet
Het geeft gewoon True terug als de poort open is, of False als deze gesloten is. Lekker simpel.
En hoe zit het met scripting en meerdere hosts?
Als je een groot aantal servers of IP-adressen moet controleren, is de pipeline van PowerShell je beste vriend. Stel, je hebt een lijst met servers in servers.txt : elke regel bevat een hostnaam of een IP-adres.
Get-Content c:\ps\servers.txt | Where-Object { -NOT (Test-NetConnection $_ -Port 25 -InformationLevel Quiet)} | Format-Table -AutoSize
Op deze manier zie je snel welke servers niet reageren op poort 25. In sommige configuraties krijg je valse negatieven als firewalls ICMP blokkeren of als de service alleen lokale verbindingen accepteert. Of het script heeft mogelijk een kleine vertraging nodig voor rate limiting. Desondanks is het een handige manier om meerdere servers tegelijk te controleren.
Testen van meerdere poorten en bereiken
Wil je meerdere poorten controleren of een snelle poortscan uitvoeren? Je kunt door een reeks poorten heen lopen:
foreach ($port in 1..1024) { if ((Test-NetConnection -ComputerName srvfs01 -Port $port).TcpTestSucceeded) { Write-Host "Port $port is open!" } }
Dit is geen volwaardige scanner, maar het is voldoende om snel open poorten te detecteren zonder dat je tools van derden hoeft te installeren.
Een lijst van alle open poorten op uw computer
Als je problemen op Windows zelf wilt oplossen en wilt zien welke apparaten op je pc luisteren, kan Get-NetTCPConnection je helpen. Probeer het volgende:
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort | Sort-Object -Property LocalPort | Format-Table
Dit toont alle luisterpoorten, wat erg handig is om instellingen te controleren of om te achterhalen of een service al actief is op de gewenste poort.
En als je wilt weten welk proces zich achter een specifieke poort bevindt (bijvoorbeeld 443), gebruik dan:
Get-Process -Id (Get-NetTCPConnection -LocalPort 443).OwningProcess | Select-Object Id, ProcessName, Path
Dit helpt bij het opsporen van ongewenste processen of het ervoor zorgen dat de juiste service luistert.
Kortom: Test-NetConnection is flexibel, maar niet perfect. Soms moet je het combineren met andere tools of controles (zoals netstat of Taakbeheer) voor een volledig beeld. Toch is het een stuk handiger dan allerlei omslachtige stappen voor eenvoudige poorttests, vooral op externe servers of voor scriptmatige controles.
Samenvatting
- Gebruik Test-NetConnection voor snelle TCP-poortcontroles.
- Leverage – Informatieniveau Gedetailleerd voor extra informatie
- Gebruik -CommonTCPPort voor bekende services.
- Script voor het批量 controleren van servers — PowerShell maakt dit verrassend eenvoudig
- Controleer lokaal open poorten met Get-NetTCPConnection.
Samenvatting
Controleren of een poort open is, is niet altijd even eenvoudig. Firewalls, netwerkapparaten en serverconfiguraties maken het lastiger. Maar PowerShell’s Test-NetConnection is een verrassend veelzijdig hulpmiddel, vooral als je de eigenaardigheden ervan begrijpt. Of je nu een snelle controle uitvoert, een scan script of een hardnekkige server probeert te troubleshooten, het is de moeite waard om het onder de knie te krijgen. Houd er wel rekening mee dat firewalls soms ICMP blokkeren zonder de poort te blokkeren, of andersom. Ga dus niet zomaar uit van de resultaten zonder extra controle.
Hopelijk bespaart dit iemand wat gepieker tijdens de volgende netwerktest. Ik hoop dat dit helpt!