Toute machine faisant partie d'Internet doit avoir une ou plusieurs adresses IP publiques. Les adresses IP publiques font partie des ressources qui doivent être uniques au niveau mondial : il ne peut y avoir deux adresses IP publiques utilisées au même moment par deux machines, de la même manière qu'un numéro de téléphone est attribué une et une seule fois à une seule et même personne. Il y a évidemment des exceptions qui confirment la règle, comme l'anycast.
Les adresses IP sont limitées en nombre : il y a 2^32 IPv4 et 2^128 IPv6 différentes. Il faut donc distribuer ces ressources de manière cohérente au niveau mondial pour éviter les doublons et aussi, soyons réalistes, pour déterminer des responsabilités (exemple : une attaque informatique vient de telle IP, qui en est le propriétaire ?).
La meilleure façon de réaliser une distribution cohérente de ressources c'est de tenir un annuaire (telle adresse, je l'ai attribué à telle personne). On se rend compte que ce modèle centralisé ne passe pas à l'échelle du monde.
Depuis la fin des années 1990, l'IANA (bras droit de l'ICANN pour la technique) est au sommet de la pyramide de distribution. Cette organisation de droit état-unien distribue des blocs d'adresses IP à des entités dites régionales, les RIR (Regional Internet Registry). Il existe 5 RIR :
Les RIR découpent les blocs d'adresses qu'ils reçoivent et les attribuent à leurs membres qui sont nommés LIR (Local Internet Registry) et qui partagent les coûts de gestion de cet annuaire et les coûts de fonctionnement des structures comme les RIR.
Ces LIR (qui sont généralement des opérateurs réseaux) peuvent utiliser les blocs d'adresses qu'ils obtiennent pour leur usage propre et/ou en distribuer une partie à d'autres entités finales : des opérateurs réseau.
Selon la législation locale, les opérateurs réseau peuvent être tenus de tenir un journal indiquant à qui ils ont attribués telle adresse IP entre telle heure et telle heure. C'est le cas en France.
Une ressource dite « Provider Independent » (PI) est attribuée à une entité finale. Même si cette entité décide de changer de LIR, elle conserve les ressources qui lui ont été attribuées. Une ressource dite « Provider Aggregatable » (PA) “appartient” au LIR qui la sous-loue. Changer de LIR dans ce cas-là revient à perdre ses ressources.
Il n'est plus possible d'avoir des blocs IPv4 PI à cause de la pénurie sauf à acheter des adresses sur le marché gris… Ce qui n'est pas cool ni ne doit être encouragé : les adresses IP, c'est comme l'air, une ressource commune que l'humanité se doit de gérer en commun sans la facturer (mais facturer sa bonne gestion commune n'est pas exclu).
Il est possible d'avoir des blocs IPv6 PI et des numéros d'AS PI. Sous l'égide du RIPE, il faut néanmoins contracter avec un LIR qui sera sponsor LIR, c'est-à-dire référant administratif auprès du RIPE pour le maintient d'un contact, le RIPE cherchant à éviter les erreurs du passé (des blocs attribués à on ne sait plus vraiment qui dont la récupération pour les remettre dans le pot commun est extrêmement difficile). Les ressources appartiennent néanmoins à l'entité finale, pas au LIR, qui peut donc changer de sponsor LIR à tout moment sans perdre ses ressources.
Il y a des LIR associatifs (Gitoyen, Tetaneutral.net,…) et des LIR commerciaux mais avec une forme juridique sympathique (OpDop (SCIC), Absolight (SCOP)) en France ou en Europe.
En février 2013, nous avons choisi OpDop. Pour quelles raisons ?
De la PA non-routée ?
En très grande majorité, les LIR sont des opérateurs réseau qui deviennent LIR car ils proposent des services sur IP (transit IP, hébergement,…) ce qui fait qu'ils ont besoin d'attribuer des adresses IP à leurs clients. On note donc une dépendance entre un service sur IP et le service de fourniture d'adresses en lui-même : rompez le contrat de service et vous perdez vos adresses.
Comme ces entités sont des opérateurs, les RIR leur impose d'annoncer l'intégralité du bloc qu'ils ont reçus. Les différentes normes techniques et bonnes pratiques imposent à un opérateur qui annonce un bloc sur Internet de savoir joindre chaque adresse de ce bloc. C'est ainsi que, même si vous choisissez un autre transitaire, vous devez quand même monter une liaison physique (ou logique si le LIR est arrangeant) avec votre LIR pour ce besoin précis. Cette liaison sert également à récupérer le trafic résiduel émis par les opérateurs qui ignoreraient ou ne recevraient pas votre annonce BGP plus spécifique et enverraient donc le trafic qui vous est destiné à votre LIR. Vu les coûts (de mise en place puis récurrents) de ces liaisons physiques, ce n'est pas rien.
OpDop fournit des services à destination des opérateurs (OpDop = opérateur d'opérateurs ;) ). OpDop s'interdit de mélanger service sur IP et fourniture d'adresses. OpDop n'a aucune infrastructure technique et n'est donc pas opérateur. Donc OpDop n'annonce pas le bloc d'adresses qu'il a reçu du RIPE. Donc il n'est pas nécessaire d'avoir une liaison vers OpDop. Chaque client d'OpDop annonce le bloc d'adresses qu'il a reçu et c'est tout. Si le client quitte OpDop, c'est que le litige porte forcément sur la manière d'attribuer les adresses puisque cette prestation n'est liée à aucun service donc le fait de perdre ses ressources (principe du PA) est légitime.
La critique négative adressée envers la pratique d'OpDop est qu'elle contribuerait à faire grossir inutilement la table de routage globale d'Internet. En effet, puisque chaque client d'OpDop annonce lui-même son bloc, cela ajoute autant de lignes dans la table de routage alors qu'il y aurait une seule ligne si OpDop annonçait l'intégralité de son bloc d'adresses. La conséquence de cela est que ça forcerait les opérateurs à investir toujours plus dans des routeurs capables de gérer une table de routage toujours plus grosse : les cartes à l'intérieur des routeurs qui se chargent de transférer les paquets ont une capacité mémoire (TCAM) limitée car ce type de mémoire coûte cher. La pratique d'OpDop irait donc à l'encontre du principe du type « Provider Aggregatable » qui visait à ne pas faire exploser la taille de la table de routage mondiale.
Cette critique ne nous atteint pas :
Cette partie n'est pas un encart publicitaire inséré par notre LIR, juste un retour d'expérience et une documentation de ce que nous avons retenus et compris après avoir écoutés plusieurs personnes / LIR.
Nous utilisons chaque IP individuellement : il n'y a pas de notions de network/broadcast. Le plan d'adressage ci-dessous est indicatif : nous n'avons pas réellement un /27 dédié à notre infra propre ni une route /27 : juste des /32 contiguës. L'indication « /27 » permet de communiquer facilement entre admins (on sait à partir de quelle adresse commence et termine la partie infra, par exemple). Cela permettrait également d'agréger les routes en réseau pour une diffusion plus aisée dans un protocole de routage interne. Chose que nous ne faisons pas. Seule exception qui confirme cette règle : notre serveur OpenVPN vers lequel est bien routé le /26 indiqué ci-dessous.
Toutes les interconnexions (entre une machine virtuelle et son hyperviseur, entre une machine d'un-e abonné-e hébergée dans notre baie et nos routeurs, entre nos deux routeurs/hyperviseurs, entre les hyperviseurs et les PDUs,…) sont adressées avec des adresses IP locales au lien (voir ci-dessus) afin d'économiser nos IP publiques. Cela permet aussi de s'abstraire des contraintes matérielles : une machine virtuelle ne sait pas sur quel hyperviseur elle est exécutée à un instant T : il faudrait donc modifier son routeur de sortie à chaque migration d'un hyperviseur à un autre ? C'est ingérable. De par leur nature même, une adresse IP locale au lien peut être utilisée sur autant d'interconnexions que désiré. Donc la TAP de chaque machine virtuelle est adressée avec une IP locale au lien, toujours la même et zooout : une seule et même adresse à indiquer comme routeur de sortie dans chaque machine virtuelle. Seule exception : notre service de VPN utilise une interconnexion adressée avec des IP publiques car OpenVPN ne semble pas pouvoir faire autrement simplement.
Un IP Address Management est un logiciel qui permet de savoir à quel-le abonné-e à un service on a assigné telles adresses/blocs IP (v4 et v6), sur telle période de temps. Ce type de logiciels permet aussi de faire des stats sur le taux d'utilisation d'un bloc IP, Enfin, ils permettent de créer facilement / automatiquement des reverses DNS.
Nous n'avons pas de gros besoins : nous ne faisons pas d'adressage dynamique, nous savons gérer nous-même les reverse (ou les calculer avec sipcalc), nous savons faire des stats d'utilisation nous même. Toutefois, nous avons finalement opté pour gérer les IPs avec COIN.
Pour apprendre comment concevoir un plan d'adressage qui tienne la route c'est-à-dire qui corresponde aux besoins que vous vous fixez tout en permettant une évolution future aisée, la vidéo de LDN est une très bonne source d'infos : Adressage IPv6/IPv4. Voir aussi les documents du RIPE (qui permet de prendre connaissance des contraintes comme un /36 par site, un seul /48 pour l'infra par site, etc.) : https://www.ripe.net/support/training/material/ripe-ncc-training-material#IPV6
Le backbone sert à adresser tout ce qui est routage interne (routeurs, transit/peering, sondes, etc.).
89.234.141.0/24 (89.234.141.0 - 89.234.141.254)
/26 ADSL & VPN -- 64:0-63
/27 INFRA -- 32:64-95
/27 VPS & housing -- 32:96-127
(attention, ce découpage pourra varier en fonction du nb d'abonnés à chaque service)
96/28 - VPS -- 16:96-111
111/28 - housing -- 16:112-127
/28 BACKBONE -- 16:128-143
/28 VPS -- 16:144-159
/27 VPS -- 32:160-191
/27 VPN Wireguard test-- 32:192-223
2a00:5881:8100::/40
2a00:5881:8100::/40
2a00:5881:8100::/44
2a00:5881:8100::/48 : Infra
2a00:5881:8100:0000::/56 : routage (en /112 par interco, 2a00:5881:8100::<ID>:[12])
2a00:5881:8100:0100::/56 : intercos VPN
2a00:5881:8100:0100::/64 : interco VPN - utilisé
2a00:5881:8100:0200::/56 : collecte ADSL
2a00:5881:8100:0300::/56 : sondes
[gap]
2a00:5881:8100:1000::/52 VMs d'infra (services) en /56
2a00:5881:8100:1000::/56 VMs simples sans subnet (/64)
2a00:5881:8100:1100:0000::/56 VMs avec subnet
[gap]
2a00:5881:8100:ff00::/56 : Intercos externes
2a00:5881:8102:: - 2a00:5881:810F:: Réserves
2a00:5881:8110::/44 -> déclaré en fourre-tout de /56 au RIPE
2a00:5881:8110::/48 VPS = 256 VPS
2a00:5881:8110:0000::/48 VPS 0
Réserve 3* /48 (8111 + 8112 + 8113)
2a00:5881:8113:ff00::/48 VPS X
2a00:5881:8114::/48 housing = 256 réseaux d'hébergés
2a00:5881:8114:0000::/56 : hébergé 0
Réserve 3 * /48 (8115 + 8116 + 8117)
2a00:5881:8117:ff00:/48 hébergé X
2a00:5881:8118::/48 VPN = 256 VPN
2a00:5881:8118::0000::/56 : VPN 0
Réserve 3 * /48 (8119, 811a, 811b)
2a00:5881:811b::ff00::/48 : VPN X
2a00:5881:811c::/48 ADSL/FO = 256 ADSL/FO
2a00:5881:811c::0000::/56 : ADSL/FO 0
Réserve 3 * /48 (811d, 811e, 811f)
2a00:5881:811f::ff00::/48 : ADSL/FO X
-> fin du fourre-tout
2a00:5881:8120::
Futurs nouveaux services innovants d'ARN (14 * /44)
2a00:5881:81ff::
89.234.141.0/24 (89.234.141.0 - 89.234.141.254)
0/26 ADSL & VPN -- 64:0-63
.1 serveur VPN -> IP de la passerelle sur tun0
.63 IP qu'openvpn n'utilise pas
64/27 INFRA -- 32:64-95
.64 ext (VM 0) ->
.65 ns0 (LXC) -> Serveur DNS qui fait autorité pour arn-fai.net, sans-nuage.fr et netlib.re
.66 recursif (LXC) -> Serveur DNS pour la résolution
.67 mail (LXC) -> (plus utilisée, migrée sur VM yunohost)
.68 web (LXC) -> netlib.re
.69 int (VM 1) ->
.70 puppet (LXC) -> Gestionnaire de configuration des machines
.71 radius (LXC) -> (VM supprimée.)
.72 zabbix (LXC) -> Serveur de monitoring
.73 VPN (VM 2) -> Serveur openVPN
.74 Forum Discourse (VM)
.75 adh (sur int)
.76 lineageos (VM) -> Machine virtuelle pour le bridge Whatsapp
.77 servicesadh (VM 4) -> sans-nuage.fr
.78 yunohost (VM) -> mail, web, coin
.79 rescue -> VM de secours pour les VPS des membres ARN
.80 servicespublics -> Services publics sans-nuage.fr
.81 coloc
.83 wireguard
.94 AES-VPN -> VPN temporaire, routé sur la VM VPN
96/27 VPS & housing -- 32:96-127
96/28 - VPS -- 16:96-111
111/28 - housing -- 16:112-127
129/28 BACKBONE -- 16:128-143
.129 Laptop d'un admin dans le DC
.130 master ganeti
.131 hwhost-1
.132 hwhost-2
.133 hwhost-3
.134 hwhost-4
144/28 VPS -- 16:144-159
160/27 VPS -- 16:160-191
192... Non utilisé
TODO
Découpage correspondant (abandonné car trop peu flexible) :
/26 accès -- 64:0-63 /27 VPS -- 32:64-95 /27 VPN -- 32:96-127 /29 infra -- 8:128-135 /29 back -- 8:136-143
Source de toute cette partie : lulu (pseudo d'un des gérants d'OpDop), IRC, 27/07/2013.
2a00:5881:8100::/40
On utilise des IPs locales au lien (voir https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml et https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml) pour plusieurs choses :
Attention : bien que 169.254.0.0/16 est réservé à l'IANA pour cet usage, Linux ne les considère pas comme des adresses link-local : il faut donc préciser « scope link » dans /etc/network/interfaces ou ip addr add.
Pourquoi le troisième octet IPv4 est 12, 42 ou 69 ? Aucune raison, c'est choisi au pif. ;)