Nous avons un routeur qui fait du PAT pour l'un de notre serveur.
Cependant, meme après l'arret du serveur ou du service qu'il héberge, de nombreuses connection restent en attente ESTABLISHED..
 
Connaissez vous une commande pour fermer les connections en cours ???

Up

net stop "connexions ouvertes"
 
(up )

Désolé, je n'ai pas de réponse, mais pour fixer les choses, ces connexions "ESTABLISHED", elles sont sur le routeur, n'est-ce pas (puisqu'elles existent quand le serveur est éteint) ?
 Dans ce cas, il faudrait préciser quel est le routeur...

et un time out sur le routeur?

Ouais elles sont sur le routeur, et le timeout n'est pas paramétrable.
 
En fait on en a deux
 
1.Routeur : NAT,Proxy mandataire sous Linux
2.Routeur : RRAS sous Windows 2000.
 
Ce timout est fixé à 500000s pour le routeur Linux et celui sous Windows ne me file pas la réponse...

500000s -> 138h avant réinitialisation...
 
C'est clair qu'on peut passer par un shutdown du routeur, mais bon....
 
Le but est de switcher entre deux processus serveurs différents sur nos deux serveurs qui sont chacun derrière un routeur connecté à internet.
 
Si on doit rebooter les routeurs à chaque fois (vu qu'ils gèrent les connections VPN aussi c'est pas le top.

Sous Windows 200, je ne sais pas du tout
Sous Linux, ça peut se configurer par l'intermédiaire du pseudo système de fichiers /proc : cf. dans "/proc/sys/net/ipv4/netfilter/"
Référence : IPSysctt tutorial, section 3.7
http://ipsysctl-tutorial.frozentux [...] RREFERENCE
 
 La variable à modifier doit être celle-ci : ip_ct_tcp_timeout_established (fixée par défaut à 432000s)
 
 Par contre, je ne comprends pas bien la raison qui motive ce changement : il y a 1 serveur (Web ?) derrière chacun des routeurs ? Le but est de faire de la répartition de charge ?
 
-- Edit: Ah, je viens de voir que même sur un noyau 2.4.21, les variables dans "/proc/sys/net/ipv4/netfilter/" n'existent pas, il faut appliquer le patch "tcp-window-tracking" de IPTables sur les sources du noyau (expliqué dans le lien que j'ai donné)

Ce sont des serveurs d'application en design qui recoivent des requetes pour des pièces en CAO. Perso j'en connais pas plus que toi !!!
 
En tout cas, comme je l'ai configuré, il reçoit les requetes pour des pièces. En fait les deux emplacements de travail sont séparés, mais partage un ensemble de pièce réparti entre Nimes et Paris.
 
Ainsi, un user de paris voit les pièces de son serveur de Paris + celles de Nimes.
 
Cependant, le truc a été mal mis en place. Les clients sont pour l'instant programmés pour accéder aux programmes serveurs par une ip privé (pour leur serveur local) + IP Public (avec un PAT pour accéder au serveur distant).
 
Alors que perso, j'aurais mit un VPN et 2 ip privée.
 
Bon passons, je ne pourrais pas de sitôt changer la config de Nîmes + celle de Paris (surtout qu'à Paris ce sont des têtes brulées.
 
Donc chaque client qui lance une requete en local aucun prob, mais quand leur requete arrive sur le site distant, il ouvre une connection qu'il ne ferme pas !!!!    
 
Au finish, à 12h00 j'ai plus de 1500 connections ouvertes...

 
je regarde ca... Thanks...

Ok, je vois. Bah, c'est une solution...
 

Ouaip... Une autre solution, dans le cas où il n'y a besoin de rediriger que quelques ports connus, c'est d'utiliser un truc comme STunnel (des binaires existent pour Windows) : on peut crypter les communications et on n'a plus besoin de faire du PAT sur les routeurs Linux/Windows (ce sont eux qui exécutent STunnel et qui redirigent les requêtes vers les serveurs internes)
 
 

 
 Je crois que ça n'est pas vraiment que la connexion est ouverte (voir sur les serveurs : certaines de ces connexions n'existent plus, non ?), c'est surtout que le routeur retient les connexions qui ont été établies à un moment donné et les garde en mémoire un certain temps, c'est tout.
 

 
 Bah... Je ne sais plus quel est le maximum d'entrées pour le module conntrack avec les noyaux 2.4 ; ça n'est pas 16 ou 32000 ? je trouve plus l'info... Et même de toutes façons, il me semble que si la table est pleine, le noyau va se débrouiller pour supprimer les entrées les plus anciennes. Puisque c'est un routeur, c'est son rôle de faire ce genre de suivi, donc pas de problème a priori.
 
 Par contre s'il y a des problèmes de performance, il faut voir que chaque entrée consomme un certaine quantité de RAM (entre 512 octets et 8 ko, à vérifier là aussi), donc il est souhaitable d'avoir 256 Mo de RAM si cette table grandit.
 
 Un autre problème peut survenir si la table est remplie _et_ que _toutes_ les connexions sont effectivement utilisées : les utilisateurs dont la connexion aura été supprimée sur le routeur vont perdre l'accès au site distant... (ça, ça se voit facilement, les utilisateurs vont venir se plaindre que "ça marche pas" et que l'équipe réseau n'en rame pas une...)

Note : il peut être intéressant de suivre l'évolution du nombre d'entrées dans "/proc/net/ip_conntrack", par exemple avec ce script
 

 
Ouvrir le fichier "suivi_conntrack.csv" avec OOo Calc (ou Excel) permet de faire des jolis graphiques... (et justification du travail   )
.

Merci, je m'y mets et je te donne des nouvelles.
 
Pour répondre à ta question, en effet, les connections restent ouvertent au niveau du routeur (meme après un reboot du serveur).
 
Et effectivement ce sont des problèmes de performances qui en découle.
 
Exemple une série de ping sur joystick est très variable.
 
ex :
ping joy -> 32ms , 4 fois
 
ping joy -> 1000ms, 4 fois
 
ping joy -> 4000ms, 4 fois
 
ping joy -> 32ms, 4 fois
 
Le ping varie énormément, et je pense que c'est dû à la capacité du routeur à établir les connections, vu sa table saturée.
 
Les utilisateurs s'en foutent un peu, pour l'instant, entre 4s et 32ms ils ne voient pas grand chose... une fois la connection établie, ils ont leur fichier.

 Oui, c'est ce que je pensais, mais c'était pour être sûr qu'on parle bien de la même chose.
 

 
 C'est à vérifier : est-ce que la charge processeur de ce routeur grimpe ("uptime", par exemple)  ? un "top" montre des processus qui bouffent des ressources ?
 Comme a priori l'application échange des données (souvent ?) entre les 2 sites, si le trafic est important, il arrive qu'un "ping" augmente, mais c'est juste qu'il faut bien faire passer toutes les données.
 Pour être plus précis, il faudrait dans un premier temps simplement voir le trafic qui passe par le routeur et le ping en fonction du temps... Il est probable que l'on voit que les pings augmentent quand le trafic est élevé. Et il faudrait relever en même temps le nombre d'entrées dans la table du routeur (par exemple avec le script plus haut) et la charge CPU. En prenant un échantillon de ces données toutes les 5/10 min, ça devrait permettre d'isoler le problème s'il y en a un.
 
 

 Bah, alors ça roule... Mais bon, il est sûr qu'il faut avoir une bonne idée du problème dès à présent : si ça se met à râler, il faut pouvoir aller voir le boss avec un document qui décrit le problème et les moyens techniques pour y remédier (utilisation de techniques permettant d'améliorer la qualité de service, augmentation de la bande passante, upgrade des machines routeurs -RAM, CPU ?-, achat de routeurs "qui sont bien parce qu'ils coûtent cher", ou autre...). Avec les coûts et le temps de mise en place, parce le chef regarde ça aussi... Bref... ch'uis un peu hors sujet, là...