内网映射方案(lanproxy)

简介: 现状现在运营商提供的宽带服务,无论是动态IP,还是固定IP,默认都是禁止所有端口服务的(目前了解上海是这样的),在路由器上配置的端口映射和DMZ都失效。

现状

现在运营商提供的宽带服务,无论是动态IP,还是固定IP,默认都是禁止所有端口服务的(目前了解上海是这样的),在路由器上配置的端口映射和DMZ都失效。申请开通端口需要域名备案,过程比较繁琐。
运营商这么做是为了防止个人随意开设各种非法服务,也防止黑客通过扫描器进行抓鸡和批量扫描。这样封禁,虽然一定程度上保证了我们的网络安全,比如说前段时间的勒索病毒正因为国内大部分用户没有独立的公网IP,并且操作系统最容易爆发漏洞的一些,135,139等端口被运营商封禁了,使得国内个人家庭电脑中招的概率小了很多;但是导致即使有公网IP,也无法使用常用端口向外网提供服务。

解决方案

通过NAPT原理得知:NAPT实现了内网主机在没有公网IP的情况下访问公网主机。
那么我们可以这样做:假设公网IP为23.23.23.23,内网IP为192.168.1.2。
公网主机先监听80端口,监听这个端口是用于向外部提供一个HTTP服务,80是WEB服务器的默认端口。同时其他任意一个端口(这里我们假设为7777),监听这个端口是用于让内网服务器主动连接进来打通一个隧道。接着内网再主动向公网主机的7777发起一个请求,这样内网就成功与公网主机建立了一个连接通道。

然后当有任何客户端主动连接公网的80端口时,公网接收到连接请求之后马上把这连接请求通过先前建立好的隧道转发到内网主机,内网主机接收到来自隧道的数据包后再主动连接内网主机自身的80端口,连接成功之后将数据包原封不动地转发数据包给80端口,待HTTP服务器程序处理完这个数据包,生成了响应报文之后再原路转发回去,最终到达公网的80端口,然后返回给最开始请求公网服务器80端口的客户端。


image

大名鼎鼎的花生壳内网版以及nat123等内网穿透工具的原理基本就是如此。

https://juejin.im/entry/59f2ed94518825098951554c

lanproxy

lanproxy是一个将局域网个人电脑、服务器代理到公网的内网穿透工具,目前仅支持tcp流量转发,可支持任何tcp上层协议(访问内网网站、本地支付接口调试、ssh访问、远程桌面...)。目前市面上提供类似服务的有花生壳、TeamViewer、GoToMyCloud等等,但要使用第三方的公网服务器就必须为第三方付费,并且这些服务都有各种各样的限制,此外,由于数据包会流经第三方,因此对数据安全也是一大隐患。

1,服务器配置

服务器如腾讯云服务器、阿里云服务器,必须有独立IP。
下载lanproxy-server-20171116.zip,解压后放到服务器上。
server的配置文件放置在conf目录中,配置 config.properties

server.bind=0.0.0.0

#与代理客户端通信端口
server.port=4900

#ssl相关配置
server.ssl.enable=true
server.ssl.bind=0.0.0.0
server.ssl.port=4993
server.ssl.jksPath=test.jks
server.ssl.keyStorePassword=123456
server.ssl.keyManagerPassword=123456

#这个配置可以忽略
server.ssl.needsClientAuth=false

#WEB在线配置管理相关信息
config.server.bind=0.0.0.0
config.server.port=8090
config.admin.username=admin
config.admin.password=admin

代理配置,打开地址 http://ip:8090 ,使用上面配置中配置的用户名密码登录

image

添加客户端:


image

配置客户端:


image

示例是将公网的80、443端口映射到内网主机的80、443端口。

2,Java客户端配置

Java client的配置文件放置在conf目录中,配置 config.properties

#与在proxy-server配置后台创建客户端时填写的秘钥保持一致;
client.key=
ssl.enable=true
ssl.jksPath=test.jks
ssl.keyStorePassword=123456

#这里填写实际的proxy-server地址;没有服务器默认即可,自己有服务器的更换为自己的proxy-server(IP)地址
server.host=lp.thingsglobal.org

#proxy-server ssl默认端口4993,默认普通端口4900
#ssl.enable=true时这里填写ssl端口,ssl.enable=false时这里填写普通端口
server.port=4993

java客户端需要以下环境:

  • 安装java1.7或以上环境
  • linux(mac)环境中运行bin目录下的 startup.sh
  • windows环境中运行bin目录下的 startup.bat

3,其他平台客户端

不用java客户端的可以使用下面提供的各个平台的客户端,省去安装java运行环境

