Traffic shaping qos



  • Bonjour,

    Malgré tous nos efforts et de bonnes connaissances pfsense nous n'arrivons pas a configurer correctement le traffic shapping en multiwan. les résultats ne sont pas satisfaisants et aléatoires ou de simples sites mis en queue hight sur le port 80 ou 553 n'arrive pas a s'afficher.
    Nous recherchons donc un expert pour nous y aider.

    la configuration :
    serveur dell R220/xeon/8go de ram/4 à 10 wan en adsl orange/1xGBIC - PFSENSE 2.0.3 - switch hp 1910-16g pour les wan et le lan

    merci

    FR



  • je sors mon popcorn ;)

    tu vas te faire recevoir toi dans pas longtemps hahaha

    be patient



  • Salut salut

    @flo

    fait peter les cahuette ?

    @ fra1000
    Heu comment dire ?

    Vous vous foutez de nous ?
    Vous nous prenez pour des asperges ? des madames Hirma ?

    Dans ces conditions débrouillez vous dans vos recherches.

    En passant tous forums ont leurs règles, coutumes, et modes de fonctionnement. les respectez vous, poussez vous cette question en premier lieu, j'en ai plein de dos de voir ce type de demande de bénicuicui qui attendent la béquée.

    NON CORDIALEMENT

    (pas donné fin le ptit florian ^^)



  • pardon c'est un peu imprécis…mais un peu de tolérance les gars quand même...

    j'ai ajouté qq fichiers avec la conf du shaping

    bien le merci

    ps : les cahuetes et les popcorn c'est pour moi !

    ![Lyon AT traffic shaping.jpg](/public/imported_attachments/1/Lyon AT traffic shaping.jpg)
    ![Lyon AT traffic shaping.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping.jpg_thumb)
    ![Lyon AT traffic shaping1.jpg](/public/imported_attachments/1/Lyon AT traffic shaping1.jpg)
    ![Lyon AT traffic shaping1.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping1.jpg_thumb)
    ![Lyon AT traffic shaping2.jpg](/public/imported_attachments/1/Lyon AT traffic shaping2.jpg)
    ![Lyon AT traffic shaping2.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping2.jpg_thumb)
    ![Lyon AT traffic shaping3.jpg](/public/imported_attachments/1/Lyon AT traffic shaping3.jpg)
    ![Lyon AT traffic shaping3.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping3.jpg_thumb)
    ![Lyon AT traffic shaping4.jpg](/public/imported_attachments/1/Lyon AT traffic shaping4.jpg)
    ![Lyon AT traffic shaping4.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping4.jpg_thumb)
    ![Lyon AT traffic shaping5.jpg](/public/imported_attachments/1/Lyon AT traffic shaping5.jpg)
    ![Lyon AT traffic shaping5.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping5.jpg_thumb)
    ![Lyon AT traffic shaping6.jpg](/public/imported_attachments/1/Lyon AT traffic shaping6.jpg)
    ![Lyon AT traffic shaping6.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping6.jpg_thumb)
    ![Lyon AT traffic shaping7.jpg](/public/imported_attachments/1/Lyon AT traffic shaping7.jpg)
    ![Lyon AT traffic shaping7.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping7.jpg_thumb)
    ![Lyon AT traffic shaping8.jpg](/public/imported_attachments/1/Lyon AT traffic shaping8.jpg)
    ![Lyon AT traffic shaping8.jpg_thumb](/public/imported_attachments/1/Lyon AT traffic shaping8.jpg_thumb)



  • Oui, c'est cela oui et en plus il insiste le bougre.

    Que dire….

    ha si ...

    vous avez un FORMULAIRE, oui non ? a première vu cela va donner un dialogue de mué qui montre à un aveugle qu'un sourd les écoutes



  • hihihi

    je te l avais bien dit @fra que t allais te faire rentrer dedans.

    @tatave

    la prochaine fois ^^ la j'ai tout gloutonné le popcorn tout seul devant tes "non cordialement"! ^^



  • @fra1000:

    pardon c'est un peu imprécis…mais un peu de tolérance les gars quand même...

    j'ai ajouté qq fichiers avec la conf du shaping

    bien le merci

    ps : les cahuetes et les popcorn c'est pour moi !

    je veux pas foutre ma merde mais:

    "j'ai donc besoin d'un expert"

    enfin, bon c est vrai que par ecrit le ton fait difficilement la musique,
    Mais:

    si tu te fais rentrer dedans, c est parce que 1/ tu donnes aucun détails  2/ tu dis de manière détendue de la criniere "J'ai donc besoin d'un expert"

    au moment ou j'ai attrappé mon popcorn, je me suis dit:

    "mais attend, le gars, il croit quoi?  quil est au SAV Pfsense?  …  a moins que ce soit @tatave qui encaisse les "support subscriptions"  ce cachottier.

    en tout etat de cause:

    j'ai vu que tu avais envoyé des captures...
    et donc?  on est censé checker la config?

    ce que veut te dire tatave, c'est que tu as un formulaire, que tu n'es pas obligé de respecter A LA LETTRE mais qui te permet d'avoir un cadre pour poster ta question

    et surtout:  pour pas que quand on lise ta question, on se dise "nan mais attend, le gars, il a fait aucun contre test, aucune recherche, aucune analyse, en gros il viens chercher son larbin"

    => Pour ca, il y a la gold subscription, ou tu fais "relire tes confs"  et ou tu "fais configurer" et ou tu globalement "fais faire"
    ce n est pas le cas ici.

    (a moins que je me trompe, sans quoi moi aussi je ne vais pas tarder a me faire ouspiller)



  • et concernant ton affaire, je lis que tu as "8 acces adsl2+ a 20M)  (donc je présume que tu dévelloppes 100 a 110 megs a une deux-centaine de metre d'un central

    sont il en gateway group tier 1 ?

    ou utilises tu multilink ppp  via  orange ?  (je me demande si ca marche sur orange d ailleurs,  chez ovh oui je sais)

    nan parce que si c est le choix 1, cela n'est pas si surprenant  (d'ailleurs on sait pas quel pb tu rencontres en fait,  il s illustre comment ton probleme)?

    donc si c est choix 1, alors tu dois savoir que ce n est pas du bonding, mais une repartition qui d'ailleurs est parcellaire, puisque tu es obligé de creer des sous regles pour dispatcher les proto (comme ssl) qui kiffent pas trop la gateway pool.

    donc concretement, utilise le formulaire, et dis nous le probleme,  parce que les "c 'est pas efficace" c est juste un peu vague
    que cherches tu a faire, qu est ce qui ne va pas + formulaire

    et tu verras, ;)



  • 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



  • 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.



  • 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.



  • 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.



  • 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.



  • Tu es d'accord avec moi concernant le stickky?



  • 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,




  • "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)



  • 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.



  • @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



  • @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.



  • 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



  • @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.



  • @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



  • @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 ^^



  • 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



  • 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



  • 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.



  • 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


  • 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



  • salut salut

    je répondrais a cela comme me l'avais dit en son temps mon mentor en informatique ==> un bon réseau informatique c'est un réseau sans utilisateur penses y connaitre au moins il y aura moins de "cons" dessus et que des personnes "con"pétantes sont celle qui utilisent sans chercher plus loin, c'est un outils de travail , bien que des fois même là on n'est pas sorti de l'auberge non plus et loin de là.

    Cordialement



  • tatave,  il manque des mots et des conjonctions de coordination dans tes posts a chaque fois

    c'est dur !  de te suivre


Log in to reply