Salut,
 
J'ai un firewall sous IpCop, et ce matin, il est planté. Il voit le routeur qu'il a en face, mais rien ne répond quand j'appelle un nom de domaine.
 
J'ai fait un ifconfig, je vois toutes les interfaces (3 cartes réseaux) mais rien au niveau config de DNS.
 
Je suis allé voir /etc/resolv.conf mais il est vide. C'est peut-être différent sur cette distrib.
 
 
Donc, y'a t'il une autre commande pour vérifier la config DNS ??
 

(ça urge, c'est pour le boulot, et je n'arrive tjs à rien de mon côté )

 
je vais essyer te t'aider je connais un peu ipcop :
 
ta version ? (1.3 , 1.40bx)  
que donne tes log ? (pas de table conntrack full ?)
tu utilises quel module de la ipcop ?
resultat d'un tracert ?
resultat d'un nslookup ? (ou dig)
 
que te donnes un  :
 
cat /proc/net/ip_conntrack | grep -c 'tcp'
?
 
et un  
 
 cat /proc/sys/net/ipv4/ip_conntrack_max
 
?

Oui, 1.3.0
 
tracert/trace : commande inconnue
dig/nslookup : même chose
 
cat /proc/net/ip_conntrack | grep -c 'tcp' = 15
cat /proc/sys/net/ipv4/ip_conntrack_max  = 3072
 
 
Comment ça quel module de l'IpCop ?
 
 
Je v voir les logs.
 
 
Mais, comment vérifier la config réseau (adresse serveur DNS) de la machine ?

si /etc/resolv.conf est vide il ne pourra faire pas résoudre de noms .
mets un nom de domaine a l'intérieur du style
nameserver ipquivabien

ok donc deja ta table de conntrack n'est pas saturé !! (tips : ds rc.loacl met ca :
echo 32760 > /proc/sys/net/ipv4/ip_conntrack_max     ; ca te permettra de ne pas te soucier d'un soucis de connexion qui te plante ton ipcop)
 
les test nslookup/tracert c depuis un poste avant l'ipcop qu'il faut le faire !!
 
ensuite va voir les log d'ipcop en cas de pb ?
 
tu as une option DNS d'un ipcop y'a quoi chez toi ?

l'ip cop forward de base les paquets en 53, son resolv n'a pas a etre FORCEMENT renseigné .

Alors, en fait, le prb de connexion viendrait d'Oleane, la provider..
Donc pas la peine de s'inquieter + que ça, ça n'est plus urgent (ce topic), mais la réponse à ma question m'interresse tjs (mais personne ne l'a lu on dirait ).
 
 
 

 
Je vais essayer un peu plus tard
 

c'est ce que j'ai fait (mais sous SSH, ça pose prb ?)
 

Rien dans les logs.
 

Je ne t'ai pas compris là

j'ai lu
et si j'ai bien compris depuis ton ipcop tu n'arrives a rien résoudre c'est cela non ?
si oui c'est un probleme de non configuration de resolv.conf a mon humble avis ...

 
Voici ma question

bah vi .
*sur la machine* (donc *localement*)  elle utilise resolv.conf pour savoir a quel dns elle doit s'addresser .
Après si on fait des requetes sur celle ci d'une machine distante a ce niveau peut intervenir des forwards de port comme l'a dis petrole666 bien que je n'ai pas saisi tout l'interet de la chose dans ce cas
 
 

Donc, si j'ai bien pigé, resolv.conf est la liste des serveurs DNS à utiliser. Dans mon cas, elle est vide. Mais je ne pense pas que la config est sauté du jour au landemain, surtout que le prb ne vient (finallement) pas de là.
 
La config (liste) doit être différente sur IpCop. Donc, je ne veux pas voir/éditer cette liste, mais savoir si il y'a une commande (un programme) à lancer pour avoir un récap de ces infos, comme un IPCONFIG /ALL sous Dos/Win.

c'est simple, localement sur un linux il *faut* que ce fichier soit renseigné pour que la machine puis résoudre des noms de domaine .
dans le cas ou tu as cette machine en serveur  on peut cependant imaginer qu'il y a en place un forward des requetes dns vers une ip précisé ( le(s) dns) quelque part dans la configuration de cette distribution .
ainsi le réseau derriere verra ses paquets redirigés vers le dns qui va bien .
on peut aussi imaginer que tu as un serveur dns qui tourne sur ta distribution et qui fait aussi un bete forwad (des requetes cette fois ) vers  les dns qui vont bien .(eux aussi indiqués quelque part dans la configuration de ta distribution ) .
Bref a part lire la doc de ip cop je ne peux pas te répondre plus sur ce point .
le dig ou le nslookup sur la machine serveur te donnera le ns utilisé par celle-ci .
Apres il y a le cas aussi ou la distribution sera en dhcp dans ce cas le dns sera fourni par ce biais donc tu pourras le vérifier sur les clients ( ipconfig/all sous win , le fichier /etc/resolv.conf sous linux )
je ne connais pas de commande sous linux equivalente au ipconfig/all de windows ( la configuration ip d'une machine n'ayant logiquement aucun lien direct avec sa configuration dns , on retrouve la notion une appli/une tache unix je dirais )

 
Effectivement, elle fait relai DNS pour un proxy, un serveur mail, puis un serveur DNS interne.

