Configuration DDNS avec DuckDNS sur OpenWrt

Pourquoi cette note existe

Cette note documente la direction pratique de configuration pour utiliser DuckDNS avec OpenWrt.

L'objectif était de rendre un réseau privé accessible par un nom de domaine stable même lorsque la propriété intellectuelle publique change.

Au lieu de se souvenir ou de vérifier manuellement l'IP public actuel, un nom d'hôte DDNS peut pointer vers la dernière adresse:

revs412.duckdns.org → current public IP

Ceci est utile pour:

• Accès à distance WireGuard
• Accès au laboratoire à domicile
• test des services auto-portés
• Administration à distance temporaire
• éviter les mises à jour manuelles de l'IP
• faciliter la gestion des profils de connexion

DDNS est simple, mais il est souvent mal compris. Il résout la modification des adresses IP. Il ne résout pas tous les problèmes d'accessibilité.

Contexte du projet

L'environnement était un routeur OpenWrt utilisé comme principal point de contrôle du réseau domestique.

La configuration en question:

• OpenWrt sur un périphérique routeur
• connexion Internet résidentielle dynamique
• Nom d'hôte DuckDNS
• WireGuard direction d'accès à distance
• règles de bâbord/pare-feu
• Services auto-accueillés
• Limites possibles du CGNAT

Un domaine DuckDNS a été utilisé comme nom d'extrémité stable.

Exemple :

revs412.duckdns.org

Le nom d'hôte est plus facile à utiliser dans les configurations VPN/client qu'une adresse IP publique changeante.

Ce que cette configuration veut prouver

• les IP publiques dynamiques peuvent être traitées de manière propre
• OpenWrt peut mettre à jour DDNS automatiquement
• les profils d'accès à distance devraient utiliser des noms d'hôte plutôt que des IP brutes
• Le DDNS et le transfert de port sont des problèmes distincts
• DDNS ne contourne pas CGNAT
• vérification doit vérifier les mises à jour DNS et la connectivité réelle
• une petite fonctionnalité de réseau peut améliorer la fiabilité de l'accès autonome

Pioche et outils utilisés

Couche réseau

• Ouvrir
• Interface WAN
• IP publique dynamique
• règles du pare-feu
• transport de port
• Direction du terminal WireGuard

Couche DDNS

• DuckDNS
• Jeton DuckDNS
• URL de mise à jour DDNS
• Client DNS dynamique OpenWrt
• mises à jour programmées
• détection publique de la propriété intellectuelle

Couche de vérification

• Recherche DNS
• contrôle externe de la propriété intellectuelle
• carnets de routeurs
• test de données mobiles
• test WireGuard à distance
• contrôle d'accessibilité du port

Construction prévue

La construction prévue est une configuration OpenWrt DDNS qui met automatiquement à jour un nom d'hôte DuckDNS chaque fois que l'IP public change.

Une configuration terminée devrait :

• Mettre à jour DuckDNS automatiquement
• survivre au redémarrage du routeur
• utiliser la bonne IP de WAN/public
• afficher l'état de mise à jour dans les journaux
• travailler avec un paramètre WireGuard
• éviter d'exposer publiquement le jeton DuckDNS
• faciliter l'entretien des configurations à distance
• identifier clairement quand CGNAT empêche l'accès entrant

Comment DDNS s'adapte à l'accès à distance

Sans DDNS, un client distant peut avoir besoin:

Endpoint = current.public.ip.address:51820

Si le FAI change la PI publique, le client rompt.

Avec DDNS:

Endpoint = revs412.duckdns.org:51820

Le nom d'hôte reste le même pendant que DuckDNS met à jour l'IP derrière.

Ceci est utile pour WireGuard car la configuration téléphone/ordinateur portable n'a pas besoin d'être modifiée chaque fois que le FAI change l'IP.

Ce que DuckDNS fait réellement

DuckDNS cartographie un nom d'hôte à une adresse IP.

Exemple :

revs412.duckdns.org
  ↓
102.x.x.x

Lorsque l'IP public change, OpenWrt envoie une demande de mise à jour à DuckDNS.

DuckDNS change ensuite l'enregistrement DNS.

C'est tout ce que fait le DDNS.

Elle ne:

• ports ouverts
• configurer les règles du pare-feu
• de contournement CGNAT
• sécuriser le service
• Démarrer WireGuard
• exposer les appareils LAN privés par lui-même

Il maintient seulement le nom d'hôte pointant vers l'IP actuel.

Modèle mental correct

Un modèle correct:

DDNS = name points to current public IP
Firewall = decides what traffic is allowed
Port forward = sends traffic to an internal host
WireGuard = secure tunnel endpoint
CGNAT = possible ISP-level blocker

