☰

iptables/https：路由器获取源自端口 443 的输入流量

tag-icon • tag-icon iptables nginx https
iptables/https：路由器获取源自端口 443 的输入流量

我认为这是一个关于 nginx/https 的问题，但它可能iptables也与我误解事情有关。

我最近在我的网络服务器（nginx）和互联网之间的路由器上设置了防火墙。 Nginx 设置为侦听端口 80 和 443，并使用 let's encrypt 证书将大多数 80 调用重定向到 443。通过适当的转发，一切都运行得很好 - 至少我还没有发现任何故障。

防火墙（iptables 过滤表）设置为ACCEPT策略，但当数据包到达链末端时，INPUT它会转发到一条LOGDROP链，该链记录并丢弃它。

查看日志后，我发现从服务器 443 端口发往路由器的数据包被丢弃。示例（MAC 和 IP 地址随机化，.136是服务器，.122是路由器）：

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped: IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272 WINDOW=0 RES=0x00 RST URGP=0

这些尝试在一夜之间半定期地出现（每十分钟尝试 1-3 次），然后逐渐消失。

假设我正确解释了日志，服务器直接从 https 端口联系路由器 - 这是没有意义的，因为为什么路由器需要加密或未加密的 Web 内容？似乎在没有要求的情况下就得到了它？

我假设对 https 内容的外部请求通过FORWARD链双向传递，因此不会显示在此处。正如我所说，AFAICT 对服务器的所有 https 请求都得到了应有的答复。

我的问题是：

这些数据包的可能解释是什么？一个奇怪的服务器滴答声导致 nginx 在没有请求数据包的情况下发送数据包？或者它是否从某个地方收到请求导致它响应错误的机器？

答案1

您提供的示例日志消息是一个RST数据包，通常在目标端口上没有任何内容侦听时由内核发送。

Oct 10 05:18:47 ASUS user.warn kernel: IPTables-Dropped:
    IN=br0 OUT= MAC=3C:AE:78:D4:B1:E3 SRC=192.168.1.136 DST=192.168.1.122
    LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=10743 DF PROTO=TCP SPT=443 DPT=33272
    WINDOW=0 RES=0x00 RST URGP=0

具体来说，这里之前有一个从 192.168.1.122 到 192.168.1.136:443 的请求已被服务器 192.168.1.136 拒绝，因为当时没有任何东西在端口 443 上侦听。（或者 192.168 上有防火墙） .1.136 具有REJECT该地址/端口组合的规则。在这个级别我们无法区分。）

不幸的是，这并不能解释为什么你的路由器 .122 应该尝试与 .136 上的 nginx 通信，但它可以帮助你更轻松地解释日志文件消息。

相关内容