Tout le monde le sait, on ne cesse de nous rabâcher la même prophétie, bientôt c’est la fin du monde !!!
Enfin, outre la fameuse année 2012, qui a déjà pris de l’avance sur le site http://www.2012fin.com (n’y aller pas !! en plus il est vérolé !!!) si j’en crois le résultat suivant :
C’est surtout la diminution constante des adresses IPv4 publiques disponibles qui continue son oeuvre.
Bien évidemment, depuis quelques années déjà, IPv6 est la réponse a ce problème, mais bon, cela ne sera pas en place partout avant bien longtemps, donc pas de cris paniqués, de viols incongrus, d’immolations inconsidérées ou de bitures monumentales (euh quoique…), IPv4 a encore de beaux jours devant lui.
Quoi qu’il en soit, il était temps de me dépoussiérer un peu et de replonger dans les méandres d’IPv6 et de remettre cela en oeuvre dans mon architecture.
Mes connaissances en IPv6 étant plus qu’anciennes, je me suis donc remis à niveau à coup de lecture multiples sur des sites divers et variés, allant des RFC aux blogs.
La liste étant particulièrement imposante, je vous laisse plutôt vous promener sur Google.
Un des sites les plus amusants pour se remettre a niveau est Hurricane Electric, un provider Internet et également Tunnel Broker IPv6, qui vous propose de passer votre Certification IPv6 à travers une série de questionnaire et d’exercices pratiques a mettre en place (exemple vous rendre sur le site via une connexion IPv6, monter un MX IPv6, des DNS IPv6 etc…), bref des étapes amusantes qui vous permettent de progresser dans votre apprentissage/remise à niveau, tout en maquettant votre future architecture.
Pour la Certification, cela se passe la : http://ipv6.he.net/certification/
Au fur et a mesure vous changez de niveau (newbie, explorer, enthusiast, administrator, professional, guru et enfin sage). Validé bien sûr par un « zoli » diplôme et un lien vers vos résultats a mettre sur votre site :
ah ah ah 😀
Bref, très instructif et amusant pour bosser IPv6 (je sais, les geeks ont des jeux bizarres…)
Fort de ma remise à niveau, il était temps de déployer IPv6 tout autour de ma sphère personnelle.
Un petit panaché donc des différents environnements et situations que j’ai rencontré et dont, je pense, l’un d’entre eux répondra à vos attentes.
RAPPEL DES FAITS
Non, je ne vous ferais pas un cours sur IPv6, mais il faut bien évidemment revoir nos classiques et surtout la façon dont fonctionne l’adressage IPv6.
Pour commencer, je vous invite a lire la page Wikipédia.
Maintenant, vous savez qu’une adresse IPv6 est longue de 128 bits contre 32 en IPv4.
De plus, l’écriture est au format hexadécimal et non décimal.
Pour résumer :
| Espace d’allocation | Fournisseur d’accès | Client | Réseau | Identifiant | |
|---|---|---|---|---|---|
| Bits | 0-15 | 16-31 | 32-47 | 48-63 | 64-127 |
| Exemple | 2001: | 0660: | 315f: | c242: | 20d:60ff:fe38:6d16 |
Mais s’il y a un « schéma » qui m’a permit de tout comprendre, c’est celui la :
2001:12d3:4:56 00: 0000:0000:0000:0000 \____________/ \_/ \..._/ partie réseau s/s partie pour l'identifiant (56) (8) (64) |
Si vous avez un /64, vous avec donc les 56 premiers bits+ les 8 bits de sous réseau + 64 bits pour vos machines (en gros cela nous fait 18 milliards de milliards d’adresses IP à votre disposition…)
Si vous avez un /56, vous avez donc les 56 premiers bits + 2^8 (256) sous réseaux X 2^64 adresses IP (18 446 744 073 709 551 616)…
Donc avec un /56 vous avec 256 sous-réseaux de 18 milliards de milliards d’adresses IP chacun… (un peu too much, non ?… 😉 )
Et bien sur, vous pouvez encore redécouper (/126, /120, /112 etc…).
Plus clair 
?
ATTENTION : Une remarque importante, iptables ne contrôle pas les flux IPv6 sur vos interfaces. Il faut utiliser ip6tables pour protéger vos accès. N’oubliez donc pas de configurer en plus d’iptables, un ip6tables sur vos serveurs/pc… (et de, surtout, laisser l’icmp6 autorisé…)
CONNECTIVITE IPv6
Si vous êtes dégroupé chez Free (ou chez Nerim), vous avez la chance d’avoir un adressage IPv6 disponible rien que pour vous.
Malheureusement, étant non-dégroupé, je n’ai pas cette option, comme de nombreuses personnes chez d’autres FAI (quand je vous disais que vous avez de beaux jours en IPv4, les FAI ne sachant pas eux même faire fonctionner leurs architectures en IPv6 de bout en bout…).
La solution est le tunnel « 6to4 ».
Un tunnel « 6to4 » permet de relier un réseau Ipv4 au réseau IPv6.
Les principaux fournisseurs de tunnels 6to4 sont :
-Hurricane Electric http://www.tunnelbroker.net
-Gogo6 (Freenet6) http://www.gogo6.com
-Sixxs http://www.sixxs.net
Je ne me lancerais pas dans un comparatif mais pour avoir utiliser les trois, j’ai un faible pour Gogo6 dont la facilité d’installation et la stabilité du tunnel m’ont bien plu.
Une fois enregistré chez eux, il en vous reste qu’a télécharger le source d’installation pour Linux (ou autre hein…) la : http://gogonet.gogo6.com/page/download-1
Compilation basique (make, make installdir=/usr/local/bin/gogoc install) et configuration des plus simples (userid, mot de passe et server=authenticated.freenet6.net bref lire le fichier de conf)
Il ne reste qu’a lancer l’executable (/usr/local/gogoc/bin/gogoc par exemple) pour voir un nouveau tunnel se monter dans vos interfaces réseaux :
tun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 adr inet6: 2001:5c0:1400:b::5b43/128 Scope:Global |
et voila, vous avez un accès IPv6 :
server:/usr/local/gogoc/bin# ping6 ipv6.google.com PING ipv6.google.com(2a00:1450:8007::6a) 56 data bytes 64 bytes from 2a00:1450:8007::6a: icmp_seq=1 ttl=55 time=60.4 ms |
simple non ?
Par votre navigateur Internet, a vous la joie de voir la tortue Kame gigoter pour prouver que vous utilisez une connexion IPv6.
SERVEURS DEDIES OVH
Ayant des serveurs chez OVH, ce dernier vous attribue une plage d’adresses IPv6 a utiliser sur votre serveur.
Pour cela rien de plus simple, se rendre dans son « Manager », sur la page « serveur dédié », et récupérer le /64 qui vous est attribué.
Le guide est dispo ici : http://guides.ovh.com/Ipv4Ipv6
Rien de bien compliquer mais personnellement, j’en voulais un peu plus et donc utiliser aussi l’IPv6 dans mes machines virtuelles VMWare…
La cela se complique un peu plus mais la réponse je l’ai trouvé sur le blog Linux Attitude, grâce à un excellent tuto écrit par StalkR.
En fait, OVH ne vous attribue pas un simple /64 mais un /56… Ce qui fait que vous pouvez subnetter vos adresses IPv6 😀
Donc pour le /64 qui m’était par exemple attribué : 2001:12D3:4:5678::/64 j’ai donc à ma disposition le bloc suivant : 2001:12D3:4:5600::/56.
Ni une, ni deux, on se prend un petit subnet pour les VMs :
- 2001:12D3:4:5678::/64 pour les serveurs physiques
- 2001:12D3:4:5681::/64 pour les VMs.
(vous suivez toujours ? 2001:12D3:4:56.. est le bloc réseau que m’attribue OVH et j’ai pour moi 256 sous-réseaux (les 8 bits après le chiffre 56, pour créer mes subnets. Dans le cas présent …78.. et ..81.. (a vous de choisir dans la plage hexadecimal de 00 a FE).
A cet effet, une page web intéressante pour visualiser d’un coup tout cela : TABLE ASCII
Chaque sous-réseau disposant de 18 milliards de milliards d’adresses pour mes serveurs (honnêtement, je n’en ai pas autant…)
Un peu de tuning Kernel parce que je ne veux pas d’autoconfiguration.
Ah oui, j’ai oublié de vous parler de cela…
IPv6 a parmi ses facultés, celle d’autoconfigurer les interfaces réseaux et les routes dynamiquement grâce au « Router Advertisement« . En gros, cela permet a Mme Michu de ne pas se prendre la tête et d’avoir une configuration automatique (genre dhcp) annoncé par le routeur IPv6 en amont de sa connexion.
Je ne rentrerais pas dans le détail, (RADVD étant une excellente solution pour l’autoconfiguration de votre parc), car personnellement je tenais a maîtriser chaque étape de mon déploiement.
serveur:~# cat /etc/sysctl.conf ... net.ipv6.conf.eth0.autoconf=0 net.ipv6.conf.eth0.accept_ra=0 net.ipv6.conf.all.accept_redirects=0 net.ipv6.conf.all.router_solicitations=1 net.ipv6.conf.default.proxy_ndp=1 net.ipv6.conf.all.proxy_ndp=1 net.ipv6.conf.all.forwarding=1 |
Sur le serveur physique :
ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0 (1) ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff (2) ip route add 2001:12d3:4:5678::/64 dev vmnet1 (3) ip neigh add proxy 2001:12d3:4:56ff:ff:ff:ff:ff dev vmnet1 (4) ip neigh add proxy 2001:12d3:4:5681::1 dev eth0 (5) |
A ajouter dans votre /etc/rc.local par exemple pour que cela soit effectif à chaque reboot (sans les (1),(2) etc..) 😉 )
Explication :
(1) J’ajoute la route vers la passerelle sur l’interface eth0
(2) J’ajoute la passerelle IPv6 comme route par défaut
(3) J’ajoute une route vers mon subnet /64 dédié a mes VMs sur l’interface VMware
(4) Je demande a l’interface vmnet1 de répondre aux requêtes à destination de l’ip de la passerelle
(5) Je demande a l’interface eth0 de répondre aux requêtes à destination de l’ipv6 de ma VM.
On attribue l’IPv6 2001:12d3:4:5681::1/64 dans notre VM.
# IPV6 iface eth0 inet6 static address 2001:12D3:4:5681::1/64 netmask 64 |
On rajoute les routes dans /etc/rc.local
ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0 ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff |
Pas la peine de toucher au kernel pour la VM.
On reboot tout le bouzin (physique et virtuel) et hop, magique, la VM est accessible en IPv6 de l’extérieur 😀
SITE WEB
Les serveurs sont en IPv6, reste à rendre accessible votre site web.
Que votre serveur http soit Nginx, Apache ou autre, pas de grandes différences. (Attention, pour Nginx il faut compiler avec l’option –with-ipv6).
Juste se rappeler que les adresses IPv6 s’écrivent entre crochets.
On fait écouter le serveur sur l’IPv6 :
Listen [2001:41d0:2:67a::150]:80 |
Et on configure un vhost en conséquence :
NameVirtualHost [2001:41d0:2:67a::150]:80 ... |
Il ne vous reste plus qu’a ajouter une entrée de type AAAA dans votre DNS.
dig -t AAAA blog.guiguiabloc.fr ;; QUESTION SECTION: ;blog.guiguiabloc.fr. IN AAAA ;; ANSWER SECTION: blog.guiguiabloc.fr. 86400 IN AAAA 2001:41d0:2:67a::150 |
Et voila, le blog est accessible en IPv6 (j’ai même mis un joli logo en bas de la page ), et vérifié par ipv6forum.
IPv6 AVEC OPENVPN
Utilisant des tunnels openvpn entre mon domicile et mes serveurs OVH, bien entendu, l’idée de me servir du bloc d’adresses IPv6 d’OVH chez moi m’a tout de suite interpellé.
Comme pour les VMs, c’est assez triviale et plutot que de vous expliquez la procédure, je vous invite a lire les excellents tutos de GeekFault ou de Vincent Riquer.
La seule différence notable est que j’utilise Vyatta comme client Openvpn chez moi (en tant que routeur d’interconnexion VPN).
Pour la spécificité Vyatta, j’ai modifié l’interface de cette façon :
openvpn-option « –dev-type tap –dev vtap0 »
Ce qui me permet d’avoir une interface de type TAP et non TUN pour mon tunnel.
Vous pouvez ou utiliser RADVD comme décrit dans les tutos cités, ou utiliser le push ipv6 via le patch de Gert Döring , ou la même technique que pour les VMs.
CISCO et ADRESSAGE PRIVE IPv6
La on se spécifie un peu…
Si comme moi, vous avez monter un gros LAN des familles, l’idée d’utiliser des adresses IPv6 publiques vous enchantent moyennement.
Après tout, vous avez déjà un adressage privé IPv4, pourquoi ne pas continuer en IPv6.
Oyé, Oyé, l’adressage privé IPv6 existe.
Il a pour nom ULA (Unique Local Address) (a lire) et répond a la RFC 4193 (ex 3879).
Son plan d’adressage est le suivant : FC00::/7
( /7 ca fait un peu de monde… en fait /8 si l’on veut être propre)
Lire cet article également, et pour les connexions site à site et la technique pour générer des plans d’adressages ULA basés sur les MAC, lire : http://www.bortzmeyer.org/4193.html (ah ah ah, est-ce la fin des conflits des domaines d’encryption VPN 😀 (les habitués des tunnels ipsec comprendront…))
Bien, trêve de plaisanterie, passons a la pratique.
On se réserve un /48 pour la maison.
fd44:4ff0:adda::/48
Mise en place de la passerelle sur le routeur Cisco pour le vlan concerné :
Vlan concerné : 10
Adressage IPv6 : fd44:4ff0:adda:10::/64
cisco#conf t Enter configuration commands, one per line. End with CNTL/Z. cisco(config)#ipv6 unicast-routing cisco(config)#int fa 0/0.10 cisco(config-subif)#ipv6 enable cisco(config-subif)#ipv6 address FD44:4FF0:ADDA:10::1/64 cisco(config-subif)# cisco#ping FD44:4FF0:ADDA:10::1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FD44:4FF0:ADDA:10::1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms |
Sur un pc du vlan :
ifconfig eth0 inet6 add FD44:4FF0:ADDA:10::5/64 pc:# ping6 FD44:4FF0:ADDA:10::1 PING FD44:4FF0:ADDA:10::1(fd44:4ff0:adda:10::1) 56 data bytes 64 bytes from fd44:4ff0:adda:10::1: icmp_seq=1 ttl=64 time=1.09 ms 64 bytes from fd44:4ff0:adda:10::1: icmp_seq=2 ttl=64 time=1.10 ms |
Et voila, rien de bien compliqué.
Si vous souhaitez ajouter une route statique ou par défaut, par exemple vers FD44:4FF0:ADDA:33::5
cisco(config)#ipv6 route ::/0 FD44:4FF0:ADDA:33::5 |
Pour vos ACL même genre (ipv6 access-list)
Un petit blog a lire avec quelques trucs et astuces Cisco et IPv6 : http://www.gho.no/tag/ipv6/
Vous pouvez donc déployer IPv6 dans votre LAN sans être routé sur Internet.
Bien évidemment, rien ne vous interdit d’utiliser les adresses IPv6 publiques dont vous disposez.
Voila pour une approche tout en douceur de l’IPv6, j’espère que ce billet vous a donner envie de manipuler un peu IPv6 et de vous préparer à la Fin du Monde 😀
Amusez-vous bien 😉
Hello,
Super article comme toujours !
J’avais commencé un projet pour passer ma petite infra en IPv6 quand j’ai eu les cours sur IPv6 en Licence Pro, puis avec mon passage du premier CCNP BSI…
Mais, dés le départ j’ai eu le même problème que toi, Free non dégroupé !
J’avais mis en place un tunnel puis j’ai finalement arrêté en me disant que si les FAI eux-mêmes ne font pas d’efforts, j’ai encore le temps !
Ton article va peut être me remotiver à prévoir ça un de ces jours 🙂
salut Bastien et merci 😀
Tu as raison, si on attend le bon vouloir des FAI, nous ne sommes pas prêt de nous « amuser » 😉
Content que cet article t’es remué de « vieux » démons :-p
Humm j’ai pas finis de lire le billet complet mais au début une petite phrase ou j’ia un doute :
« Et bien sur, vous pouvez encore redécouper (/126, /120, /112 etc…). »
En ipv6 la partie Réseau utiliser sur un segment est fixe et c’est un /64. C’est pas possible de découper au-dessus. En effet sinon tous les protocole de neighboar discovery ne fonctionnerait plus, l’identifiant fait forcement 64 bits. Si je ne me trompe pas 🙂
Désolé, rien n’interdit de redécouper plus bas…
C’est vous qui souhaitait utiliser le neighbor discovery 😉
Cela fait quelques temps que les /120 sont utilisés dans des infra ipv6 interne, après c’est une question de choix d’architecture, personnellement, cela ne me choque ni derange pas de découper le segment réseau (et je ne suis pas le seul a le penser :p)
Pourquoi pas… Il va falloir que je monte une démonstration poussé pour convaincre un guigui a bloc sur les utilisations d’un masque supérieur à 64 en ipv6. Et j’aurais peut-être tord au bout de la démonstration en plus 🙂
Sinon quand je parle de neighboard discovery je parle aussi des autre protocoles autre que la configuration automatique comme par exemple le protocole de detection d’adresse dupliqué qui se basse quand même sur les 24 dernier bit de l’identifiant d’interface pour construire son adresse multicast solicité afin de savoir si l’adresse est unique sur le segment. Ca fait bizarre de se dire qu’on met une partie host sur 8bit avec un /120 et savoir que le protocole de détection d’adresse utilise les 24 dernier bit d’un host pour savoir si il est unique :). Y’a aussi les sollicitation de voisin qui permette par exemple de remplacer l’arp d’ipv4.
Mais est-ce que ça empêche vraiment le tous de fonctionner pleinement, va falloir se pencher sur la question.
Mais je comprend que derrière une freebox qui nous donne qu’un /64 on cherche à faire mumuse avec un peu de routage et qu’on cherche à segmenter. (bien qu’il y’ai un /56 par freebox mais non accessible pour les utilisateurs).
Après la RFC donne le format d’une adresse ipv6 avec un id d’interface (la partie host) de 64 bit. C’est vrai que pourquoi suivre l’ietf et leurs RFC à la con 🙂
Je ne remet nullement en question ce que tu dis 🙂
Tu as tout a fait raison sur le fait qu’un masque supérieur a /64 soit non conforme aux RFC (même les rfc3627 qui accepte le /127 dit que c’est pas bien :p ) et qu’évidemment, cela remet en cause les protocoles liés a la couche ipv6.
C’est bien pour cela que je parlais de « réseau interne » pour faire mumuse a router et découper. Il est évident qu’en prod et pour rester conforme, on ne découpera pas autant (quoi que 😀 )
(Maintenant, les RFC, meme Free route des classes d’adresses ipv4 RFC1918 côté Wan, alors on se dit qu’on peut déroger parfois à la règle :D).
Merci en tout cas de tes explications et implication.
Tu es sûr du /56 oO
bah oui, c’est même indiqué dans le guide OVH en anglais…
http://help.ovh.co.uk/Ipv4Ipv6
Le guide te dis que tu as le subnet :
2001:41D0:1:33c::/56
C’est comme dire que tu as l’IPv4
91.121.251.150/24
Cela ne veut pas dire que tu peux utiliser 91.121.251.* mais que tu as l’ip 91.121.251.150 avec 255.255.255.0 comme netmask…
Au final, tu peux donc utiliser (toujours avec l’exemple de la doc)
2001:41D0:0001:033c::* et pas 2001:41D0:0001:03??::*
2001:41D0:0001:033d::* est le bloc /64 du serveur d’a coté :/
et donc le guide en français parle d’un /64…
Allons, le RA annonce un /56 pas un /64.
Essaye de plus d’utiliser une autre adresse publique sur ton serveur, tu verras la reaction du switch d’ovh…
Je ne suis pas le seul a l’affirmer et a l’utiliser, tout comme Free annonce un /60 également.
Mais bon, tu fais comme bon te semble (tu trouveras meme une page d’ovh qui a en titre « Bloc ipv6 /56 » 😉 )
Réponse d’octave :
> Là l’article dit qu’on a un « /56 » et donc que je peux jouer avec 2001:41D0:2:35??::* ?
est-ce que tu as droit de jouer avec toutes les IP de la /24 ?
non.
alors non.
—
Après tu fais ce que tu veux hein … 😀
Faut que je retrouve l’explication du /56 d’octave, je dois bien avoir ça quelque part 🙂
Dans mes souvenirs, le principe est qu’ils utlilisent un routeur par /24 en ipv4. Pour déployer l’IPv6 le routeur annonce un /56 et a chaque ipv4 est associé un /64. Donc chaque réseau est en fait un /56 où au maximum 254 serveurs partagent 254 /64
Je suis curieux de voir une page officielle où on te dis que tu as le droit d’utiliser tout le /56 …
La réponse d’octave me fait autant rire que celle ou je lui ai demandé si je pouvais faire des requètes nagios intra-lan ovh sans alerter leurs sondes.
Demande lui plutot pourquoi il annonce un /56 dans ses RA alors ?
Demande lui aussi pourquoi il a annoncé le /56 il y a quelques temps puis corrigés en /64 juste dans la page commerciale (et encore pas tout corrigé).
Bref, entre ce que dit octave et la réalité il y a un monde.
On utilise des RA professionnellement parlant et on annonce des /64 dans nos RA…
Ca fait un bail que nombreux sysadmin utilisent du /56 en ipv6 chez OVH, et nul blocage ni avis contraire.
Tant qu’ovh m’annonce un reseau que je peux utiliser, que la correspondance MAC/IP du switch me laisse le faire, c’est que ca marche, mais que c’est pas tres officielle.
Une page officielle chez OVH annoncant clairement ce que tu peux ou pas faire ? tu rêves ???
Moi j’attends plutot un avis officiel disant qu’on ne peut pas utiliser un /56. Vu que tout leur systemes, leurs docs, et leurs réactions disent le contraire.
Pingback: GuiguiAbloc, un blog qui merite d'être connu, technique, reseau, linux, système - linux - geek
J’ai décroché au premier tiers 😀 Faut que je me mette à l’IP V6…
Je commence par la question: QUID du failover. Peut-on utiliser l’IPv6 avec les IP failover selon la même logique ? car si on utilise des IP selon ton modèle ci-dessus, celles-ci ne seront plus utilisable en cas de migration de la VM sur un autre serveur physique non ?
A part ça, pour moi, cette histoire d’IP V6 est une montre dépense d’argent inutile, lié à la monopolisation de réseaux IP V4 par des entreprises peu scrupuleuses, et historiquement mal informées. En effet, il y aurait bien assez d’adresses IP utilisable, à ma connaissance, si toutes les entreprises utilisaient des sous-réseaux privés pour tout ce qui est distribution de service en leur cein. C’est déjà le cas dans la majorité des cas.
Mais peut-être ai-je une fausse idée de la situation, et de toute façon, je ne vais pas changer le monde, alors direction les liens indiqués 🙂
Merci d’ailleurs pour ces liens très utiles.
Il n’y a pas d’ipv6 sur les ips failover MAIS le but d’ipv6 est justement… la mobilité ! http://www.faqs.org/rfc/rfc3775.txt et http://www.6diss.org/workshops/saf/mobility.pdf.
Par contre, comme pour la majorité des fournisseurs IPV6 (OVH ou Free…) ce n’est pas disponible… Offrir de la connectivité ipv6 en restant dans une logique ipv4 cela n’a aucun sens…
D’accord avec toi sur la fausse pénurie d’ipv4. Quand ont voit ce que HP, Xerox ou IBM ont commme blocs ipv4 inutilisés depuis des années…
@Thomas
OVH confirme bien qu’un /56 est alloué par serveur :
http://forums.ovh.net/showthread.php?t=72077
Euh, Hurricane Electric (ou les autres cités) ne font *pas* de 6to4 (et heureusement, c’est une mauvaise technique, à oublier). L’adresse IPv6 citée, 2001:5c0:1400:b::5b43, est une adresse de Gogo6, *pas* une adresse 6to4.
Tu joues sur les mots :p
C’est bien un service de tunnel permettant de relier un reseau ipv4 a un reseau ipv6 mais j’avoue avoir simplifier la demonstration pour la comprehension du neophyte. Bien evidemment je ne peux qu’inviter les personnes a vouloir peaufiner IPv6 a se tourner vers des blogs plus techniques a ce sujet (le tien par exemple :p)
Ce billet n’avait aucunement vocation a etre une référence technique a IPv6 mais une première approche simpliste 🙂
bonjour
je ni arrive pas
2 questions
1 : faut il modifier le .conf pour le routage IPv6 et le proxy NDP dans le kernel, j’utilise un kernel 3.2.0 chez ovh avec lxc
2 : c’est dans les vm qu’il faut appliquer ces 2 régles ?
ip route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0
ip route add default via 2001:12d3:4:56ff:ff:ff:ff:ff
car je ne piges pas encors bien le routage IPV6
pourqoi /128 ?
@ppb : 1- non 2- oui (c’est marqué « dans la VM »)
/128 parce que j’ai découpé mes blocs IPv6.
Re merci je bataillais.
autres :
Pour le /128 car 2 sous réseaux
et pour plus ?
donc j’ai 2 sous réseaux suivant :
mon adresse ip du serveur physique récolter par le manager ovh : 2001:41d0:2:60xx::1
des sous réseaux
1° em sou réseau: 2001:41d0:2:6xx1::/64
cahque ip 2001:41d0:2:6xx1::1
2001:41d0:2:6xx1::2
……………………….3
2°em sous réseau : 42001:41d0:2:6xx2::/6
ip 2001:41d0:2:6xx2::1
2001:41d0:2:6xx2::2
………………………3
ip route add 2001:41d0:2:60ff:ff:ff:ff:ff/128
et default via 2001:41d0:2:60ff:ff:ff:ff:ff
ça permet normalement aux VMs de sortirent
par contre pour y rentrer depuis inetrnet
tu donne comme exemple :
Listen [2001:41d0:2:67a::150]:80 le 80 je pige service www
le :2:67a tu le sort d’où ? d’un autre serveur physique
il est vrai je découvre l’ipv6
HAHAHA !!!
merci
et encor bravo
/128 c’est un host (1 adresse unique) (idem qu’un /32 en ipv4)
Tu as 128 bits donc tu découpes comme tu veux (si tu ne maitrises pas les decoupages, reste sur des /64).
Le :2:67a est un exemple d’un autre host.
re bonjour
et encor merci
bon je comprand pas un truc chez OVH
dans ton exemple tu donne comme passerelle 2001:12d3:4:56ff:ff:ff:ff:ff
l’exple d’OVH appliqué au tien serait 2001:12d3:4:5ff:ff:ff:ff:ff Donc qu’elle est la bonne solution ?
j’utilse une debian
donc mon network : intrefaces:
Pour avancer dans ma compréhension j’ai voulu ignorer l’ipv4
et donc voici les 3 solutions que j’ai voulu appliqer:
avec un ssh root@2001:41D0:2:xxxx:bad:cafe:bad:caca
config 1
et je reboot à chaque config
#iface br0 inet static
#address 94.23.xxx.xxx
#netmask 255.255.255.0
#network 94.23.xxx.x
#broadcast 94.23.xxx.255
#gateway 94.23.xxx.xxx
#bridge_ports eth0
#bridge_stp off
#bridge_fd 0
#bridge_maxwait 0
iface br0 inet6 static
address 2001:41D0:2:xxxx:bad:cafe:bad:caca
netmask 64
gateway 2001:41D0:2:xx:ff:ff:ff:ff:ff
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
pour verfier ci ça sort
le ping6 http://www.free.fr NADA
ssh ok
config 2
iface br0 inet6 static
address 2001:41D0:2:xxxx:bad:cafe:bad:caca
netmask 64
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
le ping6 http://www.free.fr NADA
ssh ok
config 3
iface br0 inet6 static
address 2001:41D0:2:xxxx:bad:cafe:bad:caca
netmask 64
gateway 2001:41D0:2:xxxx:xxxx:1 (mon adresse dans le manager ovh)
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
reboot
ssh impossible
donc un petit cout de rescue pro et on remet l’ancienne version
config 4
on remait l’ipv4 et on enleve la passerelle ipv6
et la ping6 http://www.free.fr ok
et je me connecte avec ssh
root@2001:41D0:2:xxxx:bad:cafe:bad:caca
le gateway déduit de chez ovh 2001:41D0:2:xff:ff:ff:ff:ff
ça ne marche pas
bon donc je pige pas OVH ne valide pas totalement l’IPV6 ?
Ha les régles seules bloque l’accé IPV6 en ssh
net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.eth0.accept_ra=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.router_solicitations=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1
net.ipv6.conf.all.forwarding=1
les regles IP6 qui suive ne doive pas s’appliquer com ceci ? ip -6 route add 2001:12d3:4:56ff:ff:ff:ff:ff/128 dev eth0 (1)
Pour différencier d’une règle ip4 ou alors le format de l’adresse permet cette différenciation
Je sais, j’harcelle de questions, mais mes VM ne sont toujours pas capables de sortir du serveur physique
Je précise c’est un kimsufi peut êtres sont ils particuliers ?
Très sympathiquement
pp
2001:12d3:4:56ff:ff:ff:ff:ff c’est pas 2001:12d3:4:05ff:ff:ff:ff:ff .
Je n’ai rien fait de particulier a part router depuis le serveur physique vers la VM (comme expliqué dans le billet).
Les confs ont peut etre changé, voir sur les forums OVH.