NexTunnel 实现外包人员受限访问内网 GitLab 指定项目

外包场景下 GitLab 访问控制为什么不能只靠账号体系

很多团队把外包人员的 GitLab 权限管控等同于“建个账号、分个角色、限几个项目”。但真正出问题的地方往往不在 GitLab 本身。外包人员要访问内网 GitLab，首先得能连到内网。传统做法是开 VPN、开公网端口、或者把 GitLab 部署到公有云。VPN 一旦接入，默认就获得了访问内网网段的通道，GitLab 之外的内部系统、数据库、文件服务器全都在同一张网络里暴露出来。即使 GitLab 账号只能看两个项目，网络层的暴露面一点没减小。

更麻烦的是，外包项目结束后的权限回收。账号可以禁用，但 VPN 证书、设备指纹、网络策略如果没同步清理，老账号死而复活、离职设备重新接入的事情并不少见。NexTunnel 在这个场景里的价值就在于把“谁能访问内网网络”和“能访问内网里的什么服务”拆开，再把这两层都收到一个统一的后台里做授权和审计。下面的方案不是把 GitLab 暴露到公网，而是让外包人员的设备通过 NexTunnel Client 建立到内网侧的受控通道。

方案架构：NexTunnel Server 内网侧部署与 GitLab 资源发布

部署方式很直接。内网侧需要一台机器安装 NexTunnel Server，这台机器本身要能够访问到 GitLab 服务。GitLab 继续保留在内网，不做公网映射，也不需要改 GitLab 的 SSO 或账号体系。NexTunnel Server 部署完成后，管理员在管理后台完成企业初始化，并把这台 Server 绑定为内网接入点。

接下来做的事，是把 GitLab 作为一个“资源”发布出去，而不是发布整个内网网段。管理员在后台添加 GitLab 对应的内网地址和端口，比如内网某台主机上的 GitLab HTTP/HTTPS 端口，或者 SSH 克隆端口。关键在于只添加 GitLab 所在的地址和端口，不添加内网其他服务的地址。这个资源发布动作决定了外包人员通过 NexTunnel 建连之后，能触及的范围被限制在 GitLab 这一个目标上，而不是整个内网。

这套方案有一个明确的前提：NexTunnel Server 需要能够出网，与 Client 或者私有中继建立连接。如果内网完全物理隔离、没有任何到外网的通道，那任何远程访问方案都无从谈起。但只要 Server 能访问到互联网，哪怕是没有公网 IP 的内网环境，P2P 直连或中继转发都能在这个基础上工作。

设备授权与端口白名单：把访问收敛到指定项目和指定动作

光把 GitLab 发布出去还不够。外包团队有 5 个人，每个人的设备都要单独受控。NexTunnel 的设备授权机制在这里起到的作用，是让后台清楚每一台 Client 设备是谁的、当前状态是什么。管理员在后台可以针对外包项目创建一个独立的授权范围，只把该项目涉及的外包人员设备加进来。未授权的设备即使安装了 NexTunnel Client，也无法看到这个 GitLab 资源。

端口白名单和上面的资源发布是配合使用的。常见需求有两类：外包开发只需要走 HTTPS 拉代码、推代码，那就只开放 GitLab Web 端口；如果需要通过 SSH 协议做 Git 操作，再单独开放 SSH 端口。以下是一个典型的资源开放范围示例：

这里不用改 GitLab 的防火墙规则，也不用在内网核心交换机上加复杂 ACL。NexTunnel 在资源发布和设备授权这一层就把网络可达性收敛掉了。GitLab 项目级权限继续用 GitLab 自身的角色和成员管理来控制，NexTunnel 则负责网络接入层的最小化。有团队会问：GitLab 项目权限已经做得很细了，为什么还要加一层？因为 GitLab 的项目权限只在应用层有效，NexTunnel 在网络可达性上把不必要的资源直接挡住，能让后续的审计范围小得多，也干净得多。

Client 侧访问路径与 P2P/中继的选择

