Squid et HTTPS et Accès WAN

ccnet

Je me pose à peu près les mêmes questions. Comme un problème bine posé et bien compris est à moitié résolu commençons par le début. Un schéma avec adressage serait un bon début.

jdh

Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
Voilà ce que j'avais à dire.

Ah non, cela est VOTRE point de vue !

Le point de vue d'un certain nombre est la nécessité de remplir un formulaire avec des sections (simples).

Où est la difficulté à découper en sections la présentation d'un problème ?
Cela prend juste quelques minutes de plus, c'est tout ! Mais cela facilite la lecture par les autres … et cela fait toute la différence !
Notamment, le manque de clarté entraine une mauvaise compréhension de la part des lecteurs et un aller-retour de question pour préciser.

Exemple (sur les 15 derniers jours) :

KARMAZ (13-11) https://forum.pfsense.org/index.php?topic=102297.0
Mercenaire (12-11) https://forum.pfsense.org/index.php?topic=102330.0 (malgré des digressions bien inutiles)
Mamatov (17-11) https://forum.pfsense.org/index.php?topic=102546.0 (très bonne présentation)
A l'inverse :
mryou (8-11) https://forum.pfsense.org/index.php?topic=102090.0 (fil très long du aux allers et retours)
scratch (9-11) https://forum.pfsense.org/index.php?topic=102136.0 (fil long et peu intéressant)
ce fil

J'observe que ce sont toujours ceux qui refusent le formulaire qui pose des problèmes !
Et à l'inverse, ceux qui acceptent le formulaire produisent des fils intéressants.

Les exemples tout récents sont assez éclairants comme démonstration !

Je repose la question : où est la difficulté ? (quelle est la contrainte ?)
Si cela ne suffit pas : regardez l'efficacité !
Ne dit-on pas : un problème bien posé est à moitié résolu !

Je n'accepte donc pas votre réponse.
J'en ai assez marre d'avoir à réécrire toujours cette même réflexion pourtant résultat de l'observation.

chris4916

@jdh:

Mercenaire (12-11) https://forum.pfsense.org/index.php?topic=102330.0 (malgré des digressions bien inutiles)

Précise donc ta pensée ;D

J'observe que ce sont toujours ceux qui refusent le formulaire qui pose des problèmes !
Et à l'inverse, ceux qui acceptent le formulaire produisent des fils intéressants.

Tu as une manière assez particulière de présenter les choses.

Il est évident que sur pratiquement chaque nouveau fil tu as une approche très manichéenne qui consiste soit à fustiger l'auteur si le formulaire est absent soit à le féliciter si celui-ci correspond à ton attente.
ça en devient même risible.

Ce qui rend un fil intéressant, ce n'est pas uniquement le premier message, même si celui-ci y participe fortement j'en conviens, mais également les réponses et les changes qui y sont fait.

Bien sûr que les fils qui t'intéressent sont ceux dont la description rentre dans les cases du formulaire et la réponse tient en 2 lignes pour qu'ils n'y ait pas d'échanges inutiles que tu considères comme des digressions, mais comme le dit l'auteur de ce fil, si le sujet ou la forme ne t’intéressent pas, tu n'es pas obligé d'y participer. Et si ça pollue ta conception d'un forum bien propre, insiste pour avoir une section dédiée dans laquelle tu pourra faire régner ta conception de l'ordre bien établi.

Il est évident que l'auteur de ce fil à un peu du mal à comprendre et décrire l'environnement, qu'il a besoin d'aide pour le faire et que cette aide ne viendra pas de toi. C'est ton choix, je le respecte mais tu devrais faire un effort pour comprendre sa position, même si tu n'acceptes pas celle-ci.

Tatave

salut salut

juste en passant, je suis perdu aussi dans les explications du requiérant, mais bon je n'ai plus de napalm à rajouter sur les braises

pour chris

==> au coin NA

++

jdh

Je ne sais pas quoi vous répondre… enfin si, c'est très compliqué d'intégrer votre forum compte tenu de l'accueil que vous réservez.
Certes, je comprends que les nuls comme moi vous énervent mais dans ce cas là, ne vous investissez pas dans ce forum...
Voilà ce que j'avais à dire.

Je vais répondre encore plus franchement.

