Shorewall très instable sous MNF !?

[lembal]

Bonjour,

pleinement satisafait de ma MNF, celle-ci me fait depuis quelques temps des choses bizarre et j'accuse en particulier SHOREWALL !

En effet lorsque je crée une règle exception et que je clique sur Appliquer ... hé bien ça ne s'applique pas !! Obligé de me connecter en SHH et de faire un /etc/init.d/shorewall restart...

Donc j'ai essayé de bidouiller les fichiers de l'interface Web dans /var/www-naat/html/fr/secure/modules/ ... mais le PHP c'est pas mon truc !!

Alors est-ce qu'une mise à jour aurait pû me flinguer mon interface Web ?

Dans tous les cas je vais essayer la solution suivante :

Une tâche cron qui lancera un /etc/init.d/shorewall restart à CHAQUE minute !

C'est bête ou pas ?

[Jacques-]

Le restart toutes les minutes, c'est bête oui..
Il faut bien 30s au mien pour s'arrêter, digérer les règles et les mettre en place, alors 30s de Web par minute, faudra demander une remise de 50% à ton FAI...

Essaye plutôt de regarder si tu n'as pas une règle erronée dans ta config, et fais une sauvegarde de ta configuration MNF. Cela te permettra de voir quelles sont les règles qu'elle a réellement mémorisé, et tu pourras comparer avec les tiennes.
Utiliser la gestion manuelle n'est pas compatible avec l'interface pour ce que j'en ai vu, et dans ce cas que le comportement ne soit plus celui attendu ne serait pas surprenant.

Jacques

[Methos_Hi]

En effet, lorsque dans la console, tu fais un restart de shorewall, regarge bien s'il t'indique pas des erreurs.
J'ai eu ce problème également. Je voualiais appliquer une nouvelle règle mais après le "Apply", je perdait l'interface.
En regardant dans la console comment se passait le restart de shorewall (ce que fait le Apply), et bien je me suis rendu compte que ma règle était toute pourrie et qu'elle plantait shorewall.

Dommage qu'il n'y ait pas un comtrôle des règles dans l'interface car shorewall lui indiquaut clairement quel était le problème de la règle.

[lembal]

Le restart toutes les minutes, c'est bête oui..
Il faut bien 30s au mien pour s'arrêter, digérer les règles et les mettre en place, alors 30s de Web par minute, faudra demander une remise de 50% à ton FAI...

Et si le mien ne met "que" 6 secondes à se relancer ? Je viens de compter... C'est bête aussi ?! ET bon aussi surprenant que cela puisse paraître, même pendant un download... si shorewall se relance, la connexion ne se perd pas ?! Tant mieux...

Essaye plutôt de regarder si tu n'as pas une règle erronée dans ta config, et fais une sauvegarde de ta configuration MNF. Cela te permettra de voir quelles sont les règles qu'elle a réellement mémorisé, et tu pourras comparer avec les tiennes.
Utiliser la gestion manuelle n'est pas compatible avec l'interface pour ce que j'en ai vu, et dans ce cas que le comportement ne soit plus celui attendu ne serait pas surprenant.
Jacques

