Renouveler une adresse IP dynamique sur MikroTik avec RouterOS
Libérer proprement le bail DHCP du WAN, attendre la reconnexion, vérifier l’adresse reçue et automatiser l’opération sans confondre renouvellement et anonymat.
Une adresse IPv4 dite « dynamique » peut rester identique pendant des semaines. Ce n’est pas nécessairement une panne : le serveur DHCP de l’opérateur reconnaît souvent le même client et lui réattribue le bail précédent tant que celui-ci reste disponible. RouterOS permet néanmoins de libérer le bail du WAN et de relancer le client DHCP sans redémarrer tout le routeur.
L’opération est rapide, mais elle provoque une brève coupure d’Internet et ne garantit jamais une autre adresse. Le choix final appartient au serveur de l’opérateur. Ce guide montre donc comment exécuter la procédure proprement, contrôler le résultat, l’automatiser avec prudence et éviter de lui attribuer des bénéfices de sécurité qu’elle n’apporte pas.
Ce que font réellement release et renew
Dans le client DHCP IPv4 de RouterOS, les deux commandes n’ont pas le même objectif :
| Commande | Action | Résultat attendu |
|---|---|---|
renew | Demande le renouvellement des baux actuels. En cas d’échec, le client tente une réinitialisation. | Le même bail est normalement conservé. |
release | Libère le bail actuel puis redémarre le client DHCP. | Le routeur redemande un bail, identique ou différent selon l’opérateur. |
Pour demander une nouvelle attribution, release suffit donc : RouterOS redémarre lui-même le client. Exécuter d’abord renew, puis release, ajoute une demande inutile et ne rend pas le changement d’adresse plus probable.
Vérifier que le WAN utilise bien DHCP
La procédure ne s’applique qu’à un client DHCP IPv4. Elle ne convient pas à une connexion PPPoE, à une adresse statique configurée dans /ip address, à un modem LTE qui gère lui-même la session ou à un routeur placé derrière une autre box.
/ip dhcp-client print detailRepérez l’entrée dont l’interface correspond au WAN. Dans les exemples suivants, elle s’appelle ether1. Adaptez systématiquement ce nom à votre configuration : il peut s’agir de wan, vlan-internet ou d’une autre interface Ethernet.
Avant de continuer, l’entrée doit être active et afficher status=bound. Notez également les valeurs address, gateway et expires-after.
/ip dhcp-client print detail where interface=ether1Faire un essai manuel
Activez le Safe Mode avec Ctrl+X dans le terminal, puis lancez la libération sur le client identifié. Le filtre sur l’interface évite de dépendre du numéro d’ordre affiché dans la liste.
/ip dhcp-client release [find where interface=ether1 and disabled=no]Le statut passe brièvement par searching ou requesting, puis doit revenir à bound. Selon le modem et l’opérateur, la coupure peut durer quelques secondes ou davantage.
/ip dhcp-client print detail where interface=ether1
/ip route print where dst-address="0.0.0.0/0"Comparez la nouvelle valeur address avec celle notée avant l’opération. Si elle est identique, la commande a probablement fonctionné : le serveur DHCP a simplement choisi de rendre le même bail.
release relance le client DHCP. Une nouvelle adresse reste une possibilité, jamais une garantie.Créer un script RouterOS contrôlé
Une automatisation fiable doit faire plus qu’envoyer une commande. Elle vérifie l’existence du client, refuse de travailler si le bail n’est pas actif, mémorise l’ancienne adresse, attend le retour à l’état bound avec un délai maximal et consigne le résultat.
Dans System → Scripts, créez un script nommé refresh-wan-dhcp avec les politiques read, write et test, puis collez le contenu suivant :
:local wanInterface "ether1"
:local wanClient [/ip dhcp-client find where interface=$wanInterface and disabled=no]
:if ([:len $wanClient] = 0) do={
:error ("Aucun client DHCP actif sur " . $wanInterface)
}
:local oldStatus [/ip dhcp-client get $wanClient status]
:if ($oldStatus != "bound") do={
:error ("Client DHCP non lie, statut: " . $oldStatus)
}
:local oldAddress [/ip dhcp-client get $wanClient address]
:log info ("DHCP WAN: liberation de " . $oldAddress)
/ip dhcp-client release $wanClient
:local secondsLeft 60
:while (([/ip dhcp-client get $wanClient status] != "bound") && ($secondsLeft > 0)) do={
:delay 1s
:set secondsLeft ($secondsLeft - 1)
}
:if ($secondsLeft = 0) do={
:log warning "DHCP WAN: aucun bail apres 60 secondes"
:error "Expiration de l'attente DHCP"
}
:local newAddress [/ip dhcp-client get $wanClient address]
:if ($newAddress = $oldAddress) do={
:log info ("DHCP WAN: bail renouvele, adresse inchangee " . $newAddress)
} else={
:log info ("DHCP WAN: nouvelle adresse " . $newAddress)
}Le texte des journaux est volontairement écrit sans accents pour éviter les surprises lors d’un copier-coller entre terminaux. Remplacez ether1 une seule fois au début du script.
Tester avant de planifier
Lancez d’abord le script manuellement et observez le journal. Ne créez aucune planification tant que la reconnexion n’a pas été validée depuis le LAN.
/system script run refresh-wan-dhcp
/log print where message~"DHCP WAN"
/ip dhcp-client print detail where interface=ether1Contrôlez ensuite la résolution DNS, l’accès Internet, les tunnels VPN et les services publiés. Une nouvelle IP rend les connexions TCP existantes inutilisables ; elles devront être recréées.
Programmer l’exécution avec Scheduler
Si un renouvellement périodique répond à un besoin réel, choisissez une plage de maintenance. L’exemple suivant exécute le script chaque jour à 04:30. Il est fourni pour montrer la syntaxe, pas comme fréquence universelle.
/system scheduler add \
name=refresh-wan-dhcp-daily \
start-time=04:30:00 interval=1d \
on-event="/system script run refresh-wan-dhcp" \
policy=read,write,test \
comment="Maintenance du bail DHCP WAN"Le planificateur possède les mêmes politiques que le script et l’appelle explicitement. Vérifiez après la première échéance ses champs last-started et run-count, ainsi que les messages du journal.
/system scheduler print detail where name=refresh-wan-dhcp-daily
/system script print detail where name=refresh-wan-dhcpUne exécution quotidienne est souvent excessive. Elle multiplie les interruptions, peut déclencher des protections antifraude, invalider des listes d’autorisation et compliquer l’analyse des journaux. Une action manuelle ou une maintenance hebdomadaire suffit généralement.
Mettre à jour le DNS dynamique
Si des services restent accessibles depuis l’extérieur, leur nom DNS doit suivre l’adresse publique. Le service IP/Cloud de RouterOS vérifie périodiquement le changement et actualise son enregistrement DDNS. Pour l’activer volontairement :
/ip cloud set ddns-enabled=yes
/ip cloud force-update
/ip cloud printLe champ dns-name indique le nom attribué et status=updated confirme la mise à jour. Le TTL du service est court, mais les connexions déjà ouvertes ne migrent pas vers la nouvelle adresse.
N’activez pas IP/Cloud si vous ne souhaitez pas utiliser ce service. Un fournisseur DDNS externe peut être mis à jour par son propre client. Ne placez jamais un secret d’API directement dans un article, un export public ou un journal.
Pourquoi une IP différente n’est pas un bouclier de confidentialité
Changer d’adresse peut interrompre un blocage temporaire fondé uniquement sur l’IP ou réduire la continuité d’une observation très sommaire. Cela ne rend pas la navigation anonyme et ne sécurise pas à lui seul un réseau.
- les comptes connectés, cookies et identifiants applicatifs restent les mêmes ;
- le navigateur et l’appareil conservent de nombreux éléments de fingerprinting ;
- l’adresse IPv6 peut rester stable alors que l’IPv4 change ;
- le fournisseur conserve sa propre visibilité sur la connexion ;
- un service exposé reste vulnérable s’il manque des correctifs ou un pare-feu correct.
Pour renforcer réellement la sécurité, mettez RouterOS à jour, limitez l’administration au LAN ou à un VPN, désactivez les services inutiles et contrôlez les règles input. Pour la confidentialité, choisissez des outils adaptés au modèle de menace au lieu de compter sur la rotation d’un bail DHCP.
Pourquoi l’adresse ne change pas
- Le serveur conserve l’ancien bail : c’est le comportement le plus courant et il n’y a rien à corriger sur le routeur.
- Le routeur est derrière un modem : le bail public appartient au modem, tandis que le MikroTik ne reçoit qu’une adresse privée.
- L’accès utilise PPPoE : aucune entrée pertinente n’existe dans
/ip dhcp-client. - Le client est identifié durablement : l’opérateur peut réattribuer le même bail selon ses politiques et l’état de son pool.
- La ligne utilise un CGNAT : l’adresse publique est partagée et gérée en amont.
- La route par défaut ne revient pas : contrôlez
add-default-route, l’état du lien, le VLAN opérateur et les journaux DHCP.
Modifier l’adresse MAC ou le Client ID dans le seul but d’obtenir un autre bail n’est pas une solution neutre : cela peut violer les conditions de l’accès, déclencher une limitation ou empêcher l’authentification. Demandez plutôt une option d’IP dynamique, statique ou publique adaptée au fournisseur.
Désactiver l’automatisation
Pour suspendre la tâche sans la supprimer, désactivez uniquement l’entrée Scheduler. Le client DHCP continuera à renouveler normalement son bail selon les temporisations du protocole.
/system scheduler disable [find where name=refresh-wan-dhcp-daily]Après une période d’observation, supprimez la tâche puis le script si vous ne les utilisez plus.
/system scheduler remove [find where name=refresh-wan-dhcp-daily]
/system script remove [find where name=refresh-wan-dhcp]Conclusion
Sur un WAN réellement configuré en DHCP, la méthode correcte consiste à identifier le client, mémoriser l’adresse, lancer release, attendre le retour à bound et comparer le bail reçu. Le script présenté ajoute les contrôles et le délai maximal nécessaires pour que cette opération soit observable et prévisible.
Le point essentiel reste extérieur au MikroTik : le serveur DHCP décide de l’adresse. Une automatisation peut demander un nouveau bail, pas imposer une nouvelle identité publique. Elle doit donc servir un besoin d’exploitation précis, être programmée pendant une fenêtre acceptable et rester accompagnée d’un DDNS fiable lorsque des services dépendent de l’adresse.
Références techniques
À lire ensuite
À propos de l’auteur
Jeremy Kraft administre les infrastructures et les services auto-hébergés de l’IBCSC. Ces guides reprennent des configurations réellement déployées, revérifiées avant publication.
Discussion
Commentaires
Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.