Ce forum est ouvert à tous.
Il est destiné à échanger du savoir entre débutants et aguerris.
C'est un endroit où on peut s'attendre à un minimum de respect entre membres et à un minimum de règles de 'vie'.
S'il n'y a pas un minimum d'échanges respectueux, cela devient un espace foutoir, qui, immanquablement, ne va plus servir à rien.

Parmi les règles 'standard' comme l'utilisation de la langue française, le refus du langage SMS, une certaine correction vis à vis d'autres membres,
des 'anciens', contributeurs assidus, (offrant leur savoir gratuitement) ont proposé d'utiliser un 'formulaire' pour poser une question.

L'intérêt de ce formulaire est de fournir dès le départ des informations découpés en sections simples et faciles à remplir.
La proposition de ce formulaire a un but simple et pratique : accélérer la compréhension du problème.

L'utilisation du formulaire ne prend que quelques minutes et fait gagner du temps aux lecteurs comme à l'initiateur.

Je vous trouve donc très culotté

d'être un tout nouvel inscrit
qui commence par ne pas respecter le formulaire
et qui ajoute 'c'est très compliqué'.
Faudrait arrêter de prendre les autres pour des imbéciles …
Et c'est étrange de solliciter une aide sur un problème perso, et de commencer par écrire que l'on serait mal accueilli alors même que l'on commence par ne pas respecter les usages ?!

Puisque il fallait un démonstration, j'ai pris quelques fils, parmi les plus récents, avec, aussi, de nouveaux inscrits.
Pourquoi eux sont capables de faire ce petit effort ?

Au lieu de récriminer, nous aimerions plutôt savoir ce qui vous a empêché de passer les quelques minutes nécessaires à la rédaction selon le formulaire, et en quoi cela est un contrainte pour vous alors qu'elle ne l'est pas pour d'autres.

Je me doute qu'il n'y aura pas de réponses ...

bennijamm

Bonjour,
Désolé si j'ai je vous ai vexé mais si c'est le cas, c'est que je ne devais pas être loin de la vérité…
Bref, c'est pas grave.
Pour me dépatouiller, j'ai essayé de faire un schéma qui explique ce que j'ai tenté de vous dire à l'écrit.
Voir PJ.

Je vais reprendre votre formulaire et je vais le remplir, comme ça je ne serai pas le méchant nouveau !

Dessin1.png_thumb

bennijamm

Contexte :

milieu pro
niveau expertise de l'administrateur : pas assez compétent dans ce domaine, une partie de notre sécurité est donc sous-traitée

Besoin :

ce serveur a pour but d'être le barrage de sortie sur une adresse (10.0.1.244) qui n'est pas du tout filtrée par le firewall "général" (= watchguard situé chez notre hébergeur en coeur de réseau)
=> toutes les autres adresses sont filtrées : il faut être membre du domaine pour sortir
=> nous utilisons des serveurs Linux qui ne sont pas membre du domaine et qui doivent donc utiliser pfSense pour sortir sur Internet.
nous souhaitons également utiliser le portail captif pour fournir à nos clients un accès à Internet lors de leur venue dans l'entreprise. Nous souhaitons également respecter la loi en conservant les logs.

Schéma : posté dans le message précédent

WAN nombre : 1 , vlan : 0, autres réseaux accédés via routeurs : non, adressage : 10.0.1.0/24, dhcp : fourni par serveurs microsoft, dns local : oui

LAN : (modem/routeur/box) : nombre : 1, type : ???, bridge/routeur : ???, nombre d'ip publique : 0,

DMZ : non

WIFI : adressage de la borne wifi : 192.168.1.254, dhcp fourni par pfSense, dns local, usage : visiteurs

Autres interfaces : non

Règles NAT : non je ne crois pas

Règles Firewall : rien pour le moment

Packages ajoutés : squid3, lightsquid, squidguaurd, freeradius

Autres fonctions assignées au pfSense : Portail captif (sur quelle interface : LAN) et accès pour les serveurs Linux de la plage IP 10.0.1.x/24

Question : comme je l'ai déjà indiqué, je souhaiterais tout simplement mettre ce schéma en oeuvre et que ça fonctionne. Aujourd'hui mes serveurs Linux n'ont pas d'accès à Internet (le ping marche mais une commande curl www.orange.fr par exemple).
Je voudrais aussi savoir ce qui est le moins pire dans mon schéma et où se situent les points "dangereux" (sans être parano non plus).

