在CentOS 7上使用IPv6获取Squid和TPROXY


18

我在让TPROXY在CentOS 7服务器上使用Squid和IPv6时遇到麻烦。我以前使用的是带有NAT的通用拦截设置,但仅限于IPv4。我现在正在扩展设置,使其包含带有TPROXY的IPv6。

我一直在使用有关该主题的官方Squid Wiki文章来配置所有内容:

http://wiki.squid-cache.org/Features/Tproxy4

到目前为止,TPROXY配置似乎可以正常用于IPv4。但是,使用IPv6时,连接超时,无法正常工作。我将分解设置以便更好地理解。

请注意,所有防火墙和路由规则对于IPv4都是完全相同的,唯一的区别是在下面的示例中inet6以及ip6tables用于配置基于IPv6的规则。

  • 操作系统和内核:CentOS 7(3.10.0-229.14.1.el7.x86_64)
  • 根据yum,所有软件包都是最新的
  • 鱿鱼版:3.3.8(也尝试过3.5.9)
  • 防火墙:iptables / ip6tables 1.4.21
  • libcap-2.22-8.el7.x86_64

目前,IPv6连接是通过Hurricane Electric通过6in4隧道进行的,该连接在DD-WRT路由器上进行配置,然后将分配的前缀通过委派给客户端radvd。Squid框配置了多个静态IPv6地址。

Squid框位于它所服务的主LAN内。在端口80上被拦截的客户端(主要是无线客户端)通过具有以下防火墙和路由规则的DD-WRT路由器,通过我的DD-WRT路由器被推送到Squid框,这些规则和规则来自于Policy Routing Wiki文章和DD-WRT Wiki

就将流量传递到Squid框而言,这似乎工作正常。除上述之外,我还必须在DD-WRT路由器上添加的另一条规则是Squid框中已配置的传出IPv4和IPv6地址的例外规则,否则我会遇到疯狂的循环问题,并且所有客户端的流量都会中断,包括使用Squid的主要LAN 3128

ip6tables -t mangle -I PREROUTING -p tcp --dport 80 -s "$OUTGOING_PROXY_IPV6" -j ACCEPT

然后,在Squid框上,我使用以下路由规则和DIVERT链相应地处理流量。我需要添加其他规则,以防止测试过程中已经存在的链条出现任何错误。我的防火墙是CSF,我已将以下内容添加到csfpre.sh

ip -f inet6 route flush table 100
ip -f inet6 rule del fwmark 1 lookup 100

ip -f inet6 rule add fwmark 1 lookup 100
ip -f inet6 route add local default dev eno1 table 100

ip6tables -t mangle -F
ip6tables -t mangle -X
ip6tables -t mangle -N DIVERT

ip6tables -t mangle -A DIVERT -j MARK --set-mark 1
ip6tables -t mangle -A DIVERT -j ACCEPT
ip6tables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
ip6tables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129

squid.conf 配置了两个端口:

http_proxy 3128
http_proxy 3129 tproxy

此外,我还使用了Privoxy,必须将其添加no-tproxy到我的cache_peer行中,否则无法针对这两种协议转发所有流量。

cache_peer localhost parent 8118 7 no-tproxy no-query no-digest

tcp_outgoing_address由于Privoxy,我没有使用任何指令,而是通过CentOS和绑定顺序来控制出站地址。

sysctl值:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eno1.rp_filter = 0

我不确定是否rp_filter需要修改,因为安装程序可以在有或没有IPv4的情况下在IPv4上运行,并为IPv6产生相同的结果。

赛灵思

在Squid框上启用了SELINUX,但已将策略配置为允许TPROXY设置,因此不会被阻止(无论如何,IPv4的工作都显示了这一点)。我已经检查grep squid /var/log/audit/audit.log | audit2allow -a并获得<no matches>

#============= squid_t ==============

#!!!! This avc is allowed in the current policy
allow squid_t self:capability net_admin;

#!!!! This avc is allowed in the current policy
allow squid_t self:capability2 block_suspend;

#!!!! This avc is allowed in the current policy
allow squid_t unreserved_port_t:tcp_socket name_connect;

我还设置了以下布尔值:

setsebool squid_connect_any 1
setsebool squid_use_tproxy 1

IPv6连接中断

最终,TPROXY客户端的IPv6连接被完全破坏(端口3128上使用WPAD / PAC文件的LAN客户端具有完全正常工作的IPv6)。当流量似乎以某种方式路由到Squid框时,没有通过TPROXY通过IPv6的请求出现access.log。所有IPv6都请求原义IPv6和DNS,超时。我可以访问内部IPv6客户端,但同样,此流量也未记录。

我使用test-ipv6.com做了一些测试,发现它检测到我的Squid IPv6地址,但是IPv6测试显示为错误/缓慢或超时。我临时启用了via标头,发现Squid HTTP标头是可见的,因此流量至少会到达Squid框,但一旦到达那里,就无法正确路由。