Ce sont des couches séparées.

Si le nom d'hôte est correctement mis à jour mais que WireGuard ne se connecte toujours pas, le problème peut être pare-feu, transfert de port, configuration de WireGuard, CGNAT ou état du serveur.

Direction DDNS OpenWrt de base

Sur OpenWrt, DDNS peut être géré par le service DNS dynamique.

Une configuration typique nécessite:

DDNS package
DuckDNS service config
DuckDNS token
domain name
WAN/public IP detection
update interval

Les noms exacts des paquets peuvent varier selon OpenWrt build, mais la direction habituelle est:

install ddns client
configure DuckDNS service
enable service
start service
check logs

La configuration doit être persistante à travers le redémarrage.

DuckDNS Mise à jour URL Direction

Les mises à jour DuckDNS utilisent normalement un jeton et un domaine.

La demande de mise à jour ressemble à :

https://www.duckdns.org/update?domains=<domain>&token=<token>&ip=

Lorsque ip est vide, DuckDNS peut détecter l'IP public source.

Pour OpenWrt, il est généralement préférable de laisser le client DDNS gérer cela au lieu d'exécuter manuellement l'URL pour toujours.

Le jeton doit rester privé.

Configurer les valeurs pour suivre

Valeurs importantes:

DuckDNS domain
DuckDNS token
WAN interface
update interval
public IP source
enabled/disabled state
last update status

Exemple de documentation sans exposer de secrets :

Domain: revs412.duckdns.org
Token: stored privately
Interface: wan
Update mode: automatic
Use case: WireGuard endpoint

Ne pas commettre de vrais jetons à GitHub.

Utilisation de DDNS avec WireGuard

Un client WireGuard peut utiliser le nom d'hôte DuckDNS comme point de départ.

Exemple de direction:

Endpoint = revs412.duckdns.org:51820

ou avec un port UDP externe personnalisé:

Endpoint = revs412.duckdns.org:45777

Cela dépend du port public effectivement exposé par le routeur.

Le point important:

WireGuard client uses domain
DuckDNS updates domain
OpenWrt/firewall handles UDP traffic
WireGuard server handles tunnel

Toutes les parties doivent être correctes.

Relations avec les pare-feu

DDNS n'ouvre pas le port WireGuard.

Le pare-feu doit encore permettre le port UDP entrant.

Pour un serveur WireGuard sur OpenWrt, cela signifie généralement autoriser le trafic UDP vers le routeur lui-même.

Pour un serveur WireGuard derrière OpenWrt, il peut nécessiter un port vers l'hôte interne.

La distinction est importante:

WireGuard server on router
  → allow input to router

WireGuard server behind router
  → port forward to internal host

L'utilisation de DDNS ne change rien à cela.

CGNAT Limitation

Le DDNS ne contourne pas CGNAT.

Si le routeur d'origine est derrière CGNAT, DuckDNS peut pointer vers l'IP public partagé ISP, mais le trafic entrant non sollicité peut toujours ne jamais atteindre le routeur d'origine.

Dans ce cas:

DuckDNS updates correctly
domain resolves correctly
port still appears closed
WireGuard still cannot connect from outside

Ça ne veut pas dire que DuckDNS est cassé.

Cela signifie que la route publique n'atteint pas le routeur.

Corrections possibles:

• demander à ISP pour une PI publique réelle
• utiliser IPv6 si disponible
• utiliser un VPS comme paramètre WireGuard
• utiliser un tunnel inversé
• utiliser mesh VPN / réseau de superposition
• garder l'accès local seulement

Mise à jour DNS

Testez d'abord si le nom d'hôte résout.

Exemple :

nslookup revs412.duckdns.org

ou:

dig revs412.duckdns.org

Le résultat devrait correspondre à l'IP public actuel, pas nécessairement le routeur WAN IP si CGNAT existe.

Vérifier la PI publique :

curl -s ifconfig.me

Alors comparez:

DuckDNS result
external public IP
router WAN IP

Cette comparaison vous indique quelle couche fonctionne.

Test de la connectivité réelle

La résolution DNS ne suffit pas.

Après que le DDNS ait résolu correctement, tester le service réel.

Pour WireGuard :

turn off Wi-Fi on phone
use mobile data
connect WireGuard
check handshake
ping VPN router IP
access internal service

Pour un service web:

open domain from mobile data
check reverse proxy logs
check router logs
check service logs

Le meilleur test est de l'extérieur du réseau domestique.

Les essais effectués à l'intérieur du même LAN peuvent être affectés par le comportement de la réflexion et de l'épiderme NAT.

Cas courants de défaillance

Nom d'hôte ne met pas à jour

