BOT et server de clustering pas copain... :(

[Sorcier FXK]

Bonjour, depuis 1 mois maintenant je me suis lancer dans l'aventure IPCop. J'ai eu l'occasion de tester plusieurs fonctionnalité par le biais de plugins et pour finir par une réinstall complete de mon server IPCop. J'ai réinstallé seulement les plugins qui m'etaient utiles.

Donc tout se passe a merveille, jusqu'au denier plugin, Blockouttraffic, qui une fois installé bloque le server qui centralise les clients du cluster.

Avec la commande "tail -f /var/log/messages" j'ai pu voir d'un peu plus prêt ce qui se passe. Les clients envois un flag "SYN", le server de calcul ne repond pas...

Petit extrait du log messages:

Nov 30 14:57:00 FireFoX kernel: INPUT IN=eth2 OUT= MAC=00:50:fc:47:46:c2:00:1d:68:42:5e:4a:08:00 SRC=217.162.99.25 DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=15438 DF PROTO=TCP SPT=15095 DPT=12121 WINDOW=8192 RES=0x00 SYN URGP=0

Au passage, FireFoX est le server IPCop.

Donc j'ai créé une regle de transfert de port:

TCP DEFAULT IP :
1024 - 65535 => 192.168.2.252 : 12121

Donc 192.168.2.252 est le server de calcul, 12121 son port d'ecoute, et les clients non pas de ports conventionnels, le port etant choisi au hazard entre 1024 et 65535.

Suite a cette regle, ca fonctionne, mais ca fonctionne 5 min ensuite j'ai la grande joie de lire "Client not responded" sur le server de calcul. Pas vraiment top . En testant je me suis rendu compte que le simple fait de désactiver la regle et la réactiver avait pour consequence de faire fonctionner mais seulement pour 5 min apres c'est toujours pareils : "Client not responded" .

J'avoue je seche. Si quelqu'un a une idée, un conseil ou besoin de plus de renseignement pour comprendre... BOT etant un plugin indispensable a mon gout, j'ai vraiment pas envie de l'enlever et ce projet de clustering etant a la base un projet personnel, j'ai pas non plus envie de l'arreter.

En espérant avoir été clair dans mes propos.
Merci d'avance et bonne fin de week end

[jdh]

Point 0 : merci de faire quelques efforts sur l'orthographe !

Point 1 : BOT n'est pas une option : c'est totalement indispensable ! Je peux imaginer que dans une version future d'IPCOP, cela sera embarqué par défaut.

Point 2 : Le filtrage d'IPCOP repose sur Netfilter/Iptables qui a apporté le suivi de connexion.

Je peux supposer qu'avec un cluster, le traffic va vers une machine cible MAIS peut revenir via une autre ce qui forcément va poser problème au suivi de connexion ...

[ccnet]

Serveur de calcul : c'est à dire ?
Vous parler de cluster, il semble que ce soit potentiellement le point sensible pour le filtrage. Vous ne donnez aucune information sur la nature et le fonctionnement du cluster en question. Vous imaginez bien que la façon dont l'adressage du cluster fonctionne est critique pour le suivi des connexions par le firewall.

le server qui centralise les clients du cluster.

Sans autre précision c'est assez obscure.

Nov 30 14:57:00 FireFoX kernel: INPUT IN=eth2 OUT= MAC=00:50:fc:47:46:c2:00:1d:68:42:5e:4a:08:00 SRC=217.162.99.25 DST=192.168.1.2 LEN=48 TOS=0x00 PREC=0x00 TTL=116 ID=15438 DF PROTO=TCP SPT=15095 DPT=12121 WINDOW=8192 RES=0x00 SYN URGP=0

L'adresse ip source qui apparait me laisse dubitatif dans un premier temps ... Celle ci est l'adresse publique d'un client dhcp semble t il, fournie par hispeed.ch. Le tout serait géré par Clablecom, FAI suisse
?

"Client not responded" sur le server de calcul.

Cela laisse penser que le serveur tente d'ouvrir une connexion sur le client ... pas clair non plus.

En l'état des informations trop fragmentaires, je ne comprend pas le problème. Je n'en comprend que les conséquences.

Bien évidement il faut considérer BOT comme impératif.

[Sorcier FXK]

Point 0 : merci de faire quelques efforts sur l'orthographe !

Pour 2-3 accents/accords, je trouve ca pas vraiment dramatique, mais je comprend et partage le point de vue.

Point 1 : BOT n'est pas une option : c'est totalement indispensable ! Je peux imaginer que dans une version future d'IPCOP, cela sera embarqué par défaut.

Je le conçois , j'ai meme été tres surpris de ne pas voir cette "option d'origine"

Point 2 : Le filtrage d'IPCOP repose sur Netfilter/Iptables qui a apporté le suivi de connexion.

Depuis 2 semaines que je frequente quotidiennement votre forum, j'avais bien saisi. Juste un peu de mal a comprendre les docs que j'ai trouvé a ce sujet.

Je peux supposer qu'avec un cluster, le traffic va vers une machine cible MAIS peut revenir via une autre ce qui forcément va poser problème au suivi de connexion ...

Et non, d'une le trafic est extrêmement minime, part du client vers le server pour revenir vers le meme client, le cluster est européen de par ces participants. (d'ou l'ip suisse d'un participant qui m'aide a remettre ca sur pied).

Ce sont les clients qui ouvrent une connexion sur le server. Mais il n'arrive pas a leur répondre, j'ai pas le petit flag ACK de sa part dans le log messages. De plus BOT est installé mais pas activé, ce qui me surprend un peut, enfin il doit modifier quelques paramètres pendant son installation. Avant son installation aucun probleme, les clients communiquait avec le server

Le client fait ses cacluls et renvois par la suite au server un paquet contenant une chaine de caracteres, ex : ARDTF4KS3DSL43DS3, de longueur fixe, a ca le server lui renvois juste une autre chaine de caractere de meme longueur, qui sera le nouveau point de depart du client. La connection dure une microseconde pour parler vulgairement.

[ccnet]

Rien de plus qui permette de comprendre exactement le problème. Une fois on nous parle de serveur une autre fois de cluster ??

[Sorcier FXK]

Imaginez un montage en etoile, dont le server serai le point central. Le but est de cummuler les puissances de calcul afin d'arriver a la finaliter. Le calcul est divisé en plusieurs parties, et chaques clients obtient une partie de ce calcul. C'est vrai que pour moi c'est assez simple de comprendre, ca fait un petit moment que je bosse dessus


Donc, quand BOT n'est pas installé, tout fonctionne a merveille. Apres l'install de BOT client et server ne communiquent plus entre eux, BOT doit bloquer soit la comm des clients vers le server, soit du server vers les clients. Je n'ai pas réussi a déterminer le sens ou ca bloque. A part le fait que le server ne renvois pas le flag ACK aux clients qui eux envois bien le flag SYN au server. Les clients ne communiquent pas entre eux, mais uniquement avec le server. (montage en etoile, enfin pour la vision tres généraliste bien sur). Chaque client est indépendant des autres.

Je sais pas trop comment l'expliquer autrement.

Je peut bien evidement poster des logs, si ca peut aider.

[Poupou94]

Bonsoir,

tcpdump doit pouvoir aider à comprendre on trace une fois avec BOT et l'autre sans puis on compare.


Pascal.

[Sorcier FXK]

Bon la je suis en train d'essayer les derniers conseils qu'on m'a donnée.

Sauf que...

J'ai désinstallé BOT pour pouvoir faire une 2eme mesure, et la grosse surprise, les modifications qu'il a du apporter n'ont pas été supprimées avec sa désinstallation, du coup je me retrouve dans le meme probleme, BOT en moins... Ce qui rend le sniff avec tcpdump obselette pour faire une comparaison.

C'est usant .

[jdh]

BOT ou non, quand tu ne connais pas ce qui se passe pour un protocole c'est tcpdump !


Il est clair que l'on ne comprend pas bien ce que c'est que ce cluster ... S'il y avait quelque éléments de description on pourrait comprendre et proposer ...


Néanmoins, il ne me parait pas judicieux d'enlever BOT puisque c'est un impératif, ce que je croyais que tu avais compris.

Ce qui n'empêche pas de le désactiver au moment de l'analyse par tcpdump ... (désactiver et non désinstaller !)



Je peux imaginer que le protocole pourrait être décrit comme :
- sens sortant : le client doit se connecter à un serveur donné, en tcp et sur un port donné,
- sens entrant : le serveur doit se connecter au client en tcp et sur un port donné (ce qui correspond à un "port forward").

NB: ne JAMAIS oublier qu'un n° de port ne signifie rien si on ne précise pas tcp ou udp !

[Sorcier FXK]

BOT n'etait pas activé que j'avais deja le probleme, le probleme est survenu apres son installation.

A la place de cluster, si j'utilisais le therme de "calcul partagé" ca passe mieux ? Sincerement je sais pas comment decrire ca mieux... Le server ne fait que répartir les bouts de l'equation qu'il a decoupé pour les passer aux clients. Les clients calculent leur part, renvois les infos au server qui lui leur redonne un nouveau bout de l'equation. Et ainsi de suite jusqua la fin du calcul total. Par exemple le projet Free Rainbow utilise un cluster mondial. Dans le cas du projet Free Rainbow et le notre, c'est pareil sauf que eux font de la génération de rainbow table et nous du calcul sur GPU. Ca se compose d'une application client à installer sur les pc "clients" (qui peuvent etre aux 4 coins du monde comme sur un meme lan) et d'une application server qui est sur le server. Voila, ensuite les clients se connectent sur le server a intervalles réguliers (1 à 2 min) pour envoyer leur résultats et recuperer la suite du calcul.

Et oui j'ai compris que BOT est plus qu'indispensable mais, pour les besoins du "dépannage" je l'ai enlevé, ce qui m'empechera pas de le remettre par la suite. Je ne vois aucun intérêt a ne pas filtrer ce qui sort. Donc forcement il sera de retour bientot.

Ce qui me surprend le plus, c'est le simple fait de désactiver la regle de redirection de port vers mon server, et les clients arrivent a se connecter de nouveau, mais ca ne dure que 5 minutes a peine...

Arf je n'avais pas vu la fin de votre post,

Donc le sens est sortant, ce sont les clients qui se connectent sur un port precis, le 12121 et ca se passe en TCP.

[Franck78]

Salut

J'ai pas tout lu mais ceci me chagrinne beaucoup car ce ne veut rien dire:

TCP DEFAULT IP :
1024 - 65535 => 192.168.2.252 : 12121

Donc 192.168.2.252 est le server de calcul, 12121 son port d'ecoute, et les clients non pas de ports conventionnels, le port etant choisi au hazard entre 1024 et 65535.

Le client ne peut pas contacter le serveur sur autre chose que UN port défini ET stable, en l'occurence ici 12121.
Donc cette règle ne rime à rien! Ca doit même perturber le serveur qui se prend un tas de paquet qui ne le concerne pas.

Par exemple le projet Free Rainbow utilise un cluster mondial. Dans le cas du projet Free Rainbow et le notre, c'est pareil sauf que eux font de la génération de rainbow table et nous du calcul sur GPU

ca me rappelle le cassage de la clé WPA ça

[jdh]

Le sujet du "cluster" n'a aucun intérêt dans le cas présent : ce qui compte c'est la définition de protocole entre client et serveur.

(Le terme "calcul réparti" semble mieux adapté mais je vois bien ce qu'est du calcul sur des nombres premiers mais là je subodore une ânerie sur WPA en effet ...)

[Sorcier FXK]

Heuresement qu'il n'y a pas que le WPA qui existe... Merci les medias pour leur flots habituels.

Donc j'ai modifier la regle par celle ci :

TCP DEFAULT IP : 12121 => 192.168.2.252 : 12121

Comme a chaque fois que je modifie cette regle, les clients arrivent a se connecter mais pas plus de 5 min. Donc je pense que je doit mal créer la regle. Pourtant le server utilise 2 ports, le 12121, qui permet aux clients de le joindre, le port 12122 est aussi utilisé a la condition de vouloir piloter le server depuis l'exterieur. Ce qui n'est pas du tout le cas.

[Sorcier FXK]

...mais là je subodore une ânerie sur WPA en effet ...)

Là j'ai pas tout compris... ?? C'est un peu insultant non ? Genre le gars qui fait des pieds et des mains pour rassembler plusieurs staff, de faire vivre une experience et qui finalement se fait juger par des inconnu a qui il n'a jamais demander d'aide ou d'opinion sur la question du WPA, comme je l'ai dit plus haut, heureusement qu'il n'y a pas que le WPA qui existe. En attendant ma question c'est pas comment "claquer un hash ou une clé pgp plus vite", mais comment regler mon server ipcop.

Ne nous laissons pas distraire par les details car nos travaux ne nuisent a personne. Et recentrons nous sur IPCop.

[Franck78]

rainbow table, gpu, calcul réparti, c'est vraiment le topic wpa d'il y a qquinze jours!

Bon, cette régle est déjà mieux que la précédente.
A toi de fournir un tcpdump exploitable.
5 minutes, c'est obtenu comment?

D'ailleurs ca veut dire quoi? Pendant 5 minutesles connexions sont OK pour tous puis plus rien ou si un client n'a pas de conversation pendant 5 minutes avec le serveur, sa connexion devient 'foireuse' (tandis que les autres fonctionnent.

Tu n'es vraiment pas précis sur les termes employés.