Problème flux video entre deux lan

[shawnX]

Bonjour à tous,

J'ai recensement migré d' IpCop vers Pfsense pour espérer pouvoir profiter de meilleures performances. Ma machine hôte ayant lâché entre temps, je suis aussi passé sur du matériel beaucoup plus performant : un Serveur IBM Dual Proc' (Xeon) 2,4ghz avec 3 cartes Gigabit PCI-X et 2go de ram et disques SCSI 10K en raid1 (acheté une misère sur leboncoin).

Voici donc le problème que j'avais avec IpCop et qui ce répète avec Pfsense : Je possède un serveur de Stockage dans la partie "Dmz" sur un Win2008R2 avec un partage Smb et Nfs, un Boitier multimédia ce trouve dans la partie "Lan" et lit les videos en streaming sur le serveur de stockage en utilisant le partage Nfs.
Le souci étant que les videos saccades, même de tout petits clips de quelques minutes.

Avant de placer ce serveur en Dmz il se trouvait sur le Lan, la lecture se fesait en direct sans passer au travers sur Firewall et la lecture de Bluray de 50Go ce fesait sans aucun souci même avec une avance rapide sur la video.
Je pense pouvoir dire que la machine hôte de Pfsense est largement surdimensionné pour ce que j'en fait, je me tourne donc vers vous pour avoir une piste qui concerne la partie logiciel car a ce stade je ne vois pas du tout d'où peut venir le problème.

Schéma du réseaux :
http://img254.imageshack.us/img254/9493/capturegod.jpg

Merci d'avance,
Charles

[jdh]

Situation A : le serveur est sur le même réseau que le client.
Situation B : le serveur n'est pas dans la même zone que le client, et est séparé par un firewall ... qui filtre les flux.

Que peut-on conclure de la différence entre situation A et situation B ?

On ne peut conclure que
soit le filtrage bloque une partie des flux nécessaires (par exemple d'authentification),
soit le filtrage réduit la performance du trafic.

Il serait intéressant de regarder un flux parfaitement défini dans les mêmes conditions de la situation B.
Par exemple, un trafic de type ftp : transfert d'un gros fichier de 10 ou 20 Go et d'un ensemble de fichiers et répertoires pour le même volume.
IIS est à ajouter sur le serveur Windows, et sur le client on choisira Filezilla comme client ou un simple ftp intégré sous cmd.

Ce test permettra d'incriminer ou non la plateforme firewall (sans garantie).

Autre question, les matériels sont ils configurés pour des jumbo frames ? (pfSense ne me semble pas Ok pour les jumbo-frames).


Le hardware me parait largement à la hauteur de doubles cartes gigabit.

Personnellement, je me méfierai d'un serveur Windows en DMZ : il y a tellement de flux dont on ignore le rôle dans un serveur Windows qu'il est nettement plus simple et plus sûr de prendre un serveur sous Linux ou BSD. Par exemple, pour créer un serveur NFS, je prendrai presque sûrement un FreeNAS ou OpenFiler (pour rester sous Linux).

[jibe]

Salut,

il y a tellement de flux dont on ignore le rôle dans un serveur Windows qu'il est nettement plus simple et plus sûr de prendre un serveur sous Linux ou BSD.

J'adore la formule

Tout est dit sans le dire ! Okazou certains s'interrogeraient encore sur le pourquoi d'un tel conseil (FreeNAS ou OpenFiler), je précise que les flux dont parle jdh sont susceptibles d'être tellement nombreux et/ou importants qu'ils risqueraient de beaucoup diminuer la bande passante et les ressources disponibles du serveur. Comme les flux vidéo en sont aussi gros consommateurs, l'explication peut très bien se trouver tout simplement là !

Personnellement, cela fait maintenant quelques années que je ne laisse pas les postes et encore moins les serveurs W$ accéder au net, et que si je suis obligé de le faire je refuse catégoriquement de porter la responsabilité des problèmes qui pourraient en découler. L'accès internet se fait exclusivement par des postes/serveurs Linux, et j'avoue que je n'ai qu'à m'en féliciter (sauf en ce qui concerne le CA généré par les multiples interventions de contrôle et déverminage )...

[jdh]

En fait, le problème est incomplètement présenté : il n'est rien dit du filtrage configuré entre LAN et DMZ !

Si le protocole attendu est NFS, on a tendance à écrire une règle pour autoriser 111/udp (=portmap) puis 2049/udp (=nfs), mais nfs utilise ensuite d'autres ports (pour des sous-process tel mountd, statd, quotad, lockd) ...

D'ailleurs mon conseil de tester ftp présente la même difficulté : le port peut changer (mais il existe un "helper" intégré ... si on ne l'a pas décoché !). En fait, le plus sûr moyen serait peut-être scp (copy sous ssh sur 22/tcp=ssh). (Mais Windows peut-il être serveur ssh ?)

