sme/ipcop

[pat64]

Bonjour,

Je suis utilisateur d'ipcop depuis de longues années sans aucun souci.
Mais voilà tout a une fin semble-t-il.
Le premier mardi de ce mois, toutes les machines sous seven (30, en version pro) refusent de sortir sur le net.
Dans le même temps aucun problème sur les machines xpsp3.
J'ai un cop 4 zones qui fonctionne de façon optimale pour xp.
Symptôme : pas de connexion Internet, diagnostic windows : problème dns, puis problème routeur ...
Le ping vers cop ne fonctionne pas sur seven, tout est ok sur xp
Pour rétablir la situation "il suffit" de faire un ping -t sur cop pendant que cop fait un ping sur le client. Une à deux minutes après la connexion est rétablie mais elle se coupe de façon aléatoire.
J'ai essayé la version 1.19, pas mieux.
Si je monte une machine xp avec deux pattes pour remplacer cop sur seven : plus de problème. Si je supprime la passerelle : pas de problème.
Cette situation ne me satisfaisant pas du tout j'ai testé sme : tout bon !

Quelque chose dans la structure des passerelles peut-il expliquer ce phénomène ?

Patrick

[Franck78]

Symptôme : pas de connexion Internet, diagnostic windows : problème dns, puis problème routeur ...

salut,
Le diag se pose avec de vrai outils et une recherche de ce qui fonctionne bien et un minimum de reflexion. Pas avec une boite de dialogue microcoft.

Vérif 1)basique
Les 7 ne voient pas IPCOP? Et il se voient entre eux ? QUELLE IP ont-ils ?

Vérif 2)
sur IPCop avec tcpdump, l'état des reservation dhcp, les mac adress differentes,

Il faut en gros commencer par vérifier la couche liaison. Je pense à un truc comme les turbo frame par exemple.

[jdh]

Les machines ne voient pas l'ipcop ? Que dit la table ARP ?

On peut aussi s'intéresser aux switchs utilisés : ils ont une table d'adresses MAC qui peut être remplie !
(Souvent 8192 machines mais sait-on jamais ?)

Le DNS peut être en cause aussi : je suppose que c'est ipcop qui est serveur DHCP et relais DNS.

Enfin, l'ipcop répond-il correctement : mémoire ? addons ? réglage de taille de cache Squid ?

[pat64]

les postes clients sont en 192.168.64.0, le serveur dhcp est un ubuntu lts qui fonctionne correctement. Quand on interroge les clients 7 ils ont bien toutes les informations transférées du serveur (ip, masque, passerelle,dns (principal : cop)). Si on passe en ip fixe en renseignant le client on n'obtient rien de plus. Il y a clairement un problème de résolution dns, mais pas seulement. Si je pingue le serveur cop (192.168.64.254) je ne trouve qu'en faisant un ping -t et au bout d'une vingtaine de ping. Et encore faut-il que cop fasse la même chose dans l'autre sens. Sinon rien.
Toute demande de résolution dns externe échoue. Tout ping vers l'extérieur échoue. Par contre je peux pinguer tous les autres clients, serveurs ou imprimantes du réseau. D'un client xp, 7 ou d'un autre serveur (linux ou freebsd). D'un 7 je ne peux pas sortir du réseau, c'est tout.
Si le client xp ou un autre serveur tente une demande dns : tout fonctionne, aussi bien en interne que vers l'extérieur. Le problème se pose sur tous les clients 7, qu'ils fassent partie du réseau ou qu'on les rajoute (ma machine perso). Cop agit en relais des dns de mon fai, avec en secours les serveurs dns de google.
Dès que cop est écarté les clients 7 sortent sur le net.
Mais rien ne m'empêche de monter le nombre de clients xp : j'en ai rajouté 30 sur une après-midi pour voir et cop les a géré sans souci !
Les switchs ne sont pas manageables, mais dans tous les cas le serveur cop 1.9.19 tout frais donne exactement le même résultat alors que sme est opérationnel ...
J'en déduis, peut-être à tort :
cop fonctionne : pas de problème avec les 30 nouveaux, dns ok ...
les switchs semblent hors de cause (limitation technique) et fonctionnement avec les clients xp, j'ai été jusqu'à changer les switchs (2 neufs mais sans effet)
l'ensemble du câblage est revu et testé ok.
wireshark ne m'a pas permis de détecter quoi que ce soit, pas de machine inattendue, les correspondances mac/ip ont l'air de coller sur ce que j'ai vérifié.

Le réseau :
vert 64.0 un switch par salle (2 en l'espèce sont concernés) reliés à un switch central
111.0 patte rouge un switch
bleu sur un câble croisé
orange sur un switch à part
orange me sert de bac à sable, 111.0 sert de dmz avec un routeur cisco en front.
cop est seulement passerelle (proxy web, relais dns, serveur de temps).

Patrick

[Franck78]

L'IPCop semble sourd aux trames des 7.
Alors tcpdump sur IPCop, pour commencer.
C'est pas la peine de dire que dns, ping extérieur, internet ne fonctionne pas. C'est normal si rien qu'entre '7' et 'green' rien ne passe.
Change la carte réseau 'GREEN' ! Détermine qui fait que le dialogue ne se fait pas.

[jdh]

Pour compléter, quel est le filtrage pour dns ?
L'ubuntu est serveur dhcp, mais est-il dns ?
Il est notable que, désormais, dns c'est 53/udp et 53/tcp pour le filtrage.

Perso, je préfererai toujours un serveur dhcp/dns car on peut mettre à jour dynamiquement plus facilement dhcp et dns.

Je rejoins Franck78 : si le ping avec ipcop pose des difficultés, pas la peine d'aller plus loin ...

[pat64]

L'ubuntu est serveur de fichier et dhcp, pas dns.
Pour ce qui est du ping, j'ai déjà vu une machine refusant de répondre au ping mais laissant passer les demandes Internet. Je sais qu'il est plus logique de demander à un serveur de refuser de répondre aux ping sur sa patte rouge mais rien n'empêche de faire de même sur la verte. Je ne l'ai pas fait, mais puisqu'il y a un changement je dois douter de tout et pourquoi pas, envisager un changement dans la politique de sécurité.
tcpdump me montre des trames ipv6 qui ne devraient pas être là, je commence à faire le ménage sur mes clients histoire d'y voir plus clair et reviens vous voir ...
je creuse dans le même temps pour voir quels sont les changements sur 7 intervenus lors de cette fameuse semaine, il y a forcément un élément déclencheur puisque tout fonctionnait avant.
Au fait le changement de carte n'a rien donné.

Patrick

[jdh]

Pour Seven, actuellement, je décoche ipv6 de façon systématique.
J'ignore la façon dont Seven détermine qu'il a accès à Internet surtout si ipv6 est actif en même temps qu'ipv4. D'où la décoche.