问题描述
在一个EC2主机上有一个容器，希望能够从这个容器发送HTTP请求到另一个EC2主机上的另一个容器。他发现从主机A发送HTTP请求到主机B的私有DNS和暴露的容器端口可以成功接收响应。然而，当他尝试在主机B上的容器内执行相同的操作时，却遇到了”主机不可达”的错误。他认为这不是主机网络配置问题，因为AWS已经配置好了，所以他不会详细介绍这部分内容。他感到困惑的是，他在预生产环境中已经做过完全相同的操作，那里一切正常。用户想知道可能的问题是什么，以及在哪里查找故障排除的方法。
解决方案
确定已排除的问题
在用户进行了一些测试后，已经可以排除一些可能的问题。他知道容器的端口已经正常监听并接受连接，而且EC2实例的网络正常工作。以下是三个明显的问题，用户可以进一步排除。
问题1: 主机的DNS解析
首先，用户可以检查主机是否使用本地DNS解析将主机名解析为127.0.0.1，而容器端口并没有监听在回环适配器上。用户可以在服务器上尝试ping主机的DNS名称，查看它会ping哪个IP地址。还可以使用telnet连接到127.0.0.1上的端口，看是否能够建立连接。解决方法有两种：一是让回环适配器上的监听工作，另一种是使用不同于AWS生成的主机名的DNS条目。
问题2: AWS安全组设置
其次，用户可能正在将主机名解析为私有IP地址，然后由AWS安全组进行过滤。用户需要检查安全组设置，确保允许来自该端口的传入连接，并且源IP地址设置正确，要么是CIDR块中包括了主机自身的IP地址，要么是与EC2实例相关联的安全组。用户可以在安全组编辑器中轻松解决此问题。为了验证安全组是否正常工作并允许连接，用户可以设置一个AWS流量日志，以便查看网络接口上的所有TCP连接。
问题3: 容器主机的防火墙设置
最后，用户还需要考虑容器主机是否设置了防火墙，限制了对特定IP地址的传入连接。他可以查看防火墙设置，以确定是否接收到了连接，以及是否决定将连接路由到容器。
进一步排查
如果以上问题都没有解决问题，用户可能需要进一步深入排查。他可以考虑使用IP Tables在操作系统的syslog中生成日志消息，以跟踪连接经过IP堆栈的情况。这至少可以确认在网络层面上是否生成了TCP连接，并在操作系统内部接收到了连接。
总结
在解决从一个EC2主机上的容器发送HTTP请求到另一个EC2主机上的容器的问题时，用户需要排除一些可能的问题。首先，他需要确保主机的DNS解析和容器的端口监听设置正确。其次，他需要检查AWS安全组设置，确保允许了传入连接并设置了正确的源IP地址。最后，用户还需要关注容器主机的防火墙设置，以确保传入连接不受限制。如果问题仍然存在，用户可以考虑使用IP Tables生成日志消息，以深入了解连接在操作系统内部的情况。