Merci pour vos réponses rapides ! Mes questions résultantes à chaque mail dans la suite.
>> Pour un premier message sur cette liste je vais commencer par me présenter >> brièvement, je suis Yoann Gini, formateur et consultant Apple sur tout ce >> qui concerne Mac OS X et Mac OS X Server en entreprise ainsi que Xsan (donc >> consutling pour clients finaux et formations pour les certifs [inutile de >> relancer le débat sur les certifications]). > > Hmmm, vu la position d'Apple sur les produits serveurs, bon courage pour > la suite ;) Je fais de l'OS X Server car ça me permet de passer plus de temps sur les problématiques métier des entreprises (1h/1h30 de l'installation à la connexion des utilisateurs sur les principaux services, c'est confortable). Après s'ils continuent dans cette direction ce n’est pas un problème, un Mac n'est qu'un UNIX, je prendrais juste un jour de plus pour installer un BSD en tant que serveur pour la gestion des clients >> Ma première question concerne l'attitude à adopter quant à son utilisation >> de manière pérenne. Prenons un exemple avec mon client "type", à savoir du >> double WAN avec IP public fixe pour les deux liens Internet. Le routeur >> s'occupe de faire de la répartition de charge et un peu de QoS pour être >> certain que les services du type téléphonie ou services essentiels des >> serveurs passent dans tous les cas. > > Tu as deux types d'agrégation : les load balancers de niveau 5 à 7, qui > sont des bidouilles infâmes, et les vrais agrégations qui sont > transparentes (niveau 2 ou 3), ou tu as une plage d'adresse pour les > deux liens. Auriez-vous des liens à me recommander à ce sujet ? Concernant des produits de ce type et surtout la manière de les utiliser ? >> En stateless les 64 derniers bits sont créés à partir de l'@MAC, est-ce >> qu'on a moyen de jouer avec ça ? >> Il me semblait avoir lu qu'une IPv6 incomplète est recomposée à partir du >> préfixe actuel, est-ce le cas ? >> Est-il préférable de maintenir un IPv4 interne pour ne pas devenir fou ? >> (please pas ça) >> Va-t-il falloir revenir au NAT ? (please encore moins celle-là) > > Il est _possible_ de natter, en l'occurrence en NAT66 1:1, mais c'est > pas recommandé. Le dualstack est aussi possible, et souhaitable, car bon > nombre d'applications métier développées sous OS X on une gestion du > réseau absolument catastrophiques et ne passent pas en v6 (typiquement > les serveurs de licence Quark ou de vielles versions de 4D) Ouais, ça, je connais… Et pourtant il y a de très bonnes docs développeur fournies par Apple à ce niveau (je fais aussi du dev Mac à mes heures) Par contre vous n'êtes pas d'accord avec Rémy ç ce sujet : >> Est-il préférable de maintenir un IPv4 interne pour ne pas devenir fou ? >> (please pas ça) > > J'aurais tendance à dire qu'il serait préférable de ne pas mettre d'IPv4 > du tout dans le réseau et de maintenir la connectivité IPv4 avec du > NAT64/DNS64, m'enfin ça c'est du gros extrémisme qui ne marche pas dans > tous les cas. Abstraction faite des problèmes de logiciel interne, n'est-il pas mieux de faire du NAT64 en sortie de réseau plutôt que de gérer le dualstack sur les clients ? >> - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer >> la répartition de charge sans faire de NAT ? > > Soit avec une vraie agrégation, soit en NAT66. Pas d'autre alternative, > puisque c'est une bidouille crade. Qu'est-ce que tu appelles une vraie agrégation ? (Ici se font sentir mes lacunes sur le réseau pur) > Si j'ai bien une préco dans ce genre de cas : dégager les load balancers > à pas cher, et prendre plutôt un vrai FAI. Oui, c'est pas le même budget > : de deux forfaits à 30€ tu passera probablement à un récurent mensuel > de plusieurs centaines d'euros. Mais si l'objectif est d'avoir un réseau > propre, c'est un passage obligatoire. Sur les clients auxquels je pense c'est plus ou moins le cas, fibre chez Completel (on fait ce qu'on peut) ou Orange dans le meilleur des cas et une ADSL au cas où. Dans ces cas-là, l'ADSL n'est qu'en failover, mais la problématique reste la même. > Une fois que le lien est propre, il te faut un routeur assumant les > services LAN. DHCP (v4 et v6), DNS et firewalling ne peuvent être gérés > avec assez de souplesse par un Mac OS X server sans mettre les mains > dans le camboui au point d'en faire une boite noire ressemblant plus à > FreeBSD. Ça, c'est mon affaire :-) Effectivement la GUI d'administration d'OS X Server est extrêmement limité, mais pas le service web qui permet son fonctionnement, il y a une étape intermédiaire avant de retomber sur FreeBSD Quoi qu'il en soit, il n'y a que le DNS que je gère réellement sur OS X Server, le firewall et le DHCP sont faits par les routeurs la plus part du temps. > Ensuite ton adresse locale est composée d'un préfixe pseudo unique (tu > peux le générer et le répertorier là par exemple : > http://www.sixxs.net/tools/grh/ula/ ). Ce préfixe ne dépend pas de ton > fournisseur, et n'est pas routé sur Internet (par contre tu peux le > router comme tu veux sur ton réseau). En gros, comme les adresses > privées IPv4 sauf qu'en plus le préfixe a très peu de chances d'être le > même que celui d'une autre boite. Comment est-il annoncé ce préfixe local ? On peut donc se baser sur ce lien local pour monter toute l'archi interne (nom DNS interne pour le split, etc) et laisser l'autoconf gérer pour l'adresse routable sur Internet. Existe-t-il un service DHCPv6 pour l'adresse locale ? >> Il me semblait avoir lu qu'une IPv6 incomplète est recomposée à partir du >> préfixe actuel, est-ce le cas ? > > Je ne suis pas sûr de comprendre la question... Une IPv6 c'est 64 bits > de préfixe et 64 bits d'identifiant d'interface. Les 64 bits du début > sont donnés par le routeur, et les 64 bits de la fin sont au choix de la > machine (à condition de ne pas créer une adresse en double). Je précise ma question, lorsque j'ai commencé à m'intéresser à l'IPv6 j'ai lu un article disant que lors d'un accès à une IPv6, si le début était le même que l'adresse locale, alors on pouvait l'éviter En gros si mon IP local est 2001:0db8:0000:85a3:0000:0000:ac1f:8001 et que je cherche à contacter 2001:0db8:0000:85a3:030a:0020:ac1f:8001 je pourrais écrire simplement :::030a:0020:ac1f:8001. Est-ce vrai ? (Quelques problèmes quant à savoir quelle source sont valables sur le net à ce sujet) >> Pour un premier message sur cette liste je vais commencer par me présenter >> brièvement, je suis Yoann Gini, formateur et consultant Apple sur tout ce >> qui concerne Mac OS X et Mac OS X Server en entreprise > > OSX a un bon support v6 et apple se sert de v6 pour back to my mac > http://www.ietf.org/id/draft-zhu-mobileme-doc-02.txt > Curieux que vous n'ayez pas d'info de leur part ! Ça fait partie des joies du travail avec Apple (je travaille en freelance, pas en salarié). Ils ont plein de trucs super fun en interne, mais ils n'en donnent que la moitié, voir moins… >> - Sans forcément avoir de multiWAN, si je change de FAI je change de préfixe >> IPv6, or le réseau a été construit à partir de ce préfixe (service interne, >> DNS, etc.). Actuellement si je change de FAI je n'ai aucun problème >> puisqu'en interne je n'ai que des IP privés. Avec l'IPv6 je ne vois pas trop >> comment on peut gérer ce cas, est-ce qu'il faut refaire tout l'adressage >> avec le changement de fournisseur ? > > Premièrement vous devriez utiliser un DNS interne pour ne pas utliser les IP > directement. Dans ce cas le changement est facile, c'est juste l'ajout de > nouvelles IP, et un changement des enregistrement DNS. > Mais dans la plupart des cas seules quelques IP sont présentées au net pour > les services. Dans le cas d'un applicatif web, personne n'a besoin de savoir > les IPs des serveurs SQL, etc. > Il est possible de garder les IPs que votre premier FAI vous a fourni, même > si elle ne sont alors plus routable globalement, d'ajouter de nouvelles IP au > interfaces pour ajouter un accès net (mise a jour de securite, etc.) mais les > applications marcheront toujours en interne en utilisant l'adressage du > premier FAI. Ceci dit je ne vois aucune raison pour utiliser les IPs dans les > applications. Bien évidement je n'utilise que du DNS en interne, jamais d'IP ! C'est surtout pour savoir s'il y a un moyen de rendre le changement de préfixe transparent pour le DNS interne. Bien que ça n'arrive pas souvent et qu'il n'y a généralement pas beaucoup d'entrée dans le DNS, j'essaye toujours de prendre la solution qui nécessite le moins d'action de ma part :-) > Maintenant l'utilisation de l'adresse MAC n'est qu'un option > d'auto-configuration, pour des machines qui fournissent des services > publiques ce n'est surement pas très judicieux. > Router les IP en V6 comme en V4 avec DHCPv6 ou une configuration des machines > avec des IPs statiques me parait plus judicieux. > > L'auto configuration c'est bien pour les cas de "plug and play". C'est plus ou moins ce que je pensais faire. Les serveurs en statique, c'est plus pour les postes clients que je pensais user de l'autoconf (sauf nécessité de pousser des infos en plus) >> - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer >> la répartition de charge sans faire de NAT ? > > Je ne vois pas de difference avec v4 - pourquoi penses-tu que c'est plus dur > en IPV6 ? > Comment fais-tu normalement ta répartition de charge ? Actuellement ma répartition de charge se fait sur le routeur, il s'occupe de prendre la connexion WAN la moins occupée et fait le NAT en fonction. Sans NAT et avec deux préfixes différents, comment le routeur va gérer l'histoire ? Si la connexion est émise depuis le client avec le préfixe de la connexion A alors qu'il faut user du B, ça se passe comment ? Rien ne garantit qu'un client ai le même identifiant peu importe le préfixe, si ? > Tout le monde n'a pas de service publique. Beaucoup des services sont utilise > via DNS, alors un changement c'est un changement le TTL, puis un changement > d'IP et voila. > Très peu de services utilisent les IP directement de nos jours. Mon problème était plus sur la gestion des services interne s'il y a changement d'IP, mais d'après ce que je viens de lire, ce n'est pas justifié. Je pense qu'il y a quelques questions basiques dans le lot qui sont dû à l'impossibilité de pratiquer l'histoire. En tout cas merci pour vos réponses !
