软件
产品
公网访问内网License Server，端口映射方案，技术上能通，但实际操作起来坑不少。
先说结论：可行，但不推荐。 如果你只是临时测试，或者实在没有其他办法，可以试试。但如果是生产环境、长期使用，建议直接跳过这篇文章的实操部分，去看后面的替代方案。
场景很常见：员工在家办公，或者分公司在异地，需要访问总部的License Server。
正规做法是VPN拨入内网，然后像在内网一样使用。但有些公司没有VPN，或者VPN权限申请流程太长，于是IT想了个“捷径”——在路由器上做个端口映射，把内网的License Server端口映射到公网上，员工在外面直接连公网IP就行了。
想法很简单，实现起来问题却不少。
端口映射不是只开一个端口就完事了。FlexNet的通信机制决定了你必须同时处理好两个端口。
第一步：把两个端口都固定下来
如果不固定端口，vendor daemon每次启动随机选一个端口，你的端口映射规则就得跟着改，这显然不现实。
在license文件里改两行：
SERVER行指定lmgrd的端口：
text
SERVER license-server 001122334455 27000VENDOR行指定vendor daemon的端口：
text
VENDOR snpslmd /opt/synopsys/snpslmd PORT=27002第二步：在路由器上做端口映射
假设你的License Server内网IP是192.168.1.100，公网IP是203.0.113.50。
在路由器上配置两条映射规则：
| 内网IP | 内网端口 | 公网端口 | 协议 |
|---|---|---|---|
| 192.168.1.100 | 27000 | 27000 | TCP |
| 192.168.1.100 | 27002 | 27002 | TCP |
公网端口可以和内网端口一致，也可以不一样。如果不一样，客户端连接时要指定映射后的端口号。
第三步：客户端指向公网IP
客户端的LM_LICENSE_FILE环境变量改成：
text
LM_LICENSE_FILE=27000@203.0.113.50如果公网端口映射的不是27000，比如映射成了28000，那就写成：
text
LM_LICENSE_FILE=28000@203.0.113.50端口映射的原理不复杂，但用在License Server上有几个绕不过去的问题。
坑一：lmgrd返回的是内网地址，不是公网地址
这是最大的坑。客户端连上lmgrd的27000端口后，lmgrd会告诉客户端：“vendor daemon在192.168.1.100的27002端口上，你去连它。”
客户端拿到的是内网IP 192.168.1.100，它在公网上怎么连？连不上的。客户端在第一个阶段（连接lmgrd）成功了，但在第二阶段（连接vendor daemon）卡住了。
怎么解决这个问题？
需要在lmgrd启动时加一个参数，让它告诉客户端的不是内网IP，而是公网IP。
FlexNet提供了-W参数用于这个场景：
text
lmgrd -c /path/to/license.lic -W 203.0.113.50-W参数告诉lmgrd：在给客户端返回vendor daemon地址时，用这个IP地址代替本机的实际IP。
但需要注意：-W参数在某些FlexNet版本中可能不支持。而且不同版本的语法可能略有差异。如果你用的是老版本，可能需要用其他方法（比如修改/etc/hosts做地址映射，或者在NAT设备上做应用层网关ALG）。
如果-W参数不可用，还有一个变通方案：在客户端上修改hosts文件，把192.168.1.100这个IP映射到公网IP。但前提是客户端能解析到这个映射，而且网络路由允许。
这个坑不解决，端口映射就只是做到了“能连上lmgrd”，但无法完成实际的许可证签出。
坑二：防火墙和安全策略
把端口暴露到公网上，意味着任何人都能扫描你的License Server。27000是知名端口，互联网上的扫描器每天都在扫。
一旦发现开放的27000端口，攻击者就知道你跑了个FlexNet服务。如果你的lmgrd版本有已知漏洞，被利用只是时间问题。
历史上FlexNet的某些版本确实存在远程代码执行漏洞。即使没有漏洞，攻击者也可以通过暴力破解或拒绝服务攻击让服务瘫痪。
坑三：动态IP
如果你的公网IP是动态的，今天配好了，明天变了，所有客户端都得跟着改。这在实际运维中会带来持续的维护成本。
坑四：厂商的许可条款
绝大多数软件厂商的授权协议里，都明确规定License Server必须部署在企业内部网络。把服务暴露到公网上，虽然技术上能跑通，但从合规角度来说存在风险。如果遇到厂商审计，可能会被问到“你们的License Server为什么能公网访问”这类问题。虽然审计主要是查是否有超用，但公网暴露是一个容易被额外关注的点。
下面这几个方案都比端口映射更靠谱。
方案一：VPN
最稳妥的方案。员工先拨入公司VPN，获得内网IP，然后所有内网资源（包括License Server）自然就能访问了。
VPN的优点：
缺点是需要部署VPN服务，有运维成本。但对于中大型企业来说，这笔投入值得。
方案二：SSH隧道
如果公司已经有SSH堡垒机，可以用SSH隧道做本地端口转发。
在客户端执行：
text
ssh -L 27000:192.168.1.100:27000 user@堡垒机IP然后客户端的LM_LICENSE_FILE指向27000@localhost。
所有发往localhost:27000的流量，会通过SSH隧道转发到内网的License Server上。
这个方案的优点是不需要在公网上开额外端口（SSH堡垒机本来就有），而且SSH加密了通信内容。缺点是每个客户端都需要建立SSH隧道，有一定配置门槛。
方案三：IP白名单
如果你的公网IP是固定的（比如分公司有固定的出口IP），可以在路由器或防火墙上设置白名单，只允许特定IP访问27000和27002端口。
这样即使端口暴露在公网上，也只有白名单里的IP能连进来，安全性大幅提升。
缺点是IP固定的前提不总是成立，而且维护白名单也需要人力。另外，这个方案解决的是“谁可以访问”的问题，但-W参数问题仍然需要单独处理。
如果你的公司没有VPN、没有堡垒机、也没有固定IP，端口映射可能是唯一选择。
那至少做到这几点：
端口映射方案在技术上是可运行的，但实施过程中涉及双重端口映射、-W参数适配、防火墙策略等多个环节，任何一个环节出错都会导致服务异常。
优先级排序：
如果你的场景是临时测试，端口映射可以快速验证。如果是生产环境长期使用，花时间部署VPN是更值得的投入。License Server暴露在公网上带来的风险，远比配置VPN的成本要高。
技术文档
推荐好文
155-2731-8020
