[FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Raphael Maunier
Hello Tous,

Je ne suis pas du tout un specialiste de la question, mais pour les besoins
de la prochaine reunion des membres de l'association France-IX, nous aurions
besoin d'une camera qui soit en mesure de fournir un flux multicast, que
nous allons balancer vers un serveur VLC, afin que tout les non-membres
et absent  puissent acceder a la reunion ( sera egalement disponible un
serveur / chan IRC lors de la reunion)

Nous n'avons pas ce type de materiel pour le moment, et n'allons tres
propablement pas avoir le temps de le sourcer, tester et tout ce qui va
avec.

Est-ce que une personne qui aurait ce type de materiel et qui soit en mesure
de nous aider sur la mise en place, pourrait nous contacter sur
i...@franceix.net.
La reunion des membres est prevue le 08 decembre sur Paris.

Merci,

Raphael Maunier
France-IX


Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Clement Cavadore
Hello,

Pourquoi un flux multicast ? 
Tu ne peux pas unicaster le flux caméra-serveur, simplement ?

Ensuite, de toute manière, les participations en remote seront
probablement regardées en unicast.

-- 
Clément


On Wed, 2010-11-24 at 11:16 +0100, Raphael Maunier wrote:
 Hello Tous,
 
 
 Je ne suis pas du tout un specialiste de la question, mais pour les
 besoins de la prochaine reunion des membres de l'association
 France-IX, nous aurions besoin d'une camera qui soit en mesure de
 fournir un flux multicast, que nous allons balancer vers un serveur
 VLC, afin que tout les non-membres et absent  puissent acceder a la
 reunion ( sera egalement disponible un serveur / chan IRC lors de la
 reunion)
 
 
 Nous n'avons pas ce type de materiel pour le moment, et n'allons tres
 propablement pas avoir le temps de le sourcer, tester et tout ce qui
 va avec.
 
 
 Est-ce que une personne qui aurait ce type de materiel et qui soit en
 mesure de nous aider sur la mise en place, pourrait nous contacter
 sur i...@franceix.net.
 La reunion des membres est prevue le 08 decembre sur Paris.
 
 
 Merci,
 
 
 Raphael Maunier
 France-IX


---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, Clement Cavadoreclem...@cavadore.net a écrit :
 Re,

 On Wed, 2010-11-24 at 11:30 +0100, Raphael Maunier wrote:
 Pour faire un peu le geek ? Genre fournir le flux dans le vlan
 Multicast du France-IX ?

 Ouais, bah a ce moment la, si tu tiens absolument a faire geek (mais
 m'est d'avis qu'il n'y aura pas énormément de monde pour regarder le
 flux en multicast, a l'exception peut être de Renater ?), tu fais de
 l'unicast jusqu'a ton serveur VLC, et tu rebalance en multicast et
 unicast depuis ce même serveur.

Et dans ce cas ce n'est pas forcément la peine d'avoir une caméra IP:
une webcam de très bonne qualité, en USB, peut suffire, non? En la
branchant directement sur le serveur qui fait tourner VLC.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Clement Cavadore
On Wed, 2010-11-24 at 11:46 +0100, Rémi Bouhl wrote:
 Et dans ce cas ce n'est pas forcément la peine d'avoir une caméra IP:
 une webcam de très bonne qualité, en USB, peut suffire, non? En la
 branchant directement sur le serveur qui fait tourner VLC.

Tout à fait. Ou une caméra classique avec une carte d'acquisition video
quelconque.

-- 
Clément Cavadore

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Pierre Chapuis
On Wed, 24 Nov 2010 12:13:27 +0100, Clement Cavadore 
clem...@cavadore.net wrote:


Tout à fait. Ou une caméra classique avec une carte d'acquisition 
video

quelconque.


Je confirme. Configuration déjà testée :

webcam -USB- vieux laptop -ethernet- serveur qui encode et diffuse 
en {multi,uni}cast


--
Pierre 'catwell' Chapuis

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Raphael Maunier
2010/11/24 Pierre Chapuis catw...@archlinux.us

 On Wed, 24 Nov 2010 12:13:27 +0100, Clement Cavadore clem...@cavadore.net
 wrote:

  Tout à fait. Ou une caméra classique avec une carte d'acquisition video
 quelconque.


 Je confirme. Configuration déjà testée :

 webcam -USB- vieux laptop -ethernet- serveur qui encode et diffuse en
 {multi,uni}cast

 --
 Pierre 'catwell' Chapuis

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/




Re: [FRnOG] Camera IP pour fournir un flux www

2010-11-24 Par sujet Raphael Maunier
Merci,

J'ai pas mal de proposition et je pense que on va avoir une ou plus version
du flux.

Des solutions normale et des solutions geeks :)

on pourra meme faire un comparatif bien geek sur via un Mac, via une Debian
et via une solution proprio ...

Raphael

2010/11/24 Raphael Maunier raph...@franceix.net



 2010/11/24 Pierre Chapuis catw...@archlinux.us

 On Wed, 24 Nov 2010 12:13:27 +0100, Clement Cavadore clem...@cavadore.net
 wrote:

  Tout à fait. Ou une caméra classique avec une carte d'acquisition video
 quelconque.


 Je confirme. Configuration déjà testée :

 webcam -USB- vieux laptop -ethernet- serveur qui encode et diffuse en
 {multi,uni}cast

 --
 Pierre 'catwell' Chapuis

 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/





[FRnOG] Pointeur utile pour la plomberie d'adressage IPv6

2010-11-24 Par sujet Mohsen Souissi

http://www.networkworld.com/community/node/68781

Les commentaires complètent.

J'espère que cela répondra à une certaine attente sur cette liste.

Mohsen.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mathias WMN
Bonjour,

Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).

Cordialement,

Mathias

Le mercredi 24 novembre 2010 à 14:51 +0100, Rémy Sanchez a écrit :
 Bonjour à tous,
 
  Les dernières tendances en terme de n'importe quoi consistent à faire 
  passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a 
  pratiquement remplacé le TCP. Après tout, toutes les applications web 
  passent par du HTTP, or c'est plutôt vaste : distribution de contenu, 
  messagerie instantanée, flux vidéo, traitement de texte, ... Sans 
  oublier toutes les applications qui utilisent le HTTP (par exemple MSN) 
  pour faire passer leur protocole en environnement restreint, ou 
  carrément les tunnels.
 
  En bref, le port 80 est toujours ouvert, soit directement, soit à 
  travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En 
  fin de compte, serait-il cohérent d'imaginer une application analogue à 
  un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au 
  HTTP ?
 
  Ça y est je vois déjà tous les canons pointés en ma direction pour me 
  signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le 
  genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente 
  ou si c'est du grand n'importe quoi. Cependant, je pense à des 
  fonctionnalités qui m'ont l'air difficile à configurer dans les outils 
  pré-cités, comme par exemple différencier les types de flux pour y 
  assigner des priorités (long poll et dérivées, page standard, gros 
  fichier, accélérateur de téléchargements, ...), reconnaître les sous 
  protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre 
  aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du 
  HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la 
  QoS.
 
  Les outils que j'ai rencontré jusque là ne permettent pas de faire ça 
  simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), 
  après étant relativement novice en réseau j'ai assez peu touché aux 
  autres outils et aux appliances proprio, donc mon panorama est 
  restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel 
  outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? 
  Est-ce que j'ai complètement fumé la moquette ?
 
  NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, 
  non de la manière dont on pourrait les implémenter...
 
  Allez c'est parti pour une après midi à prendre des baffes :)
 

