J'ai du mal à faire fonctionner TPROXY avec Squid et IPv6 sur un serveur CentOS 7. J'utilisais auparavant une configuration d'interception générique avec NAT, mais elle était limitée à IPv4 uniquement. J'étends maintenant la configuration pour inclure IPv6 avec TPROXY.
J'ai utilisé l'article officiel de Squid sur le sujet pour tout configurer:
http://wiki.squid-cache.org/Features/Tproxy4
Jusqu'à présent, la configuration TPROXY semble fonctionner pour IPv4 sans aucun problème. Cependant, avec IPv6, les connexions expirent et ne fonctionnent pas correctement. Je décompose la configuration pour une meilleure compréhension.
Notez tous les pare - feu et les règles de routage sont exactement les mêmes pour IPv4, la seule différence est inet6et ip6tablespour la configuration des règles basées IPv6 dans les exemples ci - dessous.
- OS et noyau: CentOS 7 (3.10.0-229.14.1.el7.x86_64)
- Tous les packages sont à jour selon yum
- Version Squid: 3.3.8 (également essayé 3.5.9)
- Pare-feu: iptables / ip6tables 1.4.21
- libcap-2.22-8.el7.x86_64
La connectivité IPv6 se fait actuellement via un tunnel 6 en 4 via Hurricane Electric, ceci est configuré sur le routeur DD-WRT puis le préfixe attribué délégué aux clients via radvd. La boîte Squid a plusieurs adresses IPv6 statiques configurées.
La boîte Squid se trouve dans le réseau local principal qu'elle dessert. Les clients qui ont du trafic sur le port 80 intercepté (principalement des clients sans fil) sont poussés vers la boîte Squid via mon routeur DD-WRT avec le pare-feu et les règles de routage suivants, adaptés de l'article wiki Policy Routing et du wiki DD-WRT
- 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
Cela semble fonctionner correctement en termes de transfert du trafic vers la boîte Squid. Une règle supplémentaire que j'ai dû ajouter sur le routeur DD-WRT en plus de ce qui précède était une règle d'exception pour les adresses IPv4 et IPv6 sortantes configurées sur la boîte Squid, sinon j'obtiens un problème de boucle folle et le trafic est interrompu pour tous les clients, y compris le LAN principal qui utilise Squid 3128.
ip6tables -t mangle -I PREROUTING -p tcp --dport 80 -s "$OUTGOING_PROXY_IPV6" -j ACCEPT
Sur la boîte Squid, j'utilise ensuite les règles de routage suivantes et la chaîne DIVERT pour gérer le trafic en conséquence. J'ai dû ajouter des règles supplémentaires pour éviter toute erreur avec la chaîne déjà existante lors des tests. Mon pare-feu est CSF, j'ai ajouté ce qui suit à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 est configuré pour deux ports:
http_proxy 3128
http_proxy 3129 tproxy
De plus, j'utilise également Privoxy et j'ai dû ajouter no-tproxyà ma ligne cache_peer, sinon tout le trafic n'a pas pu être transmis pour les deux protocoles.
cache_peer localhost parent 8118 7 no-tproxy no-query no-digest
Je n'utilise aucune tcp_outgoing_addressdirective à cause de Privoxy, mais je contrôle les adresses sortantes via CentOS et l'ordre de liaison.
valeurs 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
Je ne sais pas si les rp_filtermodifications sont nécessaires car la configuration fonctionne sur IPv4 avec ou sans elles et produit le même résultat pour IPv6.
SELINUX
SELINUX est activé sur la boîte Squid, mais les politiques ont été configurées pour autoriser la configuration TPROXY, donc elle n'est pas bloquée (le fonctionnement IPv4 le montre quand même). J'ai vérifié grep squid /var/log/audit/audit.log | audit2allow -aet obtenu<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;
J'ai également défini les booléens suivants:
setsebool squid_connect_any 1
setsebool squid_use_tproxy 1
Connectivité IPv6 rompue
En fin de compte, la connectivité IPv6 est complètement interrompue pour les clients TPROXY (les clients LAN sur le port 3128qui utilisent un fichier WPAD / PAC ont un IPv6 pleinement fonctionnel). Bien qu'il semble que le trafic soit acheminé vers la boîte Squid d'une manière ou d'une autre, aucune demande via IPv6 via TPROXY n'apparaît dans le access.log. Tous les IPv6 demandent à la fois IPv6 littéral et DNS, timeout. Je peux accéder aux clients IPv6 internes mais encore une fois, ce trafic n'est pas enregistré non plus.
J'ai fait quelques tests en utilisant test-ipv6.com et j'ai découvert qu'il détectait mon adresse Squid IPv6 sortante, mais les tests IPv6 étaient soit mauvais / lents, soit dépassés. J'ai temporairement activé l'en-tête via et j'ai trouvé que l'en-tête HTTP Squid était visible, donc le trafic arrive au moins vers la boîte Squid mais n'est pas acheminé correctement une fois qu'il est là.
J'essaie de faire fonctionner cela depuis un certain temps et je ne trouve pas le problème, j'ai même demandé sur la liste de diffusion Squid, mais je n'ai pas pu diagnostiquer le problème réel ni le résoudre. Sur la base de mes tests, je suis presque sûr que c'est l'un des domaines suivants et que Squid résout le problème:
- Acheminement
- Noyau
- Pare-feu
Toutes les idées et mesures supplémentaires que je peux prendre pour faire fonctionner TPROXY et IPv6 seraient grandement appréciées!
Information additionnelle
règles 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
Table de routage IPv6 (préfixe masqué)
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
Réponses:
Je me rends compte que c'est vieux, et je n'ai pas de réponse complète à cela moi-même, mais je fais quelque chose de très similaire à vous et j'ai des symptômes presque identiques.
Premièrement: test-ipv6.com semble s'être mis à jour un peu récemment pour pouvoir gérer un nouveau type d'erreur (il a été cassé plus tôt cette année). Réessayez.
Dans mon cas, il m'a envoyé vers une URL qui décrit un problème que je semble avoir: FAQ sur la détection de MTU de chemin . Ils fournissent une URL que vous pouvez utiliser avec cURL pour effectuer un test PMTUD, puis vous pouvez vérifier votre trafic à l'aide de
tpcdumpou wirehark.Lorsque le trafic est TPROXY sur Squid, la détection de MTU de chemin IPv6 ne fonctionne pas entièrement sur votre hôte. (Je travaille toujours sur pourquoi cela ne fonctionne pas sur mon hôte, donc je n'ai pas de solution définitive).
Une brève description:
Vous pouvez donc vous assurer que vos règles de pare-feu sont définies pour accepter les messages ICMPv6 (voir RFC4890 pour une liste des types ICMP "nécessaires").
Dans mon cas, j'autorise les messages ICMP et j'ai toujours le problème. Je ne suis pas tout à fait prêt à jeter l'éponge et à simplement réduire le MTU de mon réseau (qui est l'option nucléaire).
la source