[RESOLU] UPLoad intempestif sur mon réseau.

[boulate]

Bonjour à tous.

Je me permets de poster un petit message, car j'ai un "problème" sur le réseau de la société dans laquelle je viens d'être embauché.

L'ancien Firewall/VPN (mandrake MNF) a rendu l'âme, et j'ai installé une PfSense pour la remplacer.

Tout fonctionne parfaitement (VPN, tous les services, etc.), mais un des serveurs du parc consomme un upload considérable, toutes les heures, ceci pendant 5 bonnes minutes. L'UL est tel que même une simple connexion internet sur un site classique se transforme en cauchemar.

Mes interrogations sont les suivantes :
1/ Existe il dans PfSense un moyen de contrôler quelle IP LAN consomme la bande passante ?
2/ J'ai tenté un "snif" de mon réseau LAN en promiscious, et rien d'évident n'en ressort, même au moment ou l'UL est consommée (avec un "ip.addr == <ip_passerelle>" sous wireshark par exemple). Etherape ne me met rien en évidence non plus ... je ne comprends pas. C'est probablement due à un oublie de configuration de ma part, mais j'ai du mal à identifier le problème.

Quels seraient vos conseils / outils / techniques / trucs de grand mère pour identifier ce fameux serveur qui me consomme 99% de ma bande passante (en UL donc le même le DL en pâti) ?

D'avance, merci !

Boulate.

[ccnet]

Si vous ne voyez rien avec Wireshark c'est peut être parce que vous êtes dans un environnement commuté (switch) ? Il faudrait, si vos switchs le permettent, utiliser un port configuré en span (port de copie).
Cela m'amenne à une question. Comment savez vous que c'est 95% de la bande passante et comment savez vous que c'est un serveur qui upload ?

Vous avez sans doute un nombre relativement réduit de serveurs situés dans une dmz. Une autre idée pour visualiser ce trafic serait d'utiliser les logs de Pfsense en les activant spécifiquement pour la ou les règles d'autorisation qui permettent cet upload. Vous auriez les ip source et destination, le protocole en cause.

[boulate]

Bonjour Ccnet, et merci pour cette réponse !

1/

Comment savez vous que c'est 95% de la bande passante

PfSense propose un "traffic graph" donnant l'utilisation (quasi temps réel) de notre UL et de notre DL.
Je connais notre UL max pour envoyer fréquemment des fichiers vers l'extérieur, et le graph "sature" à notre limite d'UL lorsque ce problème survient.

2/

Comment savez vous que c'est un serveur qui upload ?

Je travaille dans une agence de surveillance de la qualité de l'air (donc très orienté développement durable, économie d'énergie etc.). Si un poste de travail reste allumé la nuit : ATTENTION aux oreilles !
Donc les pics d'UL (qui apparaissent la nuit également) ne peuvent être dues qu'à un serveur. Les deux pics les plus longs (08h et 18h) surviennent alors que je suis seul au bureau (c'est une petite agence). Mon PC est donc le seul PC allumé. Mon poste de travail est sous ArchLinux, donc pas de mise à jour "cachée" ou autre. Aucun service réseau n'est lancé, netstat ne me retourne rien de "bizarre". J'ai même supprimé ma route par défaut hier soir (donc plus d'accès au net) pour en être certain.

3/ Je n'ai aucun serveur en DMZ. Les seuls services accessibles depuis l'extérieur (peu nombreux) sont "NATés".

4/ Je vais voir si mon switch me permet de configurer un port en "span" ... je n'y avait pas pensé ! Merci.
En effet, wireshark ne me retourne quasiment que des broadcast et des "IPX SAP Nearest Query" (je vais aller voir à quoi ça correspond d'ailleurs).

5/ Je vais également me pencher sur les logs PfSense, mais en cherchant à modifier mes logs, je n'ai pas trouvé ce qu'il me fallait. Je vais me remettre dessus, tout ceci doit probablement être accessible quelque part.

Merci encore pour cette réponse.

[ccnet]

Sur Pfsense lorsque le trafic d'upload est important vous pourriez activer la capture de paquet sur une interface puis l'examiner dans Wireshark. C'est probablement la meilleure solution à laquelle je n'ai pas pensé tout de suite.

des "IPX SAP Nearest Query"

C'est du trafic réseau spécifique au protocole Novell. Vous avez encore du protocol IPX sur votre réseau ?
Il faut croire que non sinon vous auriez reconnu sans doute ce protocole.
Il faut chercher d'où il vient et désactiver le protocole sur la ou les machines en cause.

[jdh]

On peut facilement trouver des "vieux" protocoles dans un réseau :

il suffit d'avoir des imprimantes à carte réseau intégrée pour lesquelles "tout" reste activé : Novell, Mac, DLC, SMB !

La sécurité réseau consiste d'abord à filtrer en sortie.

Avec pfSense, on peut commencer avec ntop qui permet d'avoir vite une idée de la bande passante utilisée par un poste. Cependant, il y a plein de nouveaux packages en 1.2.3 que je ne connais pas et qui pourrais faire mieux ...

[boulate]

Merci pour vos réponses ! Mon problème est résolu.

- J'ai utilisé la fonction de capture de paquets de PfSense (très pratique d'ailleurs) sur mon interface LAN pour isoler le serveur glouton et voir avec qui il communiquait.

- J'ai téléchargé la capture que j'ai ensuite analysé avec wireshark. Un des serveurs en est ressorti très clairement, et j'ai pu identifier la société concernée via un NSLookUp.

- Le serveur concerné étant le seul serveur sur lequel nous n'avons pas la main (il analyse et traite les données reçues par nos capteurs), j'ai dû appeler la société concernée et ils ont corrigé le problème (un fichier trop lourd qui cherchait à s'UL ==> mise en échec ==> essai le soir ==> mise en échec ==> essai le lendemain matin etc.).

Merci pour votre aide,

Boulate.

EDIT : Juste une petite question technique :
Pourquoi le fait de saturer l'UL bloque le DL ? Est ce dû au fait que je ne puisse plus envoyer les "accusés de réceptions" de chaque paquet reçu ?

[ccnet]

Si vous ne pouviez plus envoyer les acquittements TCP, la transmission serait rapidement interrompue.
Si TCP gère les acquittements différés, il y a des limites en particulier parce que l'émetteur a besoin de connaitre la taille de fenêtre disponible chez le destinataire pour savoir si oui ou non les données envoyées peuvent être reçues.