-- 
Mathias WOLFF
Directeur Associé
WM Networks

Adresse : 149 Avenue du Maine 75014 PARIS

GSM : 06.79.59.43.32

Opérateur d'opérateurs.


smime.p7s
Description: S/MIME cryptographic signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN 
m.wo...@wm-networks.fr wrote:

Bonjour,

Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).

Cordialement,


Probablement que ça rentre dans cette catégorie, mais ce que je veux 
surtout c'est pouvoir considérer le HTTP comme un protocole de niveau 4. 
Le nombre d'applications web et/ou passant par du HTTP est devenu 
tellement important que je pense qu'on a plutôt intérêt se mettre à la 
vitesse supérieure et considérer ce qui passe dans le HTTP comme des 
protocoles à part entière.


Sinon avec quoi tu ferais ton filtrage de niveau 7 ? Une recherche 
rapide me donne ce genre de résultats : 
http://firewalls.smile.fr/L-offre-open-source-en-matiere-de-filtrage/Filtrage-niveau-7, 
qui préconise l'usage de Squid, ce qui comme je le disais dans le mail 
précédent n'est pas vraiment adapté à ce genre d'usages... (ou alors, 
j'ai raté un épisode :) )


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet guillaume . monnette
Si nous etiames vendreday, j'irions plus loin...


Après la concentration de tous les protocoles au dessus de TCP (ce qui était 
deja une hérésie), puis de HTTP (n'en parlons pas)... Bienvenue vers la 
concentration vers deux fqdn : www.google.com et www.facebook.com

Je remarque en effet, que 
1/ De plus en plus de marketeux rafolent des www.facebook.com/x à la place 
d'un site. C'est pratique, car ça permet de profiler et FB est accessible via 
les pseudos acces web des téléphones mobile.
2/ Et de plus en plus de collègues utilisent les *...@gmail.com car c'est le 
webmail le moins filtré en entreprise...



- Mail Original -
De: Rémy Sanchez remy.sanc...@hyperthese.net
À: frnog@frnog.org
Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam / Berlin / 
Berne / Rome / Stockholm / Vienne
Objet: [FRnOG] Firewall HTTP


 Bonjour à tous,

 Les dernières tendances en terme de n'importe quoi consistent à faire 
 passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a 
 pratiquement remplacé le TCP. Après tout, toutes les applications web 
 passent par du HTTP, or c'est plutôt vaste : distribution de contenu, 
 messagerie instantanée, flux vidéo, traitement de texte, ... Sans 
 oublier toutes les applications qui utilisent le HTTP (par exemple MSN) 
 pour faire passer leur protocole en environnement restreint, ou 
 carrément les tunnels.

 En bref, le port 80 est toujours ouvert, soit directement, soit à 
 travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En 
 fin de compte, serait-il cohérent d'imaginer une application analogue à 
 un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au 
 HTTP ?

 Ça y est je vois déjà tous les canons pointés en ma direction pour me 
 signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le 
 genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente 
 ou si c'est du grand n'importe quoi. Cependant, je pense à des 
 fonctionnalités qui m'ont l'air difficile à configurer dans les outils 
 pré-cités, comme par exemple différencier les types de flux pour y 
 assigner des priorités (long poll et dérivées, page standard, gros 
 fichier, accélérateur de téléchargements, ...), reconnaître les sous 
 protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre 
 aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du 
 HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la 
 QoS.

 Les outils que j'ai rencontré jusque là ne permettent pas de faire ça 
 simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), 
 après étant relativement novice en réseau j'ai assez peu touché aux 
 autres outils et aux appliances proprio, donc mon panorama est 
 restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel 
 outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? 
 Est-ce que j'ai complètement fumé la moquette ?

 NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, 
 non de la manière dont on pourrait les implémenter...

 Allez c'est parti pour une après midi à prendre des baffes :)

-- 
 Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men



Ce qui me gêne un peu plus c'est que c'est une des briques du grand
firewall Chinois/Iranien/Français (inutile de rayer la mention inutile : 
la Loi LOPSSI nous prépare des choses sympa dans ce domaine...).


Pas besoin d'aller si loin, tous votre trafic http sur mobile passe par un
Firewall http, mais il fire pas la police, juste la facture



---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

  Après, vu à quel point les numéros de contorsioniste par HTTP se
  démocratisent, laisser le HTTP sans aucun filtrage donne l'impression de
  laisser tous les ports ouvert.

Il y a 10 ans:
Laisser les ports ouverts en sortie sans aucun filtrage me donne
l'impression qu'on pourra me pirater.

Ça donne la situation actuelle dont tu es insatisfait (tout le monde
fait n'importe quoi via HTTP).

Donc tu vas rajouter une couche.

Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui
font semblant d'être du vrai surf mais en fait si on met un quad-core
pour faire du DPI on se rend compte que c'est du VPN encapsulé dans
des pseudo-pages Web.

Du coup je propose la solution couillue: ouvrir les vannes sur les
autres ports.
Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne
ce qu'il n'aurait pas du cesser d'être.

Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en
RDP, inutile de faire des tunnels HTTP.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 15:55 +0100, Rémi Bouhl wrote:

 Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui
 font semblant d'être du vrai surf mais en fait si on met un quad-core
 pour faire du DPI on se rend compte que c'est du VPN encapsulé dans
 des pseudo-pages Web.

pas la peine d'attendre 10 ans, au vu des multiples process http-tunnel
qui semblent tourner sur les machines dédiées aux étudiants par ici

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Yves Dubromelle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 24/11/2010 15:47, guillaume.monne...@free.fr a écrit :
 Après la concentration de tous les protocoles au dessus de TCP (ce qui était 
 deja une hérésie)

Sur ce point j'aimerais que tu développe un peu, je ne comprend pas bien.
C'est peut-être dû à mon jeune âge, mais on m'a toujours appris que sur
Internet la couche transport du modèle OSI était fournie par TCP ou UDP
selon les besoins.
Une explication ?

Yves Dubromelle
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkztKxYACgkQ8IhKGszP0SoGRAD/Qwohzn+tWqisCz6wMDRdiR2c
0DMROC7GZZKAqpMH/YIA/1zaHnEXBd9iJRdTZLXxkewbgpOmi74CDAu9jqzuq79g
=avO1
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:

  Pour situer mon contexte et l'origine de mon idée : je m'occupe du 
  réseau dans une résidence étudiante, avec un débit très limité par 
  rapport au nombre d'utilisateurs. 

ne faudrait il pas commencer par la ? genre, augmenter le débit
disponible de maniere substantielle, plutot que d'essayer de gerer la
rareté de maniere sous-optimale ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
 Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
 dans une résidence étudiante, avec un débit très limité par rapport au
 nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le
 réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile
 de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a
 entretient d'embauche de faire de la VoIP (le problème n'existe plus au
 fait, on a trouvé des solutions quand même).

 Après en partant de ce constat, on remarque qu'il y a pas mal d'usages
 différent du HTTP, qu'on pourrait regrouper en familles avec des priorités
 différentes. Et il y a aussi des protocoles de tunnel que j'ai pas envie de
 voir passer par ce que je préfère le protocole en direct géré proprement
 plutôt qu'une horreur par HTTP. Bref, le but du jeu est de mieux contrôler
 les priorités pour améliorer le service rendu.

 Ce qui est donc à priori possible avec des trucs commerciaux, mais à mon
 avis ils servent plus à taper bêtement sur les utilisateurs qu'à vraiment
 travailler la qualité de service... Et puis bon, les trucs commerciaux c'est
 pas libre, et le dernier truc que j'ai envie de faire c'est de mettre une
 nœud aussi important de mon réseau sous des verrons (bien que des fois on
 n'ai pas le choix).


Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
et non de savoir exactement ce que font tes usagers,
qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
règles de Qos/Shaping  qui brident le fou de Download quand
il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
monde dort ?


-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot sxp...@sxpert.org 
wrote:

On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:


 Pour situer mon contexte et l'origine de mon idée : je m'occupe du
 réseau dans une résidence étudiante, avec un débit très limité par
 rapport au nombre d'utilisateurs.


ne faudrait il pas commencer par la ? genre, augmenter le débit
disponible de maniere substantielle, plutot que d'essayer de gerer la
rareté de maniere sous-optimale ?


On accepte les dons mensuels en virement, chèque ou espèce si tu veux 
:)


Plus sérieusement, on fait ce qu'on peut, car on a des ressource 
matérielles et humaines limitées. Mais c'est pas du tout de ça que je 
voulais parler, en fait. L'idée me vient de là, mais dans mon cas précis 
on a pratiquement réglé tous nos problèmes.


Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et 
que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, 
avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men
Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que 
peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des 
nouveaux outils plus adaptés que ce qu'on a aujourd'hui.


http://en.wikipedia.org/wiki/Multilayer_switch

Et ça fait aussi avec des linux 



---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Julien Gormotte



On Wed, 24 Nov 2010 15:47:48 +0100 (CET), guillaume.monne...@free.fr 
wrote:

Si nous etiames vendreday, j'irions plus loin...


Après la concentration de tous les protocoles au dessus de TCP (ce
qui était deja une hérésie), puis de HTTP (n'en parlons pas)...
Bienvenue vers la concentration vers deux fqdn : www.google.com et
www.facebook.com

Je remarque en effet, que
1/ De plus en plus de marketeux rafolent des www.facebook.com/x à
la place d'un site. C'est pratique, car ça permet de profiler et FB
est accessible via les pseudos acces web des téléphones mobile.
2/ Et de plus en plus de collègues utilisent les *...@gmail.com car
c'est le webmail le moins filtré en entreprise...


Fort heureusement, mon webmail perso n'est jamais filtré. Quoique, à un 
moment, le mot webmail avait été banni des URL accessibles chez un 
ancien employeur... (oui oui, meme pour aller faire des recherches, ou 
lire des articles sur le sujet...)






- Mail Original -
De: Rémy Sanchez remy.sanc...@hyperthese.net
À: frnog@frnog.org
Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam /
Berlin / Berne / Rome / Stockholm / Vienne
Objet: [FRnOG] Firewall HTTP


 Bonjour à tous,

 Les dernières tendances en terme de n'importe quoi consistent à 
faire
 passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on 
a
 pratiquement remplacé le TCP. Après tout, toutes les applications 
web
 passent par du HTTP, or c'est plutôt vaste : distribution de 
contenu,

 messagerie instantanée, flux vidéo, traitement de texte, ... Sans
 oublier toutes les applications qui utilisent le HTTP (par exemple 
MSN)

 pour faire passer leur protocole en environnement restreint, ou
 carrément les tunnels.

 En bref, le port 80 est toujours ouvert, soit directement, soit à
 travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... 
En
 fin de compte, serait-il cohérent d'imaginer une application 
analogue à
 un firewall, qui au lieu de s'en prendre au TCP s'attaque 
directement au

 HTTP ?

 Ça y est je vois déjà tous les canons pointés en ma direction pour 
me
 signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans 
le
 genre. C'est d'ailleurs pour ça que je demande si l'idée est 
cohérente

 ou si c'est du grand n'importe quoi. Cependant, je pense à des
 fonctionnalités qui m'ont l'air difficile à configurer dans les 
outils

 pré-cités, comme par exemple différencier les types de flux pour y
 assigner des priorités (long poll et dérivées, page standard, gros
 fichier, accélérateur de téléchargements, ...), reconnaître les sous
 protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en 
prendre
 aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par 
du
 HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour 
la

 QoS.

 Les outils que j'ai rencontré jusque là ne permettent pas de faire 
ça
 simplement (Squid, pf, iptables pour ceux que j'ai vraiment 
utilisé),

 après étant relativement novice en réseau j'ai assez peu touché aux
 autres outils et aux appliances proprio, donc mon panorama est
 restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel
 outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ?
 Est-ce que j'ai complètement fumé la moquette ?

 NDLR : l'idée ici est de débattre des fonctionnalités d'un tel 
produit,

 non de la manière dont on pourrait les implémenter...

 Allez c'est parti pour une après midi à prendre des baffes :)


---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Julien Richer
Le 24 novembre 2010 16:10, Rémy Sanchez remy.sanc...@hyperthese.net a
écrit :


 Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
 dans une résidence étudiante, avec un débit très limité par rapport au
 nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le
 réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile
 de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a
 entretient d'embauche de faire de la VoIP (le problème n'existe plus au
 fait, on a trouvé des solutions quand même).


Comment tu prends la décision que
- la conversation en voip est importante (entretien d'embauche ou teamspeak
pendant un WoW ?)
- le download n'est pas important (divX méchant illégale ou dossier
important ?)


