为什么删除 iptables nat 预路由规则后重定向仍然存在？

有志者，事竟成！如果你在学习Golang，那么本文《为什么删除 iptables nat 预路由规则后重定向仍然存在？》，就很适合你！文章讲解的知识点主要包括，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

为了尽可能提供基本的概要，我有 2 台服务器正在运行。一台服务器是在 80 上运行的 apache，另一台是我在 golang 中创建的 recaptcha 服务器守护进程，运行超过 29999。我有一个正在运行的应用程序，用于监视来自主机的所有事件，以及是否有任何类型的“值得回避”的流量命中盒子。它将通过 ipset add 避开您的 IP，并将在 80 和 443 上添加 nat 预路由规则，目标 IP 将它们重定向到端口 29999。以 1.1.1.1 为例

-A RECAPTCHA-PREROUTE -s 1.1.1.1/32 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 29999

-A RECAPTCHA-PREROUTE -s 1.1.1.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 29999

快进一点：我正在尝试访问端口 80（我回避）。我被正确重定向到我的守护进程。我解决了 recaptcha，recaptcha 正确拨出到守护进程，守护进程正确删除 IP 的预路由防火墙规则，并将它们从 ipset 中删除。在“unshun”之后，Golang 守护进程会执行 http.Redirect(w, req, "/", 200) ，目的是将您发送到 https://example.com/ ，但相反，它会立即将我发送回运行在 29999 上的 recaptcha 守护进程，即使我可以打开一个单独的浏览器（edge gag），它也会直接带我到单独浏览器上的预期端点。考虑到这一点，如果我在边缘运行初始请求，它的行为将反映其他浏览器。我和我的一位同事确信，这是浏览器中的某种奇怪的缓存问题，我们缺少适当的处理，但从那时起，我们已经用尽了我们可以在互联网上找到的大多数可能的解决方案，例如适当的缓存提供标头，并向 html 文档添加元标记。

例如):

Go 语言

w.Header().Set("Cache-Control", "无缓存，无存储，必须重新验证")

w.Header().Set("Pragma", "no-cache")

w.Header().Set("过期", "0")

HTML

需要注意的一件更有趣的事情是，在删除 unshun/firewall 后，您被错误地重定向到 recaptcha 守护程序页面。如果您在浏览器 UI 上按 ctrl+r 大约 20-50 次。您最终将停止获取验证码页面，并且它将正确命中预期的服务器端点。此外，如果您清除浏览器缓存，它也会立即将您带到正确的页面。 （这就是为什么我们认为这是一些模糊的缓存问题。

正确答案

感谢 JimB 在评论中的回复，我找到了问题的解决方案。他说我没有正确关闭连接是正确的。 我所要做的就是添加一个关闭头 w.Header().Set("Connection", "close") 和一个 defer req.Body.Close() 。 req 是处理程序 *http.Request

本篇关于《为什么删除 iptables nat 预路由规则后重定向仍然存在？》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！