9h42 tout est rentré dans l'ordre... Mais bon va vraiment falloir trouver des solutions alternatives si ça doit se reproduire...

Bonjour,

J'utilise un routeur Mikrotik RouterOS 7.x et un bypass SFR (RedSFR) : le routeur Mikrotik est relié à un boîtier ONT SFR via un câble Ethernet.
J'ai adapté les tutoriels Linux et OpenWRT.

Voici le problème que vous pourriez également rencontrer et les solutions mises en place:

Une fois par mois environ, je perds le bail DHCP qui n'est pas renouvelé. Parfois, la ligne est stable durant plusieurs mois, mais dernièrement j'ai perdu le DHCP deux fois à quelques jours d'intervalle. Il s'agit de ma maison de campagne : le VPN tombe et je n'ai plus accès à distance. Dans un premier temps, j'ai mis en place un backup 4G, mais je mangeais mon forfait en cas de bascule et je n'avais pas vraiment compris qu'il s'agissait d'un problème de DHCP ou d'ONT ou les deux. Je pense qu'il s'agit d'un problème côté SFR, sans en être certain. Cela fait des années que cela dure. La dernière interruption a eu lieu ce matin vers 2:00 et j'ai décidé d'agir :

Il suffit de basculer la prise sur laquelle se trouve l'ONT pour que tout revienne en ordre, même après plusieurs jours d'arrêt.

N'hésitez pas à réagir si vous rencontrez le même problème et connaissez des solutions plus simples :

1) Configuration

Voici ma configuration :

/ip dhcp-client print detail
0  ;;; defconf
   name="ether1" interface=ether1 add-default-route=yes default-route-distance=1 default-route-tables=main check-gateway=ping use-peer-dns=yes use-peer-ntp=no
   allow-reconfigure=no use-broadcast=both dhcp-options=hostname,clientid,vendor-id-identifier,lease-time status=bound address=86.76.x.y/24 gateway=86.76.x.y
   dhcp-server=86.64.145.169 primary-dns=109.0.66.10 secondary-dns=109.0.66.20 expires-after=9m32s

/ip dhcp-client print       
Columns: NAME, INTERFACE, USE-PEER-DNS, ADD-DEFAULT-ROUTE, STATUS, ADDRESS
# NAME    INTERFACE  USE-PEER-DNS  ADD-DEFAULT-ROUTE  STATUS  ADDRESS       
;;; defconf
0 ether1  ether1     yes           yes                bound   86.76.x.y/24

 /ip dhcp-client option print detail
Flags: * - DEFAULT
0    name="vendor-id-identifier" code=60 value="xxxxxx" raw-value="xxxx"
 
1    name="lease-time" code=51 value="0x00008CA0" raw-value="00008ca0"
 
2  * name="clientid_duid" code=61 value="0xff$(CLIENT_DUID)" raw-value="ff"
 
3  * name="clientid" code=61 value="0x01$(CLIENT_MAC)" raw-value="01"
 
4  * name="hostname" code=12 value="$(HOSTNAME)" raw-value="xxxxxxxxxx"

Le bail DHCP demandé est de 10 heures et celui reçu de 10 minutes (normal).

A y regarder de plus près cela pourrait être l'option "allow-reconfigure=no". C’est l’acceptation des messages DHCPFORCERENEW (RFC 3203). Avec yes, le serveur DHCP peut ordonner au client de renouveler son bail immédiatement, sans attendre la mi-bail. L’opérateur peut ainsi pousser un changement (nouvelle adresse, nouvelle passerelle, nouveaux DNS) sans attendre l’expiration. Je doute que cela soit le vrai problème car mon IP et la passerelle sont toujours identiques et dans la pratique fixes.

2) Monitoring statut DHCP sur le routeur Mikrotik

Une solution consiste à désactiver/réactiver le port eth1 en cas de perte de DHCP au bout de 5 minutes, en espérant que cela réveille l'ONT. En cas de reboot, 5 minutes laisse le temps au routeur pour obtenir un bail et évite une boucle infinie.

# 1. Client DHCP : pas de verification par ping, pas de script
/ip dhcp-client set [find interface=ether1] check-gateway=none allow-reconfigure=yes script=""