Normalement la réponse est donc :
- on fait de la Qos pour répartir au mieux le débit (et donc ne pas
avantager celui qui ouvre 10 flux avec un download manager)
- mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 2- même
avec de la bonne volonté tu n'arriveras jamais à savoir si c'est vraiment
important ou pas sans te tromper


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :

 Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
 et non de savoir exactement ce que font tes usagers,
 qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
 règles de Qos/Shaping  qui brident le fou de Download quand
 il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
 monde dort ?


Je plussoie l'idée.
Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
qui est prioritaire, même en faisant preuve de bon sens). Une
répartition équitable en garantissant un minimum à chaque utilisateur,
et le tour est joué :)

Rémi
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 16:59 +0100, Rémi Bouhl wrote:
 Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :
 
  Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
  et non de savoir exactement ce que font tes usagers,
  qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
  règles de Qos/Shaping  qui brident le fou de Download quand
  il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
  monde dort ?
 
 
 Je plussoie l'idée.
 Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
 vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
 qui est prioritaire, même en faisant preuve de bon sens). Une
 répartition équitable en garantissant un minimum à chaque utilisateur,
 et le tour est joué :)

ca et chercher a augmenter la bande passante disponible, ce qui n'est
pas forcément cher...
(par exemple, en évitant d'avoir a se coltiner 5km de ligne de cuivre
pourries)

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer jul...@ywigo.fr 
wrote:

Le 24 novembre 2010 16:10, Rémy Sanchez  a écrit :

Pour situer mon contexte et l'origine de mon idée : je m'occupe du
réseau dans une résidence étudiante, avec un débit très limité
par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout
soit bloqué sur le réseau, on ouvre les ports à la demande.
Seulement, j'aimerais que le débile de base qui télécharge 10 trucs
en même temps n'empêche pas le type qui a entretient d'embauche de
faire de la VoIP (le problème n'existe plus au fait, on a trouvé des
solutions quand même).

Comment tu prends la décision que 
- la conversation en voip est importante (entretien d'embauche ou
teamspeak pendant un WoW ?) 
- le download n'est pas important (divX méchant illégale ou dossier
important ?)


