Traffic Shaper & Limitation Bande Passante
-
Comme tu l'as bien compris, QoS et "bandwidth control" sont 2 choses différentes.
Mais comme tu évacues un peu vite sans vraiment de détail les pistes que tu as regardé, difficile de vraiment t'aider.Quelques pistes supplémentaires (peut-être):
Est-ce que ça répond à ton besoin ?
Est-ce bien ce que tu as testé avec Squid et qui à priori "ne marche pas" ? -
Tout d’abord merci à vous 2 pour vos réponses :)
Merci jdh pour cette précision. Mais lorsque je suis sur Traffic Shaper, dans l'espace ou je créé mes règles pour la QOS, on me parle bien de port source et de port destination.
Il me semblait donc qu'il fallait créée une règle qui dit : tous les paquets DSCP "x" venant des ports xxxx à xxxx, sur les protocoles TCP/UDP et a destination "any" sont affectés à la queue "ex:qAudio". Je faisais fausse route ?Petite précision, pour SQUID j'avais installé le package et je le faisait donc avec interface graphique depuis pfSense. Pour limiter la BP j'utilisais "Traffic Managment".
Pour chris4916 pour tes infos, je ne sais pas si "DelayPool" en ligne de commande correspond au "Traffic Management" en interface graphique.
Je voulais éviter de rentrer en ligne de cmd car se n'ait vraiment pas mon point fort, mais je pense qu'il va falloir que j'y mette les mains.Sur le principe, c'est bien ce que je souhaite faire "Limiter la BP par IP" car pas besoin d'authentifier les users.
Je vais étudier ça plus en profondeur, merci à vous deux en tout cas !
-
Pour chris4916 pour tes infos, je ne sais pas si "DelayPool" en ligne de commande correspond au "Traffic Management" en interface graphique.
Je voulais éviter de rentrer en ligne de cmd car se n'ait vraiment pas mon point fort, mais je pense qu'il va falloir que j'y mette les mains.Je ne sais pas non plus mais il te suffit d'essayer et de regarder ensuite le résultat dans la conf ;)
Sur le principe, c'est bien ce que je souhaite faire "Limiter la BP par IP" car pas besoin d'authentifier les users.
Oui j'ai bien compris que ça correspond à ton besoin, raison pour laquelle je te donne ces liens ;)
Ce qui m’interpelle un peu quand même, c'est que tu dis "j'ai essayé avec le proxy et toujours pareil" ce qui n'est quand même pas très précis au niveau du problème que tu rencontres avec la configuration de la limitation de trafic avec Squid.
-
Enfaite le gros soucis que j'ai, c'est que le service SQUID s'arrête juste après que je l'ai lancé..
Pour info j'ai la version 2.3.2 de pfSense, et SQUID en version 3.5.
Squid est installé depuis le package pfSense car j'ai une erreur lorsque je fais un "apt-get install squid" cela me met "command not found".
Et impossible de trouver le fichier squid.conf. Dans /var/squid je trouve seulement 4 dossiers (acl, cache, lib, logs).
-
Salut salut
Attention apt-get est un commande linux plus exactement débian, tres normal de ne pas pouvoir faire une installe de squid sur un pf avec cette commande là.
De plus il est préférable de mettre en place un squid sur une machine (physique ou virtuelle) sur la zone lan de votre réseau plutot que sur le pf lui meme.
Vous y gagnerez en efficacité et en sécurité.
- en efficacité par plus de paramètres à votre disposition pour gérer votre problématique.
- en sécurité car seul les sur votre lan seront impacté après avoir dit a pf que les utilisateurs doivent passer par le port de squid qui va bien pour toutes requêtes vers les le port 80 et 443 et ou 445.
Un pare feu est un pare feu, évitons de lui rajouter des trous potentiels dans la sécurité d'un tel outils.
Cordialement.
Cordialement. -
Outre la perspicacité de Tatave (apt-get sur BSD ?), le conseil d'un proxy est très judicieux !
Il et plus que probable que les règles de trafic shaping ne vont s'appliquer QUE sur des flux traversants.
Donc si Squid est installé sur le firewall, les règles n'auront, sans doute, aucun effet sur le trafic généré.
(Encore une raison de ne pas mettre un proxy sur un firewall !)
Par ailleurs, la config précise de Squid pour jouer sur les pools n'est sans doute pas inclus dans l'interface du package, ce qui justifie encore un proxy séparé. -
J'ai essayé aussi avec le package SQUID en mettant un proxy transparent, mais toujours pareil.
Une fois que tu auras vérifié que le proxy répond, fonctionnellement, à ce que tu veux obtenir en terme de limitation de bande passante par IP, il y a un point important qu'il te faudra prendre en considération:
- en mode proxy transparent, il n'y a forcément pas d’authentification possible de la part des utilisateur
- le mode proxy explicite (non transparent) ne signifie pas pour autant que l'utilisateur doivent s'authentifier
mais en mode transparent, les requêtes ne passent pas par le proxy, sauf à configurer SSL-Bump (MITM) et donc il n'y aura pas de limitation de bande passante possible.
La confusion vient que souvent proxy explicite et authentification sont associés bien que ce ne soit en aucun cas obligatoire.
-
Merci à vous pour ces informations complémentaires !
En effet, j'avais lu qu'il n'était pas forcément conseillé d'installer Squid sur le firewall surtout par rapport à l'aspect sécurité. (Un process de plus qui tourne sur un firewall = risque de faille supplémentaire) mais à quel pourcentage évalue t-on ce risque supplémentaire ? Chacun peut avoir son avis là dessus.
Par contre il est vrai que si les règles de Squid peuvent ne pas s'appliquer à cause de celles de Traffic Shaper, dans ce cas il faut vraiment que je me tourne vers une vm consacré à Squid.
Qu'elle distribution me conseillerez vous ? Je pense m'orienter vers une Debian qui m'a l'air d'être une solution stable, avec un cycle de dev assez long donc pas de MAJ toutes les semaines.
Pour rebondir sur ce que viens de dire chris4916, pour un proxy explicite sans authentification il faudrait donc utiliser Kerberos comme montré ici : https://doc.ubuntu-fr.org/tutoriel/comment_mettre_en_place_un_proxy_squid_avec_authentification_active_directory
Qu'est ce qui parait le plus facile à configurer ?
Merci encore !
-
En effet, j'avais lu qu'il n'était pas forcément conseillé d'installer Squid sur le firewall surtout par rapport à l'aspect sécurité. (Un process de plus qui tourne sur un firewall = risque de faille supplémentaire) mais à quel pourcentage évalue t-on ce risque supplémentaire ? Chacun peut avoir son avis là dessus.
Par contre il est vrai que si les règles de Squid peuvent ne pas s'appliquer à cause de celles de Traffic Shaper, dans ce cas il faut vraiment que je me tourne vers une vm consacré à Squid.
Je ne vois pas pourquoi les règles de Squid ne s'appliqueraient pas à cause de traffic shaper, ou alors je n'ai pas tout compris.
Qu'elle distribution me conseillerez vous ? Je pense m'orienter vers une Debian qui m'a l'air d'être une solution stable, avec un cycle de dev assez long donc pas de MAJ toutes les semaines.
C'est une quesiton de goût. Moi j'aime bien Debian également ;)
Pour rebondir sur ce que viens de dire chris4916, pour un proxy explicite sans authentification il faudrait donc utiliser Kerberos comme montré ici : https://doc.ubuntu-fr.org/tutoriel/comment_mettre_en_place_un_proxy_squid_avec_authentification_active_directory
non pas du tout. J'ai dû mal m'exprimer car tu n'as rien compris.
Il ne s'agit pas de "masquer" l'authentification par la mise en oeuvre d'un SSO via Kerberos (qui est effectivement une solution) mais de dire que proxy explicite et authentification sont 2 choses différentes.Tu peux tout à fait mettre en oeuvre un proxy explicite et ne pas demander du tout aux utilisateurs de s'authentifier, ni même te soucier de leur identité.
-
J'ai dit cela en rapport au message de jdh "Il et plus que probable que les règles de trafic shaping ne vont s'appliquer QUE sur des flux traversants.
Donc si Squid est installé sur le firewall, les règles n'auront, sans doute, aucun effet sur le trafic généré" A moins que j'ai mal interprété ce qu'il voulait dire..Peux tu me donner des indications chris4916, concernant la mise en œuvre d'un proxy explicite sans authentification des users ?
Étant donné que le traffic passera par ce proxy, si celui-ci venait à tomber, les users n'aurait plus de sortie vers l'extérieur je me trompe ?
-
La mise en place du proxy "explicite" est simple et n'est pas liée à l'authentification.
Vu de très très loin, il "suffit" de configurer ton proxy en mode explicite, avec un port d'écoute (par exemple 3128) et ensuite de configurer les clients (les browsers) pour qu'ils accèdent explicitement (d'où le nom) au proxy.
Ceci doit s'accompagner, au niveau du FW, par l'interdiction de l'accès à internet sur les ports 80, 443 etc… en direct. Seul le proxy peut traverser (si le proxy n'est pas sur pfSense).Techniquement, ce n'est pas plus difficile que ça et n'implique pas que les utilisateurs doivent s’authentifier.
Ceci étant, en lisant mon message, tu comprends qu'il faut aller configurer chaque poste utilisateur, ce qui n'est pas acceptable si tu as beaucoup de clients.
La solution à cette problématique passe par la diffusion d'un proxy.pac sur un serveur web internet et la mise en œuvre de WPAD pour dire aux navigateurs où trouver ce proxy.pac.Mais, un mon humble avis, il faut faire les choses dans l'ordre, sans brûler les étapes:
- d'abord un proxy en mode explicite configuré "à la main sur le browser"
- un proxy accédé depuis un proxy.pac configuré à la main sur le browser
- WPAD pour ne pas avoir à configurer proxy.pac sur le broser
Si tu as un proxy dédié (i.e. pas sur le FW), tu peux quand même y appliquer des règles de limitation de bande passante, telles que décrites plus haut.
Le choix dépend vraiment de la taille de ton pfSense (hardware, disk), de tes contraintes sur une approche "UTM" plutôt que "best of breed" (ou le contraire ;))Un proxy dédié est globalement plus simple à gérer et présente à mon avis plus d'avantages, mais c'est un débat un peu en dehors de ta question initiale 8)
-
Merci de tes précisions Chris !
J'ai fait un point avec mon responsable hier, et le programme à légèrement changé.
En effet, le fait d'avoir une distrib Linux à paramétrer et troubleshooter en cas de défaillance ne lui plait pas. Nous sommes que 2 au SI, et il est vrai que nos compétences sont limitées en ce qui concerne le monde libre et ces lignes de cmd.
Donc je suis "obligé"d'utiliser le package SQUID directement sur pfSense, même si j'ai discuté avec lui de ce qui est conseillé, des risques de sécurité, etc..
Pour l'instant il veut voir le fonctionnement en maquettage et après il avisera la mise en prod.Pour le pfSense, il se trouvera sur une machine virtuelle "Hyper-V" sans vraiment de limite au niveau hardware et pour le disque il faut que j'investisse un peu avec une logiciel de partitionnement car j'ai créé un disque virtuel de 5Go mais pfSense m'en reconnait que 4Go.
Et il voudrait aussi récupérer des logs dans le but de savoir qui utilise la bande passante et pourquoi (téléchargement iso, écoute musique etc,…) lorsque celle-ci est surchargé.
Donc je repars dans mes recherches, afin de trouver la meilleure solution et prenant compte les différentes contraintes évoqués ci-dessus.
Si vous avez des pistes, n'hésitez pas ! ;)
-
Puisque vous êtes peu expérimenté (1ère année de contrat pro), il est utile que vous partiez sur de bons principes (fruit de l'expérience) :
- un firewall ne devrait pas être virtualisé : mieux vaut un vieux pc non virtualisé à une VM dont on ne maitrise pas bien les conséquences de la virtualisation
- un proxy sollicité ne devrait pas être sur le firewall : à partir d'une certaine charge (>10 utilisateurs, ligne haute vitesse, …) c'est vraiment à recommander
- un proxy peut être virtualisé sans problème
- la compréhension des termes 'proxy transparent', 'proxy explicite', et leur conséquence devrait être connu : de multiples fils existent
- méfiance avec les 'normes microsoft' : le traffic shaping est normalement basé sur le protocole donc port cible !
- le traffic shaping est peu simple, alors que Squid dispose déjà de solutions intéressantes
- un proxy externe (=dédié) permet une configuration plus fine qu'un interface web, mais exige de parcourir la doc (forcément ...)
Il est essentiel de faire la différence entre un test et une production !
Avec les infos que je lis, je dirais : en prod, le firewall est physique, le proxy est dédié (et virtualisé).
Vous risquez de tirer de mauvaise conclusions, faute de maitrise tant des contraintes induites par les choix déjà faits et faute de maitrise des protocoles ...
-
Bonjour à tous,
J'ai avancé un peu de mon côté en prenant en compte ce que vous me dites mais que je ne peut malheureusement pas toujours appliquer.
Pour faire un point de l'avancé, j'ai paramétré "Limiters" afin de limiter la bande passante par IP. Cela fait un moment que ça tourne en phase de test et tout est ok.
Pour la partie priorisation de flux, SQUID n'est pas utilisable en même temps que Limiters. J'ai lu que ça fait depuis une certaine version de pfSense que les 2 ensemble de peuvent pas fonctionner.
J'ai donc paramétré Traffic Shaper pour faire ma QOS.
Voici la liste de mes files d'attentes :
Quand je regarde de plus près, je vois bien les flux passer sur les parties ACK et Default mais rien dans mes parties Audio, Téléphonie etc..
Sur la partie LAN, j'utilisais les ports sources des postes (apparemment Traffic Shaper est basé sur le port cible comme vous m'avez dit, mais dans ce cas à quoi sert le "port source" dans le paramétrage ?) Il faut donc que je trouve une autre solution, car mes trames sont taguées lorsqu'elles partent des postes.
Mais sur la partie WAN, j'utilise bien l'IP de mon serveur Skype avec les bon ports, mais toujours rien qui apparait dans le graphique et les logs.
Je tourne toujours en rond et commence a désespérer..