怎么用 NexTunnel 远程访问内网 Gitea 代码仓库并保留访问审计
出差途中想提交代码，却发现公司的 VPN 令牌过期、IT 还没回消息，而公网直接暴露 Gitea 又过不了安全评审——这是很多开发者的实际处境。NexTunnel 通过内网 Server 加外网 Client 的方式，不需要公网 IP、不改造网络，还能把远程访问和操作审计串起来。
下边把方案对比、部署步骤、权限收敛和审计落地讲清楚。
Gitea 远程访问三种方案对比：公网映射、传统 VPN 与 NexTunnel
选型前先看差异。公网端口映射、传统 VPN 和 NexTunnel 在 Gitea 这个具体场景下差别很大：
| 方案 | 公网 IP 要求 | 端口暴露面 | 访问控制粒度 | 审计能力 |
|---|---|---|---|---|
| 公网端口映射 | 必须有 | Gitea 直接暴露，扫描风险高 | 仅靠防火墙规则，粒度粗 | 依赖 Gitea 自身日志，来源 IP 混乱 |
| 传统 VPN | 通常需要 | VPN 网关暴露，内网横向风险大 | 用户级，难以限制到端口 | 连接日志粗，操作审计难关联 |
| NexTunnel | 不需要 | 不开放入站端口，仅出站连接 | 设备级授权 + 端口白名单 | 连接审计与操作日志可关联 |
公网映射会把 Gitea 的 Web 界面、仓库浏览、API 入口全部暴露给互联网，任何扫描器都可能找到它。VPN 收口了入口，但用户接入后往往能访问整个内网网段，对 Gitea 这种只需要一两个端口的场景权限过大。NexTunnel 的点对点访问模型更适合这类业务。
NexTunnel 部署流程：内网装 Server，外网装 Client
NexTunnel 的模型很直接：内网侧安装 NexTunnel Server，外网电脑安装 NexTunnel Client。Server 部署在 Gitea 所在内网中，不需要公网 IP，也不需要路由器做端口映射。Server 安装后与 NexTunnel 的控制平面建立出站连接，外网 Client 在后台被授权后才能通过隧道访问 Gitea。
部署时的关键操作如下：
- 在一台能访问 Gitea 的内网主机上安装 NexTunnel Server，登录管理后台完成绑定。
- 在后台添加 Gitea 资源，指定 Gitea 所在主机的内网地址和服务端口。
- 在外网电脑安装 NexTunnel Client，登录同一企业管理账号。
- 在后台将 Gitea 资源授权给该 Client 设备。
- Client 连接成功后，通过本地访问入口打开 Gitea 页面或执行 Git 操作。
这套部署不要求修改现有网络设备，也不需要在公司防火墙开入站端口。当 Client 与 Server 的网络条件允许时，NexTunnel 会尝试建立 P2P 直连，流量不经中继；如果直连失败，则自动切换中继转发。对于有数据合规要求的团队，还可以选择私有化中继部署，让中继节点也跑在自有基础设施内。
端口白名单与设备授权：把 Gitea 访问权限收紧到最小
通过 NexTunnel 发布 Gitea 时，不建议放行整个内网主机，而是要在资源层面做端口白名单。Gitea 通常只需要 Web 端口和可选的 SSH 端口，如果同一台机器还跑着数据库或其他内部服务，端口白名单可以避免远程设备顺带访问这些额外端口。
- 资源级端口白名单：只放行 Gitea 实际使用的端口，其他端口默认不通，避免横向扩展。
- 设备授权：Gitea 资源只绑定给指定 Client 设备，其他设备即使在同一个 NexTunnel 企业下，也看不到该资源的入口。
- 不暴露公网：Server 只做出站连接，外部扫描无法直接命中 Gitea，公网攻击面大幅收敛。
实际配置时，在 NexTunnel 管理后台添加 Gitea 资源后，先确认资源只包含 Gitea 服务端口，再逐个授权外网设备。设备授权可以随时撤销，撤销后对应 Client 立即失去访问能力，不需要修改 Gitea 自身配置。
访问审计怎么落地：NexTunnel 连接记录与 Gitea 操作日志联动
远程访问 Gitea 的审计需要两层信息：谁在什么时间从哪台设备建立了连接，以及连接后做了什么操作。NexTunnel 的审计记录负责前者，Gitea 自身日志负责后者。
NexTunnel 管理后台记录每个设备的连接事件，包括设备标识、连接时间、访问的资源、使用的转发方式（P2P 或中继）等信息。Gitea 则记录 clone、pull、push、仓库查看等代码操作。由于外网设备通过 NexTunnel 访问时，Gitea 看到的来源 IP 通常是内网 Server 地址或隧道地址，单看 Gitea 日志无法判断具体是哪台外网设备，需要按时间戳和资源关联到 NexTunnel 的连接审计。
实操核对路径如下：
- 在 Gitea 日志中发现异常 clone 或 push 行为，记录精确时间。
- 在 NexTunnel 管理后台按时间范围查看连接审计，找到该时间段访问 Gitea 资源的设备。
- 结合设备授权记录，确认该设备是否被允许访问 Gitea。
- 如果发现未授权设备或异常连接时长，在后台撤销授权或调整资源端口白名单。
这种方式不需要改造 Gitea 本身，也不需要额外部署日志采集系统。只要 NexTunnel 的审计功能保持开启，连接侧的证据链就可以随时回溯。需要注意的是，Server、Client 和 Gitea 主机的系统时间应保持同步，否则审计关联时容易出现时间对不上的情况。
排障清单与上线节奏
远程访问链路涉及 Server、Client、中继或 P2P 通道，排障时需要按层检查。以下是常见问题和排查方向：
- Client 无法看到 Gitea 资源：检查设备授权是否生效、Client 是否在线、资源是否已绑定到对应 Server。
- 连接建立但 Gitea 打不开：确认 Server 所在主机能访问 Gitea 的内网地址和端口，资源端口白名单是否包含 Gitea 端口。
- 访问速度慢：确认当前连接走的是 P2P 直连还是中继转发，如果中继链路不理想，可考虑部署私有化中继或优化网络环境。
- 审计记录缺失：确认审计功能在后台已启用，Server 与 Client 版本匹配，且时间同步正常。
上线时建议先在测试环境部署一台 NexTunnel Server，关联测试 Gitea 实例，授权 1-2 个开发设备验证完整流程。稳定后再推广到正式 Gitea 仓库，并按照团队规模分批授权设备。对于安全要求较高的团队，优先使用私有化中继部署，将隧道流量限制在企业可控链路上，同时每季度导出 NexTunnel 审计记录与 Gitea 操作日志做一次联合复核。