Normalement la réponse est donc :
- on fait de la Qos pour répartir au mieux le débit (et donc ne pas
avantager celui qui ouvre 10 flux avec un download manager)
- mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 
2-

même avec de la bonne volonté tu n'arriveras jamais à savoir si
c'est vraiment important ou pas sans te tromper


Bien sûr qu'on n'écoute pas le contenu des conversations pour juger si 
elles sont importantes. C'était un exemple, pour illustrer un peu... Par 
contre en règle générale on veut que la VoIP aille vite alors que de 
lancer 10 connexions HTTP pour un même fichier c'est carrément pas fair 
play. Et si ça t'intéresse, des retours qu'on a eu, les gens font 
surtout de la VoIP pour WoW, un peu pour téléphoner à leurs parents, et 
de temps en temps pour un entretient d'embauche. Quand aux 
téléchargements c'est très souvent illégal mais on a eu des cas où des 
gens ont eu un service trop lent pour télécharger un fichier qui était 
important pour leur stage.


Mais encore une fois, j'aimerais ne pas parler de ce problème en 
particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une 
utilité ou une cohérence quelconque à un outil capable de comprendre le 
HTTP et les protocoles qui y circulent à l'intérieur, dans le but 
principal de faire de la QoS ? (et pourquoi pas bloquer les tunnels, 
bien que sur ce point je pense que la réponse soit assez claire).


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl remibo...@gmail.com 
wrote:

Je plussoie l'idée.
Inutile d'aller chercher au niveau de la couche 7 ce que les gens 
font

vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
qui est prioritaire, même en faisant preuve de bon sens). Une
répartition équitable en garantissant un minimum à chaque 
utilisateur,

et le tour est joué :)


Mes utilisateurs vont être content avec leur 100kbps par personne tiens 
:)


Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon 
maintenant si la VoIP et le gros fichier passent tous les deux par le 
HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?


C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. 
Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée. Pas décider que les films de cul de Bob valent plus que les 
séries à l'eau de rose d'Alice.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Michel Py
Rémi Bouhl
 Du coup je propose la solution couillue: ouvrir les vannes sur
 les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
 afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
 Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et
 en RDP, inutile de faire des tunnels HTTP.

+1

Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille pour la 
contourner. A force, pour accéder à sa propre bécane à quelques kilomètres on 
va se retrouver avec une usine à gaz qui consomme la moitié de la bande 
passante en encapsulations successives et envoie le trafic en Suède via le 
Srilanka.

Michel
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Yves Dubromelle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 24/11/2010 17:23, Rémy Sanchez a écrit :
 Je ne parle pas de décider que tel ou tel site soit plus important, mais
 on a bien inventé la QoS pour une raison non ? Par exemple, pour que de
 la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
 maintenant si la VoIP et le gros fichier passent tous les deux par le
 HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?
 
La vraie question, c'est de savoir pourquoi les utilisateurs de ton
réseau utilisent de la VoIP sur HTTP.
Si effectivement tu considère que la VoIP est importante au point de
vouloir la prioriser par de la QoS, à ce compte là pourquoi ne pas
ouvrir le port qui va bien pour qu'ils l'utilisent ?

Je ne comprend vraiment pas la logique.

 C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je
 veux pouvoir les distinguer pour avoir une qualité de service
 appropriée. Pas décider que les films de cul de Bob valent plus que les
 séries à l'eau de rose d'Alice.
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkztPSoACgkQ8IhKGszP0SozHgD9EnLaxGpOd0le57Blr0bTkWpC
gsgjmLgr58jL9y4i0xIBAI1FHijZcULzsgoTWlKODhF1X//325Q7X5Mqxp+CRdoz
=+JU6
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

  Je ne parle pas de décider que tel ou tel site soit plus important,
  mais on a bien inventé la QoS pour une raison non ? Par exemple, pour
  que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
  maintenant si la VoIP et le gros fichier passent tous les deux par le
  HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?

Pas exactement. Tu garantis à Bob et Alice leurs 100 ko/s. Celui qui
veut faire de la VoIP il coupe ou il ralentit son
FTP/HTTP/Torrent/whatever, ou il fait de la QoS tout seul comme un
grand (y'a des softs pour ça, y compris sous Windows).

Et si ça l'amuse il freine sa VoIP pour échapper à une discussion
chiante avec sa belle mère et il booste son DDL depuis Rapidshare
parce qu'un couillon de son groupe de travail a pensé que c'était une
bonne plateforme pour héberger un dossier sérieux.

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mehdi AMINI

Salut,

Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 
pour garantir ça...


Bon maintenant si la VoIP et le gros fichier passent tous les deux par 
le HTTP, tu fais quoi ?


L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ? 
Parler de Qualité de Service et VOIP over HTTP dans la même phrase c'est 
possible ???
Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis 
pour lui :-)



C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. 
Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée.


T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti 
plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui 
méritent tant d'attention ?



Mehdi
---
Liste de diffusion du FRnOG
http://www.frnog.org/



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 08:25:14 -0800, Michel Py 
mic...@arneill-py.sacramento.ca.us wrote:

Rémi Bouhl

Du coup je propose la solution couillue: ouvrir les vannes sur
les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et
en RDP, inutile de faire des tunnels HTTP.


+1

Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille
pour la contourner. A force, pour accéder à sa propre bécane à
quelques kilomètres on va se retrouver avec une usine à gaz qui
consomme la moitié de la bande passante en encapsulations successives
et envoie le trafic en Suède via le Srilanka.


+1 aussi

J'suis le premier à vouloir faire ce que je veux du réseau. Et le 
premier à faire des tunnels.


J'ai compris que le blocage des tunnels, c'est une mauvaise idée, et en 
fait c'est pas vraiment utile, donc sur ce point là c'est clair.


Mais le fait est que là 95% du flux de données passe par du HTTP, et 
qu'on commence vraiment à avoir des types d'applications variées qui se 
distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de 
quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais 
j'ai envie de proposer des solutions pour garder un service de qualité 
:) .


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Simon Morvan

Le 24/11/2010 17:23, Rémy Sanchez a écrit :


Mes utilisateurs vont être content avec leur 100kbps par personne 
tiens :)
S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est 
plus la taille du tuyau, le problème, pas la QoS.


Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Bon maintenant si la VoIP et le gros fichier passent tous les deux par 
le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? 
Pourquoi passent-il par HTTP ? La VoIP en UDP/RTP est filtrée sur ton 
réseau ?


--
Simon.


---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 17:26 +0100, Simon Morvan wrote:
 Le 24/11/2010 17:23, Rémy Sanchez a écrit :
 
  Mes utilisateurs vont être content avec leur 100kbps par personne 
  tiens :)
 S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est 
 plus la taille du tuyau, le problème, pas la QoS.

comme je disais... tuyau trop petit, augmenter tuyau ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephen
On Wed, November 24, 2010 16:59, Rémi Bouhl wrote:
 Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :


 Si ton problÚme est juste d'avoir assez de BP pour tous tout le temps,
  et non de savoir exactement ce que font tes usagers, qu'ils utilisent
 HTTP ou non, pourquoi ne pas mettre en place des
 rÚgles de Qos/Shaping  qui brident le fou de Download quand il n'est pas
 tout seul sur les tuyaux et le laisse faire quand tout le monde dort ?


 Je plussoie l'idée.
 Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
 vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
 qui est prioritaire, même en faisant preuve de bon sens). Une
 répartition équitable en garantissant un minimum à chaque utilisateur,
  et le tour est joué :)

