通过 Nginx 代理为 Gitlab 服务器克隆的 Git 不起作用

Posted 2023-03-23

【中文标题】通过 Nginx 代理为 Gitlab 服务器克隆的 Git 不起作用

【英文标题】：Git clone through Nginx proxy for Gitlab server is not working

【发布时间】：2016-12-19 14:19:12

【问题描述】：

我的 nginx 服务器充当 Gitlab 服务器的代理，问题是当我尝试“**git clone [e-mail]:username/project.git**”时我无法克隆项目[它不是从 Nginx 服务器到 Gitlab 服务器的隧道]

当我使用 Gitlab 服务器的 IP 地址更新本地系统的 /etc/hosts 文件时，它无需密码即可正常克隆 [我已使用 Gitlab 上的 SSH 公钥更新了我的个人资料]。

所以我得出的结论是，我必须使用可以通过 Nginx 服务器将 SSH 通信从任何客户端系统隧道传输到 Gitlab 服务器的规则来更新我的 Nginx 配置。

通过如下更改尝试了此 Link 上的代码：

upstream gitlab 
server 192.168.61.102:22;


server 
listen 22;
server_name gitlab.example.com;

location / 
proxy_set_header  X-Real-IP  $remote_addr;
proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;

proxy_pass http://gitlab;

但它不起作用。如果有人帮助我调整规则以使其发挥作用，那就太好了。

注意：上面代码中192.168.61.102是我的gitlab服务器的IP地址，我的Nginx服务器是192.168.61.101

【参考方案1】：

首先，您需要停止让 Nginx 侦听端口 22。Nginx 不处理 SSH 转发，您的防火墙可以。

如果您使用 iptables，那么这些规则会将所有请求通过您的 Nginx 主机转发到您的 Gitlab 主机。

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to-destination [GITLAB-IP]:22
sudo iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 22 -j SNAT --to-source [NGINX-IP]

您可能需要更改这些命令中的eth0 以适应您的服务器设置。

---

然后您需要通过编辑/etc/sysctl.conf 文件并取消注释此行来启用数据包转发：

net.ipv4.ip_forward=1

然后用这个命令重新加载你刚刚更改的配置：

sudo sysctl -p

---

最后，这些 iptables 规则在默认情况下不是持久的，并且会在您重新启动服务器时被删除。使它们持久化的最简单方法是使用 iptables-persistent 包。你像这样安装那个包：

sudo apt-get install iptables-persistent

安装后，您可以随时使用以下命令保存/恢复 iptables 规则：

sudo invoke-rc.d iptables-persistent save
sudo invoke-rc.d iptables-persistent reload

如果您使用的是 Ubuntu 16.04 或更高版本，那么这些命令是

sudo netfilter-persistent save
sudo netfilter-persistent reload

您需要在规则生效并测试它们之后运行保存命令。然后，当您的服务器重新启动时，您保存的规则将自动加载。

【讨论】：

非常有用的详细信息，谢谢你会试一试并在完成后发布结果，但是我在问题中提到的 Nginx 代码的目的/用例是什么（来源：link） ，在我的场景中没有帮助吗？

Nginx 代码用于将 HTTP 请求转发到您的 Gitlab 主机，但您已将其设置为侦听端口 22，即 SSH 端口。它应该监听 80 端口。

那么这个链接中提到的标题为“Nginx configuration for SSH tunnel”的代码是否给出了错误的想法？

是的，写这个要点的人似乎认为 Nginx 正在处理他们的 SSH 隧道，但实际情况并非如此。他们不知道自己在说什么。

在我的 Nginx 服务器上，我已将我的 SSH 端口从 22 更改为 2201，并编写了您上面提到的规则，例如：sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to-destination 192.168.60.101:22sudo iptables -t nat -A POSTROUTING -o eth0 -p tcp --dport 22 -j SNAT --to-source 192.168.60.100

【参考方案2】：

Nginx 代理用于 http 请求。

通过 SSH 克隆时，您没有使用 http。

您需要做的是在路由器上使用端口转发或在服务器上使用 iptables。

【讨论】：

但是我在问题中提到的 Nginx 代码的目的/用例（来源：link），对我的场景没有帮助吗？

该代码的目的是将在端口 80 上接收到的 http 请求重定向到端口 3000 上的 localhost。但它始终是重定向的 http 流量。因此，使用您的代码，您可以使您的 gitlab Web 界面可以从外部世界等访问，但您不能使用 nginx 代理将 ssh 请求转换为 http。 BrokenBinary 对 iptables 的回答是正确的方法。

那么link中提到的标题为“Nginx configuration for SSH tunnel”的代码是否给出了错误的想法？