Ich habe Probleme, TPROXY mit Squid und IPv6 auf einem CentOS 7-Server zum Laufen zu bringen. Ich habe zuvor ein generisches Intercept-Setup mit NAT verwendet, das jedoch nur auf IPv4 beschränkt war. Jetzt erweitere ich das Setup um IPv6 mit TPROXY.
Ich habe den offiziellen Squid-Wiki-Artikel zum Thema verwendet, um alles zu konfigurieren:
http://wiki.squid-cache.org/Features/Tproxy4
Bisher scheint die TPROXY-Konfiguration für IPv4 ohne Probleme zu funktionieren. Bei IPv6 laufen die Verbindungen jedoch aus und funktionieren nicht richtig. Ich werde das Setup zum besseren Verständnis aufschlüsseln.
Beachten Sie alle Firewall- und Routing - Regeln sind genau die gleichen für IPv4, der einzige Unterschied ist , inet6und ip6tablesfür die Konfiguration von IPv6 - basierten Regeln in den folgenden Beispielen.
- Betriebssystem und Kernel: CentOS 7 (3.10.0-229.14.1.el7.x86_64)
- Alle Pakete sind laut yum auf dem neuesten Stand
- Squid Version: 3.3.8 (auch ausprobiert 3.5.9)
- Firewall: iptables / ip6tables 1.4.21
- libcap-2.22-8.el7.x86_64
Die IPv6-Konnektivität erfolgt derzeit über einen 6in4-Tunnel über Hurricane Electric. Dies wird auf dem DD-WRT-Router konfiguriert und anschließend das zugewiesene Präfix über an Clients delegiert radvd. In der Squid-Box sind mehrere statische IPv6-Adressen konfiguriert.
Die Squid-Box befindet sich im Haupt-LAN, das sie bedient. Clients, bei denen der Datenverkehr auf Port 80 abgefangen wird (hauptsächlich drahtlose Clients), werden über meinen DD-WRT-Router mit den folgenden Firewall- und Routing-Regeln, die aus dem Wiki-Artikel zum Richtlinien-Routing und dem DD-WRT-Wiki stammen, an die Squid-Box übertragen
- http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute
http://www.dd-wrt.com/wiki/index.php/Squid_Transparent_Proxy
ip6tables -t mangle -A PREROUTING -i "$CLIENTIFACE" -s "$PROXY_IPV6" -p tcp --dport 80 -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 ip6tables -t filter -A FORWARD -i "$CLIENTIFACE" -o "$CLIENTIFACE" -p tcp --dport 80 -j ACCEPT ip -f inet6 rule add fwmark $FWMARK table 2 ip -f inet6 route add default via "$PROXY_IPV6" dev "$CLIENTIFACE" table 2
Dies scheint in Bezug auf die Weiterleitung des Datenverkehrs an die Squid-Box in Ordnung zu sein. Eine zusätzliche Regel, die ich auf dem DD-WRT-Router zusätzlich zu den oben genannten Regeln hinzufügen musste, war eine Ausnahmeregel für die konfigurierten ausgehenden IPv4- und IPv6-Adressen auf der Squid-Box das Haupt-LAN, in dem Squid verwendet wird 3128.
ip6tables -t mangle -I PREROUTING -p tcp --dport 80 -s "$OUTGOING_PROXY_IPV6" -j ACCEPT
Auf der Squid-Box verwende ich dann die folgenden Routing-Regeln und die DIVERT-Kette, um den Verkehr entsprechend zu behandeln. Ich musste zusätzliche Regeln hinzufügen, um Fehler in der Kette zu vermeiden, die bereits beim Testen vorhanden waren. Meine Firewall ist CSF, ich habe folgendes hinzugefügtcsfpre.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 ist für zwei Ports konfiguriert:
http_proxy 3128
http_proxy 3129 tproxy
Außerdem benutze ich Privoxy und musste no-tproxymeine cache_peer-Zeile ergänzen, da sonst der gesamte Datenverkehr für beide Protokolle nicht weitergeleitet werden konnte.
cache_peer localhost parent 8118 7 no-tproxy no-query no-digest
tcp_outgoing_addressAufgrund von Privoxy verwende ich keine Direktiven. Stattdessen kontrolliere ich die ausgehenden Adressen über CentOS und die Bindungsreihenfolge.
Sysctl-Werte:
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
Ich bin nicht sicher, ob die rp_filterÄnderungen erforderlich sind, da das Setup auf IPv4 mit oder ohne IPv6 funktioniert und dasselbe Ergebnis für IPv6 liefert.
SELINUX
SELINUX ist in der Squid-Box aktiviert, aber die Richtlinien wurden so konfiguriert, dass das TPROXY-Setup zulässig ist, sodass es nicht blockiert wird (IPv4 zeigt dies trotzdem). Ich habe nachgefragt grep squid /var/log/audit/audit.log | audit2allow -aund bekommen<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;
Ich habe auch die folgenden Booleschen Werte gesetzt:
setsebool squid_connect_any 1
setsebool squid_use_tproxy 1
Unterbrochene IPv6-Konnektivität
Letztendlich ist die IPv6-Konnektivität für TPROXY-Clients vollständig unterbrochen (LAN-Clients am Port, 3128die eine WPAD / PAC-Datei verwenden, verfügen über voll funktionsfähiges IPv6). Während der Datenverkehr auf irgendeine Weise an die Squid-Box weitergeleitet wird, werden in der Box keine Anforderungen über IPv6 über TPROXY angezeigt access.log. Bei allen IPv6-Anforderungen wird eine Zeitüberschreitung sowohl für IPv6 als auch für DNS festgestellt. Ich kann auf interne IPv6-Clients zugreifen, aber auch dieser Datenverkehr wird nicht protokolliert.
Ich habe einige Tests mit test-ipv6.com durchgeführt und festgestellt, dass meine ausgehende Squid-IPv6-Adresse erkannt wurde, aber die IPv6-Tests haben sich entweder als schlecht / langsam oder als Zeitüberschreitung erwiesen. Ich habe den Via-Header vorübergehend aktiviert und festgestellt, dass der Squid-HTTP-Header sichtbar ist, sodass der Datenverkehr zumindest zur Squid-Box gelangt, aber dort nicht ordnungsgemäß weitergeleitet wird.
Ich habe seit einiger Zeit versucht, dies zum Laufen zu bringen und kann das Problem nicht finden. Ich habe sogar auf der Squid-Mailingliste nachgefragt, konnte jedoch das eigentliche Problem nicht diagnostizieren oder beheben. Aufgrund meiner Tests bin ich mir ziemlich sicher, dass einer der folgenden Bereiche und die Squid-Box das Problem sind:
- Routing
- Kernel
- Firewall
Alle Ideen und zusätzlichen Schritte, die ich unternehmen kann, um TPROXY und IPv6 zum Laufen zu bringen, wären sehr dankbar!
Zusätzliche Information
ip6tables Regeln:
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-Routingtabelle (Präfix verdeckt)
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
Antworten:
Mir ist klar, dass dies alt ist und ich selbst keine vollständige Antwort darauf habe, aber ich mache etwas sehr Ähnliches wie Sie und habe nahezu identische Symptome.
Erstens: test-ipv6.com scheint sich vor einiger Zeit aktualisiert zu haben, um einen neuen Fehlertyp behandeln zu können (er war Anfang dieses Jahres defekt). Probieren Sie es noch einmal.
In meinem Fall wurde ich an eine URL weitergeleitet, die ein Problem beschreibt, das anscheinend vorliegt: Häufig gestellte Fragen zur Pfad-MTU-Erkennung . Sie stellen eine URL bereit, die Sie mit cURL für einen PMTUD-Test verwenden können. Anschließend können Sie Ihren Datenverkehr mit
tpcdumpoder mit Wireshark überprüfen.Wenn der Verkehr mit TPROXY über Squid übertragen wird, funktioniert die IPv6-Pfad-MTU-Erkennung auf Ihrem Host nicht vollständig. (Ich arbeite immer noch daran, warum es auf meinem Host nicht funktioniert , daher habe ich keine endgültige Lösung).
Eine kurze Beschreibung:
Sie sollten daher sicherstellen, dass Ihre Firewall-Regeln ICMPv6-Nachrichten akzeptieren (eine Liste der "benötigten" ICMP-Typen finden Sie in RFC4890).
In meinem Fall erlaube ich ICMP-Nachrichten und habe immer noch das Problem. Ich bin nicht ganz bereit, das Handtuch zu werfen und nur die MTU meines Netzwerks zu reduzieren (das ist die nukleare Option).
quelle