Virgin Media (câble opérateur UK) a un système différent qui me semble pas
trop bête : pendant les périodes de forte activité réseau, la quantité de
données échangée par utilisateur est comptabilisée et si un dépassement de
quota est constaté (upload ou download), le débit est réduit pendant une
durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
l'utilisateur n'abuse pas au détriment des copains...

http://shop.virginmedia.com/help/traffic-management/traffic-management-policy.html


 Rémi
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:

 Virgin Media (câble opérateur UK) a un système différent qui me semble pas
 trop bête : pendant les périodes de forte activité réseau, la quantité de
 données échangée par utilisateur est comptabilisée et si un dépassement de
 quota est constaté (upload ou download), le débit est réduit pendant une
 durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
 l'utilisateur n'abuse pas au détriment des copains...

l'art et la maniere d'éviter d'investir... va savoir ou vont les
bénéfices ;)

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI joker@gmail.com 
wrote:

Salut,

Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 
pour garantir ça...


Bon maintenant si la VoIP et le gros fichier passent tous les deux 
par le HTTP, tu fais quoi ?


L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ?
Parler de Qualité de Service et VOIP over HTTP dans la même phrase
c'est possible ???
Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis
pour lui :-)


C'est malheureux mais beaucoup de protocoles convergent vers le 
HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée.


T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti
plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui
méritent tant d'attention ?


Ok j'avoue la VoIP c'était assez extrême, et y'a pas grand monde qui 
fait ça (voire, personne (sauf Skype ? je sais plus)). De toute façon ça 
serait débile, on leur ouvre toujours les ports de leur TS aux 
utilisateurs :)


Pour moi, y'a plusieurs familles de (plus ou moins) protocoles qui 
émergent :


	* Le bon vieux HTTP standard, avec téléchargement de petits fichiers 
un par un.
	* Le HTTP toujours standard, mais avec du téléchargement de gros 
fichiers avec potentiellement des abus à l'aide d'accélérateurs de 
téléchargements.
	* Les protocoles internes aux applications, avec des micro-requêtes en 
Ajax.

* Les long poll, comet et autres techniques de PUSH HTTP.

En somme, pourquoi l'accès à un traitement de texte en ligne devrait 
être traité avec la même priorité qu'un téléchargement de masse ? Ce 
sont deux services totalement différents, avec des besoins totalement 
différents aussi. De la même manière qu'on va faire passer le SSH avant 
le FTP, la communication évènementielle de la dernière appli à la mode 
devrait passer avant un téléchargement sur megaupload.


Pour répondre en diagonale aux autres messages : oui les utilisateurs 
qui font tout passer en HTTP sont débiles, mais en fait c'est le cas de 
n'importe qui surfant sur le web. C'est largement suboptimal, mais tout 
tend à tourner dans le navigateur.


Et encore une fois je ne dis pas que c'est impossible à gérer avec ce 
qui existe (variante: oui il y a des solutions à mes problèmes, et oui 
je les utilises). Je suggère juste la création d'un outil adapté, qui au 
lieu de demander des heures à concevoir et tuner une config, permettra 
d'avoir une config par défaut qui marche directement, sans avoir à 
détourner les fonctionalités du logiciel. J'veux dire par là, oui on 
peut faire un proxy avec nfqueue, bash, wget, rsync et 2 ou 3 autres, 
mais c'est carrément pas aussi adapté que Squid. Je veux différencier 
les flux HTTP, mais Squid n'est pas adapté pour ça.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
Le 24 novembre 2010 17:15, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :
 Mais encore une fois, j'aimerais ne pas parler de ce problème en
 particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité
 ou une cohérence quelconque à un outil capable de comprendre le HTTP et les
 protocoles qui y circulent à l'intérieur, dans le but principal de faire de
 la QoS ? (et pourquoi pas bloquer les tunnels, bien que sur ce point je
 pense que la réponse soit assez claire).


L'utilité/besoin est sans doute là vue que des produits commerciaux
existent depuis longtemps pour celà: Bluequote / Allott par exemple
(comme dit plus haut).
Après je ne sais pas si c'est la cohérence qu'il faut chercher mais
plutôt des besoins commerciaux et/ou sécuritaires plus que le manque
de BP car comme dit plus haut cette ressource n'est souvent plus un
problème.
Dans une ancienne vie on utilisait ce genre de boites pour facturer
nos clients hébergés en ferme, j'ai aussi travaillé pour un opérateur
sur une archi à base d'allot pour limiter tout ce qui relevait du
traffic P2PCo dès que le trafic n'était pas on-net. Dans les deux cas
il n'a jamais été question de regarder ce qui était échangé.
Le blocage de tel ou tel protocole ensuite relève de ta politique de
sécurité, qui de ce que je comprend diffèrerait dans ce cas de celle
d'un FAI/Opérateur (pour l'instant, quoique :))

-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 16:26:22 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et 
  que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, 
  avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui.

Pourquoi ?
On a pas encore appris les lecons du controle au nieveaux 3 et 4 ?
Faut imperativement faire les memes erreurs au niveau 7 ?

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Michel Py
 Radu-Adrian Feurdean a écrit:
 et certains elus moins cons contre cette loi.

A rajouter dans la lettre au Père Noël, définitivement.
Des politiciens moins cons que leurs prédécesseurs!

:-D

Michel.

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:23:37 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon 
  maintenant si la VoIP et le gros fichier passent tous les deux par le 

Ca ca marche en entreprise, ou la prioritisation de tel ou tel
protocole/destination/ se fait sur decision venue d'en haut (peu
importe l'impact sur les utilisateurs).
Quand la connectivite est un service offert (contre $$$ ou non), le
contenu des paquets que tu tranpostes n'est plus ton probleme. Ton
boulot dois s'arreter au plus proche du niveau 3.

  Je veux pouvoir les distinguer pour avoir une qualité de service 
  appropriée. Pas décider que les films de cul de Bob valent plus que les 
  séries à l'eau de rose d'Alice.

Mais c'est exactement ce que tu demandes.
Tu veux faire de la qualite de service, fais-la par client.

En effet c'est ca la neutralite

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:25:44 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Attention piège : on a un proxy donc c'est uniquement lui que la 
  passerelle va voir. Et limiter le nombre de connexions par IP au niveau 
  du proxy c'est pas possible à cause des long polls précédemment évoqués. 

Tu peux aussi revoir legerement ton architecture.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:33:16 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Mais le fait est que là 95% du flux de données passe par du HTTP, et 
  qu'on commence vraiment à avoir des types d'applications variées qui se 
  distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de 
  quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais 
  j'ai envie de proposer des solutions pour garder un service de qualité 

Pour la n-ieme fois, le rappel (en anglais cette fois):

We're network admins. To us, data is just a protocol-overhead.

Oublie tout ce qui depasse le niveau 3 !!!
Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de
voir les choses.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
 Pourquoi ?

Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de
débit ne soit pas pénalisé par un service qui se fiche de la réactivité
mais mange du débit à fond ?

 On a pas encore appris les lecons du controle au nieveaux 3 et 4 ?
 Faut imperativement faire les memes erreurs au niveau 7 ?

Pas moi en tout cas, quelles sont-elles ? On m'a toujours vendu la QoS
en disant que c'est trop cool, mais je suis curieux d'entendre des
contre-arguments.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:19 PM, Radu-Adrian Feurdean wrote:
 Tu peux aussi revoir legerement ton architecture.

