Journal Défi geek : réseau

Posté par  .
Étiquettes : aucune
-2
10
avr.
2010
Cher Journal,

Je souhaite te faire part d'un défi captivant sur mon blog. Ce dernier ne contient, contrairement à cette page, pas de publicité.

Il s'agit d'un problème de configuration réseau rencontré dans la vraie vie d'une vraie entreprise, et déjà résolu.

Si tu connais des moules privées de tribune, tu peux bouche-à-oreiller qu'elles peuvent venir se frotter la coquille à ce défi sans prétention ni prix ni vedettes ni mannequins dénudés sur :

http://gcarrier.fr/2010/04/09/defi-geek/


Pour conserver le fun, il serait gentil de ne pas dévoiler la réponse dans les commentaires de ce journal. La raison même de l'utilisation de mon blog est de pouvoir modérer les commentaires pour ne dévoiler la solution qu'après que chacun aie pu s'amuser avec man.

  • # intéressant mais pas tout compris

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    c'est quoi le problème à résoudre ?

    Pourquoi prendre du 10.X pour pas s'en servir comme classe A ?

    «Multiples clients sur le même segment Ethernet (i.e. aucun routeur), sur 10.0.0.0/16, addresse broadcast par défaut soit 10.0.255.255 ;»
    Ça doit être sympa un réseau de classe A (ou B :/ ) sans routeur…

    «Pour des raisons de sécurité, le serveur ne peut écouter que sur 10.0.0.0/24 et 10.0.255.255»
    …

    Dans le même genre j'ai un défi. Un disque qui contient toute ma vie et sans sauvegarde est en zfs. Dans zpool status il me dit qu'il n'est pas online, quand je reboot la machine le disque fait «scroutch scroutch» comment récupérer les données ?

    • [^] # Re: intéressant mais pas tout compris

      Posté par  . Évalué à 2.

      Le problème à résoudre :
      "Les clients envoient des requêtes en broadcast, un service sur le serveur doit y répondre ;"

      Je rends ça plus explicite dans le post.

      Ce problème est bien sûr ramené à un cas d'école pour ne pas alourdir l'énoncé. Dans la vraie vie les règles iptables ne sont pas vides non plus, et les switchs font du routage.

      Et quand bien même, certaines entreprises mettent tout leur intranet en 10.x.x.x par exemple et font des sous-réseaux par zone géographique, services, équipes, etc.

      Et pour ta comparaison avec ZFS sans sauvegarde, je te suggère de jeter un œil au monde bancaire par exemple. Ces contraintes réseau ne sont pas exceptionnellement ridicules.

      • [^] # Re: intéressant mais pas tout compris

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        > Le problème à résoudre :
        > "Les clients envoient des requêtes en broadcast, un service sur le serveur doit y répondre ;"
        Ok, cela n'était pas clair pour moi en tout cas. Donc, la carte réseau est configurée et il n'y a pas de firewall

        j'ai une solution en 3 lignes (je la met car je pense que ce n'est pas celle attendue) :
        $ echo 'cela
        fonctionne
        déjà'

        > Je rends ça plus explicite dans le post.
        Ce n'est pas juste un coup de pub pour ton blog en tout cas, et ça c'est bien.

        > Ce problème est bien sûr ramené à un cas d'école pour ne pas alourdir l'énoncé. Dans la
        > vraie vie les règles iptables ne sont pas vides non plus, et les switchs font du routage.
        j'éspère bien ^^

        >Et quand bien même, certaines entreprises mettent tout leur intranet en 10.x.x.x par
        > exemple et font des sous-réseaux par zone géographique, services, équipes, etc.
        Oui bien sûr, j'en connais même une qui avait des sous-réseaux en 92.X.0.0 m'en demandez pas plus, aucune idée du pourquoi ou comment, j'ai juste fuit.

        > Et pour ta comparaison avec ZFS sans sauvegarde, je te suggère de jeter un œil au monde
        > bancaire par exemple. Ces contraintes réseau ne sont pas exceptionnellement ridicules.
        Aucune comparaison avec ZFS sans sauvegarde, c'est _vraiment_ un disque de mon NAS qui vient de se péter ce soir.

        Mon poste est à prendre au premier degré si on veut, c'est vraiment une bonne idée que de faire des défis, j'aime bien et en réseau il n'y en a pas ( Si ce n'est quand on est admin-sys et que cela nous arrive -_-' ) Et de la même manière je n'ai vraiment pas compris ce qui n'allait pas.

        • [^] # Re: intéressant mais pas tout compris

          Posté par  . Évalué à 2.

          j'ai une solution en 3 lignes (je la met car je pense que ce n'est pas celle attendue) :
          $ echo 'cela
          fonctionne
          déjà'

          Non, j'ai donné la config de la carte réseau et avec celle-ci, les paquets ne sont pas traités.

          >> Je rends ça plus explicite dans le post.
          > Ce n'est pas juste un coup de pub pour ton blog en tout cas, et ça c'est bien.

          L'aspect publicitaire est ironiquement indiqué dans le journal... Si ça peut te rassurer je me contre-balance du nombre de visites sur mon blog, cf la nature des contenus ces derniers temps...

          Quand je disais "Je rends ça plus explicite dans le post", je voulais dire que j'avais pris en compte ta remarque en améliorant la rédaction. C'est sympa d'avoir des retours, je dois avouer que j'ai rédigé l'article en 5min à partir du problème posé par chat à un ami.[/mavie]


          > Aucune comparaison avec ZFS sans sauvegarde, c'est _vraiment_ un disque de mon NAS qui vient de se péter ce soir.

          Ah toutes mes condoléances. Pas de sauvegarde, pas de chocolat !

          > Mon poste est à prendre au premier degré si on veut, c'est vraiment une bonne idée que de faire des défis, j'aime bien et en réseau il n'y en a pas ( Si ce n'est quand on est admin-sys et que cela nous arrive -_-' ) Et de la même manière je n'ai vraiment pas compris ce qui n'allait pas.

          Effectivement le problème réel (plus complexe que la prochaine version du défi) m'a demandé de reproduire le problème avec 2 stations Sparc, une machine avec virtualisation et 2 switches avant de pouvoir réaliser ce qui se passait vraiment...

          • [^] # Re: intéressant mais pas tout compris

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            effectivement je n'avais pas fais gaffe, c'est plus clair maintenant.
            (pour la pub, c'était juste une blagounette, faut pas relever)

            Donc le problème est que d'un sous réseau, on ne peut faire un requête broadcast qui soit intercepté par le server qui se trouve sur un autre sous-réseau…

            /me fatigué, dur de comprendre

    • [^] # Re: intéressant mais pas tout compris

      Posté par  . Évalué à 2.

      J'espère que le problème proposé ici est juste un sous-problème de quelque chose que je n'imagine même pas, car dans le cas contraire, à mon avis, la vraie solution ça serait de faire les choses propres et non pas de se contraindre à des règles idiotes de quelques personnes qui n'y connaissent pas grand chose en réseau.

      C'est clair qu'avoir un masque en /24 au lieu de /16 ça va vachement protéger le serveur.

      • [^] # Re: intéressant mais pas tout compris

        Posté par  . Évalué à 1.

        Le but n'est évidemment pas de protéger formellement le serveur du reste du réseau. Par contre ce genre de mécanisme ça réduit effectivement pas mal les chances d'interaction avec le reste du monde, on peut supposer que 10.1.x.x aura plus de mal à se connecter en http dessus, qu'un utilisateur standard sur celui-ci aura plus de mal à se connecter en ftp sur 10.2.x.x, etc.

        Ça n'était pas rare il y a quelques années de limiter l'accès à un service via hosts.allow/hosts.deny.
        C'est aussi à peu près équivalent au principe désuet de rsh où on fait confiance à l'environnement matériel et aux administrateurs des machines. La pratique de filtrer l'accès à des services via l'IP distante est aussi courante.
        Ici ça serait un moyen simple et léger de restreindre l'ensemble des interactions réseau.

        Ça n'est pas le seul mécanisme de protection, ça n'est pas un mécanisme formel non plus, et ça n'a aucune importance pour le problème.

        D'ailleurs avec la version plus complexe du problème que je posterai plus tard, vous verrez la raison exacte pour cette configuration... Elle est valable.

        Je me répète : cas d'école.

        • [^] # Re: intéressant mais pas tout compris

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          c'est toujours utilisé hosts.allow / hosts.deny dans certaines entreprises :p

        • [^] # Re: intéressant mais pas tout compris

          Posté par  . Évalué à 3.

          Franchement, j'ai "hâte" de voir le "vrai" contexte parce que cette config réseau me paraît complètement tordue. Et ton contournement (car s'en est bien un), même en 3 lignes, c'est très crade.

          Vu les contraintes, ça m'étonnerait pas que le serveur doivent servir du samba sur un réseau segmenté n'importe comment. Quelle joie, un protocole de rêve avec un réseau parfaitement architecturé ...

          Sinon, moi je t'aurais préconisé de faire ça de manière "moderne", avec de l'IPv6, du multicast et en utilisant iproute2, mais ça doit être trop récent pour le monde de l'entreprise. Le pire, c'est que ça aurait pu très bien marcher en parallèle de l'ancien. (bah ouai, pouvoir faire du v6 et du v4 en parallèle c'est quand même vachement bien pour les transitions)

          • [^] # Re: intéressant mais pas tout compris

            Posté par  . Évalué à 1.

            C'est exactement ce que je sous-entendais, avec iproute2 et tout!

          • [^] # Re: intéressant mais pas tout compris

            Posté par  . Évalué à 3.

            Il fallait JumpStart'er (= installer automatiquement Solaris par le réseau) plus d'une centaine de serveurs SPARC reposant sur OpenBoot, dans un environnement où BOOTP/DHCP n'est pas envisageable pour des raisons qui ne nous regardaient pas.

            Par ailleurs le cas réel est que les machines devaient être configurées en /16 mais se trouvaient sur des segments correspondant aux /24. Chaque segment est couvert par une carte Ethernet sur le serveur de JumpStart.

            Ce serveur tourne sous Linux dans une architecture de virtualisation distribuée. Dans le cas réel le gros du travail est fait par iptables.

          • [^] # Re: intéressant mais pas tout compris

            Posté par  . Évalué à 2.

            Et pour ne pas mélanger ma réponse technique à mon jugement personnel, lui "inutile", sur ton commentaire qui n'est pas le seul dans ce cas et certainement pas le pire :

            Quand quelqu'un ne connait que peu voire pas une situation, ça me gêne profondément qu'il y porte un préjugé (si quiconque se sent offusqué je sors la définition) sur la compétence des admins ou la pertinence de leur approche.

            Certains problèmes sont suffisamment complexes pour que les mecs qui s'y confrontent doivent faire des choses inhabituelles et/ou peu maintenables. Ce n'est pas nécessairement parce qu'ils sont moins intelligents ou cultivés que vous. Et quand bien même vous auriez mieux, ça passe toujours mieux de le présenter avec humilité plutôt que dédain.

            Par ailleurs, c'est peut-être divertissant de basher le monde de l'entreprise, les protocoles conçus par Microsoft, les technos dépassées depuis les années 80 ou 90, mais certains d'entre nous y sont confrontés à titre professionnel et n'ont pas forcément la liberté de s'en plaindre (je ne parle pas pour moi, ça m'amuse). Comprenez que ça puisse être fatigant d'avoir ce genre de réactions quand on essaye d'échanger autour.

  • # sans vouloir jouer les rabats-joie

    Posté par  . Évalué à 2.

    cette questgion aurait plus sa place dans un forum.

    sinon plus sérieusement, j'ai répondu sur ton blog, j'attends avec impatience la modération !

  • # C'est fini !

    Posté par  . Évalué à 2.

    Merci aux participants. Si quelqu'un veut plus d'explications sur ce qui ne marche pas chez lui, répondez à mon mail :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.