Squid 3.3 Transparenter IPv4- und IPv6-Proxy mit TPROXY

3835
James White

Ich versuche, mein transparentes Squid-Setup zu ändern, indem ich generisches NAT, das nur auf IPv4 beschränkt ist, und für die Unterstützung von IPv6 auf TPROXY umstellt. Ich habe Schwierigkeiten, transparente Clients für die Arbeit unter dem neuen Setup zu erhalten. Alle Anforderungen werden jedoch mit Squid erfüllt, wobei bei allen Anfragen der folgende Fehler ausgegeben wird:

"Die angeforderte URL konnte nicht aufgerufen werden"

Anscheinend gibt es irgendwo ein Routing-Problem, aber ich bin mir nicht sicher, was falsch ist.

Ich benutze iptablesund ip6tablesauf meinem DD-WRT-Router und Squid-Proxy iproute2, um die Routing-Teile auf beiden Seiten auszuführen.

Standardmäßig wird das ip6table_mangleModul standardmäßig nicht in DD-WRT geladen, es wurde jedoch in den Build auf meinem Router kompiliert:

find /lib/modules -name "*.ko" | grep -i mangle /lib/modules/3.10.89/ip6table_mangle.ko 

Das Modul geladen und zum Startskript für zukünftige Starts hinzugefügt:

insmod ip6table_mangle 

DD-WRT-Routing-Informationen:

# Squid transparent proxy PROXY_IPV4="192.168.x.x" PROXY_IPV6="xxxx:xxxx:xxxx:xxxx::x" CLIENTIFACE=br0 FWMARK=3  iptables -t mangle -A PREROUTING -i $CLIENTIFACE -p tcp --dport 80 -s $PROXY_IPV4 -j ACCEPT ip6tables -t mangle -A PREROUTING -i $CLIENTIFACE -p tcp --dport 80 -s $PROXY_IPV6 -j ACCEPT  iptables -t mangle -A PREROUTING -i $CLIENTIFACE -p tcp --dport 80 -j MARK --set-mark $FWMARK iptables -t mangle -A PREROUTING -m mark --mark $FWMARK -j ACCEPT ip6tables -t mangle -A PREROUTING -i $CLIENTIFACE -p tcp --dport 80 -j MARK --set-mark $FWMARK ip6tables -t mangle -A PREROUTING -m mark --mark $FWMARK -j ACCEPT  iptables -t filter -A FORWARD -i $CLIENTIFACE -o $CLIENTIFACE -p tcp --dport 80 -j ACCEPT ip6tables -t filter -A FORWARD -i $CLIENTIFACE -o $CLIENTIFACE -p tcp --dport 80 -j ACCEPT  ip rule add fwmark $FWMARK table 2 ip -6 rule add fwmark $FWMARK table 2 ip route add default via $PROXY_IPV4 table 2 ip -6 route add default via $PROXY_IPV6 table 2  # End Squid intercept proxy config 

Squid-Proxy-Routing (auf dem Server selbst):

iptables -F -t mangle iptables -X -t mangle ip6tables -F -t mangle ip6tables -X -t mangle iptables -t mangle -N DIVERT ip6tables -t mangle -N DIVERT  iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129  ip6tables -t mangle -A DIVERT -j MARK --set-mark 1 ip6tables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT ip6tables -t mangle -A DIVERT -j ACCEPT ip6tables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129  ip -f inet rule add fwmark 1 lookup 100 ip -f inet route add local default dev eno1 table 100  ip -f inet6 rule add fwmark 1 lookup 100 ip -f inet6 route add local default dev eno1 table 100 

Tintenfisch conf:

http_port 3129 tproxy 

sysctl config:

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

eno1ist die Haupt-Ethernet-Schnittstelle, die ich auch loohne Erfolg ausprobiert habe.

Der Datenverkehr wird an die Squid-Box weitergeleitet, sodass der Router anscheinend seine Aufgabe erfüllt. Es ist der Zeitpunkt, an dem der Verkehr bei der Squid-Box endet und dort scheinbar ein Fehler auftritt. Alle Anforderungen werden protokolliert, es werden jedoch 500 Fehler zurückgegeben.

Soweit mir bekannt ist, unterstützt mein Setup TPROXY:

  • CentOS 7
  • Tintenfisch 3.3.8 (EPEL)
  • iptables / ip6tables 1.4.21
  • Linux-Kernel 3.10
  • libcap 2.22

Ich habe diese Quellen als Anleitung verwendet, bekomme aber kein funktionierendes Setup.

Irgendwelche Ratschläge, was könnte das Problem sein oder weiter zu debuggen?

1

1 Antwort auf die Frage

1
James White

Es stellte sich heraus, dass alles korrekt eingerichtet wurde. Das eigentliche Problem war meine cache_peer-Direktive für Privoxy. Der Fehler ist tatsächlich Squid, der besagt, dass er den Datenverkehr nicht an Privoxy weitergeben kann. Dies liegt daran, dass das tproxy-Setup dies verwirrt.

Um dies zu vermeiden, müssen Sie no-tproxydie cache_peer-Zeile hinzufügen

cache_peer hostname parent 8118 7 no-tproxy ...