Au niveau des règles... j'en ai un paquet ! Et généralement quand y a une erreur c'est le plantage intégral et l'allumage de l'écran de la MNF (qui ne s'allume pas souvent !) et le branchement du clavier...

Pour les modifications manuelles... je n'ai fait qu'une modification de mon squid.conf... Ca pourrait être ça ?!

Bon je pense que je vais faire lancer à ma tâche cron un restart de Shorewall toutes les ... 2 minutes !

PS : au passage, j'ai souvent des messages de ce genre dans mon syslog et je n'arrive pas à les interpréter (porotcole ICMP avec quelque chose encapsulé ??)

Code: Tout sélectionner

Shorewall:wan2all:DROP:IN=ppp0 OUT= MAC= SRC=217.
81.184.140 DST=193.251.11.134 LEN=56 TOS=0x00 PREC=0x00 TTL=116 ID=34030 PROTO=I
CMP TYPE=3 CODE=3 [SRC=193.251.11.134 DST=192.168.0.2 LEN=55 TOS=0x00 PREC=0x00
TTL=118 ID=164 PROTO=UDP SPT=4672 DPT=4672 LEN=35 ]

[Jacques-]

ICMP type 3 : Destination unreachable

Les données encapsulées sont les paquets que tu as envoyé qui n'ont pu joindre la destination.
et 4672 ce doit être le port utilisé par emule.
Si tu es en IP dynamique, c'est peut être l'ancien titulaire de l'adresse qui a envoyé le paquet qui te revient, ce ne doit pas être rare en P2P avec des IP dynamiques.

Jacques

[lembal]

Merci pour tes réponses Jacques !

C'est bien ce qui me semblait, SHOREWALL PLANTE !!!!
J'ai accepté le trafic HTTP depuis mon LAN vers le WAN (règle par défaut).
Cependant j'ai des soucis de transmission (en upload) de documents dépassant les 800/900 Ko sur des Webmails (nomade, hotmail...).

Et j'en ai enfin la preuve via mon SYSLOG :

Code: Tout sélectionner

Jun  8 09:55:11 campux kernel: Shorewall:fw2all:REJECT:IN= OUT=eth0 SRC=@IP_interne_FW DST=Mon_PC LEN=464 TOS=0x00 PREC=0xC0 TTL=255 ID=61516 PROTO=ICMP TYPE=3 CODE=0 [SRC=Mon_PC DST=@IP_serveur_WEB LEN=436 TOS=0x00 PREC=0x00 TTL=128 ID=5734 DF PROTO=TCP SPT=1368 DPT=80 WINDOW=64667 RES=0x00 ACK PSH URGP=0 ]

En bref la règle REJECT, au bout d'un certain temps, prend le dessus sur la règle exception (autorisant la sortie d'HTTP du LAN vers WAN)...

Que faire docteur ? URPME SHOREWALL ou réinstallation totale de ma MNF ???

[Jacques-]

Es-tu certain que ce n'est pas Squid qui plante lors des upload ?
Par défaut, c'est ton proxy qui reroute les connexions HTTP ce qui est le cas du webmail. Il y a d'ailleurs un post récent sur ce sujet sur le forum.

Autrement, essaye de bypasser squid (il faut autoriser HTTP comme c'est fait, le DNS du LAN->WAN et mettre les DNS de ton FAI dans le PC que tu utilise pour que tout marche et cela devrait te permettre d'éliminer au moins shorewall.
A mon avis, si shorewall rejette la règle, c'est que la communication se plante et tente de reprendre ensuite, le couopure dure trop longtemps et les paquets ne sont plus dans un état RELATED au niveau de ta règle shorewall, qui donc les rejette.

Jacques

[lembal]

Es-tu certain que ce n'est pas Squid qui plante lors des upload ?
Par défaut, c'est ton proxy qui reroute les connexions HTTP ce qui est le cas du webmail. Il y a d'ailleurs un post récent sur ce sujet sur le forum.

Autrement, essaye de bypasser squid (il faut autoriser HTTP comme c'est fait, le DNS du LAN->WAN et mettre les DNS de ton FAI dans le PC que tu utilise pour que tout marche et cela devrait te permettre d'éliminer au moins shorewall.
A mon avis, si shorewall rejette la règle, c'est que la communication se plante et tente de reprendre ensuite, le couopure dure trop longtemps et les paquets ne sont plus dans un état RELATED au niveau de ta règle shorewall, qui donc les rejette.

Jacques

Merci Jacques,

Justement je souhaite bypasser Squid... donc je ne passe pas par lui !
En fait je me sers de ma MNF comme DNS Cache et je ne fais pas pointer mes requêtes DNS vers les serveurs de mon FAI... Ca pourrait être ça ! ?

Bon je fais le test de suite...

[lembal]

Es-tu certain que ce n'est pas Squid qui plante lors des upload ?
Par défaut, c'est ton proxy qui reroute les connexions HTTP ce qui est le cas du webmail. Il y a d'ailleurs un post récent sur ce sujet sur le forum.

Autrement, essaye de bypasser squid (il faut autoriser HTTP comme c'est fait, le DNS du LAN->WAN et mettre les DNS de ton FAI dans le PC que tu utilise pour que tout marche et cela devrait te permettre d'éliminer au moins shorewall.
A mon avis, si shorewall rejette la règle, c'est que la communication se plante et tente de reprendre ensuite, le couopure dure trop longtemps et les paquets ne sont plus dans un état RELATED au niveau de ta règle shorewall, qui donc les rejette.

Jacques

Merci Jacques,

Justement je souhaite bypasser Squid... donc je ne passe pas par lui !
En fait je me sers de ma MNF comme DNS Cache et je ne fais pas pointer mes requêtes DNS vers les serveurs de mon FAI... Ca pourrait être ça ! ?

Bon je fais le test de suite...

1) Je vais connecter un PC directement au switch de ma MNF.
2) je vais l'autoriser à sortir sur du HTTP + UPD/53 et lui mettre les @IP des DNS de mon FAI
3) je vais envoyer des documents de divers poids (Mo) vers différents sites voir si la connexion ne s'interrompt pas...

