Recherche DNS lente avec proxy transparent

[Franki973]

Bonjour,

Après maintes recherches sur plusieurs forums, je ne trouve pas de réponse a un problème testé sur plusieurs IPCOPS avec différents OS clients, pourtant je ne pense pas être le seul dans ce cas:
- IPCOP en proxy transparent
- Aucun problème avec les OS Windows, Ubuntu 8.04 ou Karmic
- Problème de lenteur "recherche de l'hôte" (30s à 1 mn) au niveau de la recherche DNS avec Mandriva, Puppy Linux, Ubuntu Lucid.
- Bien entendu, j'ai testé un certain nombre de combinaisons Iptables pour "libérer" le port 53 mais sans résultat.
- En configurant manuellement un proxy pour apt-get, wget, FFox, ou sur la variable http_proxy ça passe bien évidemment mais je perd le remarquable fonctionnalité du proxy transparent. Quant a utiliser plusieurs réseaux...
Un avis d'expert ou un retour d'expérience serait le bienvenu.
Merci

[jdh]

- Aucun problème avec les OS Windows, Ubuntu 8.04 ou Karmic
- Problème de lenteur "recherche de l'hôte" (30s à 1 mn) au niveau de la recherche DNS avec Mandriva, Puppy Linux, Ubuntu Lucid.

Cela tend à dire que cela dépend de l'OS client et non d'ipcop.

Il faut donc détailler COMMENT est configuré chaque OS client au niveau de dns : reçoit-il correctement la bonne valeur de dns ?

Juste pour vérification, regarder aussi si IPCOP dispose du bon serveur dns.


Vu l'absence de schéma, de précisions élémentaires d'adressage, il nous sera difficile de donner d'autres réponses ! Tant qu'à faire, une approche un peu scientifique est nécessaire ...

NB : Que signifie "combinaisons Iptables pour "libérer" le port 53" ?

[Franki973]

Merci de suivre ce cas.
Un peu plus de détails. Voici un cas standard simple
- modem ADSL en mode bridge
- Ipcop 1.4.21 en compact flash avec 1Go mem totale dont 640Mo pour le proxy.
- interface rouge en PPOE
- Interface verte en 192.168.0.1 serveur DHCP actif
- clients en DHCP (idem avec adressage fixe)
- vu du poste client, le DNS est 192.168.0.1.
- proxy standard en mode transparent sur le port 800
Ce qui est notable:
- On supprime le proxy transparent, tout est OK
- On l'active: seuls les OS cités fontionnent correctement
Concernant le port 53, j'ai tenté de voir s'il était possible de shunter le cache DNS de l'Ipcop, de réaliser par exemple un accès direct au 8.8.8.8 de Google mais mes connaissances des règles IPtables sont sommaires et j'ai procédé par essais/erreurs plus que par logique rigoureuse.
Il est sûr que si je connaissais le moyen de tracer ce qui se passe durant cette lente "recherche de l'hôte", cela eclaicirait bien des choses.
Autre remarque: le même site rappelé une seconde fois génère la même attente.

[Franck78]

j'ai du mal voir dans la description très succinte du problème une indication orientant vers le dns.
D'autant plus en apprenant que le passage de proxy "transparent à défini" change le problème.
Et entre proxy et naviguateur? On en pense quoi??

[visa]

Bonjour,

J'avais le meme pb avec le dns sous ipcop.
En mettant les logs en service, je me suis apercu que le pb venait des requetes en IPv6.
en passant tous les pc client en IPv4, je n'ai plus de pb.

En esperant que ca puisse aider,

Cordialement

[Franki973]

Bonjour,

Excusez moi, mais je n'ai pas reçu la notification de votre message et viens seulement d'en prendre connaissance. En effet, l'IP V6 pose souvent des problèmes, phénomème régulièrement constaté avec Vista, et l'on constate que l'adresse distribuée par le DHCP Ipcop n'est pas correcte chez le client. Phénomène aléatoire apparaissant/disparaissant lors des renouvellements des baux.
De toutes façons, pour une simple connexion internet, Windows trimbale une foule de protocoles inutiles, voire dangereux, et la connexion se porte d'autant mieux en activant seulement IP V4 dans les propriétés de la carte réseau.
Cependant, dans mon cas, il ne s'agit pas de cela...
Sincères salutations

[Franck78]

Il est sûr que si je connaissais le moyen de tracer ce qui se passe durant cette lente "recherche de l'hôte", cela eclaicirait bien des choses.

l'un d'eux est simplement 'tcpdump'

A lancer sur l'interface GREEN (eth0)
tcpdump -i eth0 -n (pas de noms clair, juste des nombres

Si il y a trop de bruit,
tcpdump -n -i eth0 ip_de_la_ubuntu_fautive

Puis idem en surveillant "ppp0"

Après, c'est une question d'interprétation, d'expertise, de chance

[Franki973]

Bonjour,

Le problème est résolu, par 2 possibilités. Les experts vont surement tiquer car ces solutions ne semblent avoir aucun rapport entre elles:

1) IPV6. merci à Visa d'avoir insisté sur ce point. J'ai donc revu tout cela. Je présumais que dans la fenêtre des connexions IPV6 (Ubuntu) la méthode "ignorer" était suffisante. Il n'en est rien. En désactivant IPV6 au niveau du noyau par contre, plus de lenteurs.
A partir de Karmic et Grub2
modifier:
/etc/default/grub
Changer cette ligne:
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
en
GRUB_CMDLINE_LINUX_DEFAULT=”ipv6.disable=1 quiet splash”
Puis , mettre a jour grub :
sudo update-grub et redémarrer (Source: Help.Ubuntu.com)

Mais cela oblige a modifier tous les clients, pas évident pour une utilisation publique. Et quand l'IPV6 s'étendra...

Les tentatives de blocage du procole -p ipv6 au niveau Iptables de l'IPcop n'ont rien donné.

2) Le modem était configuré en mode routeur (avec les paramètres de connexion préalablement entrés dans le modem), avec une IP d'entrée statique (ex: 192.168.5.1), l'interface rouge également (ex:192.168.5.2) , le DNS et la passerelle indiquant 192.168.5.1. En configurant le modem en mode "bridge" avec l'interface rouge en PPOE, le problème à également disparu.

Souhaitant que ces observations puissent être utiles à d'autres.
Amicalement Frank Kourou

[jdh]

Voilà un retour qui est "bon" !

Cela justifie encore qu'il est préférable d'avoir un modem plutôt qu'un routeur. (Et les routeurs peuvent souvent devenir modem avec la RFC1483 de mémoire).

Je peux imaginer que ipv6 peut être déactivé aussi avec sysctl qui ajuste plus ou moins au vol les possibilités du noyau (p.e. sysctl -w net.ipv6.conf.all.disable_ipv6=1 ou /etc/sysctl.conf) ou avec les modules (p.e. blacklist ipv6).