Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes : - sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil de blocage pré-installé (pas de fail2ban par exemple) - je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB - depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain
Sur ton serveur: tshark dans une session screen histoire d’enregistrer tout ce qui se passe et voir si le nexthop OVH envoie des choses qui sont ignorés par ton serveur, ou voir si c’est OVH qui n’envoie rien
Le 6 sept. 2023 à 08:39, Romain romain@borezo.info a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
tshark de quel côté ? avant le problème jusqu'à ce qu'il se reproduise (ça risque de faire gros ?), ou uniquement dès que le problème se produit ?
Le mer. 6 sept. 2023 à 08:59, David Ponzone david.ponzone@gmail.com a écrit :
Sur ton serveur: tshark dans une session screen histoire d’enregistrer tout ce qui se passe et voir si le nexthop OVH envoie des choses qui sont ignorés par ton serveur, ou voir si c’est OVH qui n’envoie rien
Le 6 sept. 2023 à 08:39, Romain romain@borezo.info a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Ben avant q’ils se produisent, parce que quand il se produit, tu as plus la main non ?
Restreint à ICMP et ARP si tu veux.
OVH supporte bien Debian12 officiellement ?
Le 6 sept. 2023 à 09:12, Romain romain@borezo.info a écrit :
tshark de quel côté ? avant le problème jusqu'à ce qu'il se reproduise (ça risque de faire gros ?), ou uniquement dès que le problème se produit ?
Le mer. 6 sept. 2023 à 08:59, David Ponzone <david.ponzone@gmail.com mailto:david.ponzone@gmail.com> a écrit : Sur ton serveur: tshark dans une session screen histoire d’enregistrer tout ce qui se passe et voir si le nexthop OVH envoie des choses qui sont ignorés par ton serveur, ou voir si c’est OVH qui n’envoie rien
Le 6 sept. 2023 à 08:39, Romain <romain@borezo.info mailto:romain@borezo.info> a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/
Si si j'ai toujours accès en IPv6. Si tu as une commande toute prête je suis preneur, jamais utilisé tshark. L'image Debian 12 est bien proposée officiellement sur les dédiés d'OVH.
Le mer. 6 sept. 2023 à 09:15, David Ponzone david.ponzone@gmail.com a écrit :
Ben avant q’ils se produisent, parce que quand il se produit, tu as plus la main non ?
Restreint à ICMP et ARP si tu veux.
OVH supporte bien Debian12 officiellement ?
Le 6 sept. 2023 à 09:12, Romain romain@borezo.info a écrit :
tshark de quel côté ? avant le problème jusqu'à ce qu'il se reproduise (ça risque de faire gros ?), ou uniquement dès que le problème se produit ?
Le mer. 6 sept. 2023 à 08:59, David Ponzone david.ponzone@gmail.com a écrit :
Sur ton serveur: tshark dans une session screen histoire d’enregistrer tout ce qui se passe et voir si le nexthop OVH envoie des choses qui sont ignorés par ton serveur, ou voir si c’est OVH qui n’envoie rien
Le 6 sept. 2023 à 08:39, Romain romain@borezo.info a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
tshark -f 'icmp or arp’
Le 6 sept. 2023 à 09:16, Romain romain@borezo.info a écrit :
Si si j'ai toujours accès en IPv6. Si tu as une commande toute prête je suis preneur, jamais utilisé tshark. L'image Debian 12 est bien proposée officiellement sur les dédiés d'OVH.
Le mer. 6 sept. 2023 à 09:15, David Ponzone <david.ponzone@gmail.com mailto:david.ponzone@gmail.com> a écrit : Ben avant q’ils se produisent, parce que quand il se produit, tu as plus la main non ?
Restreint à ICMP et ARP si tu veux.
OVH supporte bien Debian12 officiellement ?
Le 6 sept. 2023 à 09:12, Romain <romain@borezo.info mailto:romain@borezo.info> a écrit :
tshark de quel côté ? avant le problème jusqu'à ce qu'il se reproduise (ça risque de faire gros ?), ou uniquement dès que le problème se produit ?
Le mer. 6 sept. 2023 à 08:59, David Ponzone <david.ponzone@gmail.com mailto:david.ponzone@gmail.com> a écrit : Sur ton serveur: tshark dans une session screen histoire d’enregistrer tout ce qui se passe et voir si le nexthop OVH envoie des choses qui sont ignorés par ton serveur, ou voir si c’est OVH qui n’envoie rien
Le 6 sept. 2023 à 08:39, Romain <romain@borezo.info mailto:romain@borezo.info> a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/
Bonjour,
J’ai eu un truc similaire mais sur Public Cloud avec Debian 12.
Install vierge, reboot ok, tout du moins pour le premier. Au-delà, montage du réseau aléatoire.
Totalement incompréhensible.
J’ai installé le paquet ifupdown et dégagé Netplan pour repasser à une version traditionnelle du réseau.
Depuis, aucun problème…
Cordialement,
Fabrice TERRANCLE
Administrateur système
Tel. mobile : 0658885108
De : Romain romain@borezo.info Envoyé : mercredi 6 septembre 2023 08:40 À : French SysAdmin Group frsag@frsag.org Objet : [FRsAG] Debian 12 - Blocage IPv4 sans fail2ban & co
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain
Sauf que là, le serveur ping bien (l'ip a tourné sur la ml sd-pro d'ovh) c'est que depuis chez Romain que le serveur cesse de répondre au ping.
Pendant cette période, peux-tu te connecter sur ton serveur par un autre biais afin de pouvoir diagnostiquer, tcpdump, etc. j'ai pensé à un blocage dans /etc/host.deny mais si tu n'a rien configuré d'autre (et puis c'est pas supposé bloquer l'icmp... si ?)
Le 06/09/2023 à 09:08, Fabrice TERRANCLE a écrit :
Bonjour,
J’ai eu un truc similaire mais sur Public Cloud avec Debian 12.
Install vierge, reboot ok, tout du moins pour le premier. Au-delà, montage du réseau aléatoire.
Totalement incompréhensible.
J’ai installé le paquet ifupdown et dégagé Netplan pour repasser à une version traditionnelle du réseau.
Depuis, aucun problème…
Cordialement,
Fabrice TERRANCLE
Administrateur système
Tel. mobile : 0658885108
*De :* Romain romain@borezo.info *Envoyé :* mercredi 6 septembre 2023 08:40 *À :* French SysAdmin Group frsag@frsag.org *Objet :* [FRsAG] Debian 12 - Blocage IPv4 sans fail2ban & co
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a
pas d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain
Liste de diffusion du %(real_name)s http://www.frsag.org/
Merci pour la piste. Je ne pense pas aller jusque là, le réseau fonctionne très bien pour tout le monde, sauf depuis mon IPv4. J'ai l'impression que dès que je coupe le ping de la sonde Uptime Kuma, le problème ne se déclenche plus (le curl chaque minute reste fonctionnel et permet de surveiller s'il y a blocage ou pas). Je vais retenter sur plusieurs jours voir si ça vient bien de la (restera à comprendre pourquoi).
Le mer. 6 sept. 2023 à 09:08, Fabrice TERRANCLE fabrice@terrancle.fr a écrit :
Bonjour,
J’ai eu un truc similaire mais sur Public Cloud avec Debian 12.
Install vierge, reboot ok, tout du moins pour le premier. Au-delà, montage du réseau aléatoire.
Totalement incompréhensible.
J’ai installé le paquet ifupdown et dégagé Netplan pour repasser à une version traditionnelle du réseau.
Depuis, aucun problème…
Cordialement,
Fabrice TERRANCLE
Administrateur système
Tel. mobile : 0658885108
*De :* Romain romain@borezo.info *Envoyé :* mercredi 6 septembre 2023 08:40 *À :* French SysAdmin Group frsag@frsag.org *Objet :* [FRsAG] Debian 12 - Blocage IPv4 sans fail2ban & co
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)
05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain
Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon réveil, et pour l'instant ça ne bloque plus.
Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.
Un normal (rpi4 à la maison vers OVH) : └─# mtr -r 54.38.38.159 -4 Start: 2023-09-07T07:14:15+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- livebox.home 0.0% 10 1.0 0.9 0.7 1.1 0.1 2.|-- 80.10.239.9 0.0% 10 3.0 2.9 2.7 3.5 0.3 3.|-- ae102-0.ncidf103.rbci.ora 0.0% 10 3.3 3.4 2.2 6.3 1.1 4.|-- ae51-0.nridf101.rbci.oran 0.0% 10 3.2 3.4 3.1 3.6 0.2 5.|-- ae41-0.noidf001.rbci.oran 0.0% 10 3.5 3.7 3.2 5.4 0.6 6.|-- be102.par-th2-pb1-nc5.fr. 0.0% 10 25.9 9.6 3.7 31.7 10.5 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 8.1 9.0 7.2 20.9 4.2 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7 7.9 0.4
Le même quelques minutes après (pas normal) : └─# mtr -r 54.38.38.159 -4 Start: 2023-09-07T07:24:27+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- livebox.home 0.0% 10 0.9 1.1 0.7 2.8 0.6 2.|-- 80.10.239.9 0.0% 10 2.8 3.0 2.7 4.4 0.5 3.|-- ae102-0.ncidf103.rbci.ora 0.0% 10 37.3 6.8 2.7 37.3 10.7 4.|-- ae51-0.nridf101.rbci.oran 0.0% 10 3.5 3.5 3.1 4.6 0.4 5.|-- ae41-0.noidf001.rbci.oran 0.0% 10 3.3 3.9 3.2 8.4 1.6 6.|-- be102.par-th2-pb1-nc5.fr. 0.0% 10 3.7 14.0 3.7 44.1 15.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 7.5 8.4 7.1 12.1 1.7 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955. 0.0
Le mer. 6 sept. 2023 à 08:39, Romain romain@borezo.info a écrit :
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Exemple cette nuit après un reboot du serveur la veille au soir : 01h43-02h13 (30 minutes) 02h26-03h26 (1 heure) 03h28-05h28 (2 heures) 05h55-? (pas encore débloqué)
Problèmes :
- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas
d'outil de blocage pré-installé (pas de fail2ban par exemple)
- je n'en ai pas ajouté depuis l'installation du serveur, uniquement
apache (avec mod_security), PHP et MariaDB
- depuis l'IP de chez moi, cette nuit, les seules requêtes générées
étaient celles de ma sonde Uptime Kuma, à savoir un ping toutes les minutes, et une requête curl toutes les minutes vers une URL qui n'a jamais retourné autre chose qu'un HTTP 200 (sauf quand l'IP est bloquée, bien entendu)
Lorsque mon IP est bloquée, curl retourne un "Connection refused". Ping retourne un "Destination Port Unreachable".
Dans les logs du serveur, je ne trouve aucune mention de mon IPv4. MTR (-4) ne signale aucun problème pour joindre le serveur. J'ai fait vérifier par OVH et ce n'est pas un de leur équipement réseau, et un redémarrage en rescue permet de récupérer le ping.
Avez-vous une idée de ce qui pourrait déclencher cela sur un Debian 12 quasiment vierge ? Je me tire les cheveux depuis quelques jours...
Merci !
Romain
Hello,
On Thu, 7 Sep 2023 09:30:19 +0200 Romain romain@borezo.info wrote:
Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon réveil, et pour l'instant ça ne bloque plus.
Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.
Un normal (rpi4 à la maison vers OVH) : └─# mtr -r 54.38.38.159 -4
Le même quelques minutes après (pas normal) : └─# mtr -r 54.38.38.159 -4
C'est quoi pour toi le truc etrange/pas normal ? 1 - le chemin qui devient plus court ? 2 - le dernier hop, apparamment 54.38.38.159, qui change de nom pour passer de mail.borezo.info a rpi4.home 3 - les temps qui montent a presque 8s 4 - tout ca en meme temps 5 - autre chose
Paul
2, le 1 s'explique si un équipement met fin au routage sur la route.
Le jeu. 7 sept. 2023 à 10:04, Paul Rolland (ポール・ロラン) rol+frsag@witbe.net a écrit :
Hello,
On Thu, 7 Sep 2023 09:30:19 +0200 Romain romain@borezo.info wrote:
Ça s'est reproduit cette nuit, mais je n'ai pas pu investiguer avant mon réveil, et pour l'instant ça ne bloque plus.
Par curiosité je fais un MTR régulier, et j'ai eu un truc étrange.
Un normal (rpi4 à la maison vers OVH) : └─# mtr -r 54.38.38.159 -4
Le même quelques minutes après (pas normal) : └─# mtr -r 54.38.38.159 -4
C'est quoi pour toi le truc etrange/pas normal ? 1 - le chemin qui devient plus court ? 2 - le dernier hop, apparamment 54.38.38.159, qui change de nom pour passer de mail.borezo.info a rpi4.home 3 - les temps qui montent a presque 8s 4 - tout ca en meme temps 5 - autre chose
Paul _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Thu, Sep 07, 2023 at 09:30:19AM +0200, Romain [romain@borezo.info] a écrit: (...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 8.1 9.0 7.2 20.9 4.2 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7 7.9 0.4
(...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 7.5 8.4 7.1 12.1 1.7 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955. 0.0
L'acheminement chez ovh change ente les 2. C'est quoi chez toi comme ip qui s'appelle "rpi4.home" ?
C'est 192.168.0.2, l'IP de mon RPI4.
└─# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3 0.3 2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3 0.9 3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0 1.2 4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2 2.8 5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6 0.2 6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6 24.7 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461. 0.0
Le jeu. 7 sept. 2023 à 10:16, Dominique Rousseau d.rousseau@nnx.com a écrit :
Le Thu, Sep 07, 2023 at 09:30:19AM +0200, Romain [romain@borezo.info] a écrit: (...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 8.1 9.0 7.2 20.9
4.2
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7 7.9
0.4
(...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 7.5 8.4 7.1 12.1
1.7
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955.
0.0
L'acheminement chez ovh change ente les 2. C'est quoi chez toi comme ip qui s'appelle "rpi4.home" ?
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Le Thu, Sep 07, 2023 at 10:19:37AM +0200, Romain [romain@borezo.info] a écrit:
C'est 192.168.0.2, l'IP de mon RPI4.
Et tut as un autre "poste" depuis lequel tu pourrais faire le meme traceroute, quand ca "marche pas" ? C'est pour chercher si par hasard c'est un equipement OVH qui emet un icmp avec cette ip la, quand c'est bloque, ou si c'est ton rpi, pour une raison non determinee.
??????# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3 0.3 2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3 0.9 3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0 1.2 4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2 2.8 5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6 0.2 6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6 24.7 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461. 0.0
Huuuum, effectivement pour l'instant depuis une autre machine branchée sur le même switch, impossible à reproduire.
romain@debian-dns:~$ mtr -nr 54.38.38.159 Start: 2023-09-07T10:41:40+0200 HOST: debian-dns Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 0.5 0.8 0.5 1.6 0.3 2.|-- 80.10.239.9 0.0% 10 5.7 3.4 2.6 6.6 1.4 3.|-- 193.253.80.138 0.0% 10 2.6 3.1 2.5 5.5 0.9 4.|-- 193.252.98.94 0.0% 10 3.0 3.4 3.0 4.3 0.4 5.|-- 193.252.98.101 0.0% 10 3.3 3.2 2.8 3.4 0.2 6.|-- 91.121.131.193 0.0% 10 3.7 5.8 2.8 25.7 7.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- 54.36.50.229 0.0% 10 7.7 7.6 7.1 9.9 0.8 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- 54.38.38.159 0.0% 10 7.4 7.1 6.6 8.1 0.5
A surveiller, merci pour la piste. Bon après depuis cet appareil, quand l'IPv4 ne répond plus, ça répond plus depuis tout mon réseau (VM Linux, ordinateur Windows, iOS en Wi-Fi et forcé en IPv4, ...).
Le jeu. 7 sept. 2023 à 10:29, Dominique Rousseau d.rousseau@nnx.com a écrit :
Le Thu, Sep 07, 2023 at 10:19:37AM +0200, Romain [romain@borezo.info] a écrit:
C'est 192.168.0.2, l'IP de mon RPI4.
Et tut as un autre "poste" depuis lequel tu pourrais faire le meme traceroute, quand ca "marche pas" ? C'est pour chercher si par hasard c'est un equipement OVH qui emet un icmp avec cette ip la, quand c'est bloque, ou si c'est ton rpi, pour une raison non determinee.
??????# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst
StDev
1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3
0.3
2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3
0.9
3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0
1.2
4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2
2.8
5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6
0.2
6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6
24.7
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461.
0.0
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient pas à envoyer la réponse à mon réseau.
35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping) request id=0x4b30, seq=33150/32385, ttl=1 36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination unreachable (Port unreachable)
MTR du serveur OVH vers chez moi : Start: 2023-09-07T23:30:08+0200 HOST: rbx Loss% Snt Last Avg Best Wrst StDev 1.|-- 54.38.38.252 0.0% 10 0.6 0.5 0.3 0.7 0.1 2.|-- 10.162.250.98 0.0% 10 0.9 0.5 0.4 0.9 0.1 3.|-- 10.72.52.32 0.0% 10 0.5 0.5 0.4 0.7 0.1 4.|-- 10.73.17.42 0.0% 10 0.2 0.2 0.1 0.3 0.0 5.|-- 10.95.64.152 0.0% 10 1.1 1.2 1.1 1.5 0.1 6.|-- 54.36.50.226 0.0% 10 4.4 4.4 4.2 4.7 0.2 7.|-- 10.200.2.73 0.0% 10 78.0 11.6 4.1 78.0 23.4 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Le jeu. 7 sept. 2023 à 10:42, Romain romain@borezo.info a écrit :
Huuuum, effectivement pour l'instant depuis une autre machine branchée sur le même switch, impossible à reproduire.
romain@debian-dns:~$ mtr -nr 54.38.38.159 Start: 2023-09-07T10:41:40+0200 HOST: debian-dns Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 0.5 0.8 0.5 1.6 0.3 2.|-- 80.10.239.9 0.0% 10 5.7 3.4 2.6 6.6 1.4 3.|-- 193.253.80.138 0.0% 10 2.6 3.1 2.5 5.5 0.9 4.|-- 193.252.98.94 0.0% 10 3.0 3.4 3.0 4.3 0.4 5.|-- 193.252.98.101 0.0% 10 3.3 3.2 2.8 3.4 0.2 6.|-- 91.121.131.193 0.0% 10 3.7 5.8 2.8 25.7 7.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- 54.36.50.229 0.0% 10 7.7 7.6 7.1 9.9 0.8 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- 54.38.38.159 0.0% 10 7.4 7.1 6.6 8.1 0.5
A surveiller, merci pour la piste. Bon après depuis cet appareil, quand l'IPv4 ne répond plus, ça répond plus depuis tout mon réseau (VM Linux, ordinateur Windows, iOS en Wi-Fi et forcé en IPv4, ...).
Le jeu. 7 sept. 2023 à 10:29, Dominique Rousseau d.rousseau@nnx.com a écrit :
Le Thu, Sep 07, 2023 at 10:19:37AM +0200, Romain [romain@borezo.info] a écrit:
C'est 192.168.0.2, l'IP de mon RPI4.
Et tut as un autre "poste" depuis lequel tu pourrais faire le meme traceroute, quand ca "marche pas" ? C'est pour chercher si par hasard c'est un equipement OVH qui emet un icmp avec cette ip la, quand c'est bloque, ou si c'est ton rpi, pour une raison non determinee.
??????# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst
StDev
1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3
0.3
2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3
0.9
3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0
1.2
4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2
2.8
5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6
0.2
6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6
24.7
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461.
0.0
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Bonjour
Attention, je pense que ces 2 lignes n'ont aucun rapport l'une avec l'autre. La 1ère ligne est bien une requête ICMP. La 2ème ligne ("IP_PUBLIQUE_MAISON ICMP 106 Destination unreachable (Port unreachable)") est une trame d'erreur en réponse à une requête UDP précédente reçue sur un port fermé.
Le filtrage tshark est trop restrictif pour bien voir ce qu'il se passe.
David
Dr David ANSART Formateur en Informatique : Réseau Système Cybersécurité Développement C/C++ https://github.com/Raizo62
david.ansart@seineetmarne.cci.fr +33 1 60 37 41 11 CFA UTEC INThttps://www.utec77.fr/ (https://www.utec77.frhttps://www.utec77.fr/) 6 Boulevard Olof Palme CS 60150 Émerainville 77436 Marne-la-Vallée CEDEX 2
[https://ci3.googleusercontent.com/proxy/femEefITJ0c36VknQvisYFKWAiJicpdYWDkX...]https://www.utec77.fr/ [https://ci3.googleusercontent.com/proxy/PrAv608xsWQ17Jtudf-ZkhHZmZ8lh6TXBNnF...] https://www.linkedin.com/company/utec77-cfa-utec [https://ci3.googleusercontent.com/proxy/AIzrqWTFNKF5v5i9fDWhKKJKcXWDJ9Z5hXyo...] https://fr-fr.facebook.com/utec77.formations/ [https://ci6.googleusercontent.com/proxy/8Jn-_XkFHlT_Fo67dJ-_mnkYfmfpCvb5RZXx...] https://twitter.com/utec_77 [https://ci6.googleusercontent.com/proxy/UzISzyJKz18dGYAuUjE0fYjVrb4OXaZRqcDM...] https://www.instagram.com/utec77/?hl=fr
________________________________ De : Romain romain@borezo.info Envoyé : jeudi 7 septembre 2023 23:38 À : Dominique Rousseau d.rousseau@nnx.com Cc : frsag@frsag.org frsag@frsag.org Objet : [FRsAG] Re: Debian 12 - Blocage IPv4 sans fail2ban & co
Vous ne recevez pas souvent de courriers de la part de romain@borezo.info. Découvrez pourquoi cela est importanthttps://aka.ms/LearnAboutSenderIdentification Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient pas à envoyer la réponse à mon réseau.
35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping) request id=0x4b30, seq=33150/32385, ttl=1 36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination unreachable (Port unreachable)
MTR du serveur OVH vers chez moi : Start: 2023-09-07T23:30:08+0200 HOST: rbx Loss% Snt Last Avg Best Wrst StDev 1.|-- 54.38.38.252 0.0% 10 0.6 0.5 0.3 0.7 0.1 2.|-- 10.162.250.98 0.0% 10 0.9 0.5 0.4 0.9 0.1 3.|-- 10.72.52.32 0.0% 10 0.5 0.5 0.4 0.7 0.1 4.|-- 10.73.17.42 0.0% 10 0.2 0.2 0.1 0.3 0.0 5.|-- 10.95.64.152 0.0% 10 1.1 1.2 1.1 1.5 0.1 6.|-- 54.36.50.226 0.0% 10 4.4 4.4 4.2 4.7 0.2 7.|-- 10.200.2.73 0.0% 10 78.0 11.6 4.1 78.0 23.4 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Le jeu. 7 sept. 2023 à 10:42, Romain <romain@borezo.infomailto:romain@borezo.info> a écrit : Huuuum, effectivement pour l'instant depuis une autre machine branchée sur le même switch, impossible à reproduire.
romain@debian-dns:~$ mtr -nr 54.38.38.159 Start: 2023-09-07T10:41:40+0200 HOST: debian-dns Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 0.5 0.8 0.5 1.6 0.3 2.|-- 80.10.239.9 0.0% 10 5.7 3.4 2.6 6.6 1.4 3.|-- 193.253.80.138 0.0% 10 2.6 3.1 2.5 5.5 0.9 4.|-- 193.252.98.94 0.0% 10 3.0 3.4 3.0 4.3 0.4 5.|-- 193.252.98.101 0.0% 10 3.3 3.2 2.8 3.4 0.2 6.|-- 91.121.131.193 0.0% 10 3.7 5.8 2.8 25.7 7.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- 54.36.50.229 0.0% 10 7.7 7.6 7.1 9.9 0.8 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- 54.38.38.159 0.0% 10 7.4 7.1 6.6 8.1 0.5
A surveiller, merci pour la piste. Bon après depuis cet appareil, quand l'IPv4 ne répond plus, ça répond plus depuis tout mon réseau (VM Linux, ordinateur Windows, iOS en Wi-Fi et forcé en IPv4, ...).
Le jeu. 7 sept. 2023 à 10:29, Dominique Rousseau <d.rousseau@nnx.commailto:d.rousseau@nnx.com> a écrit : Le Thu, Sep 07, 2023 at 10:19:37AM +0200, Romain [romain@borezo.infomailto:romain@borezo.info] a écrit:
C'est 192.168.0.2, l'IP de mon RPI4.
Et tut as un autre "poste" depuis lequel tu pourrais faire le meme traceroute, quand ca "marche pas" ? C'est pour chercher si par hasard c'est un equipement OVH qui emet un icmp avec cette ip la, quand c'est bloque, ou si c'est ton rpi, pour une raison non determinee.
??????# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3 0.3 2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3 0.9 3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0 1.2 4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2 2.8 5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6 0.2 6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6 24.7 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461. 0.0
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coophttp://www.neuronnexion.coop/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à cpdp@cci-paris-idf.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme "privé", son contenu est sous la seule responsabilité de son auteur.
C’est vrai, mais par contre, si Romain n’a rien oublié, on voit qu’alors que le serveur est capable d’envoyer un ICMP Port Unreachable (donc à priori couche IP ok, routage ok), il ne répond pas à l’ICMP Request reçu juste avant.
Romain,
Prends peut-être une trace avec:
tshark -f ‘host IP_PUBLIQUE_MAISON’
Le 9 sept. 2023 à 11:55, ANSART David david.ansart@seineetmarne.cci.fr a écrit :
Bonjour
Attention, je pense que ces 2 lignes n'ont aucun rapport l'une avec l'autre. La 1ère ligne est bien une requête ICMP. La 2ème ligne ("IP_PUBLIQUE_MAISON ICMP 106 Destination unreachable (Port unreachable)") est une trame d'erreur en réponse à une requête UDP précédente reçue sur un port fermé.
Le filtrage tshark est trop restrictif pour bien voir ce qu'il se passe.
David
Dr David ANSART Formateur en Informatique : Réseau Système Cybersécurité Développement C/C++ https://github.com/Raizo62 https://github.com/Raizo62 david.ansart@ mailto:david.ansart@seineetmarne.cci.frseineetmarne.cci mailto:david.ansart@seineetmarne.cci.fr.fr mailto:david.ansart@seineetmarne.cci.fr +33 1 60 37 41 11 CFA UTEC INT https://www.utec77.fr/ (https://www.utec77.fr https://www.utec77.fr/) 6 Boulevard Olof Palme CS 60150 Émerainville 77436 Marne-la-Vallée CEDEX 2
https://www.utec77.fr/ https://www.linkedin.com/company/utec77-cfa-utec https://fr-fr.facebook.com/utec77.formations/ https://twitter.com/utec_77 https://www.instagram.com/utec77/?hl=fr
De : Romain <romain@borezo.info mailto:romain@borezo.info> Envoyé : jeudi 7 septembre 2023 23:38 À : Dominique Rousseau <d.rousseau@nnx.com mailto:d.rousseau@nnx.com> Cc : frsag@frsag.org mailto:frsag@frsag.org <frsag@frsag.org mailto:frsag@frsag.org> Objet : [FRsAG] Re: Debian 12 - Blocage IPv4 sans fail2ban & co
Vous ne recevez pas souvent de courriers de la part de romain@borezo.info mailto:romain@borezo.info. Découvrez pourquoi cela est important https://aka.ms/LearnAboutSenderIdentification Je confirme que quand ça tombe, c'est le serveur OVH qui ne parvient pas à envoyer la réponse à mon réseau.
35 9.862648672 IP_PUBLIQUE_MAISON → 54.38.38.159 ICMP 78 Echo (ping) request id=0x4b30, seq=33150/32385, ttl=1 36 9.862704895 54.38.38.159 → IP_PUBLIQUE_MAISON ICMP 106 Destination unreachable (Port unreachable)
MTR du serveur OVH vers chez moi : Start: 2023-09-07T23:30:08+0200 HOST: rbx Loss% Snt Last Avg Best Wrst StDev 1.|-- 54.38.38.252 0.0% 10 0.6 0.5 0.3 0.7 0.1 2.|-- 10.162.250.98 0.0% 10 0.9 0.5 0.4 0.9 0.1 3.|-- 10.72.52.32 0.0% 10 0.5 0.5 0.4 0.7 0.1 4.|-- 10.73.17.42 0.0% 10 0.2 0.2 0.1 0.3 0.0 5.|-- 10.95.64.152 0.0% 10 1.1 1.2 1.1 1.5 0.1 6.|-- 54.36.50.226 0.0% 10 4.4 4.4 4.2 4.7 0.2 7.|-- 10.200.2.73 0.0% 10 78.0 11.6 4.1 78.0 23.4 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
Le jeu. 7 sept. 2023 à 10:42, Romain <romain@borezo.info mailto:romain@borezo.info> a écrit : Huuuum, effectivement pour l'instant depuis une autre machine branchée sur le même switch, impossible à reproduire.
romain@debian-dns:~$ mtr -nr 54.38.38.159 Start: 2023-09-07T10:41:40+0200 HOST: debian-dns Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 0.5 0.8 0.5 1.6 0.3 2.|-- 80.10.239.9 0.0% 10 5.7 3.4 2.6 6.6 1.4 3.|-- 193.253.80.138 0.0% 10 2.6 3.1 2.5 5.5 0.9 4.|-- 193.252.98.94 0.0% 10 3.0 3.4 3.0 4.3 0.4 5.|-- 193.252.98.101 0.0% 10 3.3 3.2 2.8 3.4 0.2 6.|-- 91.121.131.193 0.0% 10 3.7 5.8 2.8 25.7 7.0 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 10.|-- 54.36.50.229 0.0% 10 7.7 7.6 7.1 9.9 0.8 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 15.|-- 54.38.38.159 0.0% 10 7.4 7.1 6.6 8.1 0.5
A surveiller, merci pour la piste. Bon après depuis cet appareil, quand l'IPv4 ne répond plus, ça répond plus depuis tout mon réseau (VM Linux, ordinateur Windows, iOS en Wi-Fi et forcé en IPv4, ...).
Le jeu. 7 sept. 2023 à 10:29, Dominique Rousseau <d.rousseau@nnx.com mailto:d.rousseau@nnx.com> a écrit : Le Thu, Sep 07, 2023 at 10:19:37AM +0200, Romain [romain@borezo.info mailto:romain@borezo.info] a écrit:
C'est 192.168.0.2, l'IP de mon RPI4.
Et tut as un autre "poste" depuis lequel tu pourrais faire le meme traceroute, quand ca "marche pas" ? C'est pour chercher si par hasard c'est un equipement OVH qui emet un icmp avec cette ip la, quand c'est bloque, ou si c'est ton rpi, pour une raison non determinee.
??????# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3 0.3 2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3 0.9 3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0 1.2 4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2 2.8 5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6 0.2 6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6 24.7 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461. 0.0
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop http://www.neuronnexion.coop/ _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à cpdp@cci-paris-idf.fr mailto:cpdp@cci-paris-idf.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme "privé", son contenu est sous la seule responsabilité de son auteur. _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/ http://www.frsag.org/
Bonjour,
On Sat, 9 Sep 2023 14:19:33 +0200 David Ponzone david.ponzone@gmail.com wrote:
Prends peut-être une trace avec:
tshark -f ‘host IP_PUBLIQUE_MAISON’
Apparemment, mtr par defaut fait de l'ICMP. Alors, moi, ce que je ferai, c'est un enregistrement tcpdump de chaque cote (serveur OVH et serveur qui fait le mtr a la maison), avec les machines synchronisees NTP correctement, et j'attendrai de voir le souci, je noterai l'heure, et j'aurai deux tcpdump a comparer.
tcpdump -s 1500 -n -w /path/to/fichier.pcap icmp
sur les deux serveurs, pour recuperer les ICMP ECHO, les ICMP ECHO REPLY, et toutes les signalisations Unreach, etc... qui pourront venir se glisser au milieu.
Une fois que ca a eu lieu, les deux fichiers sont recuperes sur une seule machine, ouverts avec wireshark, et une petite analyse a l'heure du probleme.
Paul
Plop,
Et pour etre complet, si un serveur a plus d'une interface :
ip route get <IP-DISTANTE>
pour connaitre l'interface qui va etre utilisee, et ajout de l'option
-i <INTERFACE>
sur la ligne de commande de tcpdump, pour etre sur de capturer au bon endroit.
Paul
On Sat, 9 Sep 2023 19:03:34 +0200 "Paul Rolland (ポール・ロラン)" rol+frsag@witbe.net wrote:
Bonjour,
On Sat, 9 Sep 2023 14:19:33 +0200 David Ponzone david.ponzone@gmail.com wrote:
Prends peut-être une trace avec:
tshark -f ‘host IP_PUBLIQUE_MAISON’
Apparemment, mtr par defaut fait de l'ICMP. Alors, moi, ce que je ferai, c'est un enregistrement tcpdump de chaque cote (serveur OVH et serveur qui fait le mtr a la maison), avec les machines synchronisees NTP correctement, et j'attendrai de voir le souci, je noterai l'heure, et j'aurai deux tcpdump a comparer.
tcpdump -s 1500 -n -w /path/to/fichier.pcap icmp
sur les deux serveurs, pour recuperer les ICMP ECHO, les ICMP ECHO REPLY, et toutes les signalisations Unreach, etc... qui pourront venir se glisser au milieu.
Une fois que ca a eu lieu, les deux fichiers sont recuperes sur une seule machine, ouverts avec wireshark, et une petite analyse a l'heure du probleme.
Paul
J'arrive à reproduire avec des IP OVH, mais pas avec des IP Scaleway. Ca sent le filtrage côté OVH.
Le jeu. 7 sept. 2023 à 10:19, Romain romain@borezo.info a écrit :
C'est 192.168.0.2, l'IP de mon RPI4.
└─# mtr -nr 54.38.38.159 -4 Start: 2023-09-07T08:17:12+0000 HOST: rpi4 Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 10 1.1 0.9 0.5 1.3 0.3 2.|-- 80.10.239.9 0.0% 10 3.2 3.3 2.3 5.3 0.9 3.|-- 193.253.80.138 0.0% 10 4.5 4.0 2.2 6.0 1.2 4.|-- 193.252.98.94 0.0% 10 3.4 4.3 3.1 12.2 2.8 5.|-- 193.252.98.101 0.0% 10 3.5 3.4 2.9 3.6 0.2 6.|-- 91.121.131.193 0.0% 10 4.0 12.4 3.7 82.6 24.7 7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 192.168.0.2 90.0% 10 3461. 3461. 3461. 3461. 0.0
Le jeu. 7 sept. 2023 à 10:16, Dominique Rousseau d.rousseau@nnx.com a écrit :
Le Thu, Sep 07, 2023 at 09:30:19AM +0200, Romain [romain@borezo.info] a écrit: (...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 8.1 9.0 7.2
20.9 4.2
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
13.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7
7.9 0.4
(...)
10.|-- be103.rbx-g4-nc5.fr.eu 0.0% 10 7.5 8.4 7.1
12.1 1.7
11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0
0.0
12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955.
0.0
L'acheminement chez ovh change ente les 2. C'est quoi chez toi comme ip qui s'appelle "rpi4.home" ?
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du %(real_name)s http://www.frsag.org/
Hello,
Le Wed, Sep 06, 2023 at 08:39:42AM +0200, Romain [romain@borezo.info] a écrit:
Bonjour la liste,
J'ai récemment réinstallé un serveur dédié (chez OVH au cas où ça puisse aider dans le diagnostic), passant de Debian 11 à Debian 12.
Depuis, j'ai un blocage régulier et progressif de l'IPv4 de chez moi. L'accès en IPv6 ou depuis une autre IPv4 (y compris chez le même opérateur) fonctionne.
Le service "anti ddos" ( ou je ne sais quel peut etre son nom ) d'OVH qui fait du zele ?
-
ANSART David -
David Ponzone -
Dominique Rousseau -
Fabrice TERRANCLE -
Paul Rolland (ポール・ロラン) -
Pierre DOLIDON -
Romain