Au pire, tout le trafic est autorisé. On se demanderait alors pourquoi mettre un firewall.
Et ce serait sans compter quelques protocoles qui ne s'accommode pas d'un routeur (comme les protocoles type UPnP, DLNA, Hello, ...).

Ce que je voulais indiquer, c'est qu'il faut éviter de mettre une machine Windows en DMZ ... car les ports à autoriser ne sont pas simples déjà à trouver. (Et ils changent avec les versions de Windows !)

A vrai dire, je ne suis pas surpris, qu'avec un routeur, on a plus de difficulté à joindre un serveur Windows. (Pour les plus anciens, on se rappellera WINS qui reste souvent encore actif ...). Delà à ce que la performance soit très amoindrie, il y a un pas que je ne franchirais pas ...

[jibe]

Ce que je voulais indiquer, c'est qu'il faut éviter de mettre une machine Windows en DMZ ... car les ports à autoriser ne sont pas simples déjà à trouver. (Et ils changent avec les versions de Windows !)

Effectivement, je n'avais pas vu les choses ainsi. Me serais-je laissé emporter par mon aversion pour W$ ?

Toujours est-il que j'ai très souvent constaté des réductions notables de bande passante lorsque de machines Windows sont connectées à Internet. La cause en est souvent un relais SMTP pirate destiné à brouiller les pistes de l'origine du spam... J'ai eu même vu des réseaux complètement bloqués par le traitement des bounces...

Antivirus, me répondra-t-on... Certes. Encore faut-il :
- Qu'il soit bon. Or, c'est souvent celui pré-installé avec l'OS qui est conservé, et ce n'est pas le meilleur...
- Qu'il soit mis à jour régulièrement. Certainement fait scrupuleusement dans les entreprises un peu importantes. Mais c'est hélas loin d'être le cas dans toutes les TPE...
- Qu'il n'ait pas été insensibilisé depuis longtemps à certains virus. Fait souvent constaté : tout a l'air Ok, des virus sont régulièrement trouvés, mais un relais de spam n'est détectable que par la version live CD de Kaspersky...

[shawnX]

Bonjour Messieurs et merci de vos commentaires.

Hé bien je vais tout simplement tester le partage depuis un FreeNas, de cette manière on verra vite si c'est le windows qui est en cause ou pas.
Après un petit coup de WireShark, il y a un grand notre de "ip checksum offload" ...

Les règles de firewall sont comme dis par Jdh, mais j'ai fait des essais en ouvrant tous les ports et le problème ce représente...

Je n'ai pas précisé que tout est virtualisé sous hyper-v, mais le problème ne se présentant pas quand je bascule le serveur hors de la Dmz pour faire des essais, je n'ai pas jugé utile de le préciser.
Ce réseaux est domestique, je l'ai monté à but purement educatif avec des licences étudiantes D'où ma possibilité de faire des essais qu'on ne ferais pas en prod dans une entreprise

[jdh]

La présentation est très clairement très incomplète !

Concernant les règles, il est forcément nécessaire de penser à les présenter car ce qui caractérise un firewall c'est, un, le découpage en zones distinctes, et, deux, les règles de filtrage de flux entre zones ! C'est quand même la base !

Concernant la virtualisation, la perception des phénomènes réseaux est perturbée par la vision réseau de l'outil de virtualisation, et probablement la performance ! Il est difficile de comprendre si on a pas une bonne expertise de ce qu'il se passe dans les couches "basses" alors qu'en plus, les interfaces ou switchs sont virtualisés !

