☰

AWS 主机接收流量，但 Apache 响应缓慢

tag-icon • tag-icon amazon-web-services apache-2.4
AWS 主机接收流量，但 Apache 响应缓慢

我有一个在端口 443 上监听的虚拟主机。
通过 TCPDump，我知道主机本身正在接收来自浏览器的请求，并且据我所知，连接正常，请参阅示例转储输出：

12:26:11.238593 IP BROWSER.34156 > HOST.https: Flags [P.], seq 1:518, ack 1, win 58, options [nop,nop,TS val 2402991565 ecr 17262140], length517
12:26:11.238617 IP HOST.https > BROWSER.34156: Flags [.], ack 518, win 219, options [nop,nop,TS val 17262185 ecr 2402991565], length 0
12:26:11.240109 IP HOST.https > BROWSER.34156: Flags [P.], seq 1:1937, ack 518, win 219, options [nop,nop,TS val 17262186 ecr 2402991565], length 1936
12:26:11.257629 IP HOST.https > BROWSER.32718: Flags [S.], seq 994200905, ack 3372729358, win 26847, options [mss 8961,sackOK,TS val 17262204ecr 2402986264,nop,wscale 7], length 0
12:26:11.257640 IP HOST.https > BROWSER.mtrgtrans: Flags [S.], seq 3850405604, ack 538070284, win 26847, options [mss 8961,sackOK,TS val 17262204 ecr 2402951572,nop,wscale 7], length 0
12:26:11.267663 IP BROWSER.34156 > HOST.https: Flags [.], ack 1937, win 65, options [nop,nop,TS val 2402991594 ecr 17262186], length 0
12:26:11.296038 IP BROWSER.34156 > HOST.https: Flags [F.], seq 518, ack 1937, win 65, options [nop,nop,TS val 2402991623 ecr 17262186], length 0
12:26:11.296177 IP HOST.https > BROWSER.34156: Flags [F.], seq 1937, ack 519, win 219, options [nop,nop,TS val 17262242 ecr 2402991623], length 0
12:26:11.322100 IP BROWSER.34156 > HOST.https: Flags [.], ack 1938, win 65, options [nop,nop,TS val 2402991648 ecr 17262242], length 0
12:26:12.657696 IP HOST.https > BROWSER.24068: Flags [S.], seq 3364630219, ack 1425775294, win 26847, options [mss 8961,sackOK,TS val 17263604 ecr 1334034660,nop,wscale 7], length 0
12:26:13.094538 IP BROWSER.32718 > HOST.https: Flags [S], seq 3372729357, win 29200, options [mss 1380,sackOK,TS val 2402993424 ecr 0,nop,wscale 9], length 0

然而问题在于，当主机接收到流量时，Apache 似乎并没有立即做出响应。我不能 100% 确定此虚拟主机后面的防火墙没有有条件地阻止响应，但我相信 Apache 在某种程度上存在问题，因为在浏览器难以建立连接的时间段内，我在访问日志中看不到任何内容。当它
最终建立连接时，流量会显示在访问日志中。

还值得注意的是，该主机有两个网络接口，服务器名称注册为指向 eth0 接口的 dns 记录。在连接建立并正常工作之前，eth1 接口不会有任何输出。

Vhost 配置

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      redacted
    SSLCertificateKeyFile   redacted

    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} TRACE
    RewriteRule ^ "-" [F,L,R=405]
    LogLevel info

    ProxyPreserveHost On
    RequestHeader unset REMOTE_USER
    SSLProxyEngine on
    SSLProxyVerify none
    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    OIDCProviderMetadataURL https://myhost/auth/realms/REALMREDACTED/.well-known/openid-configuration
    OIDCRedirectURI https://myhost/redirect
    OIDCCryptoPassphrase redacted
    OIDCClientID apache
    OIDCClientSecret redacted
    OIDCProviderTokenEndpointAuth client_secret_basic
    OIDCRemoteUserClaim preferred_username
    OIDCScope "openid email profile"
    OIDCSessionType server-cache
    OIDCSSLValidateServer off
        OIDCInfoHook userinfo

    DocumentRoot "/var/www/html"
    ServerName myhost

    <Directory "/var/www/html">
        Options None
        AllowOverride None
        Require all denied
    </Directory>
    RedirectMatch ^/$ /home
</VirtualHost>

答案1

所以这实际上不是 Apache 的问题。

在不透露太多有关正在使用的系统的信息的情况下，Apache 实例位于防火墙实例后面，该防火墙实例通过 NAT 连接到 Apache 实例，并且它们之间存在 AWS 网络 ACL。

因为我们假设这是一个 Linux 实例，并且我们希望锁定流量，所以防火墙上的 ACL 有机会拒绝来自 Apache 的返回流量，因为 NATting 保留了用于打开连接的端口。

由于我们假设 Linux临时端口，但测试机器使用的是 Windows，如果 Windows 机器打开了监听端口 < 32768 的连接，那么当 Apache 尝试响应时，AWS 会根据 ACL 规则丢弃数据包并导致超时。这里的关键是 Windows 传统上使用端口 1025 - 5000 作为临时端口，尽管较新版本的 Windows使用 IANA 默认范围 49152 至 65535。

这就是为什么我们的 TCPDump 会表明流量接收正常，但如果使用“低”端口，TCP 握手将无法完成。

相关内容