NexTunnel 远程访问内网 MySQL 并限制只读

远程访问 MySQL 的权限风险：为什么“能连上”本身就是隐患

远程开放 MySQL 端口最常见的做法是公网映射 3306，但端口暴露的瞬间，暴力破解扫描就开始发生。即便是改了默认端口、强密码策略，仍然面临一个结构性缺陷：只要网络可达，攻击面就存在。运维真正需要的不是“更勇敢地把数据库放到公网”，而是一种不用改网络、不用公网 IP、同时能把访问范围收缩到指定设备和只读权限的机制。NexTunnel 解决的就是这个场景：数据库继续留在内网防火墙后面，外网开发者通过 Client 连进来，而连接过程完全受控。

一个关键意识是：远程访问和内网访问不应该有相同权限。内网直连 MySQL 的账号可能具备读写权限，因为用户已经通过了办公网准入；但远程场景下，设备位置不可信、网络路径更复杂，“最小权限”必须落到只读账号。NexTunnel 的部署思路就是把权限边界从“网络边界”推进到“设备身份加账号权限”的叠加层。

NexTunnel 访问 MySQL 的链路组成与部署前提

用 NexTunnel 远程访问内网 MySQL，本质是把数据库的 TCP 3306 连接承载到一条受控通道上，而不是把端口暴露到公网。整条链路需要三个角色配合：

• NexTunnel Server：安装在企业内网侧，位置要求在能够直接访问目标 MySQL 实例的网段内。Server 不依赖公网 IP，只需出站连接到 NexTunnel 的控制面即可完成注册。对网络策略严格的企业，这一步通常不需要改动防火墙入站规则。
• NexTunnel Client：安装在远程办公或出差使用的电脑上。Client 登录后，会看到被授权可访问的企业资源列表。传统 VPN 会把用户设备整体拉入内网，Client 的优势在于只暴露被明确授权的端口和资源，不做全量网络打通。
• 传输通道：Client 与 Server 之间的数据优先尝试 P2P 直连。当两端 NAT 类型无法打洞或网络环境不允许直连时，自动切换到中继转发。中继可以是 NexTunnel 提供的，也支持私有化中继部署，数据传输在通道内完成加密，对外不暴露任何 MySQL 端口。

部署前要确认三件事：Server 所在主机能访问 MySQL 的 3306 端口（或实例实际监听端口）；Client 设备使用环境能正常出站 HTTPS，以维持控制通道；MySQL 实例本地监听的绑定地址不需要改为 0.0.0.0，保持默认内网监听即可，因为连接发起方是同一内网侧的 Server。

如何创建只读数据库账号并启用审计关联

只读限制要分两层落实，这是 NexTunnel 方案与纯端口转发方案的关键区别。端口转发只解决“通不通”，NexTunnel 叠加的设备授权解决“谁能通”，而数据库层面的只读账号解决“通过了又能做什么”。

数据库侧步骤如下：

1. 在 MySQL 中创建专用账号，例如 ro_remote，只对该业务库授予 SELECT 和必要的 SHOW VIEW 权限。不要使用已经存在的业务读写账号，也不要对远程场景授予 UPDATE、INSERT、DELETE、DDL 权限。
2. 将该账号的允许来源地址配置为内网可访问范围。由于实际连接由 Server 发起，账号来源通常会被 MySQL 识别为 Server 所在主机地址，因此不必配置为外部公网段，避免产生不必要的误判。
3. 对只读账号执行独立连接数限制。远程读操作可能包含大量慢查询或全表扫描，应避免只读会话占用实例连接池。MySQL 的资源参数可以按账号进行控制，上线前先验证最大并发数对业务无影响。

只读账号准备完成后，再回到 NexTunnel 管理后台完成资源绑定。管理员在后台添加 MySQL 资源时，选择对应的 Server 主机和内网地址与端口，再将这个资源授权给目标设备。这个授权动作越具体越好：如果一个远程账号只用来看某个业务库，资源入口就只开放到该服务端口，不要把整个网段的 SSH、Redis、Jenkins 端口一并加上。配合 NexTunnel 的设备授权和端口白名单能力，即使 Client 设备账号被盗，攻击者也只能在设备有效期内通过指定入口访问指定资源。

NexTunnel 连接与只读链路验证步骤

操作流程从管理后台开始，到客户端连接成功结束，步骤如下：