Causes possibles:

• Service DDNS non activé
• Mauvais jeton DuckDNS
• mauvais domaine
• pas d'internet depuis le routeur
• Question DNS/package sur OpenWrt
• script/service non exécuté
• l'intervalle de mise à jour non encore déclenché

Mises à jour du nom d'hôte mais le service est inaccessible

Causes possibles:

• règles de pare-feu manquantes
• mauvais port
• mauvais protocole TCP vs UDP
• WireGuard n'écoute pas
• service non opérationnel
• mauvaise PI interne
• CGNAT
• Blocs des FSI pour le trafic entrant

WireGuard fonctionne localement mais pas à l'extérieur

Causes possibles:

• client terminal utilise IP locale au lieu de DDNS
• Port UDP non ouvert
• le trafic de blocs de routeurs en amont
• CGNAT
• mauvais port extérieur
• serveur écoute sur un port différent
• IP/routes mal autorisées

DDNS Points vers l'IP du FAI partagé

Cause probable:

• CGNAT ou NAT en amont

DDNS peut encore faire son travail, mais l'hébergement entrant peut ne pas fonctionner.

Journaux à vérifier

Sur OpenWrt, les endroits utiles à vérifier comprennent:

DDNS service status
system log
service logs
firewall logs if enabled
WireGuard status

Direction de commande utile :

logread | grep -i ddns

ou:

logread | grep -i duck

Pour WireGuard :

wg show

Cherchez :

latest handshake
transfer rx/tx
peer endpoint

Si DNS fonctionne mais qu'aucune poignée de main n'apparaît, le trafic n'atteindra peut-être pas le serveur WireGuard.

Mettre à jour les intervalles

DDNS devrait mettre à jour assez souvent pour récupérer des modifications IP, mais pas si souvent qu'il spam le fournisseur.

Un intervalle pratique est généralement:

check periodically
update only when IP changes

Le client DDNS devrait éviter les mises à jour inutiles lorsque l'IP est inchangé.

Après le redémarrage d'un routeur ou la reconnexion de WAN, une mise à jour doit se produire automatiquement.

Sécurité des jetons

Le jeton DuckDNS est un secret.

N'importe qui avec le jeton peut mettre à jour l'enregistrement DuckDNS.

Ne le placez pas dans:

• Repos public GitHub
• captures d'écran
• LIRE les fichiers
• exemples de configuration partagés
• chat logs
• Rapports d ' émission publique

Pour la documentation, voir:

DUCKDNS_TOKEN=replace_me

Pas la valeur réelle.

Dossiers/Config Hygiène

Un projet ou une note propre doit séparer:

real config
example config
documentation

Exemple :

ddns.example.conf
README.md
.env.example

Évitez de commettre de véritables exportations de configuration OpenWrt si elles comprennent des jetons, des identifiants PPPoE, des mots de passe Wi-Fi, des clés privées VPN ou des informations IP internes qui devraient rester privées.

Services publics vs Accès privé

Le DDNS peut être utilisé pour les services publics, mais cela ne signifie pas que tout devrait être public.

Meilleur modèle d'exposition:

Public:
  - website
  - reverse proxy if needed
  - selected game server ports if intended

Private:
  - router admin
  - Proxmox
  - databases
  - dashboards
  - SSH
  - internal apps

Pour un accès privé, utilisez DDNS comme paramètre WireGuard, puis accédez aux systèmes internes via VPN.

C'est plus propre que d'exposer les panneaux d'administration directement.

Comportement de redémarrage du routeur ouvert

Une configuration finie devrait survivre au redémarrage.

Vérification :

DDNS service enabled
WAN reconnect triggers update
DuckDNS hostname still correct
WireGuard still uses same endpoint
firewall rule still active

Un test de redémarrage est utile car de nombreuses configurations semblent fonctionner jusqu'au redémarrage du routeur.

Arbre de décision pratique

Need stable name for home IP?
  → Use DDNS.

Need WireGuard access to home?
  → Use DDNS as endpoint + open correct UDP port.

Domain resolves but connection fails?
  → Check firewall, service, protocol, CGNAT.

Behind CGNAT?
  → DDNS is not enough; use public IP, IPv6, VPS tunnel, or mesh VPN.

Need public reliable hosting?
  → Consider VPS or public IP instead of residential DDNS only.

Décisions pratiques

Utiliser le nom d'hôte dans les clients

Les clients distants devraient utiliser le nom d'hôte DuckDNS, et non une IP brute.

Vérifier le DNS séparément de la connectivité

Un enregistrement DNS correct ne prouve pas que le service est accessible.

Garder secrets

Les jetons DuckDNS devraient être traités comme des références.

Vérifiez CGNAT tôt

