Frp配置——stcp及p2p模式

我们在上一篇文章内网穿透神器frp——实现在家远程办公_mac,rdp,windows_黄腾霄的博客-CSDN博客中介绍了如何使用frp的tcp模式,在公网暴露内网设备的tcp服务。还根据此技术实现了对内网设备的远程桌面服务访问。今天我们来分析下这种方式存在的问题,以及可以参考的解决方案。

Frp的TCP模式问题
这里主要存在2个问题。

第一个是安全问题:

试想一下,frp的tcp模式相当于你的设备直接向公网暴露了一个tcp端口。任何设备都可以尝试连接这个端口。这里就会有很大的安全风险。

第二个问题是网络问题:

我的所有请求都需要进行frp的服务器进行中转,这里势必会造成比较大的网络延时。(尤其是我们大部分的vps是部署在国外)这对我们的服务响应速度会造成较大影响。

解决安全问题(stcp)模式
对于安全问题,frp的思路是,既然这些服务有可能被坏人攻击,那我们只要限制特定设备能够使用这个端口就好了。

那么问题来了,我怎么知道哪些设备是允许使用的呢?

服务端配置?那就又陷入了内网穿透的问题。

最简单的方法是使用密钥验证。这就是frp的Secret TCP(stcp)模式的思路。

如下图所示,frp客户端1需要暴露一个tcp端口。于是他在向服务端注册时,额外传了一个密钥。

所有其他设备期望访问这个端口,必须要先验证这个密钥。

这样一来,我们就需要在发起请求的设备上也配置一个frp客户端,通过这个客户端带着密钥发起请求。

在这里插入图片描述

如何配置

  • 服务端:配置仍然同默认配置一致,直接运行即可
  • 客户端1:配置需要将type改为stcp,并且增加一个sk字段。这里不需要远端端口,因为不公开
# frpc.ini
[common]
# 你的frp服务器的公网ip
server_addr = x.x.x.x
# 你的frp服务器的默认端口
server_port = 7000

[rdp]
type = stcp
# 只有 sk 一致的用户才能访问到此服务
sk = abcdefg
local_ip = 127.0.0.1
# 远程桌面的本地端口号
local_port = 3389
  • 客户端2: 
# frpc.ini
[common]
# 你的frp服务器的公网ip
server_addr = x.x.x.x
# 你的frp服务器的默认端口
server_port = 7000

[rdp_visitor]
type = stcp
# stcp 的访问者
role = visitor
# 要访问的 stcp 代理的名字
server_name = rdp
# 只有 sk 一致的用户才能访问到此服务
sk = abcdefg
# 绑定本地端口用于访问 远程桌面 服务
bind_addr = 127.0.0.1
bind_port = 6000

此时,你在客户端2,使用127.0.0.1:6000即可访问客户端1的远程服务。

在这里插入图片描述

在这里插入图片描述

解决网络问题(xtcp)模式
思考一下,我们的frp服务器主要目的是为了解决两台设备相互识别的情况。在正式运行时,其实并不需要服务端做什么事情。

frp客户端就好比两个相亲的对象,frp服务端是媒婆。媒婆介绍完之后,就应该有相亲对象自己聊天了。

这个就是点对点模式(p2p)。在frp中,这个可以通过设置xtcp实现。

如何配置

服务端:配置需要增加一个udp端口 7001,增加完之后就是如下

# frps.ini
[common]
bind_port = 7000
bind_udp_port = 7001
  • 客户端1:配置需要将type改为xtcp即可
# frpc.ini
[common]
# 你的frp服务器的公网ip
server_addr = x.x.x.x
# 你的frp服务器的默认端口
server_port = 7000

[rdp]
type = xtcp
# 只有 sk 一致的用户才能访问到此服务
sk = abcdefg
local_ip = 127.0.0.1
# 远程桌面的本地端口号
local_port = 3389
  • 客户端2:配置需要将type改为xtcp即可

 

# frpc.ini
[common]
# 你的frp服务器的公网ip
server_addr = x.x.x.x
# 你的frp服务器的默认端口
server_port = 7000

[rdp_visitor]
type = xtcp
# stcp 的访问者
role = visitor
# 要访问的 stcp 代理的名字
server_name = rdp
# 只有 sk 一致的用户才能访问到此服务
sk = abcdefg
# 绑定本地端口用于访问 远程桌面 服务
bind_addr = 127.0.0.1
bind_port = 6000

此时,你在客户端2,使用同样的方式,以127.0.0.1:6000即可访问客户端1的远程服务。

不过需要注意的是,目前frp的p2p服务还不完善,很多nat设备还是不能够穿透的。

此时大家还是需要切换回stcp来使用。
————————————————
版权声明:本文为CSDN博主「xinyue_htx」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/htxhtx123/java/article/details/104219317

### RTSP P2P 内网穿透实现方法 #### 配置RTSP协议以UDP或TCP传输视频流 RTSP协议支持通过UDP或TCP来传输实际的视频流。考虑到P2P底层通常由UDP实现,在配置用于P2P场景下的RTSP服务时,建议优先采用基于UDP的方式进行通信[^3]。 然而,当面对复杂的NAT环境或其他阻碍UDP直连的情况时,则应调整至TCP模式作为备选方案。具体操作是在VLC媒体播放器中选择工具—偏好设置—输入/编解码器,并在Live555流传输选项里指定RTP over RTSP (TCP)。 #### 利用STUN/TURN服务器辅助连接建立 对于大多数家庭网络而言,设备位于路由器后的私有IP地址空间内,这使得直接创建对外部互联网用户的双向数据通道变得困难。为此,引入STUN(Session Traversal Utilities for NAT)和TURN(Traversal Using Relays around NAT)服务器成为必要措施之一。这类基础设施可以帮助客户端探测自身的公共IP地址以及端口号映射关系,并提供中继转发功能以便穿越那些无法轻易打开特定端口的防火墙或复杂类型的NAT装置[^1]。 - **STUN**: 主要用来获取外部可见的信息并尝试让两端点互相发送包。 - **TURN**: 当简单的ICE候选交换失败后启用,它允许流量经过中介节点传递给目标主机。 #### 应用FRP等软件定义隧道工具 除了依赖专门设计的服务外,还可以借助像Frp这样的通用型反向代理程序完成更灵活的任务调度。例如,利用`stcp`模块可实现在不同位置间的安全透明桥接,从而间接达成类似P2P的效果而不必担心被ISP策略所限。特别是针对某些特殊应用场景如远程桌面控制,这种方法提供了极大的便利性和兼容性[^4]。 #### 考虑IPv6带来的改进机会 值得注意的是,随着全球范围内逐步推广部署下一代互联协议——IPv6,越来越多的家庭宽带接入服务商也开始为其客户提供完整的公有地址分配。这意味着理论上任何联网终端都能获得独一无二的身份标识符,进而简化了传统意义上所谓“内网”的概念及其所带来的诸多挑战。如果条件允许的话,尽可能迁移到新的架构之上不失为一种长远之计。
评论 8
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值