1. 内网侧完成 NexTunnel Server 安装，并在后台完成 Server 绑定，确认在线状态正常。
2. 在管理后台创建企业或项目后，添加需要开放的内网资源，指定 MySQL 实例的内网 IP 和端口。
3. 对资源进行授权，只勾选需要访问该库的远程人员对应的 Client 设备。不要在初期测试时使用“全员可见”或“全部设备”这类宽授权。
4. 外网侧安装 NexTunnel Client，登录后选择对应企业，查看被授权的资源，完成连接。
5. Client 连接成功后，在本地数据库客户端中连接该资源映射出的本地地址端口，使用前面创建的 ro_remote 账号进行验证。

验证不能停留在“能查询”。至少要执行以下检查：对业务表执行 SELECT 应成功；执行 INSERT、UPDATE、DELETE 必须报错；尝试访问未授权数据库应被拒绝；确认连接来源在 MySQL processlist 中显示为内网侧地址而非外网公网地址，以证明流量没有绕过通道直连内网。完成只读和连接路径双重验证后，再考虑开放给业务开发人员使用。

权限控制与运维审计：只读不是终点

只读限制解决了写操作风险，但远程访问还隐含另一个需求：知道谁在什么时间从哪台设备连过数据库。传统 VPN 模式下，多人共用出口 IP，事后出事很难定位到具体人。NexTunnel 的访问审计能力在此有直接价值。管理后台可以查看连接记录，审计维度包括设备、账号、目标资源和连接起止时间。管理员能够追溯某条异常查询对应的设备身份。

日常运维中常见问题及处理思路集中在以下情形：

• 连接突然中断怎么办：检查 Client 当前是直连还是中继转发，确认对应通道的地址和端口可用性。不要急于重启 Server，先在后台确认设备在线状态和审计记录中本次会话的结束原因。
• 只读账号仍能写入：大概率是 MySQL 授权规则命中范围过宽，比如用了通配符导致多个库继承权限，重新审查授权矩阵，不要直接在业务账号管理里叠加远程用途。
• 远程查询速度远低于内网：先观察是否处于中继路径，中继带宽和时延对分析型 SQL 影响很大。符合预期的做法是把大查询挪到内网数据导出平台，远程只做短时交互式查询。NexTunnel 的 P2P 直连在对称 NAT 或可打洞网络下可取得接近直连质量，但网络跨地域情况需要实测后做分场景评估。

绕开审计的一条常见操作是管理员给多个业务人员共用一个 Client 设备登录。这种做法会破坏设备授权的可靠性，建议从公司制度上禁止共享登录。更好的思路是每个远程角色使用自己的 Client 设备，连同只读账号一起纳入个人身份管理。

对比传统方案：为什么不用 SSH 隧道、VPN 或自建 FRP

很多团队在选型时会把 SSH 隧道、VPN 安装包、自建内网穿透框架放在一起比较。用一张表对比更直观：

[插图建议：此处插入一张通路对比图，上半部分为传统 VPN 或公网端口映射绕过边界后的全量暴露，下半部分为 NexTunnel Server 内网侧连接 MySQL、Client 外网侧受控访问的拓扑示意]

NexTunnel 的直接价值不在于传输效率多高，而在于网络架构不做侵入式改造的情况下，为每一条远程访问创建了设备身份、目标资源和操作账号三个维度的约束。对于有定期安全审计要求的团队，这意味着后台一条记录就能回答“今天下午的这条 SELECT 是哪一个员工从哪台机器发出的”。

上线建议与持续治理

第一阶段的落地建议采用小范围试点：选一个业务库，创建只读账号，授权两名开发人员的 Client 设备，给排查类和报表类场景使用。试运行一到两周后，再复盘审计记录中的连接时长、峰值时间分布和是否存在异常目标探测。不要把自动化任务中的生产库访问也纳入远程只读通道，自动化场景应该运行在内网任务集群中，不应依赖外部个人设备。

持续治理的重点可以放在三个方面：

• 设备生命周期：员工更换设备、设备丢失、项目交接时，原先的设备授权要能从 NexTunnel 后台及时清理，不能只从仓库权限里移除一人而设备仍可接入。
• 端口白名单：定期审查资源列表，确认没有历史遗留端口处于开放状态。一个数据库场景不应出现额外开放的 SSH、Redis 或存档服务入口。
• 远程账号巡检：每月检查 MySQL 中远程用途账号的授权变化，防止只读账号因为数据库升级或权限脚本被重新赋予写权限。

如果你目前正在用公网映射或 VPN 方式暴露过 MySQL，建议先用 NexTunnel 重建一条受控访问路径，然后逐步关闭原有端口映射。两条链路并行期间不要共用同一套数据库账号，便于在审计记录中清楚区分流量来自哪条路径。完成平稳迁移后，数据库的外网暴露面随之归零，剩下的连接均可在管理后台追溯到设备和资源的粒度。