Ne perdez pas de temps à régler le DDNS si le FAI bloque le trafic entrant.

Préférez VPN pour les services d'administration

DDNS doit pointer vers le terminal VPN, pas directement vers les panneaux d'administration.

Essai de l ' extérieur

Données mobiles ou VPS donne un test plus honnête que l'accès LAN.

Liste de vérification

Configuration du DDNS

• DuckDNS existe
• jeton est correct
• Service DDNS OpenWrt installé/configuré
• service activé
• Mise à jour réussie
• les journaux montrent la mise à jour réussie

Vérification DNS

• résolution du nom d'hôte
• IP résolue correspond à IP publique externe
• mise à jour survit à la connexion WAN
• update survit au redémarrage du routeur

Vérification par WireGuard

• le paramètre utilise le nom d'hôte DuckDNS
• le port UDP correct est utilisé
• pare-feu permet l'entrée UDP
• poignée de main apparaît de l'extérieur
• Le client VPN peut atteindre le routeur IP VPN
• services internes itinéraire correctement si prévu

CGNAT Vérification

• comparer le routeur IP WAN avec IP publique externe
• vérifier si WAN IP est privé ou 100.64.0.0/10
• essai à partir du réseau extérieur
• vérifier si les journaux de service montrent des tentatives

Vérification de la sécurité

• jeton non engagé
• screenshots masquent des valeurs sensibles
• Panneaux administratifs non publics
• seulement les ports visés exposés
• Révision des règles relatives aux pare-feu

Ce qu'une configuration terminée devrait montrer

Une configuration solide devrait montrer:

• Nom d'hôte DuckDNS configuré
• Service DDNS OpenWrt activé
• des journaux de mise à jour réussis
• résolution du nom d'hôte à la PI publique actuelle
• Findpoint WireGuard utilisant hostname
• test de connexion externe au réseau
• règle de pare-feu documentée
• Limitation du CGNAT documentée si présente
• Aucun secret exposé
• test de redémarrage terminé

Preuves à retenir

Voici quelques éléments de preuve utiles à cette note :

• DuckDNS page de domaine avec jeton caché
• OpenWrt DDNS config screenshot avec des secrets cachés
• mettre à jour le journal des succès
• Résultats nslookup ou dig
• comparaison externe de la PI publique
• Référence client WireGuard utilisant le nom d'hôte
• wg show poignée de main après connexion extérieure
• Capture d'écran de la règle de pare-feu
• diagramme de topologie simple
• CGNAT vérifier si nécessaire

Hypothèses techniques

Cette note suppose qu'OpenWrt est le routeur ou la passerelle réseau principale.

Elle suppose que la PI publique peut changer au fil du temps.

Il suppose que DuckDNS est utilisé comme fournisseur de DDNS.

Il suppose également que l'utilisateur veut un accès à distance ou une commodité d'hébergement, pas seulement un nom de domaine décoratif.

Principaux risques

• en supposant que DDNS ouvre des ports
• ignorer CGNAT
• utilisant le mauvais protocole pour les règles de pare-feu
• pointer WireGuard vers le mauvais port
• test uniquement depuis l'intérieur du réseau local
• exposant publiquement les panneaux de routeur/admin
• jeton DuckDNS qui fuit
• routeur redémarrer désactivation service DDNS
• mise à jour du nom d'hôte à la PI publique de FAI partagée
• cache DNS statique pendant les essais
• la confusion DNS succès avec l'accessibilité du service

État actuel

Cette note représente la couche DDNS d'une configuration maison/auto-hébergement.

Il se connecte directement à :

• Routage ouvert
• Accès à distance WireGuard
• PI publiques dynamiques
• Résolution des problèmes CGNAT
• règles du pare-feu
• accès administrateur sûr

La principale valeur est de rendre le paramètre public stable tout en maintenant le reste de la conception du réseau compréhensible.

Ce que la présente note ne prétend pas

La présente note ne prétend pas que DuckDNS contourne CGNAT.

Il ne prétend pas que DDNS est une fonction de sécurité.

Il ne prétend pas qu'un nom d'hôte rend un service accessible par lui-même.

Il documente comment le DDNS s'intègre dans une configuration d'accès à distance plus grande et où sont ses limites.

À emporter pratique

La leçon utile est:

Le DDNS résout le problème de changement de nom, et non le problème d'accessibilité.

Une configuration correcte nécessite que toutes ces couches fonctionnent :

DuckDNS hostname
current public IP
firewall rule
correct protocol/port
running service
no upstream CGNAT block
outside-network test

Une fois que ceux-ci sont vérifiés séparément, le DDNS devient une partie simple et fiable du workflow d'accès à distance.