Tu suggères ?

-- 
Rémy Sanchez
http://hyperthese.net



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:26 PM, Radu-Adrian Feurdean wrote:
 Pour la n-ieme fois, le rappel (en anglais cette fois):
 
 We're network admins. To us, data is just a protocol-overhead.
 
 Oublie tout ce qui depasse le niveau 3 !!!
 Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de
 voir les choses.

Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
les champs à la bonne valeur. À ma connaissance, les navigateurs ne
savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
commerce ça a l'air d'exister) pour différencier facilement les flux
assez finement.

D'où le problème initial de coder une application capable de faire de la
QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
valeur).

-- 
Rémy Sanchez





signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mattieu Baptiste
2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
 Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
 les champs à la bonne valeur. À ma connaissance, les navigateurs ne
 savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
 commerce ça a l'air d'exister) pour différencier facilement les flux
 assez finement.

 D'où le problème initial de coder une application capable de faire de la
 QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
 valeur).

Je me permets de répondre parce que je connais particulièrement bien
la résidence dont tu parles ;)

Tout ce que tu penses être tes problèmes sont des non-problèmes. Par
contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE.

Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ?
Ouvre avec modération le trafic que tu souhaites ne plus voir passer
dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu
fais actuellement...

Tu te plains que tout le monde peut mettre tout ce qu'il veut dans
HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et
faire je ne sais quels calculs magiques dont toi même tu ne sais
expliquer, pour catégoriser les services qui passent dans HTTP) ? Et
tu feras quoi quand un mec utilisera son propre outil non connu par
l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans
des balises normales HTML, ressemblant à du contenu normal... et que
ce mec pompera l'intégralité de la bande passante...

Tu n'es pas satisfait de squid ? De toute façon votre histoire de
proxy ce n'est que du bullshit. Vous maintenez des stats sur
l'utilisation du cache de votre proxy ? Vous avez des stats réels de
l'utilisation avec/sans proxy à la longue ?
Avec le *profil* de tes utilisateurs, le proxy sera inutile pour
plusieurs raisons :
- Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui
les intéressent eux,
- De très nombreux sites ont une politique de cache ultra restrictive,
- HTTPS ?
Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image
du jour google et quelques conneries, le proxy ne sert à rien.

La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans
le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans
HTTP, voir le cas d'utilisation d'un outil inconnu, top cool
moumoutte, qui fait du VPN.

Je vais encore le répéter, tu as un problème : la bande passante.
Quelles que soient les bidouilles que tu arriveras à trouver, on
reviendra au même problème initiale. Tu veux résoudre tes problèmes :
UPGRADE.

Enfin... comme le disent les autres réponses précédentes, ta tâche
elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce
qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute
façon une manière de faire ce qu'ils veulent). Tu as des abus
réguliers ? Tu souhaites t'en débarrasser ?
1 C'est ton boulot quotidien d'admin.
2 A toi d'éduquer (aussi durement que tu le souhaites) les
utilisateurs pour plus que ça ne se reproduise.
3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule
de cristal, mais je te mets au défi de le trouver.


-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Pascal Rullier
Le 24/11/2010 17:47, Raphaël Jacquot a écrit :
 On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:

   
 Virgin Media (câble opérateur UK) a un système différent qui me semble pas
 trop bête : pendant les périodes de forte activité réseau, la quantité de
 données échangée par utilisateur est comptabilisée et si un dépassement de
 quota est constaté (upload ou download), le débit est réduit pendant une
 durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
 l'utilisateur n'abuse pas au détriment des copains...
 
 l'art et la maniere d'éviter d'investir... va savoir ou vont les
 bénéfices ;)
   

Dans la poche des actionnaires pardi...

Cdt,

-- 
Pascal,


---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Xavier Beaudouin
Salut Rémy,

(...)

Le 24 nov. 2010 à 17:56, Rémy Sanchez a écrit :
 En somme, pourquoi l'accès à un traitement de texte en ligne devrait être 
 traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux 
 services totalement différents, avec des besoins totalement différents aussi. 
 De la même manière qu'on va faire passer le SSH avant le FTP, la 
 communication évènementielle de la dernière appli à la mode devrait passer 
 avant un téléchargement sur megaupload.

Moi pour le téléchargements de masse j'avais réglé (enfin j'avais) le pb 
autrement : répertoire /tmpfs de l'antivirus faisais 50M... tout téléchargement 
 a 50Mo devais passer par les admin... C'étais une règle... pratique... :)

 Pour répondre en diagonale aux autres messages : oui les utilisateurs qui 
 font tout passer en HTTP sont débiles, mais en fait c'est le cas de n'importe 
 qui surfant sur le web. C'est largement suboptimal, mais tout tend à tourner 
 dans le navigateur.

C'est sûr.. Je vais te donner un exemple, dans le cadre de mon taf j'ai un KVM 
IP qui lance un Java... Pas de pb... Sauf que ce truc passe par VNC... 
Evidement bloqué par des gens paranoïaques qui bloquent absolument tout ce qui 
sort y compris icmp (et pan pmtud - dtc, je parle pas non plus de l'IPv6 qui 
ne sera jamais prêt de fonctionner chez eux mais tant pis).
Résultat on avais commencé de faire des trucs avec des bidouilles genre novnc 
par exemple...
On a laissé tomber car il faillais une usine a gaz et un centrale de calcul 
pour couper le protocole VNC en morceaux de HTTP.

Résultat... encore une encapsulation de merde de plus a gérer pour les 
firewall corporate gérés par des gens pour qui TCP/IP se résume au minitel... 
(ok je vais loin, mais..).

 Et encore une fois je ne dis pas que c'est impossible à gérer avec ce qui 
 existe (variante: oui il y a des solutions à mes problèmes, et oui je les 
 utilises). Je suggère juste la création d'un outil adapté, qui au lieu de 
 demander des heures à concevoir et tuner une config, permettra d'avoir une 
 config par défaut qui marche directement, sans avoir à détourner les 
 fonctionalités du logiciel. J'veux dire par là, oui on peut faire un proxy 
 avec nfqueue, bash, wget, rsync et 2 ou 3 autres, mais c'est carrément pas 
 aussi adapté que Squid. Je veux différencier les flux HTTP, mais Squid n'est 
 pas adapté pour ça.

Y a un truc que tu peux faire avec squid c'est différencier les objets courts 
(ajax / traitement de texte / chat [ok je sors]) et les téléchargements 
lourds...
Bon c'est du tweak de conf mais ça se fait.

