跨网段访问License Server时端口不通的排查方法（telnet、traceroute）

端口不通。这三个字是FlexNet运维中最让人头疼的问题。尤其是在跨网段场景下——客户端在一个子网，License Server在另一个子网，中间隔了路由器、防火墙、交换机的三层网络环境——排查难度比同网段高出不少。

这篇文章提供一套标准的排查方法，按照从简单到复杂的顺序来。

一、先确认问题出在哪一层

跨网段访问License Server，通信链路涉及几个环节：

1. 客户端到网关的网络连通性
2. 客户端到服务器的路由可达性
3. 目标端口在服务器端是否开放
4. 中间防火墙或安全设备是否拦截
5. 服务端监听地址是否正确

排查思路很简单：从网络层开始，逐层向上排查。

二、第一步：确认IP层可达（用ping）

先看客户端的IP能不能找到服务器。这是最基础的检查。

bash

ping 192.168.1.100

• 能通：IP层没问题，往下走端口检查
• 不通：检查客户端网卡配置、网关设置、服务器IP是否正确、服务器是否开机

跨网段ping不通的情况，通常跟路由配置有关。在客户端执行tracert（Windows）或traceroute（Linux）看数据包走到哪里断了：

bash

# Windows
tracert 192.168.1.100

# Linux
traceroute -n 192.168.1.100

输出结果里的每一跳就是一个路由器。看数据包在哪一跳超时了，就能大致判断问题位置——在客户端网关之后的第一跳就断了，说明客户端网关配置有问题；到了目标网段前面断了，说明中间路由器或对端网关配置有问题。

注意： 有些网络设备禁用了ICMP，ping不通但端口可能是通的，这种情况确实存在。所以ping不通时，不要直接下结论说"服务器坏了"，后续还要继续排查。

三、第二步：确认端口是否开放（用telnet）

IP层通了之后，检查目标端口是否处于监听状态并允许外部连接。

标准用法：

bash

telnet 192.168.1.100 27000

三种结果及解读

结果一：连接成功

屏幕上显示类似下面的内容：

text

Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.

说明客户端到服务器的27000端口通信通畅。如果客户端仍然报错，问题不在网络层，需要排查其他方面——比如license文件内容、vendor daemon是否正常运行、客户端配置的环境变量是否正确。

结果二：连接超时（timed out）

text

Trying 192.168.1.100...
telnet: connect to address 192.168.1.100: Connection timed out

防火墙大概率拦截了连接请求。可能拦截的位置：

• 服务器端操作系统防火墙（iptables/firewalld/Windows防火墙）
• 中间网络设备（路由器ACL、交换机安全策略）
• 云平台安全组（如果服务器在云上）

结果三：连接被拒绝（Connection refused）

text

Trying 192.168.1.100...
telnet: connect to address 192.168.1.100: Connection refused

这种情况说明数据包能到达服务器，但目标端口没有进程在监听。检查lmgrd是否在运行，或者确认它监听的是否是27000端口。

四、第三步：跨网段场景的特殊排查

在跨网段环境中，上面两种常见错误可能是由一些跨网段特有的问题引起的：

情况1：请求到达了错误的网卡

服务器如果有多个网卡（公网、内网、管理网），lmgrd可能只监听在其中一个网卡的IP上，而这个IP恰好不是客户端能访问的那个网段的地址。

用netstat确认lmgrd绑定了哪个地址：

bash

netstat -anp | grep 27000

输出结果的本地地址字段会告诉你lmgrd监听在哪个IP上：

• 0.0.0.0:27000：监听所有网卡，外部可以访问
• 127.0.0.1:27000：只监听本地，外部无法访问
• 192.168.1.100:27000：只监听特定网卡

如果只绑定了127.0.0.1，跨网段客户端肯定连不上。需要检查lmgrd启动时是否通过-c参数指定了错误的HOST值，或者/etc/hosts中的解析指向了127.0.0.1。

情况2：客户端网关或路由配置不正确

在客户端执行：

bash

route print（Windows）
route -n（Linux）

检查默认网关是否正确。如果客户端连自己的网关都ping不通，那去任何跨网段的目标都会失败。

情况3：中间防火墙放行了端口，但安全组没放行

这是云环境特有的问题。云厂商提供了安全组（Security Group）功能，相当于在虚拟机外部还有一层分布式防火墙。

检查AWS/阿里云/腾讯云的控制台，确认安全组的入站规则中已经放行了目标端口。系统防火墙和安全组必须同时开放端口才有效——只开放其中一个，另一个没开，连接仍然失败。

情况4：跨NAT环境

如果License Server部署在NAT设备后面，客户端访问的是NAT后的公网IP，而服务器绑定的地址是内网IP，需要在NAT设备上做端口映射（Port Forwarding），把公网IP的某个端口映射到内网服务器的27000端口。

另外，如果客户端和服务器之间存在网络地址转换（NAT），客户端通过lmstat看到的“请求来自”的IP可能与FlexNet的RESERVE或EXCLUDE规则中配置的不一致，可能导致权限判断出错。

五、第四步：检查服务器端的监听状态

回到服务器上确认服务是否真的在跑：

bash

# 检查lmgrd进程
ps -ef | grep lmgrd

# 检查端口监听
netstat -anp | grep 27000

正常情况下lmgrd应该处于LISTEN状态。如果进程在但端口不在监听，可能是lmgrd启动失败但进程残留。这时应该查看debug.log排查原因。

检查vendor daemon的端口是否也在监听：

bash

netstat -anp | grep 27002

vendor daemon的端口也必须处于LISTEN状态。如果只有lmgrd的端口开着但vendor daemon的端口没开，客户端仍然无法完成签出。

六、完整的排查流程图

text

客户端报错“Cannot connect”
        ↓
ping 服务器IP
├── 不通 → 检查路由、网关、服务器状态
└── 通   ↓
telnet 服务器IP 27000
├── Connection refused → lmgrd未启动或端口不对，检查服务器
├── Connection timed out → 防火墙/安全组拦截，排查中间设备
└── Connected ✓  ↓
telnet 服务器IP vendor_daemon端口
├── 不通 → 检查vendor daemon是否运行，端口是否固定
└── 通   ↓
在服务器上用lmstat -c 27000@localhost验证服务正常
        ↓
检查客户端环境变量LM_LICENSE_FILE是否指向正确的端口@主机
        ↓
—— 问题解决 ✓ ——

七、最后

跨网段端口不通的排查思路是从IP层到应用层逐层排查：

跨网段比同网段多出了路由器、ACL、安全组这些中间设备，排查时每一步都要确认是客户端侧、服务器侧还是中间网络的问题。telnet是测试端口连通性最直接的工具，配合traceroute定位路由中断的位置，绝大部分端口不通的问题都能找到根源。