远程办公拉取 Nexus 依赖失败？NexTunnel 安全访问实战

远程办公执行 mvn clean package 或 gradle build 时，构建日志停在 Could not resolve dependencies，私服地址 https://nexus.internal.example.com 无法解析——这不是网络抖动，而是内网 Nexus 没有公网入口。VPN 会把整个内网暴露给远程人员，授权粒度太粗；SSH 端口转发要长期保持连接，且没有访问审计。NexTunnel 的处理方式是把访问收窄到一个 TCP 端口：内网 Nexus 的 8081。下面先拆解常见错误方案，再给出可落地的思路。

• 公网直接映射 Nexus 端口：需要公网 IP，且 Nexus 管理界面、API 全部暴露，极容易被扫描爆破。

• 全流量 VPN：远程办公者能访问内网所有服务，不满足最小权限；排查问题时无法定位具体依赖访问行为。

• SSH 端口转发：依赖拉取可能中断，大规模团队难以维护，也无法限制只能访问 Nexus 的 8081 端口。

用 NexTunnel 收窄访问面的最小部署流程

NexTunnel 的 Server 部署在内网侧，比如 Nexus 同网段的一台 Linux 主机或容器；Client 安装在外网开发机上。管理员在 Server 的管理后台添加一个资源，指定内网 Nexus 的 IP 地址和 8081 端口，并把该资源授权给指定设备；开发机在 Client 界面中绑定 Server，然后添加本地端口映射，将本机 8081 端口指向服务端的 Nexus 资源。两端建立 P2P 直连或中继转发隧道后，Client 本地监听 8081 端口，访问该端口等同于访问内网 Nexus 的 8081。

这里有几个必须注意的点：

• 只添加一个端口：在后台添加资源时只添加 Nexus 的 8081 端口，不要添加 22、3306、6379 等端口，避免把整个内网暴露出来。

• 设备授权要收窄：只授权当前正在使用的开发机，不要批量授权所有设备。新开发机入职或换机时，在后台加入新设备标识即可。

• 本地监听地址：Client 端建议将本地端口绑定在 127.0.0.1，而不是 0.0.0.0，这样同一台机器上的其他用户或局域网内其他设备无法借用该隧道。

链路打通后，可以在开发机上执行 curl -s http://127.0.0.1:8081/service/rest/v1/status，如果返回 Nexus 服务状态 JSON，说明隧道工作正常。此时外网开发机只监听本地回环地址，不会影响内网其他服务。

Maven / Gradle 依赖拉取如何切换到本地映射端口？

隧道建立后，需要把 Maven 或 Gradle 的依赖仓库地址从 https://nexus.internal.example.com 改为本地映射地址。Maven 使用独立的 settings 文件更便于切换，避免影响公司内网办公时的配置。

Maven 配置：

<settings>
  <mirrors>
    <mirror>
      <id>nexus-remote</id>
      <name>Nexus via NexTunnel</name>
      <url>http://127.0.0.1:8081/repository/maven-public/</url>
      <mirrorOf>*</mirrorOf>
    </mirror>
  </mirrors>
</settings>

将上述内容保存为 ~/.m2/settings-nexus.xml，构建时指定该文件：

mvn -s ~/.m2/settings-nexus.xml dependency:resolve
mvn -s ~/.m2/settings-nexus.xml clean package

Gradle 配置：

allprojects {
    repositories {
        maven {
            url 'http://127.0.0.1:8081/repository/maven-public/'
            allowInsecureProtocol = true
        }
    }
}

如果 Nexus 内网地址本身是 HTTP，Gradle 7 及以上版本需要显式设置 allowInsecureProtocol = true；如果 Nexus 启用 HTTPS，可以在 NexTunnel Client 中映射本地端口到内网 Nexus 的 HTTPS 端口，构建配置中使用 https://127.0.0.1:8443 之类的地址。依赖拉取时，Maven 会先请求本地的 127.0.0.1:8081，NexTunnel 隧道将流量转发到内网 Nexus，Nexus 再按原有策略访问中央仓库或代理仓库。

端口白名单、设备授权与访问审计如何落地？

只打通链路还不够，必须把访问面收窄到最小。NexTunnel 后台提供三个关键控制点：

• 端口白名单：管理员在 Server 后台的资源列表中只添加 Nexus 的 8081 端口作为可访问资源，其他业务端口一概不添加。即使外网开发机被攻破，攻击者也只能通过隧道请求 Nexus 的 8081 端口，无法横向移动到 GitLab、MySQL 或 Jenkins。

• 设备授权：每台 Client 在后台有唯一设备标识，管理员只授权已知开发机。新设备接入前必须在后台完成授权，否则无法建立隧道。这样避免了 VPN 那种“知道账号密码就能进内网”的粗粒度问题。

• 访问审计：在 Server 后台开启审计后，可以查看谁在什么时间、从哪台设备、连接了哪个端口、传输了多少数据。审计记录集中在后台页面，不需要到服务器上翻日志文件。运维可以据此回答“这台开发机昨天下午是否拉取了大量依赖”这类问题，而不是只能看到一条 VPN 连接记录。

这三件事不需要写配置文件，全部在 NexTunnel 管理后台和客户端界面完成。管理员第一次配置时，建议先用一台开发机完整走通“添加资源 → 授权设备 → 建立隧道 → 构建拉取”的流程，再把配置推广到团队。

P2P 直连与中继转发在 Nexus 拉取场景下怎么选？

NexTunnel 默认优先尝试 P2P 直连，NAT 打洞失败时自动切换为中继转发。两种模式对 Nexus 依赖拉取的体验不同，决策时可以对照下表：

如果团队大部分成员与公司网络之间没有复杂 NAT，P2P 直连就能满足日常 mvn package 的依赖下载。若公司要求所有远程访问流量必须经过统一出口做审计，可以在 DMZ 部署 NexTunnel 私有化中继，Server 和 Client 都指向该中继，此时流量不再依赖公网中继节点，数据不出企业可控范围。中继的部署位置和带宽会直接影响依赖拉取速度，建议在测试环境先压测一次大依赖下载，再决定是否全员切换。

落地 NexTunnel 访问 Nexus 的下一步建议

要在团队内推行，建议按以下步骤落地：

1. 选一台内网侧机器部署 NexTunnel Server，在后台只添加 Nexus 的 8081 端口资源，不开放其他端口。

2. 为 2～3 台开发机安装 Client，绑定 Server 并完成设备授权，先验证依赖拉取稳定性。

3. 将 Maven 的 settings-nexus.xml 或 Gradle 的 init.gradle 加入团队仓库，统一仓库地址为 127.0.0.1:8081。

4. 在后台开启审计，观察一周内是否有非白名单设备尝试接入或异常端口访问。

5. 确需审计集中收口时，在 DMZ 部署私有化中继，将 Server 和 Client 都指向自建中继。

NexTunnel 的价值在于把“远程办公拉取 Nexus 依赖”从一台机器的网络配置问题，变成一个可授权、可审计、可收口的端口级访问控制问题。下一步可以基于这个基础，逐步把 GitLab、Jenkins、内部业务系统等按端口逐一纳入白名单，而不是回到全量 VPN 的老路。