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.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]