Recherches : j'ai fait des tests et suivi des tutos mais ça ne semble pas être concluant…

Logs et tests : à votre demande, je peux fournir ce que vous souhaitez.

Merci pour votre précieuse aide !

chris4916

Ton schéma correspond à ce que j'ai compris de tes explications, donc celles-ci sont plutôt correctes mais, compte tenu de ce schéma, veux-tu bien reprendre tes questions initiales ?

Pb : dans les règles du firewall pour l'interface WAN, je n'ai aucune règle active. Je n'ai que la règle par défaut "Block bogon networks".
Pour autant, les machines branchées côtés WAN on accès à Internet… Je ne vois pas d'où ça peut venir...
J'ai également un proxy SQUIDv3 + SQUIDGUARD + LIGHTSQUID + portail captif

Les machines coté WAN n'accèdent jamais à pfSense donc quelles que soient les règles, portail captif, proxy etc… ça n'a aucun impact sur la manière dont ces machines "coté WAN" (coté WAN de pfSense mais sur la LAN de ton entreprise) accèdent à internet

D'où ma seconde question : sur l'interface LAN sur laquelle est branchée le portail captif, je peux surfer sans problème sur les HTTP et HTTPS.
Par contre, depuis l'interface WAN, impossible d'accéder aux sites en HTTPS… Je ne comprends pas la logique malgré ce que j'ai déjà pu lire sur le MAN on the middle sur ce forum... ?

Je ne comprends pas ce que MITM vient faire là.
D'après ce que tu décris, il doit y avoir un problème avec le service géré par ton provider : si il autorise une exception pour permettre 10.0.1.244, cette IP accède à internet en HTTPS. Par contre les IP que le provider contrôle n'y accèdent pas. Rien à voir avec pfSense mais plutôt avec ton fournisseur, je pense ;)

jdh

J'ai écris ceci à 9h39 ce matin :

Dans pfSense, les règles sont réparties par onglets : LAN, WAN, …
Ces onglets indiquent l'arrivée des paquets (enfin du paquet initial).
Par voie de conséquence, l'onglet WAN contient des règles concernant des flux allant de WAN vers LAN.
Et de même, l'onglet LAN contient les règles concernant les flux allant de LAN vers WAN.

Donc, vous n'avez sans doute rien à mettre dans l'onglet WAN !

Si vous réfléchissez un peu, en regardant votre schéma, vous voyez bien que le trafic entre les serveurs Linux et Internet ne passe pas au travers du pfSense !

Le réglage mis en place par l'opérateur consiste à autoriser l'ip WAN du pfSense, et par conséquence, toutes les machines situées dans le LAN de pfSense.
Mais en aucun cas les machines au 'même' niveau que pfSense !

Si vous voulez que vos serveur Linux accèdent, il faut, donc, que leurs adresses soient traitées comme l'IP WAN de pfSense.

Vous utilisez un schéma très traditionnel, proposé par les opérateurs : un réseau MPLS avec accès Internet contrôlé depuis le 'centre' du réseau.
De facto, le niveau de contrôle est très limité : pas de logs par ip, users, pas de blacklist ou pas de whitelist, quel stockage, …
Et chaque modif est payante, c'est leur gagne pain !

Une bien meilleure façon de gérer le trafic Internet repose nécessairement sur un proxy interne, dédié et bien configuré. (3 mots avec un sens précis !)
(Au choix il sera central ou par agences.)
(Et il aura son propre accès à Internet ...)

Dans mon entreprise, j'ai un pfsense par site avec 2 lignes (SDSL pour le vpn inter-sites, et ADSL pour l'accès Internet) et un proxy par site.
Je peux faire des blacklist ou des whitelist (pour les utilisateurs de base afin de les limiter). J'ai des logs sur 1 an (puisque c'est la loi). Et bien sûr je peux autoriser des serveurs sans authentification. (Certes cela fait des années que je le fais ...)

Vous voyez, vous avez été capable de faire un schéma et de remplir le formulaire.
Cela vous a pris 10', 20' ou 30' : qu'est ce que c'est pour être bien compris ? Où est la contrainte ? Quelle est la difficulté ?
Alors, franchement, pourquoi ne pas l'avoir fait dès le début ?
Et ça sert à quoi de parler sur l'accueil : pas de formulaire + dire mauvais accueil = vous vous attendiez à quoi ?

