On Wed, 8 Jun 2011 21:29:50 +0200, "Guillaume Barrot"
<guillaume.bar...@gmail.com> said:
> Question : que fait le technicien sur le WWN de SAN si c'est pas la même
> chose ?
Il rend pas sa baie SAN accessible en FC au monde entier......
> Deuxio, de nouveaux serveurs arrivent avec la possibilité de cloner la conf
> hard (wwn, mac etc, ex : UCS Cisco). On peut espérer que ça se généralise.
Bonjour le bordel quand on clone la conf hard sur deux unites
differentes.....
> De plus, quel intérêt de conserver la même @IP pour tous les serveurs
> attaques sur une URL ? Du push DNS au DDNS les solutions pour conserver
> le nom en changeant l'IP existent depuis longtemps.
Ah bon ? Tu sais comment updater le cache DNS des ISPs de la planete,
surtout pour ceux qui decident de ne pas trop respecter le TTL ?
> Et enfin, si tu virtualises pas de soucis, or c'est pas déconnant sur un
> certain nombre de serveurs frontaux internet.
Il y a des choses qu'on virtualise, il y a des choses (parfois meme
exposes publiquement) qu'on virtualise pas.
> Bref une faille de niveau 2 me semble peu dangereuse vis a vis des autres
> failles plus faciles a utiliser (rootkit sur un serveur Linux mal patché par
> exemple, ou SQL injection sur une infra n-tiers mal configurée).
.........
> L'IP fixe, c'est simple et maîtrisée, mais ça pose un gros problème : c'est
> fixe, et lie a ton plan d'adressage.
> Maintenant, si tu utilises des serveurs virtuels, et que tu souhaites
> pouvoir les déplacer d'un site A a un site B sans trop de contraintes,
> sachant que tes utilisateurs s'y connectent via une URL, tu as deux
> solutions :
> - un vlan étendu ou tout autre solution de Datacenter Interconnect de
> l'EoMPLS a des trucs plus exotiques comme OTV ou Fabricpath de Cisco
> - un adressage dynamique et des updates du DNS (via DDNS ou du GSLB par
> exemple)
> Le choix c'est soit la complexité d'un niveau 2 étendu (ça parait simple
> comme ça ...), soit la complexité d'une IP dynamique (et le comment
> je gère mes règles firewall etc.)
<troll>
Quand on fume un peu trop la moquette, on finit par faire du "cloud"
("cloud" de fummee *ET* cloud computing).
</troll>
Plus serieusement, est-ce que tu as jamais eu a gerer les choses dont tu
parles ? Si oui, dans quel type d'environnement ?
> Je me rappelle avoir vu tourner un vieux VAX de chez DEC avec une config
> rigolote : le service porté sur une loopback, et les
> interfaces réseaux non configurées prenait une IP dans le linklocal
> (169.254.x.x), et un daemon RIP qui tournait en standard ==> tu pouvais
> joindre ton service sans pour autant connaitre les @IPs des interfaces.
> La même chose en IPv6 avec un daemon RIPng ou OSPFv3, c'est pas bien
> compliqué a mettre en place vu comment le linklocal est bien globalement
> bien géré. Et gérer le SLAAC sur une loopback pour le coup :D
1: C'est pas bien complique pour une machine. Commence a ajouter des
zeros a la fin et ca change radicalement.
2: SLAAC sur une loopback, ca doit etre fun. Un tres bon sujet pour ce
vendredi.
> Autre solution, toute bête : pas de v6 sur les serveurs (cf la
> presentation d'IPv6 at Facebook sur le site du Nanog
> <http://www.nanog.org/meetings/nanog50/presentations/Tuesday/NANOG50.Talk9.lee_nanog50_atlanta_oct2010_007_publish.pdf>
> ).
> Pas mal de serveurs en frontal internet étant en ferme derrière des
> loadbalancers, c'est généralisable.
Ca fait juste poudre dans les yeux. Je me souviens avoir teste FB over
IPv6 a l'epoque et la premiere connexion c'etait le douche gele
(Facebook has detected that you are trying to connect from an
un-familiar location : San Francisco, California - avec en cadeau l'IP
du proxy v6-v4 et tout le cirque d'identification des amis dans des
photos avec leurs chiens et chats).
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