源码地址
https://github.com/ffay/lanproxy-go-client

发布包
https://github.com/ffay/lanproxy-go-client/releases

普通端口连接

# mac 64位
nohup ./client_darwin_amd64 -s SERVER_IP -p SERVER_PORT -k CLIENT_KEY &

# linux 64位
nohup ./client_linux_amd64 -s SERVER_IP -p SERVER_PORT -k CLIENT_KEY &

# windows 64 位
./client_windows_amd64.exe -s SERVER_IP -p SERVER_PORT -k CLIENT_KEY

SSL端口连接

# mac 64位
nohup ./client_darwin_amd64 -s SERVER_IP -p SERVER_SSL_PORT -k CLIENT_KEY -ssl true &

# linux 64位
nohup ./client_linux_amd64 -s SERVER_IP -p SERVER_SSL_PORT -k CLIENT_KEY -ssl true &

# windows 64 位
./client_windows_amd64.exe -s SERVER_IP -p SERVER_SSL_PORT -k CLIENT_KEY -ssl true

实测

image

查看管理后台的数据统计,有访问流量,说明转发成功!

目录
相关文章
|
4月前
|
测试技术
优化if-else的11种方案
优雅编码不仅提升程序效率,也增进代码可读性与维护性。通过早返回减少嵌套逻辑、运用三元运算符简化条件判断、采用`switch-case`优化多分支结构、实施策略模式灵活应对不同情境、利用查找表快速定位处理方式、封装函数明确职责划分、应用命令模式解耦操作与调用、引入状态模式管理复杂状态变化、重构条件表达式以增强清晰度、运用断言确保前提条件、及合理异常处理等十大技巧,使代码更加精炼与优雅。
69 4
优化if-else的11种方案
|
2月前
|
编解码 前端开发 UED
多屏幕适配方案
【10月更文挑战第7天】
48 1
|
4月前
|
弹性计算 应用服务中间件 持续交付
阿里云应用方案
为拥有传统单体和微服务架构混合的电商企业提供阿里云应用方案。该方案利用阿里云服务器迁移中心(SMC)实现IDC服务器到ECS的快速自动迁移,并通过云效建立自动化部署流水线。微服务应用则采用企业级分布式应用服务EDAS进行无缝迁移。数据迁移方面,实施多租户隔离与统一管理规范,确保数据迁移的安全性与合规性。此方案旨在帮助企业平滑迁移上云,优化资源管理,加速业务响应,并保障数据安全与业务连续性,助力数字化转型。
|
7月前
|
移动开发 HTML5
小气泡功能在中的两种实现方案
小气泡功能在中的两种实现方案
55 0
小气泡功能在中的两种实现方案
|
7月前
|
SQL 存储 缓存
后端架构优化方案探讨
【2月更文挑战第6天】在当今互联网时代,后端的稳定性和高效性至关重要。本文从数据库设计、服务器负载均衡、缓存策略等方面,探讨了后端架构优化的方案,旨在提供一些实用性的建议。
|
7月前
|
存储 运维 数据库
不敢书面化的解决方案就不是好方案
不敢书面化的解决方案就不是好方案
|
数据采集 监控 网络架构
火力发电厂辅控网改造方案及网络架构分析
本文简要的介绍了火力发电厂辅控网改造后的通讯方式,对辅控网网络架构及数据采集方式进行了分析。
火力发电厂辅控网改造方案及网络架构分析
|
数据可视化 数据挖掘 大数据
方案_技术方案|学习笔记
快速学习方案_技术方案
173 0
方案_技术方案|学习笔记
|
前端开发 JavaScript NoSQL
6款 Retool 最佳替代方案
本篇文章的目的通过低代码平台使用者的视角引出细节,了解他们为什么使用低代码平台以及会选择哪个低代码平台来加速内部系统的开发。
829 0
6款 Retool 最佳替代方案
|
SQL 缓存 测试技术
预告片优化方案
 看了一下代码,同时在线上做了观察压测。个人总结这个接口问题在于太过于依赖缓存,根本不会走DB。依赖缓存造成了依赖缓存的数据结构。首先要从缓存中取出一堆数据。而且要走两次,一次取正片的信息,一次取专辑内所有视频的信息。取出来的信息在CPU里计算筛选,排序。本身缓存取数据就比较快,再加上计算量大。其实我们并发量最大的api接口们都是采用这个模式设计的。调用的多了,我觉得我真是压测的狠的话,会造成CPU密集。其实现在的缓存之类的都可以持久化了,完全可以当数据库用。但是关系型数据作为一个长久的经典还有一个很重要的原因:保持一个IO和CPU使用的平衡。
预告片优化方案