A l'inverse, les autres nouveaux n'ont pas à se plaindre de l'accueil, il me semble ...

chris4916

Je reviens sur ton schéma et les explications qu'il contient:

si le contrôle d'accès à internet se fait, par le provider, sur la base d'une authentification AD, il n'y a pas beaucoup de solutions pour donner accès aux serveurs Linux.

Il faudrait que ces serveurs rejoignent le domaine (je sais ce sont des serveurs Linux :D mais ce n'est pas un point bloquant). Il faut surtout bien comprendre comment fonctionne le contrôle du provider (par exemple est-ce basé sur un ticket Kerberos et du profiling par groupe ?) soit il faut demander au provider d'ajouter des exceptions pour les IP de ces serveurs (ce qui accroit la taille de la bêche).

Cette compréhension technique du service du provider est un point de passage obligé pour une quelconque évolution du design.

Une manière élégante de résoudre ce type de problème serait de changer le schéma que tu montres (je ne sais pas si c'est possible dans ton cas)

en organisant les choses de manière différente, il doit être possible de simplifier la communication avec le provider tout en offrant plus de souplesse.

Par exemple:

Si tes machines sont regroupées sur des segments réseau différents, ta problématique va changer.

Suppose par exemple que tous les serveurs soient sur un segment, isolé, "SERVEURS".
ton Wifi "guest" dispose également d'un segment propre
les utilisateurs sur le LAN sont également sur leur propre segment

le tout est connecté à un FW qui se connecte au segment réseau connecté au réseau MPLS et donc au filtrage du provider.
Sur ce segment (coté WAN du WF), tu peux installer un proxy accessible uniquement aux serveurs et au wifi guest et demander à ton provider d'autoriser cette adresse IP.

C'est juste un exemple de design qui vise à répondre à ta problématique mais également apporter un peu de sécurité dans ton réseau.

Si tu ne peux pas changer celui-ci, un autre approche peut consister à:

changer l'adresse IP de ton FW pfSense coté WAN (par exemple 10.0.1.253)
en ~~10.0.1.254~~ 10.0.1.244, tu installes un proxy HTTP (typo)
tu configures tes serveurs sur le LAN et les machines sur le segment wifi guest pour utiliser ce proxy, lequel est autorisé par ton provider sans contrôle.

(juste un autre exemple)

La vraie difficulté ici consiste à exprimer clairement ses besoins avant de définir la solution la plus adaptée.

jdh

Il y a ici une astuce qui peut permettre de fournir un accès internet aux serveurs Linux, assez simplement.

Mais avant de la décrire, il faut avoir compris pourquoi actuellement cela ne fonctionne pas.

bennijamm

Merci pour vos réponses très constructives.
Le schéma actuel a été décidé il y a deux ans en fonction des besoins de l'entreprise et je n'en maîtrise pas le changement.
J'ai pris contact ce matin avec notre opérateur pour voir ce que nous pourrions envisager de faire.

@chris4916
Quand tu parles de segments (un pour les serveurs, un pour les utilisateurs, un pour les guests), tu parles de VLAN ? de tranches IP ?
Si c'est de VLAN que tu parles, dans mes souvenirs imagés, c'est un switch qu'on découpe virtuellement pour faire comme si on en avait plusieurs. Dans mon esprit, je ne vois pas comment les postes pourraient avec communiquer avec les serveurs s'ils sont sur 2 VLAN différents ?
Si c'est par tranche IP, dans ce cas, il faut un routeur pour faire le travail de routage entre les différents segments… ?

@jdh
Les serveurs Linux n'ont pas accès à Internet parce que le watchguard donne cet accès aux utilisateurs du domaine et aux machines dont l'adresse IP est rentrée dans dans le watchguard. Dans la pratique, on pourrait faire une demande d'ajout à notre prestataire pour nos nouveaux serveurs Linux mias cela est pénible puisque coûteux (en temps (contact du prestataire, explication de la demande, tests, rappels si pb...) et en argent).
Si vous avez donc une solution pour donner l'accès aux serveurs Linux, ça m'intéresse !

Merci

chris4916

@bennijamm:

Quand tu parles de segments (un pour les serveurs, un pour les utilisateurs, un pour les guests), tu parles de VLAN ? de tranches IP ?
Si c'est de VLAN que tu parles, dans mes souvenirs imagés, c'est un switch qu'on découpe virtuellement pour faire comme si on en avait plusieurs. Dans mon esprit, je ne vois pas comment les postes pourraient avec communiquer avec les serveurs s'ils sont sur 2 VLAN différents ?
Si c'est par tranche IP, dans ce cas, il faut un routeur pour faire le travail de routage entre les différents segments… ?

Ce peut effectivement être du VLAN ou des segments physiquement séparés. La réponse dépend de ton infrastructure réseau physique. Si tes serveurs sont, par exemple, dans un data centre ou une salle machine spécifique, il est facile de les mettre sur un réseau "isolé". Si les serveurs sont répartis dans différents bureaux, selon la manière dont est gérée la baie de brassage, ça peut être beaucoup plus difficile et le VLAN est probablement mieux adapté.

Le VLAN revient à construire, de manière virtuelle (d'où son nom) un LAN virtuel isolé.
Bien sûr qu'il faut dans ce cas, gérer le routage entre ces différents segments réseau et c'est justement tout l'intérêt puisque, en isolant les réseaux, tu contrôles qui accède à quoi et avec quels protocoles.

Mais je dirais que ce n'est que la cerise sur le gâteau (bien que dans le cas de serveurs, ce soit plutôt des "best practices")

L'idée principale qui répond à ta question initiale, c'est de dire:

faisons en sorte que tous les serverus accèdent à internet via un proxy (ce qui signifie, du point de vue de ton fournisseur de service d'une IP interne unique)
demandons au fournisseur d'autoriser cette IP ou bien configurons le proxy pour utiliser l'IP déjà autorisée.

bennijamm

Bonjour,
Bon bon bon… Pas d'évolution de mon côté.
L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.
Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".
Dans les logs du firewall, j'ai activer les logs pour la règle que j'ai placée dans WAN (voir copie d'écran), tout semble passer... mais ça ne revient pas !

En revanche pour le LAN (accès donné aux clients via un AP Wifi), aucun problème de surf.

Que dois-je faire ? Merci

firewall_rules.png_thumb

logs.png_thumb

chris4916

@bennijamm:

L'opérateur nous facture toujours la possibilité de rajouter des IP dans le watchguard. On a donc décidé de garder notre pfSense en l'utilisant comme passerelle pour que nos serveurs Linux puissent sortir sur Internet.

Tu pourrais, stp, poster un schéma à jour montrant cette modification ?

Mais en voulant configurer le pfSense, je suis embêté car les machines du réseau local (donc connectées via l'interface WAN), configurées avec la passerelle qui correspond à l'interface Wan, peuvent pinguer n'importe quelle domaine mais au moment où je veux aller sur Internet, "la page est inaccessible".

J'avoue ne pas comprendre ce que ça signifie. Le schéma devrait répondre à mon interrogation.
Dans ce que tu décris, il semble que les PC utilisateurs ne sont pas derrière pfSense (celui-ci étant intercalé entre le LAN et l'équipement en 10.0.1.254) mais sur un segment auquel serait connectée l'interface WAN de pfSense (en 10.0.1.202)
Si c'est le cas, c'est normal que ça ne fonctionne pas car si 10.0.1.202 est la gateway des PC, ceux-ci vont accéder à cette IP pour joindre internet (au lieu de 10.0.1.254). Tu as peut-^tre ajouté une route pour renvoyer vers 10.0.1.254 (ce qui est une mauvais eidée sauf à prendre quelques précautions de configuration dans pfSense) mais lorsque les paquets reviennent à 10.0.1.254, celui renvoie ces paquet directement vers le PC alors que celui-ci attend une réponse de 10.0.1.202.

Bref, un nouveau schéma s'impose ;)

bennijamm

Oui, ça doit être ce que tu décris.
Le pfsense est passerelle pour les serveurs Linux. Je n'ai pas créé de route ni rien.
J'ai mis à jour mon schéma.
Si tu peux m'indiquer quoi faire… je suis preneur.

Dessin1.png_thumb

chris4916

Ce schéma ne fonctionne pas, sauf si, et c'est un design que je ne vais pas supporter, pfSense exécute un proxy Squid qui écoute sur son interface WAN.
Je ne comprends même pas pourquoi ça marcherait pour les serveurs et pas pour les PC :o

1 - il faut que tes serveurs soient derrière pfSense et non pas coté WAN
2 - si tu n'as pas besoin de pfSense pour tes serveurs (pas de fonction d'isolation via un FW des serveurs et des PC, alors installe un proxy en 10.0.1.244, configure pfSense pour avoir 10.0.1.243 (par exemple) en adresse WAN et dirige les clients qui sont derrière pfSense (wifi) vers 10.0.1.244 (proxy HTTP)
3 - ne change rien aux PC: ceux-ci sont déjà autorisés au niveau du watchguard si ils utilisent 10.0.1.254 comme dft GW.

ccnet

Je ne vois pas non plus comment ce schéma pourrait fonctionner. Bien évidement il faut mettre les serveurs derrière Pfsense (éventuellement un second pour ne pas toucher à ce qui est tombé en marche) sur la pâte Lan. Ils en ressortiront translatés avec l'ip wan de Pfsense qui n'a qu'à être une ip autorisée sur le firewall opérateur. Mais il faudra router le trafic à destination de ces serveurs si ils doivent être accédés depuis les machine du lan. Tout cela est tellement alambiqué que je pense avoir perdu de vue l'expression de besoin initiale (si il y en avait une). Sinon le proxy tel que proposé par Chris convient.

Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) …

jdh

Ce que je constate, c'est

l'initiateur n'est pas compétent, et fait des réglages 'au petit bonheur' en espérant que cela puisse fonctionner
l'initiateur a écrit un passage virulent sur le forum et ne semble pas près de s'en excuser (pour moi c'est un blocage !)
un utilisateur émet des idées, certes logiques mais hélas parfaitement inaccessibles à l'initiateur, en sus de quelques digressions et erreurs. De plus cet utilisateur encourage l'initiateur dans ses opinions vis à vis du forum …
la société veut tout et son contraire : pas d'expertise = confiance au FAI et ne veut pas payer d'où bricolage par amateur pas éclairé

Or, dans ce cas, avec les réglages initiaux (bien meilleurs et bien plus logiques), il y a une astuce (non trouvée par chris4916) qui donnerait l'accès souhaité.

En fait on en revient exactement à ce que j'ai écrit le 17 à 9h39 et qui reste d'actualité :

Il y a nécessité de disposer d'un conseil en réseaux qui saura mettre en oeuvre les bonnes techniques (cela a forcément un coût : patauger depuis tout ce temps a déjà couté !)
J'ajoute que, malgré l'astuce que je vois, il y a nécessité de remettre à plat ce schéma !

En ce qui me concerne, à partir du moment où il n'y a pas d'excuses, je ne vois pas pourquoi je donnerais la piste, pourtant simple, qui donnerait l'accès souhaité.
Je répète qu'il y a une astuce simple et il n'est pas question de segments, ....

@ccnet :
Beaucoup de PME font confiance à leur opérateur et utilisent un réseau MPLS avec accès Internet 'central'.
Dans le cas, l'opérateur a 'vendu', en sus, un contrôle utilisateur pour la navigation, ce qui 'attire' la PME.
Mais la PME ignore les imperfections et difficultés qui ne manqueront pas, accompagnées de leurs solutions payantes.
Le schéma est bancal parce que la PME tente d'ajouter un pfsense sans expérience et sans passer à une solution solide (i.e. sans accès Internet central)
C'est fréquent en effet ...

chris4916

@ccnet:

Ps1: Je reste étonné par le nombre de réseaux aux architectures approximatives et bancales.
Ps2: Et dire qu'avec une architecture saine ce serait si simple (ou presque) …

Oui surtout que quand c'est simple, généralement ça marche ;-) mais dans la vraie vie, pour certaines sociétés, l'infrastructure n'est pas le résultat d'une réflexion murement réfléchie pour chacune des évolutions et il y a parfois des verrues qui poussent suite à des décisions rapides, d'urgence mal gérée ou de contrainte dont on ne tient plus compte quand on regarde la big picture à postériori.

Si les intervenants dans la société change, il n'y a pas toujours continuité, d'où des designs parfois étranges.

Et heureusement car si tout était parfait, on s'ennuierait ;D ;D ;D