Traffic shaping qos

Florian22

et je ne vois d'ailleurs aussi qu'un seul pool gateway dans tes rules.

tu ne differencies donc pas ?

tu dois avoir des erreurs exotiques en SSL, avec des connexions qui coupent bruatalement.
tu ne peux pas inserer le traffic ssl dans ton pool "loadbalance" surtout si tes 8 modems sont en tier1

proxiel

Effectivement nous avons un seul pool avec l'ensemble des gateways en tier 1. Nous n'avons pas de problèmes grace à l'option "Sticky connection" qu'on trouve dans system miscellaneous. Seul certaines applications qui utilisent plusieurs serveur cible peuvent nous poser des problèmes.

Le problème est que le surf avec ces règles est très lent voir impossible. Nous nous retrouvons avec des timeout que nous n'arrivons pas à expliquer.

Florian22

OK,

Ben je te remercie de prendre 10-15min a faire le formulaire, et surtout de faire ton schema "pieuvre"
a savoir

DU POSTE CLIENT SUR LE LAN ==================> toute la traversée ======> jusqu'auX WANs

et concernant le sticky, je ne pense pas que ce soit aussi simple, peut etre tatave pourra nous en parler.

a savoir : Faut il faire un sous groupe pour le SSL avec tiers 1 2 3 … et le trigger failover (donc dédier une seule interface de sortie a chaque fois rien que pour le ssl)

ou faire tout en tiers1 et activer sticky.

Florian22

le probleme avec sticky c'est que ca "lie" les states d'un client avec un WAN, jusqu'a expiration des states, et qu'il me semble que ca ne "balance" pas les states sur differents WANs.

