The Sunday 07 December 2008 14:27:49 Pascal Hambourg, you wrote : > Thomas Preud'homme a écrit : > > The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote : > >> Thomas Preud'homme a écrit : > >>> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert > >>> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de > >>> kame.net qui danse. > >> > >> Jamais eu besoin de cette option pour faire les résolutions DNS en > >> adresse IPv6 en premier. C'est le cas par défaut, ce que certains > >> regrettent. > > > > Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. > > As-tu quelque chose de spécial dans sysctl.conf ? > > Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour > empêcher les communications IPv4 sur les sockets IPv6. Au départ c'était > pour contourner un bug de BIND9, mais ça a aussi un effet de bord > intéressant : les adresses IPv4 n'apparaissent plus sous la forme > > ::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la > > même façon sur toutes mes Debian (sarge et etch), même celles qui n'ont > pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du > noyau pourrait influencer la résolution DNS de la glibc qui est en > userland. > > Il faudrait creuser un peu plus pour voir ce qui se passe, notamment > faire une capture des paquets DNS, et utiliser des outils plus bas > niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et > IPv6, et affiche l'adresse destination effectivement choisie pour > établir la connexion. Je veux bien regarder mais a priori il n'y a juste aucune tentative pour récupérer un champ AAAA. Ou en tout cas s'il y en a une c'est pas l'adresse choisie. Il doit bien y avoir un paramètre chez moi qui pose problème. Pourriez-vous coller un /etc/network/interfaces à tout hasard (je doute que le problème se situe dans ce fichier mais sait-on jamais). > > >>> J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel > >>> je n'avais jamais pensé. Si je fais un reconfigure les interfaces > >>> réseaux en écoutant un flux radio, celui-ci se poursuivra > >>> (éventuellement avec une coupure si le buffer est trop petit) sans > >>> problème, n'ayant aucune mémoire contrairement au NAT. > >> > >> Je ne vois pas le rapport. Tu peux détailler ? > > > > Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois > > effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir > > avec le suivi de connexion d'iptables. > > En effet. Sauf si la machine utilise la cible MASQUERADE sur ces > connexions. Quand l'adresse IPv4 de l'interface de sortie change, les > connexions masquées avec l'ancienne adresse sont supprimées. Ce n'est pas le cas, c'est le routeur qui l'utilise. Et je n'ai plus de routeur depuis deux mois environ. De plus mon IP externe était fixe comme les IPs du réseau local (fixée par adresse MAC dans dhcpd.conf). > > > Donc même en renouvelant la requête dhcp ça ne devrait > > avoir aucun effet sur la règle qui laisse passer les connexions établies. > > Et sinon le fait de redémarrer l'interface réseau devrait effectivement > > même dans ce cas purger iptables et donc considérer les paquets arrivant > > à partir de ce moment comme une nouvelle connexion. > > Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour > purger la table de suivi des connexions il faut décharger le module > noyau correspondant ou le faire explicitement avec le programme > 'conntrack' du paquet du même nom. Cordialement, Thomas Preud'homme -- Why debian : http://www.debian.org/intro/why_debian
Attachment:
signature.asc
Description: This is a digitally signed message part.