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