使用带有源和目标标签的防火墙规则将 GCE 中的 SSH 访问限制到 Linux 堡垒主机

使用带有源和目标标签的防火墙规则将 GCE 中的 SSH 访问限制到 Linux 堡垒主机

我在同一个项目和同一个默认网络中拥有多个 GCE 实例。我已将其中一个实例指定为“堡垒”服务器,并希望阻止从互联网向堡垒服务器以外的所有实例进行 SSH 连接,但允许堡垒服务器通过 SSH 连接我的其他实例。

因此,我修改了 default-allow-ssh 规则,使其仅允许 SSH 连接到带有“jumphost”标签的目标,并将该标签应用于我的堡垒实例。这有效,因为我可以从互联网通过 SSH 连接到我的堡垒服务器,但无法再从互联网通过 SSH 连接到我的其他实例。

然后,我创建了一条新的 restricted-allow-ssh 规则,该规则只允许从我的堡垒实例通过 SSH 访问我的其他实例:

gcloud compute --project "<my project>" firewall-rules create "restricted-allow-ssh" --allow tcp:22 --description "Allow SSH only from bastion server" --network "default" --source-tags "jumphost" --target-tags "restricted-ssh"

然后,我将“restricted-ssh”标签应用于除堡垒服务器之外的所有实例。

似乎到目前为止,我无法从互联网 telnet 到标记为“restricted-ssh”的实例上的端口 22,但我可以从堡垒服务器通过端口 22 telnet 到它们。

但是,当我尝试从我的堡垒服务器使用 gcloud compute ssh 连接到任何实例时,它就会挂起,最终我会收到“连接超时”错误。

有趣的是,使用 gcloud 和我的实例的简称(例如“dev”)似乎可以解析为我的堡垒服务器的公共 IP 地址。但 nslookup 将其解析为端口 22 开放的内部网络地址。似乎我的堡垒主机上的“gcloud compute ssh”试图通过外部 IP 地址,但由于端口已关闭而被拒绝。

有没有什么简单的解决方法或简单的替代方法可以达到相同的结果?

答案1

事实证明,使用我的穷人堡垒解决方案,我可以从我的 jumphost 使用 ssh -I ~/.ssh/google_compute_engine。无需 gcloud compute ssh。

相关内容