# 2. Script du chien de garde
/system script remove [find name=wan-watchdog]
/system script add name=wan-watchdog policy=read,write,test source={
  :local c [/ip dhcp-client find interface=ether1]
  :if ([/system resource get uptime] < 00:05:00) do={ :return 0 }
  :if ([/ip dhcp-client get $c disabled]) do={ :return 0 }
  :if ([/ip dhcp-client get $c status] != "bound") do={
    :log warning "WAN : pas de bail DHCP, rebond ether1"
    /interface ethernet disable ether1
    :delay 10s
    /interface ethernet enable ether1
  }
}

# 3. Planificateur toutes les 5 minutes
/system scheduler remove [find name=wan-watchdog]
/system scheduler add name=wan-watchdog interval=5m policy=read,write,test on-event=wan-watchdog(écrit avec l'aide de Claude.ai et en cours de test)

3) Bascule de la prise de courant de l'ONT dans Home Assistant

La solution ultime ("ceinture et bretelles") consiste à tester l'absence d'Internet dans Home Assistant depuis 15 minutes et de basculer une prise Zigbee de l'ONT. Voici une copie d'écran du script : Je teste l'absence d'Internet sur 8.8.8.8 depuis 15 minutes et 1.1.1.1 depuis 10 minutes. Si les deux IP ne répondent pas au ping, je bascule automatiquement la prise de l'ONT. Le script a été testé et fonctionne.

4) Une dernière solution consiste à utiliser le watchdog du routeur Mikrotik en pingant 8.8.8.8 et sans réponse durant 3600 s (1 heure), rebooter. Je n'ai pas mis en place ce dernier garde-fou car le routeur est stable et n'a encore jamais planté.

Cordialement,

il y a une rupture de stock concernant les enceintes

Non, on a eu une très grosse charge de 22h à 9h (la charge a diminué suite à la mise en place de nouvelles règles de filtrage).

Aujourd'hui de nombreuses requêtes provenant d'IP très largement distribuées.

Les IPv4 (il y a aussi un peu d'IPv6) sont toutes hors de France.

Quelques AS concernées :
- AS63911   NetActuate, Inc   Royaume-Uni
- AS398781   OCULUS NETWORKS INC   États-Unis
- AS45102   Alibaba (US) Technology Co., Ltd.   Allemagne
- AS45102   Alibaba (US) Technology Co., Ltd.   États-Unis
- AS45102   Alibaba (US) Technology Co., Ltd.   Singapour
- AS45102   Alibaba (US) Technology Co., Ltd.   R.A.S. chinoise de Hong Kong
- AS45102   Alibaba (US) Technology Co., Ltd.   Japon
- AS45102   Alibaba (US) Technology Co., Ltd.   Malaisie
- AS42689   Glide Student & Residential Limited   Royaume-Uni
- AS11404   Wave Broadband   États-Unis
- AS37705   TOPNET   Tunisie

Là encore une fois, on a toujours le problème des PHPSESSID insérés (incorrectement en plus) dans les URL : seulement 9 requêtes sans PHPSESSID, et 428 avec, avec à chaque fois un PHPSESSID différent (il n'y a pas une seule répétition).

Je pense qu'on a toujours le même problème : on des crawlers qui considèrent des URL identiques comme étant distinctes, parce qu'elles diffèrent par le PHPSESSID. Et même si c'est un bot "intelligent" qui cherche à ignorer le PHPSESSID, il ne peut pas le faire car il est ajouté de manière incorrect : on voit que dans chaque requête, il vient après un %3B au lieu d'un ? ou un &. Il n'est donc pas parsable comme un query parameter.

A mon avis c'est vraiment le problème n°1 du site concernant les bots.

Il faut voir que le problème des PHPSESSID insérés concent à 99,9% des robots. Le trafic des utilisateurs réel n'a presque jamais de problème de PHPSESSID.

J'ai hésite à filtrer automatiquement les IP avec un PHPSESSID dans la requete, mais il y a quelques cas où un utilisateur réel à un PHPSESSID (aprés avoir posté un message de mémoire).

La campagne de publicité s'est arrêté rapidement et les retours sont assez peu nombreux sur les réseaux. C'était un "test" ou bien les retours commerciaux et d'image ne sont pas suffisamment bon pour continuer la promotion de l'objet ?