配置git从公网能访问-基于frp

一个小小的疏忽带来了一下午+上午的工作量

可以说,晚上都没有睡好.
只因为在云主机机的防火墙,忘了开同端口UDP.

起因与上下文与结论

我需要全面将工作环境移植到互联网。其中一个是gitlab。
但一直没有成功。
原因是总是ssh git@<公网IP> -p 端口失败。

最终的解决：仅仅是因为 在同端口忘记开UDP。

总结：
如果需要将一个gitlab公布到公网，至少需要开放三条防火墙条目：
http
ssh TCP
ssh UDP
我就是因为忘记了第三条。

网上似乎没有讲解这些东西。那些AI也都不行。
当然，也可能是用腾讯云的人不多，我记得阿里云主机似乎同时在一个端口开以选多种传输模式。
也可以是我买的是轻量云主机。
总之我掉到这个坑里，晚上都没睡好。痛定思痛，早晨没有搞成，就睡了两个小时，吃完午饭，我原想到将frpc的 local和remote，设置成不同的端口时，再一次看到防火墙，看到只有TCP时，我认为是不对的。加入UDP果然就对了。

主要收获

1。公网主机的防火墙需要至少三条

如果需要将一个gitlab公布到公网，至少需要开放三条防火墙条目：
http
ssh TCP
ssh UDP

3。gitlab的http端口和ssh端口，需要分为两个

这条按说不需要解释，因为gitlab装好后，默认就是分为两个的。
但要注意为什么分为两个，以及带来的深远的影响。

分为两个原因是，http协议与ssh协议完全不同。所谓的不同是ssh很复杂，而且与UDP相关。
而http在传输协议角度，就是TCP。很干净。

这一条就导致，gitlab不益使用二级域名来解析。当然不是说不可以，但我打算放弃，永远带着端口。不想再冒风险。实际上，我认为利用nginx来分别解析HTTP和ssh，以实现隐藏端口，也是可能的。但我的目标是发布到公网上，而不是追求完美。在这之前，我最大的困难是无法发布到公网。
所以，这方面的内容（指二级域名解析）本文中没有。

3。不要用nginx来解析二级域名

二级域名对于你花了大价钱买的真正的DNS解析，当然是二级域名，你也可以绑定到指定的IP，即不同的域名指令不同的IP（至少原理是这样，国家法律是否允许不清楚）。
但像我样的穷人，显然二级域名对我们的意思是现代化的nginx这类路由的手段。
当然，我还真很喜欢nginx这种二级域名解析到某个端口的模式。

不过，对于git来说，这却用不着！

4。 frpc的端口，与其它的相同，不需要local和remote配置为不同端口。可以相同。

测试指令

最终的成功的指令是：

ssh -T git@<公网IP或域名> -p <port>

 ssh ssh协议。
-T -T 选项的作用是禁用终端分配（Disable pseudo-tty allocation）。具体来说，它会告诉 SSH 客户端不要为当前会话分配一个伪终端（pseudo-terminal）。
git **理解这条也是理解整体git体系的关键之一**。git是一个用户名。也就是gitlab所在的主机中，有这样一个用户名，就叫git

用到的指令

ssh

1. 生成 SSH 密钥对

如果你还没有 SSH 密钥对，可以使用 ssh-keygen 命令生成。打开终端，运行以下命令：

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

• -t rsa：指定密钥类型为 RSA。
• -b 4096：指定密钥长度为 4096 位，更安全。
• -C "[e-mail]"：添加注释，通常是你的邮箱地址。

运行命令后，系统会提示你输入保存密钥的文件路径（默认路径为 ~/.ssh/id_rsa），直接按回车键使用默认路径即可。接着，系统会提示你输入一个密码（passphrase），用于保护私钥。如果你不想设置密码，直接按回车键跳过，但这样会降低安全性。

2. 将公钥添加到远程主机

生成密钥对后，需要将公钥（~/.ssh/id_rsa.pub）添加到远程主机的 ~/.ssh/authorized_keys 文件中。有以下几种方法：

方法 1：使用 ssh-copy-id 命令

这是最简单的方法。运行以下命令：

ssh-copy-id user@remote_host

• user：远程主机的用户名。
• remote_host：远程主机的 IP 地址或域名。

系统会提示你输入远程主机的密码，输入后，公钥将自动添加到远程主机的 ~/.ssh/authorized_keys 文件中。

方法 2：手动复制公钥

如果远程主机没有安装 ssh-copy-id，可以手动复制公钥。首先，将公钥内容复制到剪贴板：

cat ~/.ssh/id_rsa.pub

然后，登录到远程主机，打开或创建 ~/.ssh/authorized_keys 文件：

ssh user@remote_host
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
nano ~/.ssh/authorized_keys

将复制的公钥内容粘贴到 authorized_keys 文件中，保存并退出。

3. 配置本地 SSH 客户端

如果你有多个密钥，需要指定使用哪个密钥连接到远程主机。编辑本地的 SSH 配置文件 ~/.ssh/config，添加以下内容：

Host remote_hostHostName remote_host_ip_or_domainUser userIdentityFile ~/.ssh/id_rsa

• Host：自定义的主机别名。
• HostName：远程主机的 IP 地址或域名。
• User：远程主机的用户名。
• IdentityFile：指定使用的私钥文件路径。

tcpdump抓包

1. 确定网络接口

首先，需要确定要抓包的网络接口。运行以下命令列出所有可用的网络接口：

sudo tcpdump -D

通常，eth0 或 any 是常用的选择。any 接口可以捕获所有网络接口的数据包。

2. 抓取与 SSH 端口 9022 相关的数据包

使用以下命令抓取与 SSH 端口 9022 相关的数据包：

sudo tcpdump -i any -nnvvXSs 1514 port 9022 -w output.pcap

• -i any：指定抓取所有网络接口的数据包。
• -nn：不解析主机名和端口号，直接显示 IP 地址和端口号。
• -vv：显示更详细的信息。
• -X：以十六进制和 ASCII 格式显示数据包内容。
• -s 1514：设置抓取的数据包大小为 1514 字节，避免截断。
• port 9022：指定只抓取与端口 9022 相关的数据包。
• -c 100：限制抓取的数据包数量为 100 个。

3. 分析抓取的数据包

抓包完成后，可以根据以下内容进行分析：

• TCP 三次握手：检查是否成功建立了 TCP 连接。如果客户端发送了 SYN 包，但服务器没有响应，可能是服务器未监听该端口或防火墙阻止了连接。
• 数据包标志：查看数据包的标志（如 RST、ACK 等）。如果出现 RST 包，可能表示连接被重置。
• 数据包内容：通过 -X 选项查看数据包的十六进制和 ASCII 内容，可能会发现一些错误信息。

4. 可以尝试将 -i 参数设置为 any，以捕获所有接口的数据包。

• 如果需要将抓取的数据包保存到文件中，可以使用 -w 选项，例如：

  sudo tcpdump -i any -nnvvXSs 1514 port 9022 -w output.pcap
  

gitlab相关

这里当然不重要,因为你都已走到要公网发布,对gitlab一般比较熟了。

配置

docker exec -it blgitlab bash
vi /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
vi /etc/gitlab/gitlab.rb

SSH 配置 /etc/ssh/sshd_config 文件
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

sudo systemctl restart ssh"

重启

sudo gitlab-ctl reconfigure

sudo gitlab-ctl restart