Controllare lo stato di una porta sull'host remoto

Ho bisogno di una linea di comando che possa controllare lo stato della porta su un host remoto. Ho provato ping xxx.xxx.xxx.xxx:161 ma non riconosce l'host". Ho pensato che fosse una "buona" risposta finché non ho fatto lo stesso comando contro un host che so che ha quella porta aperta. Questo è per un file batch su Windows che controllerà lo stato della porta remota poi eseguirà un comando che usa quella porta remota per informazioni, poi il comando di controllo della porta remota di nuovo, poi il comando che usa quella porta sul prossimo server per informazioni, e così via. Ho cercato ovunque e ho pensato che il ping potrebbe farlo, ma ci devono essere varie versioni di ping, suppongo, dato che il server su cui sto facendo questo non mostra quell'opzione.

Solo per ridere, ho provato un web-based port checker remoto da un sito web - e i risultati sono stati corretti sia per il "problema" server che per il server corretto. Tuttavia, non posso usarlo in un batch con 500+ IP di server.

C'è qualcosa che posso fare che sia semplice? Le mie competenze Perl sono estremamente arrugginite (usalo o perdilo), non conosco altri linguaggi basati su Windows tranne il batch. Unix è la mia abilità, ma questo deve essere eseguito da Widows Server 2003.

Sembra che tu stia cercando uno scanner di porte come nmap o netcat, entrambi disponibili per Windows, Linux e Mac OS X.

Per esempio, controlla telnet su un ip conosciuto:

nmap -A 192.168.0.5/32 -p 23

Per esempio, cerca le porte aperte da 20 a 30 su host.example.com:

nc -z host.example.com 20-30
Commentari (7)

nc o 'netcat' ha anche una modalità di scansione che può essere utile.

Commentari (1)

Penso che tu stia cercando Hping (http://www.hping.org/), che ha una versione per Windows.

"L'interfaccia è ispirata al comando unix ping(8), ma hping non è

solo in grado di inviare richieste ICMP echo. Supporta TCP, UDP, ICMP..."

È anche molto utile se si vuole vedere dove lungo un percorso una porta TCP è bloccata (come da un firewall), dove ICMP potrebbe non esserlo.

Commentari (0)