Si ça plante encore... se pourrait-il que ces déconnexions intempestives soient dues à la qualité de la ligne téléphonique ??

[Jacques-]

Il ne faut jamais oublier la couche basse, si le réseau téléphonique est pourri, le trafic aussi.
Mais il est aussi possible que ce soient les Webmails qui limitent la taille de tes fichiers, ou ton antivirus qui ralentisse le tout en contrôlant tout ce qui sort (c'est le cas de Norton sous Windows).

Tu peux aussi essayer de logguer la règle HTTP pour voir ce qui sort, passe et se coupe éventuellement.
Tu as aussi un truc tout con c'est un MTU mal configuré (pour le PPPOE il faut le réduire, mais c'est normalement bien fait dans la config MNF 8.2, pas forcé pour une autre version).

Bons tests.

Jacques

[lembal]

Il ne faut jamais oublier la couche basse, si le réseau téléphonique est pourri, le trafic aussi.
Mais il est aussi possible que ce soient les Webmails qui limitent la taille de tes fichiers, ou ton antivirus qui ralentisse le tout en contrôlant tout ce qui sort (c'est le cas de Norton sous Windows).

Tu peux aussi essayer de logguer la règle HTTP pour voir ce qui sort, passe et se coupe éventuellement.
Tu as aussi un truc tout $%#&! c'est un MTU mal configuré (pour le PPPOE il faut le réduire, mais c'est normalement bien fait dans la config MNF 8.2, pas forcé pour une autre version).

Bons tests.

Jacques

Bon j'ai déjà fait quelques tests...

- Webmail : hors de cause (taille limitée à 5 Mo), mes fichiers font 1.5 Mo à tout cassé ! De plus ça me fait la même chose vers des sites Web du genre CMS (plone....)
- Il n'y a que 4 liaisons qui peuvent être en cause : celle du PC au switch, celle de la MNF au switch, celle de la MNF au modem et en fin LA ligne FT... Je change donc les liaisons m'appartenant - les câbles RJ-45 !
- L'anti-virus... hmmmm possible, d'autant plus que j'ai Symantec Anti-virus... je le désactive !

... je peux appeler FT pour leur dire de checker ma ligne ???

[lembal]

Bon j'ai désactivé tout anti-virus, j'ai testé plusieurs sites (pas des webmails), j'ai testé plusieurs poids de fichiers, j'ai testé une machine directement connectée au switch de la MNF sans aucun autre traffic et j'ai échangé les câble avec des neufs - résultats : pareil, au mieux j'envoie un fichier de 900 ko !! Je peux appeler FT maintenant...à tout hasard ??

[Jacques-]

Je tenterais bien une demande vers FT en effet.
Personnellement, je doute que cela vienne de shorewall. Soit les paquets sont autorisés, soit ils ne le sont pas, mais un upload en cours n'est pas interrompu de ce fait, tant que la connexion est ouverte il n'y a pas de raison de refuser un paquet.
Si ton PC est sous Winchose, tu peux aussi configurer ton modem directement dessus et tenter l'upload. Parce que de toute façon, la première chose que le gars en face te dira c'est que ce n'est pas supporté chez eux si tu n'as pas suivi l'installation de leur kit à la lettre; Autant leur dire après, une fois qu'il aura brûlé sa première réponse...
Bons tests

[lembal]

Je tenterais bien une demande vers FT en effet.
Personnellement, je doute que cela vienne de shorewall. Soit les paquets sont autorisés, soit ils ne le sont pas, mais un upload en cours n'est pas interrompu de ce fait, tant que la connexion est ouverte il n'y a pas de raison de refuser un paquet.
Si ton PC est sous Winchose, tu peux aussi configurer ton modem directement dessus et tenter l'upload. Parce que de toute façon, la première chose que le gars en face te dira c'est que ce n'est pas supporté chez eux si tu n'as pas suivi l'installation de leur kit à la lettre; Autant leur dire après, une fois qu'il aura brûlé sa première réponse...
Bons tests

Je penses que je vais les appeler... malheureusement je ne peux pas tester leur kit... c'est une ligne en production et je ne peux pas la couper comme cela... je n'ai cas dire que j'ai suivi l'installation de leur kit à la lettre comme tu me dis et on verra bien !!

[lembal]

Bon alors je reviens à l'attaque...

J'ai testé un portable sous Win98 + Enternet (PPPoE) + AV désactivé directement branché au modem ADSL et j'ai essayé quelques uploads... à partir de 3 Mo ça plante (sur différents sites)... bon j'aurais besoin de faire des tests complémentaires mais ma marge temporelle est assez restreinte (ligne en pro oblige !)... J'ai donc appelé FT pour qu'ils fassent des tests sur la ligne : aucun soucis selon eux... le réseau fonctionne (merci FT, je m'en étais pas rendu compte ) et ils arrive à vois mon modem... Pour le débit il faut voir avec Wanadoo. Wanadoo me donne mon débit 1024/256... oui ça c'est le théorique ! Pour le débit réel en upload, il faut voir avec FT... il me faut maintenant lancer une procédure d'expertise auprès de FT (facturée bien sûr !) !! Alors avant cela j'aimerais savoir si ma MNF n'est pas en cause avant de faire venir des techniciens et d'être facturé :

