拥有一个私有网络，其中的服务器需要 SSH 访问。由于实例位于私有子网中，因此无法通过 SSH 直接访问，需要通过公共 Bastion 主机进行访问。
Workstation -> via SSH -> Bastion -> via SSH Forwarding -> private subnet instnce
我们使用 NAT 主机作为私有网络的公共网关。
User -> via HTTP -> NAT -> via private networking -> private subnet instance
将 Bastion 和 NAT 主机分开有什么好处？将它们合并有什么好处？
答案1
从技术角度来看，你可以使用 NAT 作为堡垒主机，但从架构角度来看你不应该这么做。原因如下：
堡垒主机是内部基础设施的入口点，而 NAT 通常将数据库等重要服务连接到互联网。因此，两者都应尽可能得到保护。
你的堡垒主机和你的 NAT 具有相反的角色：
- 堡垒主机应允许从互联网发起连接（来自有限的 IP 范围），并拒绝所有到互联网的发起流量
- NAT 应拒绝所有来自互联网的发起流量，并允许从内部网络到互联网的发起流量
此外，堡垒主机只是一个管理服务器，因此便宜的实例通常就足够了，而 NAT 必须能够潜在地路由大量流量。
除非您不关心安全性，否则没有合理的理由使用 NAT 作为堡垒主机；-)
答案2
您描述的堡垒主机简而言之就是一个跳跃主机，它允许从“网络”开始然后向上在 OSI 级别集中控制访问。您可以通过用户名和密钥限制对此类单个主机的访问，这就足够了。您还可以在那里部署所有类型的审计/命令日志记录。
NAT 表示网络级别仅有的— 您可以控制协议、源和目标 IP（和端口），但大部分就是这样。
当谈到将它们结合起来时，唯一可能的影响可能是由于两者之间不必要的干扰。最坏的情况是：
- NAT 滥用允许 SSH 登录堡垒主机本身（极不可能，几乎不可能）
- 允许登录跳转主机的用户将破坏 NAT 规则（理论上可行，但相对容易受到限制，我们应该记住 SSH 用户在定义上是受信任的——这意味着这是一个小反对意见）
- 踪迹混杂。除非强制分开，否则您无法区分 Bastion 主机本地用户的流量和 NATed。使用适当的日志记录不是问题。使用专用 IP 进行 NAT 和 SSH 环境也可以解决这个问题。如果不允许 Bastion 的 SSH 本地用户建立传出连接，这不是问题。