没有公网 IP，如何外网访问内网 GitLab？

公司 GitLab 部署在内网，工程师在家或出差时没法 push 代码，怎么办？

直接开放端口到公网？不安全。部署 VPN？太重太麻烦。

这篇文章聊聊几种常见方案，以及各自的适用场景。

一、问题场景

很多中小团队的 GitLab 是这样的：

部署在公司内网某台服务器上，IP 是 192.168.x.x
没有公网 IP，或者公网 IP 不固定
工程师偶尔需要在家、在客户现场、在咖啡厅 push 代码

直接让网管把 GitLab 的 80/443 端口映射到公网？风险太高。GitLab 里全是代码和内部文档，一旦被扫描到，就是活靶子。

那怎么办？

二、方案一：VPN（传统但笨重）

最常见的思路：公司部署 VPN，员工连上 VPN 就等于进了内网，自然能访问 GitLab。

优点

技术成熟，方案多（OpenVPN、WireGuard、IPSec 等）
连上之后，内网所有资源都能访问，不止 GitLab

缺点

问题	说明
配置复杂	服务端要配证书、路由、防火墙规则，客户端也要逐个配置
权限粗放	连上 VPN 就是内网人，能访问所有服务器，无法限制只能看 GitLab
维护成本高	账号管理、密钥轮换、故障排查，需要专人维护
体验一般	连上 VPN 后，所有流量走公司网关，访问外网变慢

适合谁：有专职运维、对安全要求高、愿意投入人力维护的大中型团队。

不适合谁：没运维的中小团队，或者只需要偶尔 push 代码的场景。

三、方案二：内网穿透工具（轻量但有局限）

内网穿透的思路是：在内网机器上跑一个客户端，主动向公网中继服务器建立连接，外网通过这个中继访问内网服务。

常见工具

工具	特点	适用场景
ngrok	开箱即用，有免费版	临时演示、个人开发
frp	开源免费，自建服务端	有云服务器的团队
ZeroTier / Tailscale	组建虚拟局域网，P2P 直连	多设备组网
花生壳	国产老牌，有硬件盒子	不想折腾的小白用户

优点

部署简单，通常一条命令启动
不需要公网 IP，也不需要改路由器
成本低，很多工具免费或很便宜

缺点

问题	说明
安全风险	穿透工具把内网服务暴露到公网，如果配置不当，相当于给攻击者开了后门
无权限管控	知道地址就能访问，无法区分"谁能访问 GitLab，谁能访问数据库"
无审计日志	谁什么时候访问了、做了什么，通常没有记录
稳定性依赖中继	免费版限速、限连接数；自建需要额外服务器
地址会变	很多工具每次启动分配随机域名，Git 远程地址得跟着改

适合谁：个人开发者、临时演示、对安全要求不高的内部工具。

不适合谁：多人协作、代码敏感、需要审计的生产环境。

四、方案三：云厂商私网连接（企业级但贵）

如果公司已经在用阿里云、腾讯云、AWS 等，可以考虑云厂商的私网连接方案：

方案	说明	成本
专线接入	拉一根物理专线到公司	高（月租几千到几万）
VPN 网关	云厂商托管的 VPN 服务	中（按量计费）
云企业网	多 VPC 互通，可连本地 IDC	中高
SD-WAN	软件定义广域网，智能选路	中高

优点

云厂商托管，稳定性有保障
和云资源天然打通

缺点

成本高，中小企业负担不起
配置依然复杂，需要懂网络的人
过度设计："我只是想 push 个代码，为什么要买专线？"

适合谁：已有大量云资源、预算充足、有专职网络工程师的企业。

不适合谁：GitLab 在内网物理机/虚拟机、预算有限的小团队。

五、方案四：ZTNA（零信任网络访问，精细化方案）

ZTNA（Zero Trust Network Access）是近几年兴起的一种远程访问架构，核心理念是：

不假设任何网络是可信的，每次访问都要验证身份和权限。

和传统 VPN "连进来就放行"不同，ZTNA 的特点是：

特性	VPN	ZTNA
访问范围	整个内网	仅授权的应用/端口
权限粒度	粗（能连/不能连）	细（能访问哪个服务的哪个端口）
默认策略	允许所有	拒绝所有，显式放行
审计能力	弱（只知道谁连了 VPN）	强（每次访问都有日志）
部署复杂度	高	低

在 GitLab 场景下怎么用？

假设公司内网有一台 GitLab 服务器 192.168.1.100:80，管理员可以：

在内网任意机器上部署 ZTNA 服务端
把 192.168.1.100:80 设为目标资源
给工程师 A 的笔记本授权：只能访问 192.168.1.100:80
给工程师 B 授权：可以访问 GitLab + Nexus 仓库
给外包 C 授权：只能访问 GitLab 的只读镜像

工程师在外网安装客户端后，Git 远程地址完全不变 ，还是 http://192.168.1.100/project/repo.git，push/pull 体验和内网一样。

但工程师 C 无论如何也访问不到内网的 MySQL、Redis、文件服务器------因为根本没授权。

ZTNA 的优缺点

优点：

权限精细到个人、到端口
不暴露整个内网，攻击面极小
全程有审计日志，可追溯
部署简单，通常不需要改网络架构
开发者无感知，不用改 Git 地址

缺点：

需要额外部署一套系统（但通常比 VPN 简单）
小众方案，知名度不如 VPN 和 ngrok

适合谁：

有代码安全顾虑的团队
需要给外包/兼职开放部分权限的场景
想替代 VPN、减少内网暴露面的公司
没有专职运维、希望开箱即用的中小团队

六、四种方案对比总结

维度	VPN	内网穿透	云厂商私网	ZTNA
部署难度	高	低	中高	低
成本	中（人力+服务器）	低	高	低~中
安全粒度	粗（全网访问）	无（知道地址就能进）	中	细（按应用/端口）
审计能力	弱	无	中	强
开发者体验	一般（需改路由）	差（地址常变）	一般	好（地址不变）
适合场景	大型企业、全内网访问	个人/临时	云原生企业	中小团队、精细化管控

七、我的建议

按团队规模选：

**1~3 人，偶尔 push：用 nextunnel免费版本，随时使用，最简单
**5~20 人，有外包/兼职：考虑 ZTNA（推荐nextunnel团队版或者企业版），权限好管控，不怕外包乱逛内网
**20 人以上，有专职运维：推荐nextunnel企业版
**全云架构，预算充足：nextunnel私有化部署

按安全要求选：

代码不敏感、内部工具 → 内网穿透够用
代码是核心资产、有合规要求 → VPN 或 ZTNA
需要给不同人不同权限 → ZTNA

八、写在最后

没有公网 IP 访问内网 GitLab，本质是个"便利 vs 安全"的权衡。

图省事 → 内网穿透，但要接受安全风险
图安全 → VPN，但要接受维护成本
两者都要 → ZTNA 可能是更好的中间路线

技术选型没有银弹，适合自己的才是最好的。

你团队是怎么解决这个问题的？欢迎在评论区聊聊。