frp
frp copied to clipboard
fatedier
建议把配置文件打包到可执行文件里，或者通过命令行传入，以减少ini文件的传播
The solution you want
Alternatives considered
How to implement this function
Application scenarios of this function
这样提，是因为每个frpc跑的时候都带有一个ini文件，这个文件里带有token，如果其他人拿到这个token就可以做其他事情了。 所以建议frpc端的配置文件，是否能在编译的时候给配置文件，然后编译进去。
如果你的需求简单，可以使用 command 模式，比如说 frpc tcp --server_addr=xxx --token=xxx --local_ip=xxx --local_port=xxx --remote_port=xxx
- 构建可执行文件后的话，传 token 值给 frp 的方式，按你的说法，理论上都可能泄漏。
- 构建可执行文件前的话，因为是你的 token，要么你自己构建？因为我们做的话，就不能对其他用户负责了。
@zsinba 需要明确你的需求具体是什么。
- 不希望同一台机器上的其他用户查看到 token。
- 不希望单个用户的 token 泄露产生影响。
- 针对第一点，可以考虑支持启动时输入 token，不记录到文件中，运行后其他人也无法查看。
- 针对第二点，可以考虑结合使用 https://github.com/gofrp/fp-multiuser 插件，可以给不同用户分配不同的 token。
@zsinba 需要明确你的需求具体是什么。
- 不希望同一台机器上的其他用户查看到 token。
- 不希望单个用户的 token 泄露产生影响。
- 针对第一点，可以考虑支持启动时输入 token，不记录到文件中，运行后其他人也无法查看。
- 针对第二点，可以考虑结合使用 https://github.com/gofrp/fp-multiuser 插件，可以给不同用户分配不同的 token。
感谢老板的回复
- 启动时输入token，这个是一个好办法。 但是如果想做重启后FRPC随机启动，就没办法了。
- 使用fp-multiuser是可以一定程度上解决共用Token的问题，但是这还是把user\pwd泄露出去了。
目前遇到的场景是这样的： FRPS就一台，通过域名或者IP对外，这都ok。 FRPC有N台，每一台映射自己的HTTP（S）、TCP、UDP（至今没用过UDP，不清楚），都需要一个.ini文件，这个文件里记录了服务器的域名或者IP地址（这个肯定是避不开的），同时还记录了Token，这个Token是共用的。 管理员可以控制FRPS的机器 ，但是FRPC的机器是任意的， 每次跑FRPC，都要提供明文的.ini文件. 这个文件有几个地方:
- 启动的时候,需要frpc -c frpc.ini这样启动,需要命令行或者bat/sh; 这增加启动的难度(知道了肯定不难嘛)
- frpc.ini文件是纯明文,里面的配置信息挺多. 特别是token 所以,期望是FRPC打包的时候,把ini文件打包进去. 因为老板你开源出来的系统 实在太方便了,分分钟编译一个出来. 所以打包进去,也很好修改配置文件. 目的: 跑frpc的时候,就一个frpc.exe或者frpc文件,直接执行. 这样一来不泄露token,二来让frpc运行非常方便.
见过最方便的客户端是"灰鸽子"远控那样. 配置一些参数,主控端直接生成一个客户端的exe出来 . 这家伙连抠脚大汉都一分钟上手.三年级不及格小孩马上会用.
真实场景: 我用海思的板子做了一个采集器,通过硬件采集视频流,然后通过RTMP,WEBRTC,RTSP,SRT待输入把采集的视频流输出.
海思的板子跑的是Linux变种,所以跑FRPC是好跑的.
为什么以在板子上面跑FRPC? 因为我要远程监控和控制板子. 两个方面的控制 ,一是通过web控制台控制,二是通过SSH控制 .这两个是通过FRPC映射出来的. 还有哪方面使用到了FRPC? 我给每个硬件一个硬件ID, 通过硬件ID来标记和远程连接它. 比如硬件ID是12345,那这个硬件的地址就是: https://12345.device.abc.com; 我相当于使用FRPC组了一个局域网. 连接到FRPS后, 组成了一个可以反向连接的"物联网"
同时,这些硬件是要提供到每个客户那边,当板子断网的时候(反正各种原因无法连接网络),就要给客户root账号做辅助排查. 这里,FRPC就完全暴漏了.
所以,期望是FRPC编译出来 ,是一个可执行文件,直接丢到服务里跑就成.
@zsinba 如果你担心手动重启后会影响到后续的重新运行，可以提供一种方式将 token 通过加密的方式存储在机器上，其他人也看不到，frpc 启动时可以读取加密的内容做解密后运行，加密的内容中可以加入一些机器信息，确保无法简单复制到其他机器上运行。
编译进二进制，这个你可以自己修改代码来实现，实际上也并不复杂。
@zsinba 如果你担心手动重启后会影响到后续的重新运行，可以提供一种方式将 token 通过加密的方式存储在机器上，其他人也看不到，frpc 启动时可以读取加密的内容做解密后运行，加密的内容中可以加入一些机器信息，确保无法简单复制到其他机器上运行。
编译进二进制，这个你可以自己修改代码来实现，实际上也并不复杂。
加密的方式也可以.这也是好办法. 期望能加入.
我个人建议参考wireguard的Peer鉴别方式
- 服务器上必须记录每个客户端的PublicKey，而服务器本身保存好自己的PrivateKey
- 每个客户端记录服务器的PublicKey，而每个客户端本身保存好自己的PrivateKey即可
可以考虑在ini中配置token从环境变量读取 通过shell脚本执行启动命令的时候用户从控制台输入token配置到环境变量里 启动服务时ini从环境变量读取到token 启动完成后清除环境变量的token 这样其他用户查看ini就只知道token是从环境变量来的 但是因为这个环境变量已经被清除所以无法读取到token的内容
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/ 之前使用cloudflare tunnel的方式也不错，只给客户端分配不同的token启动，其他配置全部在服务端完成 如果能进一步根据每个设备生成唯一id做验证，也可以解决token泄露的问题了吧
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/ 之前使用cloudflare tunnel的方式也不错，只给客户端分配不同的token启动，其他配置全部在服务端完成 如果能进一步根据每个设备生成唯一id做验证，也可以解决token泄露的问题了吧
本喵也覺得這是最好的方式
現在無論是token 還是PrivateKey都需要客戶端保管好否則就會被濫用，無論存儲在環境變量配置檔案還是嵌入可執行程序都存在被讀取的可能。服務器提供的功能由客戶端指定感覺就不是安全合理的設計。應該由服務器配置好自己爲哪些客戶端提供反代服務(例如兩個不同客戶端都要映射9000端口，服務器怎麼處理都不合理)，然後驗證連接的客戶端只爲它提供相應的服務。這樣即使客戶端token泄漏影響也有限(不會影響其它未泄漏的客戶端服務)
@zuiwuchang 那你可以考虑试试看结合这里的插件使用。https://github.com/gofrp/plugin#%E4%B8%AD%E6%96%87%E6%8F%92%E4%BB%B6
目前插件机制可能还不是很优雅，后面的方向就是提高扩展能力，各种额外的需求都由插件或外部应用来控制管理，负责和 frp 进行交互。这个项目不会花太多精力在一些用户管理之类的功能上，没有那么多时间，除非以后直接做面向终端用户的收费产品。
大的方向就是 v2 的设计，在 about-v2 里有说，但是目前也没有太多精力，一次搞一个完整的新的架构实在是太困难，所以可能还是在当前版本上慢慢过渡，一点一点重构到新的架构，中间也可能会有一些不兼容的更新。
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/ 之前使用cloudflare tunnel的方式也不错，只给客户端分配不同的token启动，其他配置全部在服务端完成 如果能进一步根据每个设备生成唯一id做验证，也可以解决token泄露的问题了吧
的确 ， 这种方式是比较好用的。 但是CF Tunnel在国内并不好用。 国内也没有开源平替的产品； 国内的云服务器的CDN可以对外提供服务， 但是还是需要公网 ip才好和CDN交换数据；
另外 一方面， 如果国内云服务商提供CF Tunnel的产品，最终还是因为流量费（8毛一吉）没法大量使用。
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/ 之前使用cloudflare tunnel的方式也不错，只给客户端分配不同的token启动，其他配置全部在服务端完成 如果能进一步根据每个设备生成唯一id做验证，也可以解决token泄露的问题了吧
这个就是nps的策略啊,客户端只需要用服务端签发的token注册上去就不管了,其他所有的控制,全放在服务端,和frp完全是反着来得的. 就算这个token泄露了,其他客户端用这个连上之后也干不了任何事情
老实说→_→ 如果诸位真的需要类似nps的策略，那为什么不用隔壁【字母+数字+3个字母】？虽然我知道这完全是两个不同设计的工具，但是如果frp改成那种模式的话其实等于就是了。
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/ 之前使用cloudflare tunnel的方式也不错，只给客户端分配不同的token启动，其他配置全部在服务端完成 如果能进一步根据每个设备生成唯一id做验证，也可以解决token泄露的问题了吧
这个就是nps的策略啊,客户端只需要用服务端签发的token注册上去就不管了,其他所有的控制,全放在服务端,和frp完全是反着来得的. 就算这个token泄露了,其他客户端用这个连上之后也干不了任何事情