Chaque jour, je reçois des courriels qui, le plus souvent, ressemblent à ceci :

Subjet: Information de domohost.local Message: Adresse IP publique (sans changement) : 171.45.8.239 Adresse IP de l'hôte DDNS (modomo.twilightparadox.com) : 171.45.8.239

Ce message dit que mon réseau local (où se trouve l'ordinateur domohost) peut être atteint de l'extérieur en utilisant l'adresse IP 171.45.8.239 ou le nom de domaine modomo.twilightparadox.com. Le serveur domotique exécute le script une fois par jour vers quatre heures du matin pour que je puisse lire le résultat en début de journée. Un système distant utilisé pour les sauvegardes hors site envoie également un message similaire une fois par jour à peu près à la même heure. Enfin, mon ordinateur de bureau, également sur mon réseau local, exécute le même script que domohost vers midi, mais il envoie un courriel uniquement lorsqu'il y a eu un changement.

Lorsque les adresses IP ne correspondent pas, le message constitue un avertissement que le service de nom de domaine dynamique a été perturbé et qu'il peut être nécessaire de rectifier la situation. Même si les adresses IP sont presque toujours les mêmes, je trouve de tels messages réconfortants lorsque je suis loin de chez moi, car ils indiquent implicitement que l'ordinateur hôte du système domotique fonctionne.

Cet article présente le script Python qui envoie ces notifications. Cependant, avant d'aborder le script, il y a un aperçu du système de nom de domaine dynamique. Cette section est suivie d'une discussion sur quelques échecs rencontrés dans le passé qui m'ont incité à créer le script. Je fournis souvent le contexte de cette manière, mais naturellement, beaucoup voudront passer directement au script vers la fin du billet.

Les adresses IP et les noms d'hôtes dynamiques dans ce billet sont fictifs, inventés de toute part. Toutes mes excuses si par malheur une de ces adresses ou un de ces noms correspond à vos coordonnées et que l'on fouille votre site dans l'espoir d'accéder à mon système ultra-secret.

Table des matières

Réseaux locaux privés

Pour commencer, regardons une représentation simplifiée de mon réseau local et de sa connexion au réseau étendu (WAN) ou à Internet (qui est essentiellement une collection de très nombreux réseaux avec une infrastructure de dorsales, ponts, passerelles, routeurs, commutateurs, serveurs de noms et ainsi de suite pour tout relier ensemble). Cliquez sur l'image pour la voir en taille réelle.

Chaque appareil connecté à mon réseau domestique a une adresse IP unique utilisée pour acheminer les données (divisées en morceaux appelés paquets ou datagrammes) vers et depuis d'autres appareils sur le réseau local. Avec des centaines de milliers, voire des millions d'autres, j'utiliser le sous-réseau 192.168.1.0/24 faisant partie du réseau du privé 192.168.0.0/16 ce qui signifie que tous les périphériques du réseau local ont une adresse IP dans la plage 192.168.1.1 à 192.168.1.254 (les adresses 192.168.1.0 et 192.168.1.255 sont réservées à des fins spéciales). Le fait que mon voisin dispose également d'un ordinateur de bureau avec l'adresse 192.168.1.101 ne pose aucun problème puisque nos deux réseaux locaux ne sont pas physiquement connectés.

Seule une petite partie des données traversant mon réseau domestique est véritablement locale. Il m'arrive d'utiliser un navigateur Web sur l'ordinateur de bureau à 192.168.1.135 pour consulter l'interface Web du système domotique sur le Raspberry Pi à 192.168.1.22 par exemple. La plupart des transferts de données se font avec des ordinateurs externes lors de l'échange de courriels, de la participation à des vidéoconférences, de la visualisation de flux vidéo ou de l'écoute de flux audio, etc.

Accès au réseau étendu (Internet)

Les choses peuvent devenir un peu plus compliquées lors de l'accès aux ordinateurs du réseau étendu. Imaginez si mon voisin et moi demandons au même moteur de recherche des informations en utilisant des ordinateurs de bureau distincts qui ont la même adresse IP, disons 192.168.1.101. Comment la réponse du moteur de recherche peut-elle alors parvenir à la bonne machine ? Une partie importante de la réponse est que le moteur de recherche n'a pas reçu deux requêtes de 192.168.1.101. Au lieu de cela, il a reçu une demande de 171.45.8.239, qui est l'adresse IP publique attribuée par mon FAI à l'ensemble de mon réseau domestique et une autre demande de 95.23.9.8, qui est l'adresse publique du réseau local de mon voisin qui son FAI lui a attribué. Ces deux adresses, 171.45.8.239 et 95.23.9.8 sont uniques et ne se trouvent nulle part ailleurs sur l'ensemble de l'Internet, de sorte que la réponse parviendra au bon réseau local.

Bien sûr, nous nous butons à un nouveau problème : comment la réponse du moteur de recherche parvient-elle au bon ordinateur une fois qu'il a atteint le réseau local ? Le système d'adressage IP est en réalité plus compliqué qu'une simple adresse IP. Les données sont en fait transférées entre des "points finaux" qui sont des processus exécutés divers ordinateurs. Les points d'extrémité sont identifiés par l'adresse IP de l'ordinateur et un numéro de "port". Par exemple, l'interface Web de mon système domotique est à 192.168.1.22:8080, tandis que le serveur Web par défaut sur le même Raspberry Pi est à 192.168.1.22:80. Ainsi, le routeur/la passerelle traduit les adresses IP privées et les numéros de port en adresses IP et numéros de port publics sur les données sortantes et l'inverse avec les données entrantes de l'extérieur. Nous sommes sur le point de nous enfoncer dans la complexité de la traduction d'adresses réseau (NAT) et cela sort du cadre de cet article. Tenons-nous-en à la traduction IP et espérons que le reste se fera sans problème.

Accéder à un réseau local depuis l'extérieur

Tant que j'initie des échanges de données depuis mon LAN vers le WAN, les choses sont très simples de mon point de vue, car NAT s'occupe des détails de manière totalement transparente. Mais que se passe-t-il lorsque je veux joindre mon système domotique sur mon LAN qui a l'adresse IP privée 192.168.1.22 d'une chambre d'hôtel ? Voir l'image sur la droite et cliquer dessus pour la voir en taille réelle. N'oubliez pas que l'adresse IP privée ne peut pas être acheminée via l'Internet public (source). En d'autres termes, l'URL 192.168.1.22:8080 n'ira nulle part si elle est utilisée dans un navigateur Web sur un ordinateur dans la chambre d'hôtel même si YouTube peut être visionné avec cette machine. Cependant, si je connais l'adresse IP publique du LAN à la maison, alors je peux joindre le serveur domotique. En d'autres termes, l'URL 171.45.8.239:8080 fonctionne sur l'ordinateur distant.

Aussi invraisemblable que cela puisse paraître, j'ai utilisé cette technique à des fins de test. Il s'avère que mon FAI accorde des périodes de bail DHCP assez longues. Le bail est la durée pendant laquelle une adresse IP attribuée à un client est réservée pour ce client même lorsque la connexion est interrompue. Plus d'une fois, il a été possible de tester certains aspects de l'accès à distance au réseau local en obtenant l'adresse IP publique attribuée à partir du routeur/de la passerelle, puis en parcourant environ 15 km jusqu'au café le plus proche pour se connecter à mon réseau domestique à partir du WAN en utilisant cette adresse. La longue durée de bail DHCP est une arme à double tranchant comme nous le verrons plus tard.

Service de nom de domaine dynamique

Envoyer des courriels à intervalles réguliers avec l'adresse IP publique du réseau local est une façon peu plus avancée d'assurer l'accès au réseau local depuis l'extérieur. Il s'agit d'une fonction du script présenté ci-dessous. Je n'ai jamais compté sur cette technique, mais elle a été mise en œuvre en tant que solution de rechange depuis environ trois ans maintenant. Il ne s'agit que d'une version DIY de la technique utilisée par de nombreuses applications telles que Zerotier, Teamviewer ou même MyDomoticz qui fournissent un accès ou un contrôle à distance des appareils (ce n'est pas une recommandation d'aucune de ces applications). De telles applications communiquent avec le « quartier général » lorsqu'elles sont lancées, ce qui signifie que ce dernier connaît leurs adresses IP publiques et peut les retransmettre afin que les appareils puissent ensuite échanger des données directement entre eux. Fondamentalement, le script Python en faut autant sauf que l'adresse IP du réseau local est déposée dans un endroit facilement accessible sur Internet, un compte de messagerie. Puisque je sais comment récupérer mes courriels, je peux obtenir l'adresse publique de réseau domestique depuis tout ordinateur relié à l'Internet.

Il existe une meilleure approche pour connaître l'adresse IP publique d'un réseau local qui est transparente, fonctionne la plupart du temps et est largement utilisée. En effet, elle est suffisamment populaire pour que le routeur « gratuit » fourni par mon FAI la supporte... plus ou moins. Je parle du service de nom de domaine dynamique (DDNS). Nous sommes tous des utilisateurs du service de nom de domaine Internet (DNS). C'est ce qui permet d'utiliser des noms d'hôte tels que www.google.com ou www.duckduckgo.com au lieu de leur adresse IP 142.251.32.100 et 52.149.246.39 pour atteindre les moteurs de recherche respectifs dans un navigateur Web. Le DDNS est fondamentalement le même que le DNS, sauf que l'adresse IP associée à un nom d'hôte n'est pas nécessairement fixe. Comment cela fonctionne-t-il du point de vue de l'utilisateur ? J'utilise simplement l'URL modomo.twilightparadox.com:8080 sur mon ordinateur portable dans cette chambre d'hôtel et automatiquement je peux voir la page Web de mon système domotique.

Voici ce qui se passe dans les coulisses, encore une fois en simplifiant au maximum. Le navigateur doit résoudre le nom d'hôtemodomo.twilightparadox.com en une adresse IP. Cela se fait en interrogeant le système de serveur de noms de domaine 1. Quel serveur DNS exactement est interrogé en premier n'est pas si important. S'il connaît l'adresse IP, il renvoie l'adresse, sinon, il transmet la requête à un autre serveur. Ces requêtes récursives devraient finalement aboutir et l'adresse IP trouvée remonte dans la chaîne jusqu'à ce que le navigateur obtienne l'adresse IP publique de mon réseau 2. Désormais, les datagrammes IP peuvent être échangées entre les deux appareils à 10.10.5.205:80 et 171.45.8.239:8080 3 sans autre intervention avec le système de noms de domaine. Bien entendu, le NAT sera exécuté à la fois dans la passerelle LAN domestique et dans la passerelle LAN de l'hôtel.

Ce qui précède est outrageusement simplifié, surtout en ce qui concerne la partie 3. Comme indiqué ci-dessus, les datagrammes IP avec un point final de destination 171.45.8.239:8080 arrivent à la passerelle LAN domestique, ils seront simplement abandonnés. Pour que l'accès au serveur domotique fonctionne comme décrit, il serait nécessaire de faire un « transfert de port » (port forwarding) pour que les datagrammes TCP destinés au port entrant 8080 soit acheminé vers le point final 192.168.1.22:8080

. On peut certainement le faire pendant une courte période pour tester les choses, mais avant de percer des trous permanents dans le pare-feu du réseau local, la sécurité doit être soigneusement examinée. Il ne faut jamais autoriser le transfert de données par HTTP non sécurisé entre le réseau local et le réseau étendu. Au minimum, le protocole HTTPS avec protection par nom d'utilisateur et mot de passe doit être utilisé. L'utilisation de certificats SSL/TLS serait préférable. En pratique, je confie la sécurité à un réseau privé virtuel (RPV). Cela nous éloigne du sujet principal de cet article. Regardez Google Home Mini avec Domoticz par l'entremise de IFTTT. Bien que je n'utilise plus Google Home et IFTTT, je pense que la discussion et les informations pratiques sur le HTTPS, le cryptage TLS/SSL, la redirection de port et les noms de domaine dynamiques reste pertinente. Quant au RPV, j'utilise Wireguard dont la popularité ne cesse de croître (voir Installation et configuration de WireGuard...).

Au final, qui connaît l'adresse IP de modomo.twilightparadox.com ? C'est mon fournisseur de service de nom de domaine dynamique comme indiqué avec l'utilitaire nslookup qui fait partie du paquet dnsutils.

Comment FreeDNS (c'est-à-dire afraid.org) connaît-il l'adresse IP publique de mon adresse personnelle ? Je lui ai donné l'adresse lorsque je me suis inscrit au service de nom de domaine dynamique et je lui indique la nouvelle adresse IP chaque fois que mon FAI modifie l'adresse publique de mon réseau domestique. Techniquement, je ne le fais pas manuellement, mon routeur le fait. Quant au nom de domaine lui-même, il a été mis à ma disposition par FreeDNS qui possède le domaine twilightparadox.com entre autres. Tout ce que j'avais à faire était de trouver le sous-domaine modomo pour m'assurer que le nom complet modomo.twilightparadox.com était unique. C'est l'une des meilleures offres sur le Web car tout est gratuit. Apparemment, des individus ou des organisations qui ont besoin de services DNS plus complexes subventionnent les resquilleurs comme moi et je les remercie beaucoup pour leur aide.

En général le DDNS fonctionne bien, mais j'ai rencontré deux problèmes qui relèvent d'une même cause.

Échecs DDNS

Le FAI peut changer l'adresse IP publique de mon réseau local quand il le souhaite. Cette adresse IP est attribuée avec le protocole DHCP habituel qui permet à un serveur d'ordonner à ses clients de se reconnecter quand il le souhaite. Lorsqu'ils le font, le serveur peut attribuer une adresse IP différente. Chaque fois que l'adresse IP publique est modifiée et que FreeDNS en est informé, cela peut prendre jusqu'à une heure avant que les caches DNS soient actualisées et que la nouvelle adresse IP soit propagée. Ainsi, pendant cette heure (maximum), mon réseau local domestique ne peut pas être atteint avec le modomo.twilightparadox.com car la résolution de ce nom d'hôte aboutira à l'ancienne adresse IP.

Bien sûr, ce délai maximum d'une heure avant la mise à jour du système de noms de domaine suppose que mon routeur informe FreeDNS du changement de son adresse IP publique immédiatement. Malheureusement, je ne suis pas sûr que cela se fasse correctement. Il n'y a pas de véritable documentation sur la configuration du service de mise à jour DDNS dans le routeur. Il n'y a que quelques champs à remplir qui ont des noms plutôt cryptiques. Il est également très difficile de tester en raison de la longue période de bail DHCP définie par mon FAI. J'ai déconnecté mon routeur pendant plus de deux heures dans l'espoir de me voir attribuer une nouvelle adresse IP lors de la reconnexion (et donc de tester la mise à jour du DDNS par le routeur), mais malheureusement, la même ancienne adresse IP a été attribuée. Comme je ne suis pas la seule personne à utiliser Internet à la maison, il est difficile de suspendre tout accès à l'extérieur pour des périodes plus longues.

Une façon de contourner ce problème consiste à renoncer à la prise en charge de la mise à jour DDNS intégrée au routeur. Je pourrais utiliser l'un des nombreux scripts proposés sur FreeDNS pour mettre à jour l'adresse IP publique à intervalles réguliers. D'ailleurs c'est que j'ai dû faire avec un autre compte fonctionnant sur un autre réseau local avec un ancien routeur qui ne prend pas en charge le DDNS, et cela semble bien fonctionner. Bien sûr, je suis trop têtue pour faire ça, car le support intégré « devrait fonctionner ».

L'autre problème que j'ai rencontré semble être lié à FreeDNS. Apparemment, s'il n'y a "aucune activité", le fournisseur de services DDNS suspend le compte. Je ne suis pas trop sûr que ce soit simplement une activité. Une demande d'adresse IP d'un nom de domaine dynamique suffit-elle ? Suffit-il d'effectuer une mise à jour de l'adresse IP publique associée à un nom de domaine dynamique (même si l'IP n'a pas changé) pour remettre à zéro le compteur ? Ou est-il nécessaire de se connecter au compte sur freedns.afraid.org tous les six mois ou à peu près ? Durant les circonstances exceptionnelles que nous avons connues pendant la pandémie de Covid19, je n'ai pas accédé au LAN de l'extérieur pendant plus d'un an. Pendant toute cette période, le FAI n'a pas changé l'adresse IP publique du LAN pour autant que je sache. Il semblait que le routeur n'avait pas du tout mis à jour l'adresse IP publique pendant cette période (est-ce parce que l'adresse IP n'avait pas changé ou est-ce parce que le service de mise à jour sur le routeur n'était pas activé correctement ?) et je sais que je ne me suis pas connecté à mon compte chez FreeDNS. Le résultat final était qu'à un moment donné, je ne pouvais pas accéder au réseau local lorsque j'essayais de tester un serveur Wireguard nouvellement installé. Heureusement, la réactivation du service ne nécessitait que la connexion au compte.

Le script Python décrit dans la section suivante devrait fournir un avertissement lorsque l'un ou l'autre de ces types de problèmes se présente.

Notification par courriel

Si le script a pu obtenir l'adresse publicIP, il l'enregistre immédiatement dans un fichier disque pour sa récupération la prochaine fois que le script est exécuté. Le script crée ensuite le corps du message électronique indiquant l'adresse IP publique actuelle et l'adresse IP affectée au nom de domaine dynamique du réseau local. L'étape suivante consiste à créer le sujet du message en ajoutant une chaîne évidente, "*** ERREUR ***"; si une adresse IP n'a pas pu être trouvée ou si elles ne correspondent pas. La dernière étape consiste à envoyer le courriel.

La partie la plus compliquée du script consiste à obtenir l'adresse IP publique du réseau local, également appelée adresse IP de réseau étendu ou l'adresse du routeur vers l'extérieur. On pourrait penser qu'obtenir les informations du routeur serait la chose la plus simple à faire. En effet, le routeur fourni par mon FAI affiche cette information dans son interface Web sur la page System Information illustrée à droite. Malheureusement, je ne trouve pas la requête qui permettrait d'obtenir cette page ou l'information désirée. Il faut donc recourir à des sites Web qui affichent l'adresse IP des clients HTTP qui s'y connectent. J'ai appris à mes dépens que de tels sites peuvent disparaître, donc la version actuelle du script contient une liste (getIpSites) de quatre sites encore en activité (au moins au 9 août 2021). Voici les sites et la réponse brute obtenue de chacun.

De toute évidence, les deux premières réponses sont beaucoup plus faciles à analyser, mais les deux autres sont suffisamment simples pour qu'une expression régulière puisse trouver toutes les adresses IP (version 4) sans problème et, heureusement, l'adresse IP publique recherchée est toujours la première trouvée.

Sachant que le service m'est fourni gratuitement, seules trois demandes sont effectuées chaque jour comme décrit dans l'introduction. Pour essayer d'équilibrer le nombre de demandes effectuées, la fonction getIPSites ordonne les sites de manière aléatoire avant que le script n'essaie chaque site à tour de rôle jusqu'à ce qu'il en trouve un qui renvoie une adresse IP valide. J'ai pensé qu'il était préférable de signaler lorsqu'un site ne répondait plus dans la chaîne ipSiteComments qui sera ajoutée au message électronique si elle n'est pas vide.

Réflexions finales et références

Soyez prudent lorsque vous recevez un courriel indiquant que l'adresse IP publique n'est pas la même que l'adresse IP associée à un nom d'hôte dynamique. N'oubliez pas que la mise à jour des enregistrements DNS peut prendre jusqu'à une heure si le fournisseur de services Internet (FAI) a modifié l'adresse IP publique qu'il a attribuée au réseau local. En fait, cela peut prendre plus de temps si le router ou le script de mise à jour est lent à informer le fournisseur de services de noms dynamiques que l'adresse IP publique a changé. Si je cherche désespérément à atteindre mon réseau local de l'extérieur et que je ne peux pas attendre une heure ou deux, je peux toujours modifier le fichier de configuration Wireguard (dans le répertoire/etc/wireguard sur une machine Linux) et changer la dernière ligne.

où l'adresse 168.102.82.120 est l'adresse IP publique trouvée dans le courriel. À vrai dire, je préfère attendre une heure ou deux.

Cela est assez osé de ma part de présenter le script checkip4.py étant donné que je ne peux écrire des scripts Python qu'avec l'aide d'un bon moteur de recherche. Veuillez transmettre toute amélioration ou suggestion en cliquant sur le lien de courriel au bas de la page. Si vous décidez de l'essayer, n'oubliez pas d'ajuster toutes les constantes vers le début du script à votre situation particulière.

Notons que s'il est impossible d'obtenir une adresse IP publique valide, il y a de fortes chances qu'il ne soit pas possible d'envoyer un courriel. Une sorte de journalisation des erreurs devrait être ajoutée au script. Si je me souviens bien, je l'ai fait ailleurs et ce n'était pas si difficile, mais étant donné mon attitude nonchalante habituelle, je ne plancherai pas sur cela avant d'avoir rencontré le problème. Comme indiqué, une certaine forme de ce script fonctionne depuis des années sans jamais rencontrer de problème, à l'exception de la dépendance initiale sur un seul site Web pour obtenir l'adresse IP.

Il n'y a aucune mention d'IPv6 ici pour une raison simple. J'évite autant que possible IPv6. Je suis tout simplement trop paresseux pour étudier ce schéma d'adressage et j'attendrai d'y être obligé pour le faire.

Il est juste de donner des références pour des éléments du script obtenus d'autres personnes.

Enfin, les diagrammes de réseau ont été en partie créés avec diagrams.net (anciennement draw.io).