en gros: la premiere requête ira sur un WAN, puis toutes les autres iront sur le meme, jusqu'a ce que le client n'ait plus de states ouvertes dans pf. (ce qui n'arrive jamais)

donc concretement : si tes utilisateurs sont résidentiels, ils auront le même WAN, jusqu'a ce quils ferment leur pc, et reviennent sur le réseau.

donc : au mieux, tes clients changeront de WAN souvent (si l'utilisateur a un profil, : "je viens, je pars, je ferme tout, je reviens"
au moyen pire, ils changeront de WAN chaque jour : "bon je vais me coucher, je ferme tout" (les states expirent)

au pire, ils restent quasiment tout le temps aggripés au meme wan 'genre celui qui laisse son pc tout le temps allumés, les connexions permanentes.

et beaucoup font cela !, ils sont plus nombreux qu'on le pense, moi par exemple dans radius je les identifie facilement, ce sont les seuls qui font tout le temps des sessions de 24 heures piles, ensuite l'appareil réouvre de lui meme une nouvelle session.

tu as des gens qui ont des connexions permanentes de 3-4-6 jours, autant de temps ou des states existent, et ou ton client va pas changer de WAN.

et ca perso, je trouve ca un peu pourri.

Tatave

Salut salut

@flo

même mes clients je les rembarre de la même manière, le plus amusant c'est qu'ils reviennent tous la tête entre les guibolles pour ne pas dire autre chose, et surtout quand ils veulent tout pour rien, que la résolutions est facturé au temps passé, ca piaille à réception de la douloureuse mais quand on leur montre les echanges de mails et le temps perdu pour avoir les info et tester x ou y idée ) et qu'on leur montre par a + b en passant par c que s'il avait bien tout donné au bon moment et pas comme ils l'ont fait, la note serait beaucoup moins salée.

@pour notre cornichon ici présent
je dirais effectivement on schémas et surtout pas mué (ip factices s'il veux mais quelle garde la logique de son archi et par piiter un vrai poste de demande d'entre aide, et pas un bout par ci pas la.

==> me venge sur un boite de tagada, Na

ps: si certain aime se faire taper dessus comme cela, pourquoi pas, mais a la longue cela use.

Florian22

Tu es d'accord avec moi concernant le stickky?

proxiel

Bonjour,

Voici un schéma qui résume l'ensemble de mon réseau.
L'ensemble des modems sont connectés sur des lignes du même opérateur. (Aucune ligne en PPPOE du fait du problème de gateway similaire)

Nous avons un seul pool gateway avec tout en tier 1.

Sur ça nous n'avons absolument aucun problème et l'infra fonctionne depuis plusieurs années maintenant.

Nous avions testés au départ avec du "Wizzard" MultiWan + Single Lan mais avons abandonné de faire de mettre le traffic shapping aussi sur les WAN car nous avions des problèmes dû aux ports aléatoires de retour.

Le problème que nous avons :

Nous créons 1 qInternet sur le Lan dans laquelle nous mettons des "Sous queues" :
qACK Priority 6
30 % de la bande passante totale

Cette queue nous l'atribuons à l'ensemble des règles pour le ACK

Nous ajoutons ensuite à la queue internet une qOthersHigh dans laquelle nous mettons les ports de 1 à 1024 et plusieurs ports connus de vpn, les ports 8001 à 8100…

Et nous ajoutons enfin une qP2P en default.

Nous y attribuons 3 Mbits

Schema final :

Lan
qInternet 120Mb
qACK 30% Minimum
qOthersHigh 60% Minimum
qP2P 3Mo (Default)

Voici l'ensemble de notre configuration.

Merci,

QOS.png_thumb

Florian22

"le probleme que nous avons est:"

=> oui ok et donc? ce probleme quel est il? quelle est la symptomatique?

concernant le stycky, on en reparlera mais je suis sur

1/ d avoir lu quelque part que ca generait le comportement de "fixation d'un client sur une sortie"
2/ de l'avoir moi même expérimenté (essai, + kill des states + essai)

=> après c'est a vous de voir si ce comportement peut poser PB. a savoir, que vous allez avoir des utilisateurs qui vont stagner sur un de vos modems.
(c'est grace a ce phenomene que vous n'avez pas de pb avec SSL et les modems en tiers 1 monogroupe)

Juve

Florian a raison, le fonctionnement du sticky est le suivant :

a la première connexion nécessitant un acheminement par une gateway, pf réalise l'élection de la gateway puis inscrit dans une table l'association client <-> gateway avec le timestamp du moment de l'élection.
a chaque nouvelle session, pf évalue cette table pour savoir si une adhérence à une gateway existe déjà. Si l'entrée existe, le timestamp est mis a jour.
pf possede un thread d'arriere plan qui toutes les secondes évalue cette table. si la différence entre le moment de l'évaluation et le timestamp est suprérieure a la valeur du timeout(configurable). Alors l'entrée est supprimée et une nouvelle élection de gateway aura lieu au prochain acheminement.

En résumé : sticky = client collé à une gateway.
Il est préférable d'avoir des regles en amont pour HTTPS par exemple, utilisant des pool failover pour ces protocoles. En jouant sur les masques côté source et plusieurs règles/pool, on peut tout a fait obtenir un loadbalancing équitable.

Bon courage.

Florian22

@Juve:

Il est préférable d'avoir des regles en amont pour HTTPS par exemple, utilisant des pool failover pour ces protocoles. En jouant sur les masques côté source et plusieurs règles/pool, on peut tout a fait obtenir un loadbalancing équitable.

Bon courage.

salut juve.

peux tu m en dire plus? (même si c'est hors sujet)

tu veux dire que si par exemple tu as 5 sorties,
et que tu as 5 origines réseau (vlan par ex)

tu peux simuler un éclatement par les regles et mettre le tier 1 different pour chacun des wan vis a vis du ssl
et mettre les 4 autres sur chacun des pools en tiers 2 .. 3 ..etc

c est pas con du tout!!! ca m etais pas venu une seconde a l esprit !!!!!!!!!! lol je me sens con la

–-
concernant le demandeur fra1000

on est bien d'accord, le stiky lui evite d'avoir donc de gros pb avec le controle d'origines/session sur ssl

je ne sais pas encore quel est la symptomatique de son pb, mais avec sticky activé,
il ne dispose que d'un balancing basé sur ce que tu décris (timestamp, assignation wan)

et donc il se retrouve avec des requêtes qui ne se distribuent pas, et ne maitrise pas qu'il puisse avoir deux ou trois utilisateurs a requetes gourmandes qui seraient aggripées sur le meme wan

(j espere que je me fais comprendre ;) ) mdr

proxiel

@Florian22:

"le probleme que nous avons est:"

=> oui ok et donc? ce probleme quel est il? quelle est la symptomatique?

Concrètement, un fois les queues créés et les floating en place, tout le traffic vers le "wan" time out.

Ping, web, etc…

(Nous avons essayé de placer les floats alternativement sur les Wans, le lan, wans+lan.)

Concernant le Sticky, oui effectivement, c'est la solution simple pour le SSL (particulièrement le HTTPS) et le multiwan.

Florian22

vous avez donc trouvé le problème, puisque il apparait avec VOTRE configuration du shaping (donc érronée)

quel type de réseau exploitez vous? (conso, profil user, profil conso, étendue)

vous avez une foule de regles, cela parait étonnant

Juve

@Florian22:

tu veux dire que si par exemple tu as 5 sorties,
et que tu as 5 origines réseau (vlan par ex)

tu peux simuler un éclatement par les regles et mettre le tier 1 different pour chacun des wan vis a vis du ssl
et mettre les 4 autres sur chacun des pools en tiers 2 .. 3 ..etc

c est pas con du tout!!! ca m etais pas venu une seconde a l esprit !!!!!!!!!! lol je me sens con la

Oui tu as compris.

Florian22

@Juve:

Oui tu as compris.

OK ;)

et dans un cas de double Nat comme celui la ?

je schematise:

1 2 3 4 5

lan wan lan wan's
<–------------------------------------------------------------------------------------------------>
CLIENT ++++++++ PASSERELLE +++++++ BALANCER --- MULTI WANS
<-------------------------------------------------------------------------------------------------->
dhcp+proxy dhcp bridges

<<------------------------->>
entre la et la

comment tu ferais pour propager la reconnaissance de sources sachant que 4 voit tout le trafic comme si il ne venait que de 3 ?

je sais c'est atypique, mais ca provient d'une utilité qui fait que Squid ne fonctionne pas en multi
donc il est mis sur la passerelle. qui contient également des fonctions de portail captif

EA1000

@Florian22:

vous avez donc trouvé le problème, puisque il apparait avec VOTRE configuration du shaping (donc érronée)

quel type de réseau exploitez vous? (conso, profil user, profil conso, étendue)

vous avez une foule de regles, cela parait étonnant

Bonjour Flo,

Je suis Ed un collaborateur de Fra.

Effectivement, le problème venait de la configuration des règles PFs, c'est sur que si on les mets en "Pass" et pas en "Queue" ça risque pas de marcher, RTFM(enu)… RTFMM même que...

Enfin au moins maintenant ça fonctionne bien. Merci pour vos idées en tout cas.

Pour répondre à ta question:

Nous fournissons un service d'accès au web dans des lieux publics.

L'étendue varie d'une dizaine de postes clients à plus d'un centaine en fonction des sites.

Nous avons sur nos pfsense le portail captif (qui bride la bp per user.), l'ensemble des règles nous permet de restreindre le service DNS à celui du PF (on a une couche de filtrage par le DNS), ainsi que de permettre l'accès à l'infra à différents prestats.

voilà voilà.

Sinon, juste pour comprendre précisément, sticky va "coller" tout le trafic d'un client à un wan, jusqu'à ce qu'il n'y ai plus de connections pour ce client?

Et de bonnes fêtes à vous au fait ^^

Florian22

quelle est la politique de service de votre réseau (j'entends par la : quels sont les flux autorisés par vos CGV et quels sont les flux que vous ne souhaitez pas voir sur votre réseau)

exemple : VPN, exemple, SMTP etc..

je vais vous repondre dans la globalité, et vous préconiser en suivant

EA1000

De façon générale, tout est autorisé sauf le P2P.

Concrètement, c'est la raison qui nous a poussés à mettre en place la QoS, à savoir laisser le trafic des "ports bien connus" passer, et bottlenecker le reste.

Au demeurant, on se doute bien qu'il suffit au client d'avoir un VPN pour faire ce qu'il veut (vu que qu'on autorise les VPNs ;D )…

Et bon réveillon à vous, avec modération! :D

Florian22

par defaut le paranoiaque que je suis fait l'inverse :

bloquer tout > autoriser ce que l on veut.

je vous invite a retirer vos rules de shaping qui sont non fiables (objet du post)
pourquoi ne pas confier la QoS a vos switches et AP, les cisco le font.

et de bosser via des rules, et pool de rules, directement sur la toute premiere interface coté clients.

par ailleurs, vous ne pouvez bloquer le p2p (sans vous aventurer dans le réseau style MACDONALDS (ports 80/443 only) et encore.. vous et moi savons que c'est contournable tout ca..)

pour ce faire, faites le via dns, en interdisant les autres dns, et en vous appuyant sur un service de blackliste dns, par categories,

bloquez le p2p (ce qui aura pour effet de mettre un terme au trackers et au annuaires)
bloquez les categories, proxy, vpn,

bloquez le vpn par rule
faites du cas par cas, si un user veut son VPN université, dérogez le. dites lui que vous le dérogez, dites lui que si l'infra VPN Université évolue, il devra vous recontacter pour MaJ, faites vous mousser en rendant un service dérogé.

a/ les VPN restent bien bloqués
b/ son VPN (innoffensif) est dérogé
c/ ca marche pour lui, vous rendez un service

=> par ailleurs, si un utilisateur veut utiliser un VPN, par defaut whynot, ce n est pas votre responsabilité qui sera engagée pour le trafic encapsulé effectué
-> Bon débarras, vous ne faites que transporter, collecter.
-> Attention, si le réseau de destination est pourri, c'est vous qui mangerez => les utilisateurs ne voient generalement peu plus loin que le bout de leur nez
-> Vous vous obligez donc a gerer les demandes SAV pour mauvaises qualité de lignes pour cause de destination VPN a chier -> travail en +

vous ne pouvez rien faire de plus, et de toutes facons en cas de pb, via ces methodes, vous remplissez vos obligations HADOPI en termes de mise a disposition d acces

(je le sais, étant été une fois ya longtemps contraint de me justifier sur un réseau en particulier qui cumulait a cause d'un utilisateur précis, de nombreux mails de procedures graduée.

n'encombrez pas votre réseau, vous ne pouvez rien faire pour empecher un utilisateur qui veut a tout prix.
et en sur encombrant le réseau, en le "nord coree-isant" vous vous ferez mal voir de ceux qui "ne veulent pas a tout prix"

faites juste le max pour vous exonnerer

n'hesitez pas a flanquer dehors un utilisateur qui ne joue pas le jeu,
mieux vaut UNE resiliation unilaterale, qu'un RENSSENTI GLOBAL des autres, parce que vous nord coreeisez le réseau,

la hadopi n'a aucun pouvoir, le seul pouvoir qu'elle a, c'est d aprecier votre bonne foi, ou votre insuffisance, et vous "faire poursuivre" ou pas, ou se retourner contre l'abonné que vous aurez bien identifié en étant pas en "insuffisance".

la liste des methodes est longues

-CGV
-Mail automatique de rappel aux CGV lorsque le proxy detecte un truc (mot clé, extension fichier)
-Anti contournement (sites proxy, vpn) dans le max du possible (sans rentrer dans le style coree du nord)

blackisting dns (confiez cela a opendns ou la concurrence, faire des blacklistes, et pire, les tenir a jour, ce n est pas votre metier)
identifier l user a chaque mail hadopi
mettre en demeure l user, l informer quil viole les CGV, l informer de la proc hadopi.
garder trace de l incident pendant 6 mois (reset hadopi)

si vous faites cela, il ne peut rien vous arriver, la hadopi ne PEUT pas vous faire poursuivre, vous n etes pas de mauvaise foi quant aux obligations d'empechement

(même si la hadopi a un discours du style '' vous etes tenu d'empecher, vous n'y avez pas reussi, c est de votre faute''

clairement non.

–
en fait vous l'aurez compris, tout ca est la pierre angulaire du dilemme qui est présent sur chaque réseau commercial
(et encore plus sur les réseaux, a population jeune, contenus-vores, peu fortunés, extremement exigeants)

A => Se proteger juridiquement
B => Proteger la qualité de service face aux trafics qui non seulement engagent votre responsabilité, et que vous devez transporter, et qui consomment des ressources globales au dépit des bonnes ressources, empecher que A-C-D atteigne B

C => Proposer un réseau le moins réstreint possible

D => Le restreindre au maximum possible en ayant l'art que ca ne puisse etre "vu/compris" que par 2-3% des utilisateurs
(les geeks, les grandes gueules qui ont tout vu et savent tout)

E => Se faire bien voir (etre vu comme un réseau fiable) par les 97% autres, (les rentables)
pour sefaire bien voir, on actionne "B"

ABCDE - pierre angulaire chiante, mais vitale dans un réseau ou les usagers ne sont pas QUE des usagers, mais des clients.

Tatave

salut salut

je dirais +1
et rajouterais un F

dire ok je le fait mais vous me signez un papier votre demande et qui vous engage nommément en cas de problème et que cela me dégage de toutes responsabilités

Florian22

nan mais tatave quand tu y penses, combien de trous ducs vont sur vpnbook.com ou autre site du style et se font bourrer le mou, et utilisent ca non stop ?

c est insecure
ca degrade potentiellement la qualité globale de la ligne (ressenti utilisateur)
ca genere des retours service client

moi c est pour cela que j interdis le VPN, je ne les autorises que lorsqu ils sont legitimes, travail, fac..
cas par cas.

–
pour mesurer l'ampleur du probleme, il suffit de voir combien de postes clients executent cacaoweb.exe
et entendre la réaction de je m en foutisme quand tu expliques au gens qu'ils ont gagné un formatage avec cette merde

les gens veulent globalement le beurre et l argent du beurre, souvent ils croient tout savoir.
interdire les VPN d anonymisation ultra mutualisés, et hors de controles

c est autant se rendre service que leur rendre. quid de la protection des données? quid de la qualité de service?

tu as des gens qui utilisent des DNS basés a l autre bout de la terre, va leur expliquer ca... t es fichu d avance, ils aiment pas qu on critique leur materiel..
lol

mieux vaut interdire l'utilisation de ce genre de choses, et forcer l homogenéisation
surtout sur des réseaux " de facs, de résidences, de travail" bref, tu m as compris

en plus tu detectes pleins de choses bizarres en faisant comme ca,
tu n imagines pas combien de retours nous avons eu, lorsque nous avons bloqué les DNS tiers

combien d'appareils dégueulasses, avaient des reglages statiques, de DNS, alors que l user ne sait meme pas ce que sait qu'un DNS

combien d'appareils avec processus malveillant, surfaient SUR NOS RESEAUX -- en NOTRE NOM -- avec des DNS de merde vereux aux états unis.

tu as beau dire que c est pour ca que le surf était finalement lent (sur nos réseaux)
tu nes que rarement cru. et ton image "fiabilité réseau" en a pris un coup