Problème de connexion des postes clients.

[vinsang]

Bonjour,

Voilà, je possède un IPCOP 1.4.18 avec les interfaces verte, bleue et rouge.
l'interface verte à comme adresse: 192.168.15.201
l'interface bleue à comme adresse: 192.168.55.201
l'interface rouge à comme adresse: 193.54.198.107

L'interface rouge est reliée directement au routeur, et est le seul périphérique à être reliée au routeur.
L'interface verte est reliée à un switch permettant de relié les postes clients
L'interface bleue est reliée à un switch (différent du switch de l'interface verte) permettant de relier les différents point d'accès sans fils.

Les add ons URLFilter et ADVProxy sont installés sur IPCOP et fonctionne comme il se doit.
L'interface verte ne permet pas le DHCP (inactif dans services/serveur DHCP), et les postes clients ont une IP fixe en 192.168.15.X.
Les accès à vert fonctionnent et permettent une navigation filtrée de l'Internet.
L'interface bleue permet le DHCP (actif dans services/serveur DHCP), et les postes client n'ont pas d'IP fixe. Les postes clients sans fils obtiennent bien une adresse de la part d'IPCOP EN 192.168.55.X.
J'ai mis en place une reconnaissance par adresse MAC dans parefeu/accés bleu.
Les accès à bleu fonctionnent et permettent une navigation filtrée de l'Internet.

Cependant j'ai quelques soucis de fonctionnement. De façon aléatoire, les requètes d'accès vers IPCOP ne permettent plus d'obtenir les pages WEB.
Dans ces moments de pannes, tous les pings qui passent en temps normal ne passent plus tous.


En cas de panne d'accès,

passe les ping vers :
192.168.15.201 (à partir d'un poste relié à vert)
193.54.198.107 (à partir d'un poste relié à vert)
194.2.0.20 (à partir d'un poste relié à vert)

ne passe pas les ping vers :
www.google.fr


Je ne vois pas d'ou peut provenir mon problème. Avez vous une idée ?

Cordialement

[Gesp]

Il faudrait regarder s'il n'y a pas un pb avec la résolution de nom à ce moment

Je pense que pour faire afficher les stats de dnsmasq, c'est

killall -USR1 dnsmasq

Il doit y avoir le nombre de requêtes servies avec les stats des réponses reçues des serveurs amont.
Cela manque dans la page de statut, il faudrait juste peut-être un petit helper pour que cela fonctionne dans l'interface web.

[Franck78]

Salut,

De façon aléatoire, les requètes d'accès vers IPCOP

depuis GREEN, ou BLUE ou les deux ? Avant de dire que dnsmasq marche pas (jamais encore vu) il n'y aurait pas un bouclage caché entre GREEN et BLUE....



194.2.0.20 : DNS de orange. Tu as le droit de l'utiliser? C'est ton FAI ??

"Les pages WEB": pas très top comme outil de diagnostic.
Utilise "host nom.de.machine" sur IPCop, sur les clients d'IPCop.
En paralèlle d'un "tcpdump port 53" sur une console d'IPCop.

[vinsang]

Salut,

Depuis GREEN les pages demandées ne s'affichent pas .
Depuis BLUE, je ne sais pas , je n'ai jamais fait le test encore en période de panne...

Oui, mon FAI est Orange Business Service, par conséquent, j'ai droit d'utiliser leur IP comme DNS.

Tu as raison, les pages WEB ne sont pas véritablement un outil de diagnostique, mais dans mon post, il s'agissait surtout d'une constatation de disfonctionnement montrant que les pages WEB ne s'affichaient pas, pas vraiment de dire que je m'en servait pour vérifier le disfonctionnement.

Je vais essayer un tcpdump pour voir .

[Gesp]

Avant de dire que dnsmasq marche pas (jamais encore vu)

Je ne pensais pas nécessairement à cela, plutôt à un problème du coté serveur dns.

Je ne sais plus pour Wanadoo/Orange mais chez Free, il est arrivé que l'adresse attribuée pour le dns change et si l'ancienne adresse fonctionnait encore, ce n'était pas le cas pour les noms ayant changé récement d'IP.

Dans le cas de Free, une adresse de cache local dns est attribué (ce que l'on peut comprendre en résolvant le nom de l'IP fournie).

Donc la première chose à faire en cas de problème dns et si l'on a des IP dns saisies dans la configuration, c'est je pense de repasser en auto et de vérifier si les dns reçus sont identiques à ceux que l'on utilisait en manuel.

Si le problème est intermittant, le nom d'un serveur est résolu à certains moments et pas à d'autre, cela peut dépendre de quel dns a été élu par dnsmasq (le plus rapide à la première interrogation jusqu'à une non-réponse ou une interruption de la connexion).
La stat fournie par dnsmasq peut aussi éclairer ce pb.

Concernant le tcpdump, c'est sûr que cela doit aider, déjà pour s'assurer que la requête est bien reçue coté IPCop, retransmise coté RED et voir si pb est du coté résolution de nom (ce que pourrait indiquer l'absence de réponse au ping) ou un blocage général du trafic qui ne toucherait pas la résolution du nom (le nom pourrait être résolu par dnsmasq si le nom n'est pas en cache depuis un temps supérieur au TTL)