>NETASQ est aussi une solution capable d'agréger plusieurs liens (routé
>ou en point à point), de faire de la QoS et surtout de l'analyse
>protocolaire pour des prix très abordables.
De mémoire le prix du matériel Netasq est assez élevé ou alors les équipements
les moins sont très bridés en fonc
Hello, j'ai lu avec passion l'ensemble des interventions de ce thread.
Tout d'abord pour répondre a ta question, tu peux le developper le
firewall HTTP mais en fait iptables avec la partie l7 et une base de
signature protocolaire doit pouvoir faire ça. Y a plus qu'a creer un
projet sur sourceforge
Rémi Bouhl wrote:
Avec une option à cliquer "je gère la QoS moi-même" pour les barbus.
J'estime cela tres peu probable car le S de QoS, implique une ligne
de facture par service. Je conçois que cela ait de l'interet, mais
pas dans les conditions actuelles des contrats, un seul niveau de
servic
riginal -
> De: "Rémy Sanchez"
> À: frnog@FRnOG.org
> Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne
> / Rome / Stockholm / Vienne
> Objet: Re: [FRnOG] Firewall HTTP
>
> On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
>> On Wed,
quot;
À: frnog@FRnOG.org
Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne /
Rome / Stockholm / Vienne
Objet: Re: [FRnOG] Firewall HTTP
On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
> On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
> wrote:
>
>> Bon
>>> Rémi Bouhl a écrit:
>>> À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
>>> torrent qui soit prioritaire, c'est lui qui marque les paquets.
>> La je trouve que tu rêves un peu, peut-être que certains
>> de tes étudiants vont faire ça, mais pas Mme Michu.
> Sa machinbox va le f
Le 27/11/10, Michel Py a écrit :
>> Rémi Bouhl a écrit:
>> À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
>> torrent qui soit prioritaire, c'est lui qui marque les paquets.
>
> La je trouve que tu rêves un peu, peut-être que certains de tes étudiants
> vont faire ça, mais pas Mme M
> Stéphane Le Men a écrit:
> Vous ne pensez pas qu'avec une QoS, genre Wall-Street,
> vous ne trouverez pas client pour acheter vos premieres
> places dans vos files d'attente au bon prix ?
Tu n'es pas le premier à y penser; c'est une bonne idée, mais le client n'est
généralement pas assez sophis
Le 27/11/10, Stéphane Le Men a écrit :
> Michel Py wrote:
>
>>un jour ou l'autre quelqu'un avec un
>>téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté
>>d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est
>>pas le QOS qui va faire le réseau 3G afficher la page remplie
Michel Py wrote:
un jour ou l'autre quelqu'un avec un
téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté
d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est
pas le QOS qui va faire le réseau 3G afficher la page remplie de
merdasse sous HTTP à la vitesse du 4G.
S
Rémy Sanchez a écrit :
Bon, avant toute chose j'aimerais préciser que dans mon mail de base je
ne parlais absolument pas d'optimiser mon cas particulier, mais bien de
lancer le débat sur l'intérêt de considérer le HTTP comme un protocole
de transport dans les firewalls, par ce que le web change
"Rémy Sanchez" a écrit :
>Donc le DiffServ & co c'est une vaste fumisterie ? On s'est amusé à
>utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
>fait de QoS ?
Je n'ai jamais trop compris l'intérêt de DiffServ, il a les mêmes inconvénients
que ToS a priori.
Je vois 3 pos
On Thu, Nov 25, 2010 at 08:01:47PM +0100, Rémy Sanchez wrote:
> Donc le DiffServ & co c'est une vaste fumisterie ? On s'est amusé à
> utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
> fait de QoS ?
Moi je l'ai utilisé lorsque j'avais encore un ADSL avec un upload à
16 Ko/s.
>>> Michel Py a écrit :
>>> un large réseau interne ou tout est permis; en tant que FAI les
>>> données des clients sont privées, mais en tant qu'opérateur
>>> d'entreprise (ici) le réseau est le tien, pas besoin de demander
>>> d'autorisation pour sniffer le trafic des employés.
>> Christophe Bae
On 11/26/2010 12:56 PM, e-t172 wrote:
> Mon opinion, qui n'engage que moi, est que tu te trompes de problème.
> Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la
> VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton
> problème c'est que tes utilisateurs puissent s
Le 26/11/10, e-t172 a écrit :
> Le principal avantage est qu'il est impossible de tricher :
> l'utilisateur aura beau tenter de tunelliser ou de forger les champs ToS
> de ses paquets IP, ça ne changera strictement rien car tout est basé sur
> son adresse IP, qu'il est impossible de falsifier (enf
Mon opinion, qui n'engage que moi, est que tu te trompes de problème.
Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la
VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton
problème c'est que tes utilisateurs puissent se marcher sur les pieds,
c'est-à-dire que
On 11/25/10 20:01, Rémy Sanchez wrote:
Donc le DiffServ& co c'est une vaste fumisterie ? On s'est amusé à
utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
fait de QoS ?
Cela m'étonnerait fortement. L'utilisation du champs TOS des en-têtes IP
pour effectuer un marquage
Michel Py wrote:
Non il y a des utilisations valides, mais une chose est certaine:
> ni QOS ni rien d'autre ne vont transformer un petit tuyau en un
> tuyau plus gros. QOS, c'est la cerise sur le gâteau QUAND tu as
> suffisamment de BP. Quand le tuyau n'est pas assez gros, ne rien
> faire est s
2010/11/25 Rémy Sanchez :
> C'est quand
> même pas des clowns à l'IETF non ?
IPv6 ?
--
Mattieu Baptiste
"/earth is 102% full ... please delete anyone you can."
---
Liste de diffusion du FRnOG
http://www.frnog.org/
2010/11/25 Christophe Baegert
> Bonjour,
>
> Le 25/11/2010 23:30, Michel Py a écrit :
> > un large réseau interne ou tout est permis; en tant que FAI les données
> des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le
> réseau est le tien, pas besoin de demander d'autorisation
Bonjour,
Le 25/11/2010 23:30, Michel Py a écrit :
> un large réseau interne ou tout est permis; en tant que FAI les données des
> clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau
> est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des
> employ
> Guillaume Esnault a écrit:
> Cette discussion me met mal à l'aise.
Grandis. C'est une liste de FAI, l'interception et l'analyse des flux, même si
c'est souvent une Albanerie, ça fait partie du boulot. Et la requête originale,
même si tout le monde pense plus ou moins que ça ne servirait pas à
On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
> On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
> wrote:
>
>> 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
On 11/25/2010 11:52 AM, Rémi Bouhl wrote:
> Le proxy sert de cache donc évite de re-télécharger plusieurs fois les
> mêmes contenus, tout simplement? Bon, avec le "Web 2.0" c'est moins
> utile.
Même pas, vu qu'avec le web 2.0 tout le monde va sur les^Wle même site
(ça commence par face et ça finit
On 11/25/2010 11:20 AM, Guillaume Esnault wrote:
> Cette discussion me met mal à l'aise.
>
> Ce genre d'outil relève de l'écoute sur le contenu ou le langage
> (Layer7).
>
> C'est comme si nous faisions des écoutes téléphoniques automatiques.
> Selon ce qui est dit il serait fait certaines actio
Selon Rémi Bouhl :
>
> Le proxy sert de cache donc évite de re-télécharger plusieurs fois
> les mêmes contenus, tout simplement? Bon, avec le "Web 2.0" c'est
> moins utile.
On en reparle quand les protocoles de streaming à base de chunk seront
un peu plus répandus :-)
Et sinon, cette discussion h
Pour ne pas gérer la congestion, on évite la congestion.
Gérer la congestion est une solution onéreuse et complexe.
a+
On Thu, 25 Nov 2010 15:29:34 +0100, Pierre Chapuis
wrote:
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
wrote:
Bon et finalement, est-ce que la QoS sert à quelquechos
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
wrote:
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...
Bien résumé. Encor
Le 25/11/10, François a écrit :
> Pour revenir au sujet, puisque l'on parlait de voip et de skype, je
> crois savoir que skype peut utiliser le port 80 mais pas HTTP. et
> seulement en cas de filtrage sur d'autres ports.
Skype est conçu pour contourner à peu près tout ce qui est
contournable, et
J'ai entendu dire (sans retrouver la source écrite) que les écoutes
aléatoires et "anonymes" étaient autorisées. Et qu'en ce moment les
autorités en usent et abusent.
Pour revenir au sujet, puisque l'on parlait de voip et de skype, je
crois savoir que skype peut utiliser le port 80 mais pas HTTP.
Bonjour à tous,
Cette discussion me met mal à l'aise.
Ce genre d'outil relève de l'écoute sur le contenu ou le langage
(Layer7).
C'est comme si nous faisions des écoutes téléphoniques automatiques.
Selon ce qui est dit il serait fait certaines actions.
Certain organismes comme la NSA (Echelon)
Hé, moi j'ai une solution !
Un serveur, meme un vieux Pentium 75 devrait suffire, 4 Mo de ram, ca
tournera nickel.
Apres, un squid, un peu de poudre verte, et voilà.
On dit merci qui ?
...
Merci la poudre verte !
---
Liste de diffusion du FRnOG
http://www.frnog.org/
On 25/11/10 00:04, Rémy Sanchez wrote:
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
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 le
Le 25/11/10, Rémy Sanchez 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 "fouill
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,
Le 24 novembre 2010 23:19, Rémy Sanchez 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 pl
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote:
>
> On Wed, 24 Nov 2010 22:02:08 +0100, "Rémy Sanchez"
> 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 pas
On Wed, 24 Nov 2010 22:02:08 +0100, "Rémy Sanchez"
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. A
-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 fich
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
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote:
> 2010/11/24 Rémy Sanchez :
>> 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
>>
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 auss
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 es
2010/11/24 Rémy Sanchez :
> 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 facil
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
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
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
On Wed, 24 Nov 2010 17:33:16 +0100, "Rémy Sanchez"
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
On Wed, 24 Nov 2010 17:25:44 +0100, "Rémy Sanchez"
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 re
On Wed, 24 Nov 2010 17:23:37 +0100, "Rémy Sanchez"
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/...
> 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/
On Wed, 24 Nov 2010 16:26:22 +0100, "Rémy Sanchez"
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 en
Le 24 novembre 2010 17:15, Rémy Sanchez 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 circul
On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI
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
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 consta
On Wed, November 24, 2010 16:59, Rémi Bouhl wrote:
> Le 24/11/10, David Ramahefason 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 d
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èm
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 p
On Wed, 24 Nov 2010 08:25:14 -0800, "Michel Py"
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 p
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 garan
Le 24/11/10, 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
-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
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 f
On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl
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 équ
On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer
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
On Wed, 2010-11-24 at 16:59 +0100, Rémi Bouhl wrote:
> Le 24/11/10, David Ramahefason 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 d
Le 24/11/10, David Ramahefason 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 quan
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 l
oui, meme pour aller faire des recherches, ou
lire des articles sur le sujet...)
- Mail Original -
De: "Rémy Sanchez"
À: frnog@frnog.org
Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam /
Berlin / Berne / Rome / Stockholm / Vienne
Objet: [FRnOG] Firewall HTTP
B
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
--
On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot
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 fa
> 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é
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ébi
-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
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
Le 24/11/10, Rémy Sanchez 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'
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 ht
;est le
webmail le moins filtré en entreprise...
- Mail Original -
De: "Rémy Sanchez"
À: 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 t
On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN
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 r
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 :
> Bonj
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 cont
83 matches
Mail list logo
