我正在 Linux 上开发某种透明代理的概念验证。
透明代理拦截 TCP 流量并将其转发到后端。 我用 https://www.kernel.org/doc/Documentation/networking/tproxy.txt和用于传出 TCP 连接的欺骗套接字。
在我的开发 PC 上，我能够使用 Docker 模拟网络并且一切正常。
但是我需要在AWS上部署测试环境。
提议的设计:
同一子网中的三个虚拟机:
- 客户端，192.168.0.2
- 代理，192.168.0.3
- 后端，192.168.0.4
在客户端上，我通过 192.168.0.3 添加到 192.168.0.4 的路由
在代理上，我将 TPROXY 配置为拦截 TCP 数据包并将其转发到具有 192.168.0.2 IP 源地址的后端。我们的透明代理在这里工作。
在后端我运行简单的网络服务器。我还通过 192.168.0.3 添加到 192.168.0.2 的路由，否则数据包将直接返回到 192.168.0.2
问题:
拟议的网络设计是否会按预期工作？
AWS 使用某种软件定义的网络，我不知道它的工作方式是否与我将 3 个 Linux 机器连接到一个以太网交换机的方式相同。
最佳答案
Will proposed network design work as expected?
极不可能。
实例可以访问的 VPC 中的 IP 网络，从所有外观来看，是一个 IP 网络(第 3 层)，而不是以太网网络(第 2 层)，即使它作为尽管它是以太网。
以太网交换机“感兴趣”的发件人/收件人地址是 MAC 地址。 EC2 网络感兴趣的发件人/收件人地址是 IP 地址。如果您通过欺骗地址和操纵路由表来调整实例的 IP 堆栈，则仅有两种可能的结果应该是其中之一:根据基础设施对 IP 地址所在位置的了解，数据包实际上会到达正确的实例 应该 存在...否则数据包将被网络丢弃。最有可能的是后者。
有一个IP Source/Destination Check Flag在每个 EC2 实例上禁用 一些 网络内置的数据包阻止，否则网络会认为是欺骗，但这应该只适用于 IP 地址在 VPC 超网 CIDR block 之外的流量——每个实例的 IP 地址都是基础架构已知的，不受您正在考虑的那种调整的影响。
可以想象，您可以使用通用路由封装 (GRE) 协议(protocol)、OpenVPN 或其他一些隧道解决方案在实例之间构建隧道，然后这些实例将在不同的 IP 子网中拥有额外的网络接口(interface)，它们可以在其中直接交换流量不同的子网和它们组成的规则，因为网络看不到封装在隧道中的数据包上的地址，并且不会对内部有效负载施加任何限制。
可能相关:在AWS以外的某个云提供商，网络设计远不如VPC的提供商，我使用实例间隧道(用OpenVPN构建)构建自己的虚拟私有(private)子网，使更多比其他云提供商提供的更有意义，所以我想说这可能是一个完全可行的替代方案——我的解决方案增加的延迟是亚毫秒级的。
但这一切都假设您有正当理由选择涉及数据包处理的解决方案。应该有更好、更实用的方法来解决您要解决的确切问题。
关于linux - AWS 上的测试设置以测试 TCP 透明代理 (TPROXY) 和欺骗套接字，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43778935/