NPS——搭建属于你的内网穿透平台

敲得码黛

发布于 2022-04-18 17:16:31

8.6K2

发布于 2022-04-18 17:16:31

文章被收录于专栏：敲得码黛

引言

!! 在日常的开发工作中，对接第三方API是在所难免的，一些比较复杂的业务场景往往需要双向交互（指不仅仅需要请求第三方API，而且还需要第三方API回调指定地址）。一般来说开发阶段通常由开发同学在本地环境完成，再由运维同学将应用部署到公网环境中与第三方进行联调，联调过程中可能会遇到一些的问题（例如：返回值与期望值不符合、字段名不一致、状态码不一致等），于是就需要开发同学再次编写代码修复问题后丢给运维同学重新部署，运维同学部署后再次进行联调，联调过程的中如果开发同学又发现了bug，那么就需要再次修改代码并丢给运维同学重新发布。工作流程如下：开发同学编写代码——>运维同学部署——>与第三方联调——>发现Bug——>开发同学编写代码——>运维同学部署——>与第三方联调——>发现Bug——>开发同学编写代码——>运维同学部署——>与第三方联调——>发现Bug——>开发同学编写代码——>运维同学部署——>与第三方联调——>发现Bug——>开发同学编写代码。反复了十几遍后，运维同学终于崩溃了（搁着鸡生蛋蛋生鸡呢？）：运维同学气鼓鼓的说道：“我还有自己的工作任务要忙，你就不能一次性修改完所有的问题后再给我吗？” 开发同学也很无奈的说：“我也没办法呀，有些问题只能在联调时发现，我本地环境跟第三方联调不了呀。” 运维同学：“为什么联调不了？” 开发同学：“第三方需要回调我们的api，我是在本地写的代码，网络不通回调不了啊。” 运维同学：“这还不简单？一个内网穿透不就搞定了。免费的内网穿透有一个Sunny-Ngrok，但是不太稳定，或者你也可以用NPS自己搭建一个” 开发同学：“噢，好的好的，我去看一下” PS：作为一个多年的白嫖党，我首先体验了Sunny-Ngrok白嫖版，使用了一段时间后发现隧道总是时不时的就down了，而且一down就是好几天，考虑到以后可能经常需要使用，于是决定使用自己价值好几百的云服务器搭建一个内网穿透平台。

前期准备

Docker环境
云服务器（需要公网IP）
域名（可选）
官方文档(参考)：https://ehang-io.github.io/nps/#/
镜像地址(参考)：https://hub.docker.com/r/ffdfgdfg/nps
GitHub(参考)：https://github.com/ehang-io/nps/

我要白嫖

!! 个人nps平台地址：hechaoqi.cn/nps 如果没有公网服务器，或者是不想搭建的同学，可以通过微信或公众号联系我开通账号。

平台搭建

服务端搭建

下载配置文件

下载地址：https://minhaskamal.github.io/DownGit/#/home?url=https://github.com/ehang-io/nps/tree/master/conf

下载完成后，将配置文件上传至服务器，并解压，解压完成后将产生如下几个文件

[root@VM_16_15_centos conf]# pwd
/usr/docker/nps/conf
[root@VM_16_15_centos conf]# ls
clients.json  hosts.json  multi_account.conf  npc.conf  nps.conf  server.key  server.pem  tasks.json

启动服务端

为了方便移植，我将采用docker的部署方式，启动命令如下。(需注意/usr/docker/nps/conf目录是配置文件的解压目录)

[root@VM_16_15_centos nps]# docker run -d --name nps --net=host -v /usr/docker/nps/conf:/conf ffdfgdfg/nps
09de94305d60671336a5fb41a512b833a70fb4540a1bd653f1d33b6fe19b1f57
[root@VM_16_15_centos nps]# docker logs nps
2022/04/09 03:32:18.306 [I] [nps.go:202]  the version of server is 0.26.10 ,allow client core version to be 0.26.0
2022/04/09 03:32:18.568 [I] [server.go:200]  tunnel task  start mode：httpHostServer port 0
2022/04/09 03:32:18.568 [I] [connection.go:71]  web management start, access port is 8080
2022/04/09 03:32:18.568 [E] [tcp.go:80]  listen tcp 0.0.0.0:8080: bind: address already in use
2022/04/09 03:32:18.568 [E] [server.go:105]  listen tcp 0.0.0.0:8080: bind: address already in use
2022/04/09 03:32:18.571 [I] [connection.go:62]  start https listener, port is 443
2022/04/09 03:32:18.571 [I] [connection.go:36]  server start, the bridge type is tcp, the bridge port is 8024
2022/04/09 03:32:18.571 [I] [connection.go:53]  start http listener, port is 80
2022/04/09 03:32:18.571 [E] [http.go:67]  listen tcp 0.0.0.0:80: bind: address already in use

通过日志看到nps服务启动失败了，原因是80和8080端口被占用，检查一下nps.conf配置文件，发现nps默认占用了80、443、8080、8024这四个端口，其中80与443是http与https的代理端口，8080是web管理后台的端口、8024是客户端与服务端通信的端口。一般情况下我通常将80与443端口分配给nginx使用，所以在这里通过修改nps.conf，将80与443端口号修改为180与1443（http_proxy_port=180 https_proxy_port=1443），并修改初始密码（public_vkey=xxx）。然后再次启动nps

[root@VM_16_15_centos /]# docker start nps
d489c2750d90ec429d504ce4230dff169c406c349f343845af06f8be3c8e9141
[root@VM_16_15_centos /]# docker logs nps
2022/04/09 04:02:22.387 [I] [nps.go:202]  the version of server is 0.26.10 ,allow client core version to be 0.26.0
2022/04/09 04:02:22.748 [I] [connection.go:36]  server start, the bridge type is tcp, the bridge port is 8024
2022/04/09 04:02:22.749 [I] [server.go:200]  tunnel task  start mode：httpHostServer port 0
2022/04/09 04:02:22.749 [I] [connection.go:71]  web management start, access port is 8080
2022/04/09 04:02:22.753 [I] [connection.go:62]  start https listener, port is 1443
2022/04/09 04:02:22.753 [I] [connection.go:53]  start http listener, port is 180