1. 项目概述从“能用”到“安全可用”的内网穿透最近在帮几个朋友的公司和工作室部署内网穿透服务发现一个挺普遍的现象很多人把 frp 跑起来能在外网访问到内网的服务器、NAS或者开发环境就觉得大功告成了。但一问到安全配置比如认证、访问控制往往就停留在默认状态或者只是简单改了个端口。这其实埋下了不小的隐患。frp 本身是一个非常优秀、轻量的内网穿透工具但它的默认配置是为了快速上手在安全方面是“裸奔”的。一旦暴露在公网你的服务就可能成为扫描器眼中的“肉鸡”或者被未授权的用户随意访问。所以今天我们不聊怎么把 frp 搭起来这个教程已经满天飞了我们深入聊聊怎么把它“锁”好。核心就围绕标题里的三个关键词内网穿透、认证配置、安全配置 TOKEN。我会结合实际的部署案例拆解从服务端到客户端如何通过一套组合拳将你的 frp 服务从“门户大开”变成“固若金汤”。无论你是个人开发者管理测试环境还是小团队需要远程办公接入这些配置都是让你的服务能长期、稳定、安全运行的基础。2. 核心安全风险与设计思路拆解在开始配置之前我们必须清楚我们正在对抗什么。一个暴露在公网的 frp 服务端frps主要面临以下几类风险2.1 未授权访问与代理滥用这是最直接的风险。如果没有任何认证任何人只要知道了你的 frps 服务器地址和端口就可以启动自己的 frpc 客户端将他的内网服务通过你的服务器穿透出去。你的服务器就成了免费的公共代理节点消耗你的带宽和资源甚至被用于非法活动。2.2 身份仿冒与中间人攻击即使设置了密码如果通信是明文的攻击者可以在网络中窃听获取你的认证信息然后冒充合法的客户端进行连接。2.3 服务端资源耗尽与DDoS恶意客户端可以建立大量连接或者配置大量无用的代理耗尽服务端的连接数、内存等资源导致正常服务不可用。2.4 客户端被恶意服务端欺骗客户端frpc同样面临风险。如果客户端配置错误连接到了一个恶意的 frps那么内网服务的流量就会被导向这个恶意服务器导致数据泄露。基于这些风险我们的安全设计思路应该是分层、纵深防御的第一层网络层隔离与最小化暴露。通过防火墙策略仅开放必要的端口并且可以考虑将 frps 置于非标准端口。第二层强身份认证。确保只有持有合法凭证的客户端才能连接到服务端。这是最核心的一环。第三层通信链路加密。防止通信内容被窃听和篡改。第四层细粒度访问控制。即使客户端认证通过也要限制其能代理哪些端口、哪些协议。第五层客户端自身安全。保护客户端的配置文件防止密钥泄露。接下来我们就围绕认证配置和安全配置 TOKEN这两个核心点展开详细的实操。3. 认证配置详解从基础密码到TOKEN鉴权frp 提供了多种认证机制从简单的静态密码到更安全的动态 Token我们需要根据场景选择。3.1 基础认证密码authentication.method与authentication.token在 frps 和 frpc 的配置文件中都有一个[common]段落。最基础的认证是在这里设置一个相同的静态密码Token。服务端配置示例[common] bind_port 7000 # 启用认证并设置认证方法为 token authentication.method token # 设置一个强密码作为 token authentication.token YourStrongPassword123!#客户端配置示例[common] server_addr your_server_ip server_port 7000 # 必须和服务端保持一致 authentication.method token authentication.token YourStrongPassword123!# [web] type tcp local_ip 127.0.0.1 local_port 80 remote_port 8080注意这里的authentication.token是一个静态字符串。它的安全性完全依赖于这个字符串的复杂性和保密性。务必使用高强度密码大小写字母、数字、特殊字符组合长度大于16位并确保配置文件权限如 Linux 下的 600 权限不被他人读取。3.2 OIDC 动态令牌认证对于企业级应用或需要集成现有身份体系如微软 Entra ID, Okta, Keycloak的场景静态 Token 就不够用了。frp 支持基于 OIDC 的动态认证。工作原理frpc 启动时会根据配置向指定的 OIDC Provider身份提供商发起认证请求获取一个具有时效性的 Access Token然后用这个 Token 去连接 frps。frps 会向同一个 OIDC Provider 验证该 Token 的有效性。配置核心参数authentication.method oidcauthentication.oidc_client_id: 在 OIDC Provider 注册的应用 Client ID。authentication.oidc_client_secret: 对应的 Client Secret。authentication.oidc_issuer: OIDC Provider 的颁发者地址例如https://login.microsoftonline.com/your-tenant-id/v2.0。authentication.oidc_audience: Token 的受众通常就是 Client ID。服务端配置示例[common] bind_port 7000 authentication.method oidc authentication.oidc_issuer https://your-oidc-provider.com authentication.oidc_audience your-frp-client-id客户端配置示例[common] server_addr your_server_ip server_port 7000 authentication.method oidc authentication.oidc_client_id your-frp-client-id authentication.oidc_client_secret your-client-secret authentication.oidc_issuer https://your-oidc-provider.com authentication.oidc_audience your-frp-client-id # 可选指定Token缓存路径避免频繁获取 authentication.oidc_token_cache_file ./frpc_oidc_token.cache实操心得OIDC 配置相对复杂需要先在身份提供商那里创建应用、配置回调地址frp 通常不需要因为它使用客户端凭证模式。它的最大好处是实现了集中化的用户管理和认证员工离职后只需在身份提供商禁用账号而无需逐个修改 frp 的 Token。对于小型团队或个人静态 Token 更简单对于超过10人的团队建议考虑 OIDC。4. 全方位安全加固配置实操认证只是第一道门。要构建一个健壮的 frp 服务还需要一系列的安全配置组合拳。4.1 启用 TLS 加密通信无论认证密码多复杂如果通信过程是明文的一切皆有可能被窃听。frp 支持在控制连接和数据通道上启用 TLS 加密。准备证书你可以使用自签名证书用于测试或内部环境或由 Let‘s Encrypt 等机构签发的证书。这里以自签名证书为例# 生成CA私钥和根证书 openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj /CCN/STGD/LSZ/OMyOrg/CNMyRootCA # 生成服务器端证书 openssl genrsa -out server.key 2048 openssl req -new -key server.key -out server.csr -subj /CCN/STGD/LSZ/OMyOrg/CNyour_server_ip openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 3650 -sha256将生成的server.crt和server.key放到 frps 所在服务器ca.crt需要分发给所有 frpc 客户端。服务端配置[common] bind_port 7000 authentication.method token authentication.token YourStrongPassword123!# # 启用TLS仅允许加密连接 tls_only true # 指定服务端证书和密钥 tls_cert_file /path/to/server.crt tls_key_file /path/to/server.key # 可选强制验证客户端证书双向TLS更安全 # tls_trusted_ca_file /path/to/ca.crt客户端配置[common] server_addr your_server_ip server_port 7000 authentication.method token authentication.token YourStrongPassword123!# # 指定受信任的CA证书以验证服务端身份 tls_enable true tls_trusted_ca_file /path/to/ca.crt # 如果服务端启用了双向TLS客户端也需要配置证书 # tls_cert_file /path/to/client.crt # tls_key_file /path/to/client.key4.2 配置细粒度访问控制认证通过后我们还需要限制客户端能做什么。这主要通过服务端的allow_ports和客户端的privilege_mode等配置实现。服务端限制可用端口范围[common] bind_port 7000 authentication.method token authentication.token YourStrongPassword123!# # 只允许客户端绑定10000-10100范围内的远程端口 allow_ports 10000-10100这样即使客户端配置了remote_port 8080连接也会被拒绝因为 8080 不在允许范围内。这可以有效防止客户端滥用端口。客户端使用低权限模式在 frpc 的每个代理配置中可以设置privilege_mode false。在这种模式下客户端不能动态请求新的代理只能使用配置文件中预先定义好的代理。这需要服务端配合在 frps 中为每个客户端预设代理配置通过privilege_mode_tokens配置更复杂但安全性最高适用于完全托管的环境。4.3 网络层与系统层加固防火墙策略在 frps 的服务器防火墙如 iptables, firewalld, 云服务商安全组上严格限制入站规则。只对外开放 frps 的绑定端口如 7000和你计划映射的远程端口如 10000-10100。禁止所有其他端口的入站访问。使用非标准端口将 frps 的bind_port从默认的 7000 改为一个不常见的高位端口如 37172可以减少被自动化扫描工具发现的概率。限制服务器访问配置 frps 的bind_addr例如设置为127.0.0.1或内网 IP然后通过反向代理如 Nginx来暴露服务让 Nginx 来处理 SSL 卸载、访问日志、速率限制等安全性更高。配置文件权限确保frps.ini和frpc.ini的权限设置为仅所有者可读如chmod 600 frps.ini防止密码泄露。定期更新关注 frp 项目的 GitHub 发布页及时更新到最新版本修复已知安全漏洞。5. 一个完整的企业级安全配置案例假设我们有一个小团队需要安全地访问内网的 GitLab 和 Jenkins。我们将使用静态Token认证TLS加密端口范围限制的组合方案。5.1 服务端配置frps_full.ini[common] # 网络与基础 bind_addr 0.0.0.0 bind_port 34789 # 使用非标准端口 kcp_bind_port 34789 # 如需KCP端口一致 vhost_http_port 8080 # HTTP反向代理端口按需开启 vhost_https_port 8443 # HTTPS反向代理端口按需开启 # 安全核心配置 authentication.method token authentication.token MyTeamSecureFrpToken2024! # 强密码 # TLS加密 tls_only true tls_cert_file /etc/frp/tls/server.crt tls_key_file /etc/frp/tls/server.key # 访问控制 allow_ports 20000-20050 # 只开放50个端口供映射 # 管理与监控 dashboard_addr 0.0.0.0 dashboard_port 7500 dashboard_user admin dashboard_pwd AnotherStrongDashboardPwd! # 控制台密码不要和token一样 enable_prometheus true # 开启监控指标 # 资源与连接限制 max_pool_count 50 max_ports_per_client 5 # 每个客户端最多用5个端口 subdomain_host frp.yourdomain.com # 自定义域名用于HTTP类型代理5.2 客户端配置frpc_gitlab.ini[common] server_addr frp.yourcompany.com # 建议用域名不要直接用IP server_port 34789 authentication.method token authentication.token MyTeamSecureFrpToken2024! tls_enable true tls_trusted_ca_file /etc/frp/tls/ca.crt # 连接保活 heartbeat_interval 30 heartbeat_timeout 90 # 代理GitLabHTTPS [gitlab-https] type tcp local_ip 192.168.1.100 # 内网GitLab服务器IP local_port 443 remote_port 20000 # 使用允许范围内的端口 # 可选绑定自定义域名需服务端配置subdomain_host # custom_domains gitlab.yourcompany.com # 代理JenkinsHTTP [jenkins-http] type tcp local_ip 192.168.1.101 local_port 8080 remote_port 20001 # 代理一个内部Web服务使用HTTP反向代理特性 [internal-web] type http local_ip 192.168.1.102 local_port 3000 custom_domains internal-app.frp.yourcompany.com # HTTP认证再加一层保护 http_user webuser http_pwd WebAppPwd1235.3 部署与启动将证书文件、配置文件放到安全目录。设置严格的文件权限chmod 600 /etc/frp/tls/*.key /etc/frp/*.ini。使用 systemd 管理服务确保异常退出后自动重启。服务端 systemd 单元文件示例/etc/systemd/system/frps.service[Unit] DescriptionFrp Server Service Afternetwork.target [Service] Typesimple Usernobody # 使用非root用户运行 Restarton-failure RestartSec5s ExecStart/usr/local/bin/frps -c /etc/frp/frps_full.ini ExecReload/usr/local/bin/frps reload -c /etc/frp/frps_full.ini LimitNOFILE1048576 [Install] WantedBymulti-user.target启动并设置开机自启sudo systemctl enable --now frps。6. 常见问题排查与安全运维技巧即使配置得当在实际运行中也可能遇到问题。这里记录几个我踩过的坑和排查技巧。6.1 连接失败问题排查表问题现象可能原因排查步骤连接服务端失败1. 网络不通/防火墙阻断2. 服务端未启动3. 端口错误1.telnet server_ip server_port测试连通性。2. 登录服务器检查 frps 进程 ps aux认证失败1. Token 不一致2. OIDC 配置错误3. TLS 证书问题1. 仔细核对 frps 和 frpc 的authentication.token确保完全一致注意空格。2. 检查 OIDC 的 issuer, client_id, secret 是否正确网络是否可达 OIDC 服务。3. 检查 TLS 证书路径、权限以及 CA 证书是否受信。可尝试暂时关闭 TLS (tls_enable false) 测试是否为证书问题。无法绑定远程端口1. 端口被占用2.allow_ports限制3.max_ports_per_client超限1. 在服务端使用 netstat -tlnpDashboard 无法访问1. 未启用或配置错误2. 防火墙/安全组3. 绑定地址错误1. 确认dashboard_port已配置且不为0。2. 检查dashboard_addr如果是0.0.0.0则监听所有IP。3. 确保服务器防火墙放行了 dashboard 端口。6.2 安全运维技巧Token 轮换策略对于静态 Token应制定定期更换策略如每季度。更换时先在 frps 配置新 Token 并重启然后分批更新 frpc 配置并重启实现平滑过渡。使用配置管理工具如 Ansible可以简化此过程。日志审计启用 frps 的详细日志并配置日志轮转和集中收集如 ELK Stack。定期审查日志关注认证失败、异常连接等事件。[common] log_file /var/log/frps.log log_level info # 生产环境建议用 info调试时用 debug log_max_days 7使用 TCP MUX 多路复用在[common]部分设置tcp_mux true默认开启。这可以大幅减少大量连接时的资源消耗提升性能和安全防护能力因为连接数更少。客户端自动重连与健康检查确保客户端配置了login_fail_exit false这样认证失败或网络中断后会不断重试。对于关键服务可以在客户端机器上编写脚本通过检查本地服务端口和 frpc 进程状态来实现双重重启保障。备份与版本控制所有配置文件尤其是包含 Token 的应进行加密备份并纳入版本控制系统如 Git便于追踪变更和快速恢复。切记不要在版本库中明文存储密码可以使用ansible-vault等工具加密或使用占位符在部署时替换。安全是一个持续的过程而不是一次性的配置。对于 frp 这样的内网穿透工具保持“最小权限”和“纵深防御”的原则定期审查和更新你的配置才能让它真正成为业务的高效助力而非安全短板。