Mise en place de Squid et TPROXY avec IPv6 sur CentOS 7


18

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

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

J'ai essayé de mettre à jour vers une version ultérieure de Squid (3.5), pour exclure tout problème de bogue / version, mais le problème persiste.
James White

1
Je commente juste pour dire que cela fonctionnait il y a environ un an sur une boîte CentOS 6. Cependant, il a soudainement cessé de fonctionner un jour (après une mise à jour du noyau, je pense) et je n'ai pas réussi à le faire fonctionner depuis. Si j'active la configuration IPv6 TPROXY, cela interrompt fondamentalement tout le trafic du port 80 et rien n'atteint le calmar. Je l'ai abandonné pour le moment. Le noyau que j'utilise actuellement est 2.6.32 - Je note que sur wiki.squid-cache.org/Features/Tproxy4 , ils listent une version minimale du noyau de 2.6.37 donc je suis déjà à court de cela. Si jamais j'en discute, je mettrai à jour ici mes résultats.
parkamark

Alors j'ai finalement réussi à faire fonctionner ça. Le problème était que le port IPv4 «intercept» était égal au port IPv6 «tproxy» dans squid.conf - cela est détaillé dans la documentation, mais je pensais que je pouvais m'en tirer car je n'avais pas ces ports à l'écoute adresses / piles spécifiques avec le port, il n'y a donc aucune raison spécifique pour laquelle elles devraient entrer en conflit, non? Eh bien, cela semble être une fausse présomption. Lisez la suite ...
parkamark

J'avais défini "http_port 192.168.0.1:3128 intercept" et "http_port [fd00 :: 2]: 3128 tproxy" dans squid.conf - ne faites pas ça! Ce doit être simplement "http_port 3128 intercept" et "http_port 3129 tproxy". Vous ne pouvez pas avoir le port tproxy IPv6 lié à une adresse IPv6 spécifique, puis vous attendre à ce que toute la magie du pare-feu / routage fonctionne. Vous ne pouvez spécifier que les ports seuls, ce qui signifie que Squid se liera à toutes les adresses / interfaces sur ces ports. J'ajouterai des règles de pare-feu pour verrouiller ces ports ouverts au besoin.
parkamark

Réponses:


1

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:

  • ICMP est extrêmement important dans IPv6. Beaucoup de gens veulent bloquer l'ICMP et finissent par causer plus de mal que de bien.
  • Si un paquet est "trop ​​gros" pour votre connexion, le paquet est abandonné et un message ICMP de type 2 ("Paquet trop gros") est censé être envoyé au serveur d'origine, lui demandant de réduire la taille du paquet et de le renvoyer.
  • Si le message ICMP ne parvient pas au serveur, le serveur continue de renvoyer le gros paquet - qui est immédiatement supprimé car il est trop volumineux.
  • Cela a été décrit comme un "trou noir" car les paquets n'atteignent jamais leur destination.

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).

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.