外包团队访问内网 Gitea 的三条路线，为什么其中两条在出事之后才被否掉
Gitea 跑在公司内网一台低配服务器上，外包团队要提交代码、看 Issue、做 Code Review。最直接的诱惑是把 Gitea 的 3000 端口通过端口映射暴露到公网，或者干脆放到云服务器上重搭一套。真正的问题不在搭建成本，而在出事后你有没有能力回答三个问题：谁在什么时间、从哪个设备、对哪个仓库做了哪些操作。NexTunnel 解决 Gitea 外包访问的核心方式，是把“网络可达”和“访问可审”这两件事绑定在同一条链路里，而不是先开放、再祈祷没有问题发生。
怎么评估内网 Gitea 暴露方案的访问面与审计盲区
做架构决策前，先把三种常见路线摆在同一张表里对比。表里列的是安全边界、审计能力、部署改造成本这三个对 IT 决策者最重要的维度。
访问路线 | 安全边界 | 操作审计能力 | 对现有网络的改造 |
|---|---|---|---|
公网端口映射到 Gitea 3000 端口 | 边界等同于 Gitea 自身认证强度，暴露面大 | 依赖 Gitea 日志，无法关联设备与网络入口 | 需要公网 IP 或现有网关配置端口转发 |
将代码库迁移到公有云 Gitea 实例 | 数据离开内网，合规边界外扩 | 日志受制于云平台，跨网络审计链路断裂 | 需要重新配置仓库权限、Webhook、CI 联动 |
NexTunnel Server 部署在内网侧，外包终端安装 Client 按授权访问 | 不开放公网入站端口，按设备和端口二维收敛 | 后台可见连接时间、目标端口、授权设备，与 Gitea 应用日志共同形成双段日志 | 不改动防火墙入站规则，不迁移仓库数据 |
表里没有写性能，因为 Gitea 的使用模式是间歇性 Git 操作和页面浏览。瓶颈通常不在网络延迟，而在权限失控。外包人员如果使用个人电脑或项目部共用电脑接入，只靠 Gitea 账户密码无法防止账号共享、也看不到“谁的设备在登录”。NexTunnel 的意义不是替代 Gitea 自带的认证，而是在网络入口处再加一层设备级约束，让每一次 TCP 连接到 Gitea 端口之前，先经过设备授权判断。
NexTunnel Server 放内网哪一侧，决定了审计日志能不能串起来
实施中容易被忽视的是 Server 与 Gitea 的网络位置关系。NexTunnel Server 必须部署在能够直接访问 Gitea 服务的网络区域，也就是 Gitea 所在的内网侧。它不需要和 Gitea 装在同一台机器上，但到 Gitea 的 3000 端口（或反向代理后的 80/443 端口）必须有可达路由。
部署位置的判断依据有三个：
不要跨核心防火墙做长链路转发：如果 Server 被放在 DMZ 或另一个隔离网段，那么每一次从 Server 到 Gitea 的流量都需要额外放行规则，等于把问题从一个网段移到另一个网段，访问审计的路径也会被拉长。
NexTunnel Server 到 Gitea 建议独占安全组规则：在管理后台将 Gitea 的访问端口以资源形式登记后，内网侧只有 Server 发起向 Gitea 的连接。传统方案需要允许任何来源访问 Gitea 端口，现在可以收窄到仅 Server 所在主机。
便于把 Client 连接审计与 Gitea 操作日志做时间线拼合：Server 看到的是“哪个设备的 Client 在 14:32:07 连到 Gitea 3000 端口”，Gitea 日志看到的是“哪个用户在 14:32:11 对仓库执行了 push”。两者时间窗口接近，但粒度不同。将 Server 放在稳定、低时钟漂移的内网基础设施上，这种做法才有排查价值。
[插图建议：网络拓扑示意图，展示外包终端 NexTunnel Client、NexTunnel Server 与内网 Gitea 的位置关系，突出无需公网入站端口]
给外包人员的访问授权，为什么必须按“设备加端口”而不是按“账号加仓库”来做
Gitea 自己管的是账号、组织、仓库读写权限，这层权限无法回答“是否允许这台电脑发起连接”。假定一个外包员工把 Gitea 账号密码同步在个人家里的台式机上，公司无法在网络上感知。NexTunnel 的资源授权模式要求先有设备被授权，再谈能访问哪个端口。这样做有两个直接效果。
第一，访问面从“任意互联网位置猜密码”收窄为“指定 Client 设备”。外包人员离场时，在管理后台撤销设备授权即可立即切断网络层访问，不需要等 Git 凭证轮换完成。第二，端口白名单限制爆破面。即使外包账号被盗，攻击者还需要使用已被 NexTunnel 授权的设备发起到 Gitea 端口的连接。对于分给外包团队只做代码提交的场景，管理员只需要在 NexTunnel 后台将 Gitea 的服务端口授权给指定设备，其他内网服务端口一概不可达。
落地时不要一次给 22 端口加 3000 端口。优先把要求说清楚：外包团队只走 HTTP/HTTPS 方式访问 Gitea，Git over SSH 视情况另行授权。端口授权越小，审计记录中的异常连接越容易被识别。
审计能力不是“看日志”，而是提前定好几个必须能回答的排障查询
一次外包人员反馈“传不上去代码”，可能是网络问题、Gitea 问题或客户端问题。有 NexTunnel 的访问审计能力，排查顺序会发生变化。对于每一次连接，管理后台应能回答以下基本问题：
是哪个 Client 设备在什么时候向 Gitea 端口发起请求；
连接持续了多长时间，是否异常断连；
从哪个入口建立，是 P2P 直连还是经过中继转发；
连接的是哪个资源端口，是否曾被策略拒绝或未授权。
在没有 NexTunnel 的传统映射方案里，这些信息要么分布在出口防火墙日志里，要么根本不存在。出问题后最常见的情况是运维无法确认“到底连进来了没有”。而当 NexTunnel Server 部署在内网侧后，连接记录留在管理后台，可以和外网侧的客户端状态互相印证。需要提醒的是，NexTunnel 的审计覆盖网络连接行为，Gitea 内部的代码查看、分支创建等操作日志仍然以 Gitea 自身记录为准。两者是互补而非替代关系。审计越完整的办法是：网络层连接记录以 NexTunnel 为准，应用层数据操作以 Gitea 日志为准，故障定责再看 CI 与代码托管联动记录。
P2P 直连失败时自动中继，对外包异地多网络环境适配到什么程度
外包团队可能在民宅网络、园区出口、4G/5G 热点之间切换。NAT 类型不同会导致直连成功率波动。NexTunnel 在 Client 与 Server 可以做 P2P 直连的情况下优先直连；在网络环境差异较大、对称型 NAT 限制或防火墙阻止的情况下，会通过中继转发维持连通性。中继不改变授权逻辑，也不改变审计能力。这点对交付经理很重要：他们不希望和外包远程办公人员反复沟通“换个网络再试”。人工沟通界面稳定，审计链路也不会因为网络切换而断掉。
需要考虑的是中继是否私有化。如果外包业务包含大量代码传输，走中继转发会产生额外带宽成本。NexTunnel 支持私有化中继部署，技术上由后台控制路径选择，实施时不必替用户预设“哪些网络一定走中继”。判断原则很朴素：授权设备能稳定直连就少占中继带宽，直连不通时确保访问不中断。进行割接试运行时，建议同时记录几个典型网络环境的连接路径表现，用于估算未来带宽。
落地步骤与验收清单：不只是装 Server，还要验证“关上门之后到底通不通”
面向运维的操作流程应该脱离泛泛论述，拆成可以实际执行的步骤。整个过程不是把端口映射换成另一个工具，而是改变接入模型：默认拒绝一切公网直接访问 Gitea 的路径，外包终端只能通过 NexTunnel Client 建立到 Gitea 的网络连接。
① 部署 Server 并清理旧的公网暴露端口。先安装 NexTunnel Server，位置靠近 Gitea 所在内网网段。测试期内不要立刻关闭公网映射，但要把目标切换到验证新的接入链路。公网端口全部验证成功后必须关闭或删除。
② 后台绑定资源，明确 Gitea 开放的协议端口。将 Gitea Web 用的 HTTP/HTTPS 端口登记为可访问资源。这个资源不是 Gitea 整个服务器，也不是同一主机的全部端口。只登记准备放给外包团队访问的那一类端口。
③ 给外包设备安装 Client 并发放授权。每台需要访问 Gitea 的外包终端安装 NexTunnel Client。设备安装完成后在管理后台主动授权，不要保留匿名接入入口。未授权设备不能看到服务列表，不能向内网 Gitea 地址发起连接。
④ 连接链路验证与异常记录触发规则确认。让外包人员在授权设备上打开 Gitea 页面，进行一次实际代码提交。管理员在 NexTunnel 管理后台确认出现对应连接记录，包括设备名称、目标端口、开始和结束时间，并检查是否出现中继接入记录。验收标准不是功能演示成功，而是“每次访问产生可查询连接记录”。
⑤ 应用层日志对齐与故障排查责任划分。保存 NexTunnel 连接记录与 Gitea 审计日志的时间线对照关系。后续任何跨网络问题，先查 NexTunnel 记录确认连接是否成功建立，再查 Gitea 日志确认应用层是否收到请求，大幅减少“网络问题”与“服务问题”互相推诿的时间。
最后要注意一个现实问题：P2P 直连如果无法建立，对外包终端的网关会有依赖性。验收时不要只在一个网络环境下测试一次通过就结束，建议至少覆盖外包团队常用的三种网络出口，确认在至少一种网络下有意外的长时间中继回退。此时再多关注私有化中继部署和带宽效果，避免生产阶段才发现网络方案不适配。