外包人员在自己的电脑上安装 NexTunnel Client，登录后由管理员在后台完成该设备的授权。设备被授权后，Client 端能看到管理员为其开放的 GitLab 地址。点击连接后，NexTunnel 会尝试建立从外网设备到内网 Server 的通道。网络条件允许的情况下走 P2P 直连，数据传输不经过企业任何中转节点；NAT 穿透不成功时自动中继转发。对于有合规要求的企业，可以在内网侧部署自己的私有中继，所有流量都从私有中继走。

从外包人员视角看，连接成功后，本机就可以直接访问管理员指定的 GitLab 地址。这个访问体验和拉到内网网线基本一致。Git 的 HTTPS 或 SSH 地址写法、CI 配置文件里的仓库地址，都能沿用内网地址。不需要改 hosts、不需要重新贴公网地址、也不需要 VPN 客户端里切来切去。

这里需要注意的一点是，P2P 直连建立成功后，外包人员设备与内网 Server 之间形成的是针对已开放资源的点对点通道。即使同一台外包设备上装了几个 NexTunnel Client，或者同一台设备被授权到不同的资源，每个资源的连接都是独立受控的。

访问审计怎么做才不是“记日志但没人看”

外包人员的访问审计最怕两件事：一是没有记录，二是记录了但追查时要跨三四个系统拼 IP。NexTunnel 在后台的访问审计能力，记录的是哪个设备在什么时间连了哪个开放资源。因为前面已经做了设备授权和端口收敛，审计里出现的每一条记录都能直接对应到某台外包设备和某个 GitLab 端口。

审计的价值在这个场景下主要体现在三类：

• 确认外包人员访问 GitLab 的时间段，对比外包考勤或交付记录，判断是否有异常时段活动。
• 一旦 GitLab 出现异常操作，可以缩小排查范围到具体设备，而不是先查整个 VPN 出口 NAT 后的 IP。
• 外包项目结束时，导出该项目设备的完整访问记录，作为清退和权限回收的佐证材料。

管理员不需要到 GitLab 控制器里翻 Ruby 日志，也不需要到网关上导流日志。NexTunnel 后台的审计记录直接把设备和目标端口关联好，这对没有独立 SOC 团队的研发型企业来说更现实。

方案落地顺序与避坑清单

这套方案落地可以按以下顺序推进，不建议一上来就给所有外包人员全量切：

1. 内网侧安装 NexTunnel Server，确认其能访问 GitLab 且自身能连通外网或私有中继。
2. 在管理后台绑定 Server，添加 GitLab 的 HTTPS/SSH 端口资源。
3. 先拿一个外包人员做一个授权试点，确认连接路径、P2P 或中继、访问成功率。
4. 根据试点结果确定开放端口范围和 GitLab 项目级权限模板。
5. 批量创建授权设备，分组管理不同外包团队。
6. 在后台确认每个新设备的授权状态，避免未授权设备带病进入。

有几个避坑点值得提前注意。第一，GitLab 的 SSH 端口和 HTTPS 端口不要为了省事绑成一个“全端口”资源，应该拆开授权。第二，外包人员如果同时参与两个甲方的项目，设备授权不要跨项目混用，最好一个项目一个授权范围。第三，要确认目标 GitLab 地址在 Server 侧可达，和 Client 侧无关。第四，审计记录只覆盖 NexTunnel 建连的通道，GitLab 上的项目权限问题还是要在 GitLab 内部解决。

[插图建议：外网外包设备通过 Client 连接 → P2P/中继 → NexTunnel Server → 内网 GitLab 目标端口，旁边标注未授权资源路径被阻断]

用 NexTunnel 收紧外包访问内网 GitLab 的下一步

与其继续靠 VPN 和 GitLab 账号双轨管理，不如先在两到三个外包人员的小范围内做一次验证。在 NexTunnel Server 内网侧部署好后，导入 GitLab 指定端口，授权试点设备，然后用一周时间观察 Client 连接稳定性和审计记录是否满足要求。验证通过后再把新的外包入场流程统一为“设备授权开通 GitLab 端口”，高权限 GitLab 操作仍维持原有评审机制不变。接入路径这条线清楚了，外包团队的资源停留范围就从整张内网缩成了一台 GitLab 的两个端口。