Une nouvelle maison pour le serveur

Posté le ∙ Classé dans materiel web

Voilà plusieurs années que mon vaillant petit serveur était branché tranquilou sur le 82.64.33.242. Je l’ai mis en service à l’été 2016 : le kit de connexion était simple : un Raspberry, une Freebox, une IP fixe gratuite (quel luxe), une connexion ADSL sur prise T et c’était parti. C’est resté comme ça jusqu’à ce mois d’Août.

Aujourd’hui, pour des raisons qui vont au-delà de la portée de ce site, le 82.64.33.242 n’est plus. Après déjà trois ans de bons et loyaux services j’ai donc du me résoudre à rapatrier le serveur là où je réside actuellement, au Québec. L’avantage de la manœuvre c’est que la connexion est 20x plus rapide étant donné ma connexion câblée. Et puis, en cas de coup dur, je n’ai pas à téléphoner à 5000 km pour demander à ce qu’on me redémarre la machine. Mais quand même en trois ans je n’ai eu qu’une seule panne sérieuse nécessitant une intervention locale.

Alors voilà, ici le problème classique de l’auto-hébergement se pose. Comment faire lorsqu’on est obligé d’utiliser une IP dynamique ? Au début, j’ai commencé à regarder des solutions comme DynDNS (qui, à ma grande surprise est devenu payant et appartient à Oracle - on veillera donc à l’éviter) ou NoIP.

En fouillant dans les options de mon compte OVH (chez qui je loue mon nom de domaine), j’ai vu un onglet DynHost. Ce service, inclu dans la location du nom de domaine, permet de le faire pointer sur une IP dynamique. Il permet la gestion des sous-domaines, ce qui résoud donc mon problème.

Dans le futur, je vais pouvoir augmenter l’espace de stockage et développer des nouveautés, parce que la machine est loin d’être à bout de souffle.


J’en profite pour râler un peu concernant l’IPv4 et aussi l’IPv6. D’un côté je trouve ça grotesque qu’on en soit encore à utiliser massivement encore la v4 à l’aube de l’an de grâce 2020. De l’autre côté, je m’insurge contre le délire de l’IPv6 qui est selon mon humble avis, une norme de merde, et ce pour plusieurs raisons.

  • Les adresses sont excessivement trop longues ; si par exemple on s’était contentés de rajouter 16 bits à l’IPv4 on aurait 281 474 milliards d’adresses contre 4 milliards aujourd’hui. De telles adresses seraient du type 192.168.250.240.222.111 donc encore lisibles et gérables par des êtres humains. On pourrait gager aisément qu’une telle quantité d’adresses sera suffisante pour un bout de temps.

  • Une adresse par appareil, ce n’est pas nécessaire et ça pose des problèmes de sécurité s’ils sont branchés franco de port à Internet (pensez aux objets IoT chinois sécurisés emmental). Dans les entreprises/écoles, le modèle traditionnel actuel de sous-réseaux protégés sera de toute façon toujours privilégié, dans ce cas il est plus facile d’avoir des adresses locales (et je prédis que pour les réseaux locaux on restera sur IPv4 pour encore au moins 40 ans - j’aime faire des prédictions à l’emporte-pièce).

En somme, s’ils s’étaient contentés de résoudre le vrai problème de l’IPv4 au lieu de tout réinventer en complexifiant inutilement les choses (plus de complexité = plus de bogues), la transition de la v4 vers la version suivante se serait certainement passée bien plus vite. Était-ce nécessaire d’encore rajouter de la complication dans le domaine déjà alambiqué du réseau ? Le monde entier doit-il être victime des barbus de l’IETF qui jouissent du fétichisme d’établir des normes tordues ?

Étant donné l’importance de cette brique d’Internet, il aurait été judicieux d’y aller un peu plus sobrement dans la modernisation de cette norme.