我一直在尝试使它工作一段时间,但找不到问题所在,我什至在Squid邮件列表中也提出过要求,但一直无法诊断出实际问题或解决问题。根据我的测试,我很确定它是以下区域之一,并且Squid可以解决问题:

  • 路由
  • 核心
  • 防火墙功能

我将为使TPROXY和IPv6正常工作而采取的任何想法和其他步骤将不胜感激!

附加信息

ip6tables规则:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DIVERT     tcp      ::/0                 ::/0                 socket
TPROXY     tcp      ::/0                 ::/0                 tcp dpt:80 TPROXY redirect :::3129 mark 0x1/0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain DIVERT (1 references)
target     prot opt source               destination
MARK       all      ::/0                 ::/0                 MARK set 0x1
ACCEPT     all      ::/0                 ::/0

IPv6路由表(前缀已模糊)

unreachable ::/96 dev lo  metric 1024  error -101
unreachable ::ffff:0.0.0.0/96 dev lo  metric 1024  error -101
2001:470:xxxx:xxx::5 dev eno1  metric 0
    cache  mtu 1480
2001:470:xxxx:xxx:b451:9577:fb7d:6f2d dev eno1  metric 0
    cache
2001:470:xxxx:xxx::/64 dev eno1  proto kernel  metric 256
unreachable 2002:a00::/24 dev lo  metric 1024  error -101
unreachable 2002:7f00::/24 dev lo  metric 1024  error -101
unreachable 2002:a9fe::/32 dev lo  metric 1024  error -101
unreachable 2002:ac10::/28 dev lo  metric 1024  error -101
unreachable 2002:c0a8::/32 dev lo  metric 1024  error -101
unreachable 2002:e000::/19 dev lo  metric 1024  error -101
unreachable 3ffe:ffff::/32 dev lo  metric 1024  error -101
fe80::/64 dev eno1  proto kernel  metric 256
default via 2001:470:xxxx:xxxx::1 dev eno1  metric 1

我已尝试更新到Squid(3.5)的更高版本,以排除任何错误/发布问题,但问题仍然存在。
詹姆斯·怀特

1
只是说我大约在一年前在CentOS 6机器上工作过。但是,它突然停止了一天的工作(我认为在内核更新之后),此后我一直没有使其工作。如果启用了IPv6 TPROXY设置,则它基本上会中断所有端口80的流量,并且没有任何东西到达鱿鱼。我暂时已经放弃了。我当前正在运行的内核是2.6.32-我注意到在wiki.squid-cache.org/Features/Tproxy4上,它们列出的最低内核版本是2.6.37,所以我已经不够了。如果我有任何疑问,我将在这里更新我的发现。
parkamark

因此,我终于完成了这项工作。问题在于使IPv4“拦截”端口等于squid.conf中的IPv6“ tproxy”端口-在文档中对此进行了详细说明,但是我认为我可以不这样做,因为我监听了这些端口特定的地址/堆栈以及端口,因此没有特定的原因为什么它们会发生冲突,对吗?好吧,这似乎是一个错误的假设。继续阅读...
parkamark's

我在squid.conf中定义了“ http_port 192.168.0.1:3128拦截”和“ http_port [fd00 :: 2]:3128 tproxy”-不要这样做!它必须只是“ http_port 3128拦截”和“ http_port 3129 tproxy”。您不能将IPv6 tproxy端口绑定到特定的IPv6地址,然后期望所有防火墙/路由魔术都能正常工作。您只能单独指定端口,这意味着squid将绑定到这些端口上的所有地址/接口。我将添加防火墙规则以根据需要锁定这些打开的端口。
parkamark

Answers:


1

我意识到这已经很老了,我自己对此还没有完整的答案,但是,我做的事情与您非常相似,并且症状几乎相同。

首先:test-ipv6.com似乎最近已进行了一些更新,以能够处理一种新型错误(今年早些时候已被修复)。再次进行测试。

就我而言,它向我发送了一个描述我似乎遇到的问题的URL: 路径MTU检测常见问题解答。它们提供了一个URL,您可以将其与c​​URL一起使用以进行PMTUD测试,然后您可以使用tpcdump或wireshark 检查流量。

当通过Squid对TPROXY进行通信时,IPv6路径MTU检测不能完全在您的主机上工作。(我仍在研究为什么它在我的主机上不起作用,因此我没有明确的解决方案)。

快速说明:

  • ICMP在IPv6中极为重要。许多人想阻止ICMP,最终造成弊大于利。
  • 如果某个数据包对于您的连接而言“太大”,则该数据包将被丢弃,并且应该将2类ICMP(“太大的数据包”)消息发送到原始服务器,要求其减小数据包大小并重新发送。
  • 如果ICMP消息未发送到服务器,则服务器将继续重新发送大数据包-由于太大,该大数据包将立即丢弃。
  • 这被描述为“黑洞”,因为数据包永远不会到达目的地。

因此,您可能需要确保将防火墙规则设置为接受ICMPv6消息(有关“所需” ICMP类型的列表,请参阅RFC4890)。

就我而言,我允许ICMP消息,但仍然有问题。我还没有做好准备,只是降低网络的MTU(这是核选项)。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.