公司 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 可能是更好的中间路线
技术选型没有银弹，适合自己的才是最好的。
你团队是怎么解决这个问题的？欢迎在评论区聊聊。