/Xavier

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote:
 2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
 Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
 les champs à la bonne valeur. À ma connaissance, les navigateurs ne
 savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
 commerce ça a l'air d'exister) pour différencier facilement les flux
 assez finement.

 D'où le problème initial de coder une application capable de faire de la
 QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
 valeur).
 
 Je me permets de répondre parce que je connais particulièrement bien
 la résidence dont tu parles ;)
 
 Tout ce que tu penses être tes problèmes sont des non-problèmes. Par
 contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE.
 
 Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ?
 Ouvre avec modération le trafic que tu souhaites ne plus voir passer
 dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu
 fais actuellement...
 
 Tu te plains que tout le monde peut mettre tout ce qu'il veut dans
 HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et
 faire je ne sais quels calculs magiques dont toi même tu ne sais
 expliquer, pour catégoriser les services qui passent dans HTTP) ? Et
 tu feras quoi quand un mec utilisera son propre outil non connu par
 l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans
 des balises normales HTML, ressemblant à du contenu normal... et que
 ce mec pompera l'intégralité de la bande passante...
 
 Tu n'es pas satisfait de squid ? De toute façon votre histoire de
 proxy ce n'est que du bullshit. Vous maintenez des stats sur
 l'utilisation du cache de votre proxy ? Vous avez des stats réels de
 l'utilisation avec/sans proxy à la longue ?
 Avec le *profil* de tes utilisateurs, le proxy sera inutile pour
 plusieurs raisons :
 - Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui
 les intéressent eux,
 - De très nombreux sites ont une politique de cache ultra restrictive,
 - HTTPS ?
 Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image
 du jour google et quelques conneries, le proxy ne sert à rien.
 
 La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans
 le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans
 HTTP, voir le cas d'utilisation d'un outil inconnu, top cool
 moumoutte, qui fait du VPN.
 
 Je vais encore le répéter, tu as un problème : la bande passante.
 Quelles que soient les bidouilles que tu arriveras à trouver, on
 reviendra au même problème initiale. Tu veux résoudre tes problèmes :
 UPGRADE.
 
 Enfin... comme le disent les autres réponses précédentes, ta tâche
 elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce
 qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute
 façon une manière de faire ce qu'ils veulent). Tu as des abus
 réguliers ? Tu souhaites t'en débarrasser ?
 1 C'est ton boulot quotidien d'admin.
 2 A toi d'éduquer (aussi durement que tu le souhaites) les
 utilisateurs pour plus que ça ne se reproduise.
 3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule
 de cristal, mais je te mets au défi de le trouver.
 
 

Je voulais justement pas ramener la résidence en question sur le tapis
par ce que je sais très bien que les problèmes viennent de la bande
passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
c'est un peu une impasse. Quand à éduquer les utilisateurs... Déjà ils
lisent pas les papiers/mails qu'on leur donne aussi court soient-ils, et
en plus ils changent tous les ans. M'enfin, c'est pas le problème, ce
troll là on l'a déjà assez souvent pour éviter de le ramener ici.

La question était bel et bien générique, à savoir est-ce qu'un tel
logiciel peut être intéressant dans un nombre suffisant de cas ?  Je me
demande si, étant donné que la quasi exclusivité du trafic est du HTTP,
est-ce que ça a du sens d'essayer de le considérer administrativement
comme un protocole de transport ?

Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si
on résume, la QoS ne sert à rien quand on a assez de bande passante, et
elle n'est pas assez efficace quand y'a pas assez de bande passante...

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 09:53 PM, Xavier Beaudouin wrote:
 Y a un truc que tu peux faire avec squid c'est différencier les objets 
 courts (ajax / traitement de texte / chat [ok je sors]) et les 
 téléchargements lourds...
 Bon c'est du tweak de conf mais ça se fait.

C'est plus où moins là où je veux en venir : c'est des choses qu'on
fait, mais c'est ni évident ni standard.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Jean-Pierre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour,

Le 24/11/2010 19:39, Rémy Sanchez a écrit :
 On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
 Pourquoi ?
 
 Pour qu'un service qui a besoin d'une bonne réactivité mais de peu
 de débit ne soit pas pénalisé par un service qui se fiche de la
 réactivité mais mange du débit à fond ?

Simple : faire une réservation de BP par utilisateur/@IP. Le reste de BP
étant mangée par qui veut/en a besoin.

(Faut peut être mettre les mains dans le cambouis pour y arriver)

 On a pas encore appris les leçons du contrôle au niveaux 3 et 4
 ? Faut impérativement faire les mêmes erreurs au niveau 7 ?
 
 Pas moi en tout cas, quelles sont-elles ?

- - Que c'est aux applications elles même et au système final de faire ce
contrôle de flux
- - Que gérer les contrôles de flux en cœur de réseau provoquait des
effets de bords non désirés (oscillations de trafic sur des liens
identiques, latence inexpliquée,

 On m'a toujours vendu la
 QoS en disant que c'est trop cool, mais je suis curieux d'entendre
 des contre-arguments.

De mon coté, on m'a appris que la QoS c'est trouver une règle pour
dropper/ralentir des paquets suivant une règle définie par l'admin.

Et donc que les marchands de contenus trouvaient ça bien car c'est
leur(s) service qui est mis en valeur (au détriment d'autres services
forcément).

Le souci majeur avec la QoS dans les grands système est la diversité des
utilisateurs. Tous n'ont pas les mêmes besoins. Untel a besoin de ses
résultats de simulation sur le calculateur de la boîte (Big file), tel
autre a besoin de récupérer les tonnes de PDF de ses mails. Un autre
encore va passer ses journées à balancer/récupérer des chaines de mails
avec la dernière blagounette. On peut même envisager une équipe de
développeurs qui publieraient leurs applications en torrent pour limiter
la BP.

Dis autrement, les protocoles ne sont pas représentatif de l'usage, ni
des attentes de l'utilisateur, et encore moins de leurs besoins.

Accessoirement, gérer de la QoS sur des tunnels encapsulés dans du HTTP,
risque de rapidement transformer le réseau en un champ de bataille avec
d'un coté le(s) gens qui veulent filtrer et les utilisateurs qui
*contourneront* le système de filtrage.

(Toute ressemblance avec une loi finissant par I relève du hasard)


Jean-Pierre
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkztiMcACgkQcPNeJG1THnNoMwCglYBRUBjMEfTicRsKjVekP10X
W8sAoJDHDDiXA/l03FRkF/EenicG2mj4
=G5XX
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

 par ce que je sais très bien que les problèmes viennent de la bande
 passante, et tu sais comme moi à quel point on n'a pas de budget. Donc

T'as un probleme de bande passante, t'as de utilisateurs qui veulent de
la bande passant ?
1. Augmente tes prix
2. Cree des services premium, plus chers, pour ceux qui veulent plus,
qui te permettent de financer ta bande passante

Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu
arrives dans un DC, ca coute presque rien (si jamais t'as encore de
probleme en DC, tu prononce le mot magique Cogent et tout le monde
rentre dans les rangs).

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Pointeur utile pour la plomberie d'adressage IPv6

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 22:31:16 +0100, Antoine MUSSO amu...@free.fr
said:

 En revanche j'ai au moins deux problèmes avec le /127 :
   - le routeur qui a pour masque par défaut un /64 et l'annonce au 
 backbone aspirant ainsi toutes tes intercos.
   - l'impossibilité d'intercaler un équipement (sonde) dans l'interco 
 sans renuméroter.
 
 Bref, pas sûr de l'utilité du /127.

Effectivement, le /127 ca le fait pas. Mais le /126 semble la norme pour
certains grands operateurs, et le /112 c'est un tres bon compromis.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote:
 
 On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
 remy.sanc...@hyperthese.net said:
 
 par ce que je sais très bien que les problèmes viennent de la bande
 passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
 
 T'as un probleme de bande passante, t'as de utilisateurs qui veulent de
 la bande passant ?
 1. Augmente tes prix
 2. Cree des services premium, plus chers, pour ceux qui veulent plus,
 qui te permettent de financer ta bande passante
 
 Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu
 arrives dans un DC, ca coute presque rien (si jamais t'as encore de
 probleme en DC, tu prononce le mot magique Cogent et tout le monde
 rentre dans les rangs).
 

On étudie la liaison IPoAC pour arriver au point de présence de Cogent
le plus proche :)