Je note que la présentation du problème avance petit à petit, mais l'outil de virtualisation n'est pas encore cité.
Il serait bon de penser que, si vous souhaitez avoir un avis, il ne faut pas commencer par biaiser les informations : "je ne note pas ceci car ce ne doit pas avoir d'impact" est une erreur fondamentale : le plus petit détail a son importance.


Je ne pense pas qu'il soit possible d'aller plus avant : l'impact de la virtualisation sur un firewall est LOIN d'être négligeable :
- il faut savoir qu'un problème des plus essentiels de la virtualisation est l'horloge (du fait du partage de temps),
- dans un firewall, le temps de réponse à un paquet est directement lié au traitement cpu du paquet,
- un firewall ne peut que très difficilement s'accommoder de tranches de temps fournies par le virtualiseur !

En production ou pour de la performance, il ne faut pas virtualiser un firewall !
Ce schéma et cette question font un bon exemple de démonstration pratique !

Je confirme que, pour certaines tâches données, un serveur Linux est plus efficace qu'un serveur Windows :
un FreeNAS sera plus efficace pour du NFS qu'un serveur Windows, et sans doute même pour un partage CIFS (du fait que ZFS ou ext3 soit plus performant que NTFS).


NB : j'aurais du pensé qu'il y avait de la virtualisation du fait du nombre de machines ...

[jibe]

Salut,

C'est vrai que le problème semblait relativement bien présenté au départ (surtout comparé à ce que nous avons, hélas, de plus en plus souvent !), mais qu'on s'aperçoit en avançant qu'il manque des données vitales pour la compréhension de ce qui se passe.

Il faut avoir bien en tête que, lorsqu'on s'adresse à un expert, c'est à lui de juger ce qu'il est utile de savoir ou non. Dans la mesure où la présentation visuelle (paragraphes, sauts de ligne, disposition claire et logique etc.) est bien faite, les données inutiles ne sont jamais gênantes.

Mais en plus, si on respecte une bonne logique de présentation du problème, il n'y aura pas de données inutiles. Tout au plus des données peu importantes et/où n'intervenant pas dans la résolution du problème, mais rien ne dit qu'elles ne sont pas malgré tout nécessaires à sa compréhension. La logique aurait dû ici être la suivante :

- Description (qui peut éventuellement être résumée dans ce cas précis) des besoins
- Description (obligatoirement complète) des solutions techniques mises en œuvre pour couvrir ces besoins (ici, description des deux cas : serveur en LAN et serveur en DMZ, avec les schémas correspondant, schémas qui font apparaître clairement tout ce qui est virtualisé, par exemple par un trait pointillé ou une zone de couleur regroupant les appareils concernés).
- Description du problème constaté
- Description des éventuels tests, mesures, recherches etc. déjà effectués.

Le post que j'ai fait récemment devrait aider pour le début de cette démarche. Peut-être devrais-je le compléter ou en faire un autre pour ce qui concerne la présentation et la résolution des problèmes ? (suggestions et idées bienvenues )

En tous cas, comme il y est déjà dit :
Ne pas oublier que celui qui tente d'aider n'a pour cela que ce qu'on lui dit. Si on ne lui dit pas tout, ou si on lui dit des choses fausses, il lui est impossible, tout expert qu'il soit, de donner des solutions ou conseils adaptés.

A noter également que l'origine d'un problème peut se trouver (se trouve souvent, si le projet n'a pas été mené de manière rigoureuse) dans les solutions techniques choisies, voire dans l'élaboration du cahier des charges. Il est indispensable que l'expert qui aide ait bien tous les éléments pour en juger ! S'il n'a pas tous les éléments, il a de fortes chances de partir sur une fausse route. En effet, selon la manière dont les choses lui sont présentées, il ne pourra partir que sur un a-priori :
- Si le problème semble relativement bien présenté (comme ici), il pensera que, probablement, les solutions techniques ont été choisies avec soin et qu'elles ont un maximum de chances d'être bien adaptées
- SI le problème est mal présenté, il pensera que les solutions techniques ont été choisies en dépit du bon sens et qu'elles ont toutes chances d'être inadaptées.

Dans les deux cas, il s'agit de suppositions, sans aucun moyen de vérification. Donc, les possibilités de faire fausse route ne sont pas négligeables.