c l'option (module ) dont je te parlais.
Ps: je ne l'utilise pas, je forward les requets DNS chez free.

bah, elle est configurée de base comme ça, je n'ai rien activé (de mémoire). Il n'y a pas d'option dans l'interface d'admin.
 
 
Prb résolu, ça venait bien du provider.

 
nb : le tuyau de la saturation de la table des connexion sert surtout qd tu fais du p to p, car la limite des 3172 saute rapidement (en tout cas j'avais c sous xMule sur ma linux mdk 9.2)
 
De base les distrib propose un suivi de connec à 32760 (c une bonne valeur je pense )

Pour un proxy/serveur mail presque rien d'autre qui passe par lui, je pense que je n'aurai pas de prb. Mais je regarderai comment on fait la manip.  
Encore merci

ah bah en fait c'est juste une commande
J'ai fait la manip. Faut faire quelque chose de spécial pour que le nouveau paramètre soit pris en compte ?

 
oui.
 
car la ipcop (tout comme un mandrake avec kernel secure + msec) fait des verifications reguliere de ses propres fichiers et si tu places la limite direct avec un echo 32760 > /proc/ ....
 
Elle te le vire illico à la prochaine verif (via l'execution du cron)
 
Donc tu dois bien mettre la ligne :
echo 32760 > /proc/sys/net/ipv4.......
 
Dans le fichier rc.local.
 
ps : il se trouve sous /etc/.....
Bonne utilisation à toi c un chti firewall sympa.
 
la v 1.4 va bientot sortir au menu , petite priorisation de traffic, ids etc ...

Donc, si je pige bien, on fait en sorte que la ligne soit rajoutée régulièrement, pour contrer l'écrasement auto du système de check ?
 

 
 
 
Y'a une date de prévu pour la V1.4 ? (QoS )

j'essaye d'éditer le fichier, avec "joe", mais je ne trouve pas comment saucegarder et quitter

 
non tu figes cette ligne ds un fichier de configuration, elle ne sera jamais enlever .
 

je pige rien
 
rc.local c'est pas pour cron ?

j'ai trouvé comment sauvegarder avec joe ..
http://www.stben.net/joeedit.html
 

tappes :
 
vi /etc/rc.d/rc.local
 
puis : touche INSERT
 
tu saisi :
 
echo 32760 > /proc/sys/net/ipv4/ip_conntrack_max
 
tu tappes :
 
ESC
 
puis :
 
:wq
 
puis :
 
ENTREE
 
tu reboot (saisis reboot) et tu devrais avoir ta valoir inchanger.

J'ai correctement édité avec Joe
 
J'ai rebooté, puis vérifié, et la commande est toujours présente.
 
merci

bon surf a vous, avec linux en gateway , tu auras tu temps libre devant toi.

Ca tourne déjà sans prb depuis 1 an
 
SME 5.6 + squidguard + sarg pour le proxy, et IpCop depuis 1.5 an.

euh, rc.local c'est un script qui est éxécuté en dernier au démarrage ; il n'est pas éxécuté régulièrement donc je comprends pas bien l'intérêt de mettre ton echo dedans si c'est un cron qui change la valeur ;  
de toute façon, les valeur de /proc, ça se configure avec sysctl.conf si on veut faire les chose bien

tu phylosophes ?
moi je pratique.
 
installes une ipcop, met l'ip_conn..._max ds sysctl.conf (chose que je faite depuis le debut) et attends 1 jour ... ta valeur gicle. c comme ca.
 
Donc j'ai tu la mettre ds le rc.local.
 

et je te répète que rc.local est un fichier de démarrage et à moins que ipcop soit foutu bizarrement, il n'y a aucune raison pour qu'il soit éxécuté régulièrement

mjules> cela ne sert a rien d'argumenter avec lui , monsieur fait de la prod' lui

c bien, tu l'as dit.
 
si je met l'option ip_conntrack_max ds le sysctl.conf eh bien elle saute , je ne sais pas pourquoi.
 
en la mettant ds le rc.loacl (via un echo) avec 25 j de uptime je suis tjs à 32760.
 
Que dire de plus ?

tu es lourd la.

le sysctl s'execute avant le rc.local
donc entre le sysctl et le rc.local, il doit y avoir un script qui positionne le ip_conntrack_max a une valeur arbitraire