拦截 http 代理 - 与普通代理相比的缺点
我想知道出于网络过滤的目的考虑实现拦截代理（具有缓存支持）有多“现实”。我还想支持 IPv6、客户端身份验证和缓存。
阅读squid wiki 的缺点列表 http://wiki.squid-cache.org/SquidFaq/ InterceptionProxy 实现了拦截代理，它提到了使用它时需要考虑的一些缺点（我想澄清一下）：
- 需要带有 NAT 的 IPv4 - 代理拦截不支持 IPv6， 为什么 ？
- 它会导致路径 MTU (PMTUD) 可能失败 - 为什么？
- 代理身份验证不起作用 - 客户端认为它正在直接与原始服务器对话，在这种情况下有没有办法进行身份验证？
- 拦截缓存仅支持 HTTP 协议，不支持 gopher、SSL 或 FTP。您无法为除 HTTP 之外的其他协议设置到代理服务器的重定向规则，因为它不知道如何处理它 - 这似乎很合理，因为在这种情况下将流量重定向到代理的方式是通过防火墙更改来完成的数据包从原始服务器到代理自己的地址（目标 NAT）的目标地址。在这种情况下，如果我想拦截除 http 之外的其他协议，如何知道连接的目的地，以便我可以将其中继到该目的地？
I would like to know how "realistic" is to consider implementing an intercepting proxy(with cache support) for the purpose of web filtering. I would like to support also IPv6, authentication of clients and caching.
Reading to the list of disadvantages from squid wiki http://wiki.squid-cache.org/SquidFaq/InterceptionProxy that implements an intercepting proxy, it mentions some things to consider as disadvantages when using it(that I want to clarify):
- Requires IPv4 with NAT - proxy intercepting does not support IPv6, why ?
- it causes path-MTU (PMTUD) to possibly fail - why ?
- Proxy authentication does not work - client thinks it's talking directly to the originating server, in there a way to do authentication in this case ?
- Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since it will not know how to deal with it - This seems quite plausible as the way redirecting of traffic to proxy is done in this case is by a firewall changing the destination address of a packet from the originating server to the proxy's own address(Destination NAT). How would in this case, if i want to intercept other protocols besides http know where the connection was intended to go so I can relay it to that destination ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
流量可能会通过多种方式被拦截。它不一定需要使用 NAT（IPv6 不支持）。例如，透明拦截肯定不会使用 NAT（透明是指代理不会使用自己的地址而是使用客户端地址生成请求，从而欺骗 IP 地址）。
PMTUD 用于检测客户端和服务器之间的路径中可用的最大 MTU 大小，反之亦然，它有助于避免客户端和服务器之间的路径上的 Ip 数据包碎片。当你在中间使用Proxy时，即使检测到MTU，也不一定与从客户端到代理、从代理到服务器的MTU相同。但这并不总是相关的，它取决于正在服务的流量以及代理的行为方式。
如果代理代表客户端进行身份验证，则它需要了解身份验证方法，并且可能需要客户端中存在的一些 cookie。这样想...如果代理可以代表您验证对受限资源的访问，则意味着任何人都可以代表您执行此操作，而良好身份验证的目的就是保护您免受这种可能性的影响。
我猜这是 Squid 人员发表的一篇非常古老的帖子，但是存在可以将您想要的任何内容重定向到特定服务器的技术。一种简单的方法是将您的服务器放置为网络的默认网关，然后所有数据包都通过它，您可以将您喜欢的数据包重定向到您的应用程序（或另一台服务器）。而且你不限于 HTTP，但你受限于应用程序协议的工作方式。
Traffic may be intercepted in many ways. It does not necessarily need to use NAT (which is not supported in IPv6). A transparent interception will surely not use NAT for example (transparent in the sense that the Proxy will not generate requests with his own address but with the client address, spoofing the IP address).
PMTUD is used to detect the largest MTU size available in the path between the client and server and vise versa, it is useful for avoiding fragmentation of Ip packets on the path between the client and server. When you use a Proxy in the middle, even if the MTU is detected, it not necessarily the same as the one from the client to the proxy and from the proxy to the server. But this is not always relevant, it depends on what traffic is being served and how the proxy is behaving.
If the proxy is authenticating in the client behalf, it needs to be aware of the authentication method, and it will probably need some cookies that exist in the client. Think of it this way... If a proxy can authenticate an access to a restricted resource on your behalf, it means anyone can do it on your behalf, and the purpose of a good authentication is to protect you from such possibilities.
I guess this was a very old post from the Squid guys, but the technology exists to redirect anything you want to a specific server. One simple way to do it is by placing your server as a Default Gateway for the network, then all packets pass through it and you could redirect the packets you like to your application (or another server). And you are not limited to HTTP, BUT you are limited to the way the application protocol works.