Y'a pas moyen d'avoir un centime de budget supplémentaire, pour
l'instant on est bien parti pour rester sur le modèle actuel (y compris
la facturation etc). C'est vraiment une petite échelle (~150 étudiants),
donc rien de trop faisable à ce niveau.

Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette
résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à
me poser la question, le but du jeu n'était pas de trouver un moyen
magique de faire rentrer plus de choses dans le même tuyau. C'était
juste une interrogation générique, que j'ai formulé et re-formulé 1 mail
sur 2, donc je vais éviter de le refaire ici.

En tout cas, merci à tous pour vos réponses :)

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
Le 24 novembre 2010 23:19, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :

 Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette
 résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à
 me poser la question, le but du jeu n'était pas de trouver un moyen
 magique de faire rentrer plus de choses dans le même tuyau. C'était
 juste une interrogation générique, que j'ai formulé et re-formulé 1 mail
 sur 2, donc je vais éviter de le refaire ici.


Je ne te comprend pas trop tu expose un problème précis mais tu ne
veux pas qu'on se focalise dessus.
Tu voulais discuter de quoi exactement ?? Savoir s'il était possible
de faire de la classification de paquets en L7 ??
La réponse est oui, cela existe depuis plus de dix ans (Packeteer /
Allot et sans doute des solutions Open Source).
Sinon tu as a ta disposition tout plein de tricks pour jouer avec la
Qos sur tes équipements et la solution à la Virgin me semble
est la plus intéressante pour toi.

-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 11:33 PM, David Ramahefason wrote:
 Je ne te comprend pas trop tu expose un problème précis mais tu ne
 veux pas qu'on se focalise dessus.
 Tu voulais discuter de quoi exactement ?? Savoir s'il était possible
 de faire de la classification de paquets en L7 ??
 La réponse est oui, cela existe depuis plus de dix ans (Packeteer /
 Allot et sans doute des solutions Open Source).
 Sinon tu as a ta disposition tout plein de tricks pour jouer avec la
 Qos sur tes équipements et la solution à la Virgin me semble
 est la plus intéressante pour toi.

Avec mon problème précis, je remarque que le HTTP permet de servir un
nombre varié d'applications en réseau. Et finalement, plus
d'applications passent par le HTTP que par du TCP ou de l'UDP directement.

La question porte donc sur les capacités des logiciels actuels en L7 :
sont-ils capable de différencier les différentes applications et de
prendre en compte leurs spécificités ?

Et par là, je veux dire que de plus en plus le HTTP prends la forme d'un
protocole niveau 4 voire 3, et par conséquent il y a peut être besoin de
le changer la manière dont on le traite.

Par exemple, est-ce que les outils actuels sont conçu pour pouvoir
reconnaître un accélérateur de téléchargement qui prends simultanément
10 morceaux d'un fichier sur megaupload ? De reconnaître long poll et de
lui donner une forte priorité pour baisser la latence ? Le tout avec la
configuration par défaut/peu de configuration ? [*]

Si les outils actuels en sont incapable, est-ce que cela aurait un
intérêt de créer un tel outil ? Les avis sur la QoS semblent partagés,
est-ce que cela est vraiment utile ?

Peut être qu'aujourd'hui le problème n'est pas flagrant, mais on voit de
plus en plus d'applications faire du (quasi) temps réel. On s'éloigne
vraiment loin du principe initial du HTTP... D'où mes interrogations,
pour éviter de se retrouver totalement désarmé dans un monde où le HTTP
écrase les autres protocoles et où l'on se retrouve sans aucune
visibilité sur les types de service.

J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer
sinon j'suis plus à ça près -_-

-- 
Rémy Sanchez


[*] Je sais que le réseau automagique n'existe pas et qu'il faut un
minimum savoir ce que l'on fait. Cependant, dans le cas présent tous les
gens qui mettraient en place ce genre de solutions auraient à peu près
les mêmes problèmes, donc finalement ça ne sert à rien d'écrire la conf
indéfiniment...



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 25/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

 J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer
 sinon j'suis plus à ça près -_-

Tout le monde a compris le problème (plein de gens, font des trucs
très différents en HTTP, pas assez de BP pour tous).

C'est juste que la solution fouiller au niveau 7 n'a pas l'air
d'être la seule réponse, ni même la meilleure.

L'idée plusieurs fois évoquée de partager la BP équitablement (pour
être précis: de garantir un minimum à chaque utilisateur, en toutes
circonstances) est plus simple à mettre en place, plus propre
éthiquement et techniquement, et garantit en toutes circonstances un
équilibre entre les usages.

Pourquoi ne pas l'envisager?

Rémi.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/25/2010 12:40 AM, Rémi Bouhl wrote:
 Tout le monde a compris le problème (plein de gens, font des trucs
 très différents en HTTP, pas assez de BP pour tous).

Justement, pas vraiment. C'est une vision plus globale : l'usage des
réseaux change, est-ce qu'il faut pas changer la manière des les
administrer ?

C'est une question de fond, abstraite, générique, pour faire de la
théorie pure et se demander si les choses doivent rester comme ça.

 C'est juste que la solution fouiller au niveau 7 n'a pas l'air
 d'être la seule réponse, ni même la meilleure.
 
 L'idée plusieurs fois évoquée de partager la BP équitablement (pour
 être précis: de garantir un minimum à chaque utilisateur, en toutes
 circonstances) est plus simple à mettre en place, plus propre
 éthiquement et techniquement, et garantit en toutes circonstances un
 équilibre entre les usages.
 
 Pourquoi ne pas l'envisager?

Si bah forcément avec ce qu'on a c'est ce qu'on risque de faire (quoi
qu'on s'en sort bien autrement là). Faut pas croire, on a travaillé les
différentes configs et maintenant on a un service de qualité très
raisonnable tant qu'on cherche pas à voir une vidéo sur youtube.

Mais en fin de compte, si elle était possible, est-ce que l'autre
approche que je propose serait intéressante ? Je ne cherche pas du tout
à la réaliser pour l'instant, je suis à la recherche d'avis purement
théoriques, pour savoir si ça serait une bonne pratique, si ça
apporterait quelque chose, ...

Et au passage si la solution dont je parle existe déjà, ça m'intéresse
aussi.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Antoine MUSSO

On 25/11/10 00:04, Rémy Sanchez wrote:
snip

La question porte donc sur les capacités des logiciels actuels en L7 :
sont-ils capable de différencier les différentes applications et de
prendre en compte leurs spécificités ?


  J'ai vu quelques produits capables de différencier les parties 
messageries, photos et chat d'un réseau social bien connu.  Idem pour 
les wikis : différenciations entre consultation et édition.
  Une autre fonction intéressante, était de prioriser les différentes 
requêtes HTTP, en fonction du contenu (js, image, gros paquets / petits 
paquets).


  Est-ce que çà a une utilité ?  Pour ma boîte probablement pas, on 
doit probablement réserver une certaine quantité de bande passante pour 
quelques sites publics très utilisé et pros (genre pagesjaunes).  Les 
flux métiers passent à coté sur des liaisons dédiées.


  Le problème qu'il peut éventuellement se poser, c'est le SSL.  Mais 
là encore, on peut très bien terminer le flux sur un boitier puis 
resigner pour l'utilisateur.  Dans une entreprise, c'est potentiellement 
assez simple puis qu'il y a une charte d'utilisation, on peut même 
envisager des exceptions (consultation à la CPAM, banque ...).


--
Antoine Musso
---
Liste de diffusion du FRnOG
http://www.frnog.org/