- Zones :

Code: Tout sélectionner

1    lan    eth0    detect          
2    peda    eth1    detect          
3    wan    ppp+    detect    dhcp+noping

- Règles par défaut :

Code: Tout sélectionner

1    peda    all    DROP    info       
2    lan    all    REJECT    info       
3    dmz    all    REJECT    info       
4    fw    all    DROP    info       
5    wan    all    DROP    info       
6    all    all    REJECT    info

- Règles exceptions : que des ACCEPT ou des DNAT... rien de méchant !

Précision : quand je passe par le proxy, mes upload passent BEAUCOUp mieux que si je contourne Squid... normal, les fichiers sont envoyés à Squid qui les envoient depuis la MNF... ?! C'est logique ce que je dis ?


Je vais peut-être en arriver à réinstaller ma MNF et je voudrais pas en arriver là...

PS : je rappelle le type d'erreurs que je trouve dans mes logs :

Code: Tout sélectionner

Jun  8 09:55:11 campux kernel: Shorewall:fw2all:REJECT:IN= OUT=eth0 SRC=@IP_interne_FW DST=Mon_PC LEN=464 TOS=0x00 PREC=0xC0 TTL=255 ID=61516 PROTO=ICMP TYPE=3 CODE=0 [SRC=Mon_PC DST=@IP_serveur_WEB LEN=436 TOS=0x00 PREC=0x00 TTL=128 ID=5734 DF PROTO=TCP SPT=1368 DPT=80 WINDOW=64667 RES=0x00 ACK PSH URGP=0 ]