Alsace Réseau Neutre

Outils pour utilisateurs

Outils du site

Piste :
benevoles:technique:adressage

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
benevoles:technique:adressage [2021/10/11 16:17] – ↷ Page déplacée de atrier:technique:adressage à benevoles:technique:adressage ljfbenevoles:technique:adressage [2024/10/20 11:06] (Version actuelle) – ced117
Ligne 48: Ligne 48:
 ** De la PA non-routée ?** ** 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 ([[atrier:technique:routage#qu_est-ce_qu_un_transitaire|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.+En très grande majorité, les LIR sont des opérateurs réseau qui deviennent LIR car ils proposent des services sur IP ([[benevoles:technique:routage#qu_est-ce_qu_un_transitaire|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 [[atrier:technique:routage#qu_est-ce_qu_un_transitaire|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.+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 [[benevoles:technique:routage#qu_est-ce_qu_un_transitaire|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. 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.
Ligne 71: Ligne 71:
 ===== Topologie ARN ===== ===== Topologie ARN =====
  
-**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 [[atrier:technique:routage|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.+**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 [[benevoles:technique:routage|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. 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.
Ligne 111: Ligne 111:
   /28 BACKBONE          -- 16:128-143   /28 BACKBONE          -- 16:128-143
   /28 VPS               -- 16:144-159   /28 VPS               -- 16:144-159
 +  /27 VPS               -- 32:160-191
 +  /27 VPN Wireguard test-- 32:192-223
  
  
Ligne 178: Ligne 180:
      
     .64      ext (VM 0)     ->      .64      ext (VM 0)     -> 
-    .65        ns0 (LXC)      -> Serveur DNS qui fait autorité pour la arn-fai.net, sans-nuage.fr et netlib.re+    .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     .66        recursif (LXC) -> Serveur DNS pour la résolution
-    .67        mail (LXC)     -> Serveur mail arn-fai.net +    .67        mail (LXC)     -> (plus utilisée, migrée sur VM yunohost) 
-    .68        web (LXC)      -> Site arn-fai.net+    .68        web (LXC)      -> netlib.re
    
-    .69      int (VM 1)+    .69      int (VM 1)     -> 
     .70        puppet (LXC)   -> Gestionnaire de configuration des machines     .70        puppet (LXC)   -> Gestionnaire de configuration des machines
-    .71        radius (LXC)   -> Serveur d'authentification+    .71        radius (LXC)   -> (VM supprimée.)
     .72        zabbix (LXC)   -> Serveur de monitoring     .72        zabbix (LXC)   -> Serveur de monitoring
    
-    .73      VPN (VM 2)     -> Serveur openVPN+    .73      VPN (VM 2)       -> Serveur openVPN 
     .74      Forum Discourse (VM)     .74      Forum Discourse (VM)
-    .75      adh (sur int)  -> COIN + 
-    .76      lineageos      -> Machine virtuelle pour le bridge Whatsapp+    .75      adh (sur int) 
 + 
 +    .76      lineageos (VM)   -> Machine virtuelle pour le bridge Whatsapp 
     .77      servicesadh (VM 4) -> sans-nuage.fr     .77      servicesadh (VM 4) -> sans-nuage.fr
-    .94      AES-VPN (VPN temporaire, routé sur la VM VPN)+ 
 +    .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/27 VPS & housing     -- 32:96-127
Ligne 205: Ligne 222:
   .131    hwhost-1   .131    hwhost-1
   .132    hwhost-2   .132    hwhost-2
 +  .133    hwhost-3
 +  .134    hwhost-4
          
 144/28 VPS               -- 16:144-159 144/28 VPS               -- 16:144-159
 +160/27 VPS               -- 16:160-191
  
-160... Non utilisé+192... Non utilisé
 </code> </code>
      
Ligne 269: Ligne 289:
 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 : 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 :
  
-  * Lien direct entre les deux machines physiques (pour [[atrier:technique:routage|iBGP]] et DRBD) : 169.254.69.0/24 et fe80::69:0/112+  * Lien direct entre les deux machines physiques (pour [[benevoles:technique:routage|iBGP]] et DRBD) : 169.254.69.0/24 et fe80::69:0/112
  
   * Interface TAP d'une machine virtuelle (utile pour forwarder les paquets à un routeur depuis une machine virtuelle sachant qu'on ne connaît pas l'hyperviseur/routeur sur lequel la VM est exécutée + économie d'IPs publiques) : 169.254.42.0/24 et fe80::42:0/112   * Interface TAP d'une machine virtuelle (utile pour forwarder les paquets à un routeur depuis une machine virtuelle sachant qu'on ne connaît pas l'hyperviseur/routeur sur lequel la VM est exécutée + économie d'IPs publiques) : 169.254.42.0/24 et fe80::42:0/112
  
-  * 169.254.43.0/24 et fe80::43:0/112 sont aussi utilisés pour l'hébergement des machines physiques dans notre baie, pour les mêmes raisons car nous utilisons [[atrier:technique:carp|CARP]].+  * 169.254.43.0/24 et fe80::43:0/112 sont aussi utilisés pour l'hébergement des machines physiques dans notre baie, pour les mêmes raisons car nous utilisons [[benevoles:technique:carp|CARP]].
  
-  * Réseau contenant les [[atrier:technique:pdu|PDU]] : 169.254.12.0/24 et fe80::12:0/112 (réservé en avance mais nos PDUs actuels ne prennent pas en charge IPv6)+  * Réseau contenant les [[benevoles:technique:pdu|PDU]] : 169.254.12.0/24 et fe80::12:0/112 (réservé en avance mais nos PDUs actuels ne prennent pas en charge IPv6)
  
 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. 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. ;) Pourquoi le troisième octet IPv4 est 12, 42 ou 69 ? Aucune raison, c'est choisi au pif. ;)
benevoles/technique/adressage.1633961848.txt.gz · Dernière modification : de ljf