6

Windows下bat批处理脚本使用telnet批量检测远程端口小记

 3 years ago
source link: https://zhang.ge/5050.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
Jager · 7月1日 · 2015年bat · windows · 批处理 · 批处理维护工具 9208次已读

多年没写过批处理了,来新公司的第一个case却是需要写一个bat脚本,批量更新采集agent的配置文件,其中就涉及到远程IP的端口检测。

本以为会和Linux一样可以简单判断:

echo q|telnet -e 'q' $ip $port && echo "$ip:port 通"||echo "$ip:port 不通"

结果发现Windows下面telnet退出并没有执行结果的返回值:

一、借助工具

于是我优先开启懒人法则,找其他替代工具。果然,在Windows老娘家找到了:

Portqryhttps://support.microsoft.com/en-us/kb/310099/zh-cn

确实可以使用,不过检测速度不敢恭维,通与不通都很慢!鉴于手头没有更好的解决办法,就先试试看,贴一下我写的Portqry相关demo:

::使用微软官方工具【PortQry】进行检测的代码:
@echo off & setlocal enabledelayedexpansion
rem 要检测的IP和端口
set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'
set serverport='9922'
rem 模块化调用
call :check
::****其他代码略****
:check
rem ※探测端口模块--PortQry方案※
for /f "tokens=1,* delims=," %%i in ("!server_ip!") do (
echo 正在检测 %%i 的 !serverport! 端口...
rem 这是关键的检测代码:
"!tools_dir!\PortQry.exe" -n %%i -p tcp -e !serverport! | find "LISTENIN" >nul && (
echo 【成功】:可以连接到 %%i:!serverport!
echo 【失败】:无法连通 %%i:!serverport!
echo=
set server_ip=%%j
goto check
goto :eof
::*******其他代码略********

Ps:check是一个被call调用的模块,里面的一些变量就不做介绍了。

于是兴冲冲的封装成exe,给IDC(server2003系统)执行,结果第一台就悲剧了!远程桌面直接断开了:

然后再也连不上了,要他们去机房看了下,结果告诉我系统没了!!??太震精了有木有?一个简单的文本操作脚本,居然把系统干掉了么?而且脚本中都不存在任何删除命令。。。

要那边提供了一下启动错误信息,原来是系统引导坏了:

个人分析了一下,应该是Portqry这个工具导致系统蓝屏关机,进而导致引导损坏!

尼玛,娘家人介绍时说好的“性格”良好呢?

唉,看来这个工具是不敢使用了,俗话说林子大了什么系统都有嘞!

二、另辟蹊径

既然工具不敢用了,还是继续折腾代码吧!周末睡觉前突然灵感一闪,想起了tasklist判断窗口名称这个“失传绝技”,于是把刚关闭的本子又打开,终于在GF的不断抱怨之下搞定了这个问题。

①、窗口判断

思路比较简单:使用start命令在新窗口执行telnet -e 和 exit命令,如果端口畅通,那么新开的窗口将会立即关闭,而不通的窗口则会保持近半分钟左右,且窗口名称类似 telnet 192.168.1.1,这半分钟时间足够脚本来判断通还是不通了。

于是将上面check部分修改如下:

::使用telnet命令检测的代码
@echo off & setlocal enabledelayedexpansion
rem 要检测的IP和端口
set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'
set serverport='9922'
rem 模块化调用
call :check_port
::****其他代码略****
:check_port
rem ※探测端口模块--telnet方案※
for /f "tokens=1,* delims=," %%i in ("!server_ip!") do (
echo [No.!check_num!]:正在检测 %%i 的 !serverport! 端口...
rem 新窗口打开telnet,如果端口畅通会立即退出,脚本会在3秒后查看telnet窗口是否退出,如果没有退出表示端口不通!
start /min cmd.exe /k "echo q|telnet -e 'q' %%i !serverport! & exit"
ping -n 3 127.1>nul
rem 查找窗口名为“Telnet ${ip}”的cmd窗口,如果存在则表示此IP不通
tasklist /fi "windowtitle eq Telnet %%i" | find "cmd.exe" >nul && (
echo 【失败】:无法连通 %%i:!serverport!
echo 【成功】:可以连接到 %%i:!serverport!
echo=
set server_ip=%%j
goto check_port
goto :eof
::其他代码略...

样就解决了Windows下telnet探测远程端口的问题了,而且检测速度比微软哪个portqry快多了,果然思路比技术更重要,只要有想法,任何技术都不应该成为瓶颈!

②、进程判断【最新补充】

当使用窗口判断的方案下发各大机房实施的时候,又一个问题出现了!窗口判断在某些版本的Windows下是行不通的,比如英文版下的命令提示符窗口名称和中文版的就不一样,所以这个方案也是不完善的!

于是,继续抓耳挠腮,想出了第二个方案:通过判断telnet进程数量来判断网络是否畅通。

方案思路:

a. 先判断脚本执行之前是否存在 telnet.exe 的进程,如果存在则统计数量

b. 和窗口判断一样,利用start命令在新的cmd命令提示符中执行 telnet 命令

c. 延迟几秒后统计系统中存在的telnet.exe进程数(存在的telnet表示是不通的)

d. 和最开始统计的 telnet 进程数比对计算,就知道有几个IP是不通的了

示例代码:

::使用telnet命令检测的代码
@echo off & setlocal enabledelayedexpansion
rem 要检测的IP和端口
set server_ip='192.168.1.1,192.168.1.2,192.168.1.3'
set serverport='9922'
::****其他代码略****
rem 刚开始先计算telnet.exe的进程数量,避免脚本执行之前就已经存在telnet.exe
call :telnet_num conf
rem 模块化调用
call :check_port
:check_port
set /a check_num+=1
rem ※探测端口模块※
for /f "tokens=1,* delims=," %%i in ("!server_ip!") do (
echo [No.!check_num!]:正在检测 %%i 的 !serverport! 端口...
::call :set_iPSec %%i
rem 使用telnet组合命令进行测试,如果端口畅通会立即退出,脚本会在3秒后查看telnet窗口是否退出,如果没有退出表示端口不通!
start /min cmd.exe /k "echo q|telnet -e 'q' %%i !serverport! & exit"
echo=
set server_ip=%%j
set total_num=!check_num!
goto check_port
ping -n 3 127.1>nul
#再次计算telnet进程数量,而且已经排除执行之前就有的telnet数量
call :telnet_num
echo 可用数量为:!telnet_num!
goto :eof
:telnet_num
rem 检测telnet进程数量,已排除脚本之前存在telnet
set conf=0
for /f "delims=*" %%i in ('tasklist ^| findstr "telnet.exe"') do (
if "%1"=="conf" (
set /a conf+=1
) else (
set /a telnet_num+=1
set /a telnet_num=!telnet_num!-!conf!
goto :eof

很明显,这样就可以知道我测试了所有IP当中有几个是不通的了。遗憾的是无法知道是哪个IP不通。不过在手头的这个case当中是不需要具体不通的IP的,只要知道通的IP是否达标就行。

好了,终于把这个问题给解决了。显然,任何时候都需要给出多个方案,而不是自满于一个方案。否则出问题就会焦头烂额了。当然,再次说明了想法比技术更重要。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK