Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 8 septembre 2023 Romain a écrit :

> Non l'IP en 10.200.2.73 ne me dit rien, chez moi c'est du 192.168, ce qu'il
> se passe entre mon range chez moi et l'IP OVH, je maîtrise rien, c'est OVH
> et/ou les différents liens qu'il possède.

Oui les IP 10.x.x.x et 192.168.x.x sont des IP privées qui ne sont pas
routées sur internet. Donc 10.200.2.73 est interne à OVH. Ca doit être
lui qui bug.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Non l'IP en 10.200.2.73 ne me dit rien, chez moi c'est du 192.168, ce qu'il
se passe entre mon range chez moi et l'IP OVH, je maîtrise rien, c'est OVH
et/ou les différents liens qu'il possède.
Merci pour le lien, je vais lire cela.

Le ven. 8 sept. 2023 à 09:14, NoSpam  a écrit :

>
> Le 08/09/2023 à 09:11, NoSpam a écrit :
>
> Bonjour
>
> J'ai trouvé cela
>
>
> https://community.ovh.com/t/proxmox-ip-failover-probleme-reseau-vers-orange/36874/13
>
> La 10.200.2.73 est une IP OVH
>
> Le 07/09/2023 à 23:38, Romain a écrit :
>
> 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%100.6   0.5   0.3   0.7
> 0.1
>   2.|-- 10.162.250.98  0.0%100.9   0.5   0.4   0.9
> 0.1
>   3.|-- 10.72.52.320.0%100.5   0.5   0.4   0.7
> 0.1
>   4.|-- 10.73.17.420.0%100.2   0.2   0.1   0.3
> 0.0
>   5.|-- 10.95.64.152   0.0%101.1   1.2   1.1   1.5
> 0.1
>   6.|-- 54.36.50.226   0.0%104.4   4.4   4.2   4.7
> 0.2
>   7.|-- 10.200.2.730.0%10   78.0  11.6   4.1  78.0
>  23.4
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>
> Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau interne
> de ???
>
> La 10.200.2.73 te dit quelque chose ?
>
>
> Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :
>
>> Le 7 septembre 2023 Thomas Trupel a écrit :
>>
>> > Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
>> > lancé sur rpi4 à la survenance du problème permettrait de détecter un
>> > éventuel problème de routage sur rpi4.
>>
>> Moi je pensais au bon vieux "route -n" mais on se refait pas :)
>> Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
>> bien aussi pour voir les devices connus dans le voisinage et qui devrait
>> être cohérent avec le routage.
>>
>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 08/09/2023 à 09:11, NoSpam a écrit :


Bonjour


J'ai trouvé cela

https://community.ovh.com/t/proxmox-ip-failover-probleme-reseau-vers-orange/36874/13

La 10.200.2.73 est une IP OVH


Le 07/09/2023 à 23:38, Romain a écrit :
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


Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau 
interne de ???


La 10.200.2.73 te dit quelque chose ?



Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de
détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut
être
bien aussi pour voir les devices connus dans le voisinage et qui
devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Bonjour

Le 07/09/2023 à 23:38, Romain a écrit :
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


Dubitatif: réseau interne OVH - Sortie OVH public - retour réseau 
interne de ???


La 10.200.2.73 te dit quelque chose ?



Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de
détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
bien aussi pour voir les devices connus dans le voisinage et qui
devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

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%100.6   0.5   0.3   0.7   0.1
  2.|-- 10.162.250.98  0.0%100.9   0.5   0.4   0.9   0.1
  3.|-- 10.72.52.320.0%100.5   0.5   0.4   0.7   0.1
  4.|-- 10.73.17.420.0%100.2   0.2   0.1   0.3   0.0
  5.|-- 10.95.64.152   0.0%101.1   1.2   1.1   1.5   0.1
  6.|-- 54.36.50.226   0.0%104.4   4.4   4.2   4.7   0.2
  7.|-- 10.200.2.730.0%10   78.0  11.6   4.1  78.0  23.4
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0

Le jeu. 7 sept. 2023 à 14:17, Michel Verdier  a écrit :

> Le 7 septembre 2023 Thomas Trupel a écrit :
>
> > Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> > lancé sur rpi4 à la survenance du problème permettrait de détecter un
> > éventuel problème de routage sur rpi4.
>
> Moi je pensais au bon vieux "route -n" mais on se refait pas :)
> Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
> bien aussi pour voir les devices connus dans le voisinage et qui devrait
> être cohérent avec le routage.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Thomas Trupel]

Bonjour Romain,

Pour compléter la réponse de Michel, un "ip route get 54.38.38.159" lancé sur 
rpi4 à la survenance du problème permettrait de détecter un éventuel problème 
de routage sur rpi4.

Cordialement,
Thomas

7 sept. 2023 12:55:53 Romain :

> Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le 
> serveur chez OVH.
> Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en 
> même temps, peut-être une correction de leur côté.
> A suivre.
> 
> Le jeu. 7 sept. 2023 à 12:37, Michel Verdier  a écrit :
>> Le 7 septembre 2023 Romain a écrit :
>> 
>>> Je n'en ai aucune idée, mais :
>>> - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
>>> reproduire sur une IP Scaleway
>>> - depuis une VM hébergée sur un petit NUC branché au même switch que le
>>> RPI4, je ne reproduis pas le problème avec MTR
>>>
>>> J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
>>> déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
>>> complet.
>> 
>> Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
>> fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
>> l'ip 54.38.38.159 (mail.borezo.info[http://mail.borezo.info]). Celui qui 
>> bloque aboutit sur l'ip
>> 192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
>> routage chez toi. Ce que confirmerait ton test avec le nuc.
>> Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
>> Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
>> voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
>> lui-même au lieu de l'avoir vers ta box.
>> 

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Thomas Trupel a écrit :

> Pour compléter la réponse de Michel, un "ip route get 54.38.38.159"
> lancé sur rpi4 à la survenance du problème permettrait de détecter un
> éventuel problème de routage sur rpi4.

Moi je pensais au bon vieux "route -n" mais on se refait pas :)
Sinon un "arp -n", "ip neighbour" pour être au goût du jour, peut être
bien aussi pour voir les devices connus dans le voisinage et qui devrait
être cohérent avec le routage.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Oui j'ai du full stack des deux côtés.

Le jeu. 7 sept. 2023 à 13:57, zithro  a écrit :

> On 07 Sep 2023 12:55, Romain wrote:
> > Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur
> le
> > serveur chez OVH.
> > Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
> > même temps, peut-être une correction de leur côté.
> > A suivre.
> >
>
> Rah ce top posting ...
>
> Pour info, si OVH utilise des IP privées sur son réseau interne, c'est
> normal qu'elles apparaissent dans les mtr.
> Comme ton DNS local (ou avahi, etc) connait cette adresse, il te
> l'affiche comme étant une machine locale.
>
> Les routeurs internes de certains FAIs et hébergeurs ont parfois des IPs
> RFC1918, voire APIPA (pour CG-NAT), afin d'économiser les IPv4 publiques.
>
> T'as une IPv4 full stack des deux côtés (chez toi et chez eux) ?
> D'après mes souvenirs ça peut poser des problèmes si ce n'est pas le cas.
>
> Autre piste, tu peux essayer des traceroutes avec les 3 protocoles :
> ICMP, UDP, TCP. Il y a parfois des différences.
>
>
> --
> ++
> zithro / Cyril
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[zithro]

On 07 Sep 2023 12:55, Romain wrote:

Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le
serveur chez OVH.
Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
même temps, peut-être une correction de leur côté.
A suivre.



Rah ce top posting ...

Pour info, si OVH utilise des IP privées sur son réseau interne, c'est 
normal qu'elles apparaissent dans les mtr.
Comme ton DNS local (ou avahi, etc) connait cette adresse, il te 
l'affiche comme étant une machine locale.


Les routeurs internes de certains FAIs et hébergeurs ont parfois des IPs 
RFC1918, voire APIPA (pour CG-NAT), afin d'économiser les IPv4 publiques.


T'as une IPv4 full stack des deux côtés (chez toi et chez eux) ?
D'après mes souvenirs ça peut poser des problèmes si ce n'est pas le cas.

Autre piste, tu peux essayer des traceroutes avec les 3 protocoles : 
ICMP, UDP, TCP. Il y a parfois des différences.



--
++
zithro / Cyril

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
> même temps, peut-être une correction de leur côté.

J'en doute quand même. Pour faire suite aux échanges sur debian-user, il
se peut que ce soit ta box et pas rpi4 qui soit en cause. Mais ton test
avec le nuc semble indiquer que c'est plutôt rpi4. L'idéal serait que tu
laisses le mtr périodique sur rpi4 mais aussi sur le nuc. Si les 2
tombent c'est ta box qui serait en cause. Si le nuc fonctionne c'est rpi4
en cause.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Les erreurs étaient bien (et sont encore, même si moins nombreuses) sur le
serveur chez OVH.
Pour le moment je n'arrive plus à reproduire. Comme j'échange avec OVH en
même temps, peut-être une correction de leur côté.
A suivre.

Le jeu. 7 sept. 2023 à 12:37, Michel Verdier  a écrit :

> Le 7 septembre 2023 Romain a écrit :
>
> > Je n'en ai aucune idée, mais :
> > - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
> > reproduire sur une IP Scaleway
> > - depuis une VM hébergée sur un petit NUC branché au même switch que le
> > RPI4, je ne reproduis pas le problème avec MTR
> >
> > J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne
> et
> > déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
> > complet.
>
> Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
> fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
> l'ip 54.38.38.159 (mail.borezo.info). Celui qui bloque aboutit sur l'ip
> 192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
> routage chez toi. Ce que confirmerait ton test avec le nuc.
> Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
> Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
> voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
> lui-même au lieu de l'avoir vers ta box.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Je n'en ai aucune idée, mais :
> - le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
> reproduire sur une IP Scaleway
> - depuis une VM hébergée sur un petit NUC branché au même switch que le
> RPI4, je ne reproduis pas le problème avec MTR
>
> J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
> déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
> complet.

Je vais essayer de clarifier. Tu es sur l'ip 192.168.0.2 (rpi4.home). Tu
fais un mtr vers l'ip 54.38.38.159. Celui qui marche aboutit bien sur
l'ip 54.38.38.159 (mail.borezo.info). Celui qui bloque aboutit sur l'ip
192.168.0.2 (rpi4.home). Là le problème est sans doute un problème de
routage chez toi. Ce que confirmerait ton test avec le nuc.
Les erreurs rx checksum étaient bien sur ton serveur ou sur rpi4 ?
Regarde tes tables de routage sur rpi4 avant et pendant le problème pour
voir. Mais ça fait comme si rpi4 mettait la route vers 54.38.38.159 vers
lui-même au lieu de l'avoir vers ta box.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Je n'en ai aucune idée, mais :
- le RPI4 ne reproduit ce problème que vers des IP OVH. Impossible à
reproduire sur une IP Scaleway
- depuis une VM hébergée sur un petit NUC branché au même switch que le
RPI4, je ne reproduis pas le problème avec MTR

J'ai fourni les MTR à OVH, on verra bien. Peut-être que mon RPI4 déconne et
déclenche un filtrage côté réseau OVH qui finit par déclencher un blocage
complet.

Le jeu. 7 sept. 2023 à 11:53, Michel Verdier  a écrit :

> Le 7 septembre 2023 Romain a écrit :
>
> > └─# mtr -r 54.38.38.159 -4
> >  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9
>  0.4
> >  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.
>  0.0
>
> Je n'avais pas fait attention mais ton resolv change de mail.borezo.info
> en rpi4.home. Qu'est-ce qui change sur ton client pour provoquer ça ?
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 07/09/2023 à 11:47, Michel Verdier a écrit :

Le 7 septembre 2023 Romain a écrit :


Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

L'option -n évite le dns mais ça n'apporte rien de plus.
Bein si, on aurait vu de suite une IP privée de rpi4.home, pas besoin de 
poser la question ...

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> └─# mtr -r 54.38.38.159 -4
>  15.|-- mail.borezo.info   0.0%106.9   7.2   6.7   7.9   0.4
>  12.|-- rpi4.home 90.0%10  7955. 7955. 7955. 7955.   0.0

Je n'avais pas fait attention mais ton resolv change de mail.borezo.info
en rpi4.home. Qu'est-ce qui change sur ton client pour provoquer ça ?

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 7 septembre 2023 Romain a écrit :

> Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
> compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
> mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

L'option -n évite le dns mais ça n'apporte rien de plus.
Entre les 2 mtr on voit que le nombre de hop entre be103.rbx-g4-nc5.fr.eu
et ton serveur change. Peut-être pas du filtrage ddos mais un changement
de routage chez eux. Et ça en général ça indique un problème, donc chez
eux. Le mieux c'est de leur soumettre tes mtr. Avec les heures où ça
plante ils vont pouvoir faire le lien avec leurs logs.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

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:18, Romain  a écrit :

> └─# mtr -nr 54.38.38.159 -4
> Start: 2023-09-07T08:17:12+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- 192.168.0.10.0%101.1   0.9   0.5   1.3
> 0.3
>   2.|-- 80.10.239.90.0%103.2   3.3   2.3   5.3
> 0.9
>   3.|-- 193.253.80.138 0.0%104.5   4.0   2.2   6.0
> 1.2
>   4.|-- 193.252.98.94  0.0%103.4   4.3   3.1  12.2
> 2.8
>   5.|-- 193.252.98.101 0.0%103.5   3.4   2.9   3.6
> 0.2
>   6.|-- 91.121.131.193 0.0%104.0  12.4   3.7  82.6
>  24.7
>   7.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   8.|-- ???   100.0100.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:17, Romain  a écrit :
>
>> Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
>> compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
>> mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?
>>
>> Le jeu. 7 sept. 2023 à 09:54, NoSpam  a écrit :
>>
>>> rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...
>>> Le 07/09/2023 à 09:30, Romain a écrit :
>>>
>>> Ç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+
>>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>>> StDev
>>>   1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1
>>> 0.1
>>>   2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5
>>> 0.3
>>>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3
>>> 1.1
>>>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6
>>> 0.2
>>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.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.0100.0   0.0   0.0   0.0
>>> 0.0
>>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9
>>>   4.2
>>>  11.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  12.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  13.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  14.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  15.|-- mail.borezo.info   0.0%106.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+
>>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>>> StDev
>>>   1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8
>>> 0.6
>>>   2.|-- 80.10.239.90.0%102.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%103.5   3.5   3.1   4.6
>>> 0.4
>>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4
>>> 1.6
>>>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1
>>>  15.0
>>>   7.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>>> 0.0
>>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1
>>>   1.7
>>>  11.|-- ???   100.0100.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  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 ser

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

└─# mtr -nr 54.38.38.159 -4
Start: 2023-09-07T08:17:12+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.10.0%101.1   0.9   0.5   1.3   0.3
  2.|-- 80.10.239.90.0%103.2   3.3   2.3   5.3   0.9
  3.|-- 193.253.80.138 0.0%104.5   4.0   2.2   6.0   1.2
  4.|-- 193.252.98.94  0.0%103.4   4.3   3.1  12.2   2.8
  5.|-- 193.252.98.101 0.0%103.5   3.4   2.9   3.6   0.2
  6.|-- 91.121.131.193 0.0%104.0  12.4   3.7  82.6  24.7
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.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:17, Romain  a écrit :

> Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
> compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
> mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?
>
> Le jeu. 7 sept. 2023 à 09:54, NoSpam  a écrit :
>
>> rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...
>> Le 07/09/2023 à 09:30, Romain a écrit :
>>
>> Ç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+
>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>> StDev
>>   1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1
>> 0.1
>>   2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5
>> 0.3
>>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3
>> 1.1
>>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6
>> 0.2
>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.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.0100.0   0.0   0.0   0.0
>> 0.0
>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9
>> 4.2
>>  11.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  12.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  13.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  14.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  15.|-- mail.borezo.info   0.0%106.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+
>> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
>> StDev
>>   1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8
>> 0.6
>>   2.|-- 80.10.239.90.0%102.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%103.5   3.5   3.1   4.6
>> 0.4
>>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4
>> 1.6
>>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1
>>  15.0
>>   7.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   8.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>   9.|-- ???   100.0100.0   0.0   0.0   0.0
>> 0.0
>>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1
>> 1.7
>>  11.|-- ???   100.0100.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  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
>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais ma
compréhension est-elle bonne, à savoir qu'un équipement sur la route vers
mon serveur met fin au routage ? Ca pourrait être "l'anti-ddos" d'OVH ?

Le jeu. 7 sept. 2023 à 09:54, NoSpam  a écrit :

> rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...
> Le 07/09/2023 à 09:30, Romain a écrit :
>
> Ç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+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1
> 0.1
>   2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5
> 0.3
>   3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3
> 1.1
>   4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6
> 0.2
>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.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.0100.0   0.0   0.0   0.0
> 0.0
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   9.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9
> 4.2
>  11.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  12.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  13.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  14.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  15.|-- mail.borezo.info   0.0%106.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+
> HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst
> StDev
>   1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8
> 0.6
>   2.|-- 80.10.239.90.0%102.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%103.5   3.5   3.1   4.6
> 0.4
>   5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4
> 1.6
>   6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1
>  15.0
>   7.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   8.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>   9.|-- ???   100.0100.0   0.0   0.0   0.0
> 0.0
>  10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1
> 1.7
>  11.|-- ???   100.0100.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  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
>>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

rpi4.home c'est chez toi ? Avec le -n on aurait eu les IP ...

Le 07/09/2023 à 09:30, Romain a écrit :
Ç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+
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+
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  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

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[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+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%101.0   0.9   0.7   1.1   0.1
  2.|-- 80.10.239.90.0%103.0   2.9   2.7   3.5   0.3
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.3   3.4   2.2   6.3   1.1
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.2   3.4   3.1   3.6   0.2
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.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.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%108.1   9.0   7.2  20.9   4.2
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 13.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 14.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 15.|-- mail.borezo.info   0.0%106.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+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%100.9   1.1   0.7   2.8   0.6
  2.|-- 80.10.239.90.0%102.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%103.5   3.5   3.1   4.6   0.4
  5.|-- ae41-0.noidf001.rbci.oran  0.0%103.3   3.9   3.2   8.4   1.6
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.7  14.0   3.7  44.1  15.0
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.5   8.4   7.1  12.1   1.7
 11.|-- ???   100.0100.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  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
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> La seule piste que j'ai (en attendant le prochain blocage et la collecte de
> mtr dans l'autre sens, tcpdump & co, c'est qu'avec ethtool, je vois un taux
> d'erreur qui augmente progressivement (rx_csum_offload_errors). De là à
> dire que ces erreurs sont générées par des paquets qui viennent de mon IP,
> et que ça entraîne un blocage invisible je ne sais où... Il y a déjà eu un
> changement de câble réseau, mais le problème reste. Le support OVH me dit
> que si ça continue en mode rescue il faudra changer la carte mère, sauf
> qu'en rescue il n'y aura pas les mêmes services de montés, et donc pas le
> même trafic pouvant être générateur d'erreurs.

Oui en général des erreurs checksum comme ça ça vient du matériel. Et
plutôt du serveur.
Le traffic tu peux peut-être le simuler, une erreur matériel sera
indépendante du contenu. Pour le port 80 tu as ab du paquet
apache2-utils qui le fait facilement. Tu devras peut-être faire varier la
taille du paquet.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

>
> Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
> de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
> quotas.


Rien de lourd, sachant que c'est illimité chez OVH (le serveur à 500/500
Mbps unmetered), et puis en cas de quota ça serait bloqué partout, pas que
sur IPv4 et pas que sur mon IPv4.

La seule piste que j'ai (en attendant le prochain blocage et la collecte de
mtr dans l'autre sens, tcpdump & co, c'est qu'avec ethtool, je vois un taux
d'erreur qui augmente progressivement (rx_csum_offload_errors). De là à
dire que ces erreurs sont générées par des paquets qui viennent de mon IP,
et que ça entraîne un blocage invisible je ne sais où... Il y a déjà eu un
changement de câble réseau, mais le problème reste. Le support OVH me dit
que si ça continue en mode rescue il faudra changer la carte mère, sauf
qu'en rescue il n'y aura pas les mêmes services de montés, et donc pas le
même trafic pouvant être générateur d'erreurs.

Le mer. 6 sept. 2023 à 15:11, Michel Verdier  a écrit :

> Le 6 septembre 2023 Romain a écrit :
>
> > Il y a bien iptables par défaut, mais :
> >
> > # iptables -nL
> > Chain INPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain FORWARD (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target prot opt source   destination
>
> Ok. Donc reste le mtr à partir du serveur. L'option -n n'apportera rien
> de plus. Par contre tu peux peut-être faire un nmap en jouant avec
> certaines options. Je pense à -PN -PS --reason, les différents scans avec
> les options -s (et peut-être -sO), et bien sûr avec -v -v.
> Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
> de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
> quotas.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> Il y a bien iptables par défaut, mais :
>
> # iptables -nL
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination

Ok. Donc reste le mtr à partir du serveur. L'option -n n'apportera rien
de plus. Par contre tu peux peut-être faire un nmap en jouant avec
certaines options. Je pense à -PN -PS --reason, les différents scans avec
les options -s (et peut-être -sO), et bien sûr avec -v -v.
Sinon est-ce que ta volumétrie est lourde car il peut y avoir un bridage
de la bande passante sur ton serveur, et donc blocage si tu dépasses tes
quotas.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Il y a bien iptables par défaut, mais :

# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Le mer. 6 sept. 2023 à 11:19, Michel Verdier  a écrit :

> Le 6 septembre 2023 Romain a écrit :
>
> > J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
> > la mienne est bloquée), ça fonctionne.
>
> Je reprends en français ça sera plus simple :)
> Tu n'as pas fail2ban, mais as-tu iptables ou nftables (ou autre chose) ?
> Il peut y avoir des règles qui provoquent ce comportement.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Michel Verdier]

Le 6 septembre 2023 Romain a écrit :

> J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
> la mienne est bloquée), ça fonctionne.

Je reprends en français ça sera plus simple :)
Tu n'as pas fail2ban, mais as-tu iptables ou nftables (ou autre chose) ?
Il peut y avoir des règles qui provoquent ce comportement.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Les ports SSH et HTTP sont bien ouverts.

Je testerai le mtr -n au prochain coup. Pas encore testé avec nc, je le
ferai.

La commande curl était la suivante :
└─# curl -v http://54.38.38.159
*   Trying 54.38.38.159:80...
* connect to 54.38.38.159 port 80 failed: Connection refused
* Failed to connect to 54.38.38.159 port 80 after 7 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 54.38.38.159 port 80 after 7 ms: Connection
refused

J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
la mienne est bloquée), ça fonctionne.

Le mer. 6 sept. 2023 à 09:31, NoSpam  a écrit :

>
> Le 06/09/2023 à 09:13, Romain a écrit :
>
> Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).
>
> Port http non ouvert, port ssh inexistant sauf s'il écoute sur un autre
> port
>
>
> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
>> ping et traceroute ...
>
>
> └─# mtr -r 54.38.38.159
>
> mtr -n 54.38.38.159
>
>
>
> tcpdump sur le port 80 avec enregistrement.
>>
>
> Côté serveur dédié OVH ou côté sonde Uptime Kuma ?
>
> Serveur bien sûr
>
> Au moment du blocage j'ai déjà tenté de reproduire des pings & curl vers
> l'IP de mon dédié sur lequel tournait tcpdump, aucune requête vu de mon IP
> à la maison.
>
> Je ne comprends pas cette phrase. As tu testé avec nc ?
>
> Quelle est la commande curl exécutée ?
>
>
> Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :
>
>> Bonjour
>>
>> Le 06/09/2023 à 08:39, Romain 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.
>>
>> J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
>> suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80
>>
>> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
>> ping et traceroute ...
>>
>> >
>> > 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...
>> tcpdump sur le port 80 avec enregistrement.
>>
>>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Le 06/09/2023 à 09:13, Romain a écrit :

Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).

Port http non ouvert, port ssh inexistant sauf s'il écoute sur un autre port


ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
ping et traceroute ...


└─# mtr -r 54.38.38.159

mtr -n 54.38.38.159



tcpdump sur le port 80 avec enregistrement.

Côté serveur dédié OVH ou côté sonde Uptime Kuma ?

Serveur bien sûr
Au moment du blocage j'ai déjà tenté de reproduire des pings & curl 
vers l'IP de mon dédié sur lequel tournait tcpdump, aucune requête vu 
de mon IP à la maison.


Je ne comprends pas cette phrase. As tu testé avec nc ?

Quelle est la commande curl exécutée ?



Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :

Bonjour

Le 06/09/2023 à 08:39, Romain 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.

J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v
 80

ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
ping et traceroute ...

>
> 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...
tcpdump sur le port 80 avec enregistrement.

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

Non c'est un blocage général semble-t-il (http, https, ssh, ping, ...).

ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
> ping et traceroute ...


└─# mtr -r 54.38.38.159
Start: 2023-09-01T07:39:01+
HOST: rpi4Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- livebox.home   0.0%100.7   0.8   0.6   1.0   0.1
  2.|-- 80.10.239.90.0%102.8   2.7   1.9   3.1   0.4
  3.|-- ae102-0.ncidf103.rbci.ora  0.0%103.1   3.9   2.5  11.2   2.7
  4.|-- ae51-0.nridf101.rbci.oran  0.0%103.4   3.3   3.2   3.5   0.1
  5.|-- ae41-0.noidf001.rbci.oran  0.0%102.9   3.2   2.1   3.9   0.5
  6.|-- be102.par-th2-pb1-nc5.fr.  0.0%103.6  13.8   3.6  66.0  19.8
  7.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  8.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
  9.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 10.|-- be103.rbx-g4-nc5.fr.eu 0.0%107.3   7.4   7.2   7.7   0.2
 11.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 12.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 13.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 14.|-- ???   100.0100.0   0.0   0.0   0.0   0.0
 15.|-- mail.borezo.info0.0%106.8   7.0   6.6   8.6
0.6

└─# ping 54.38.38.159
PING 54.38.38.159 (54.38.38.159) 56(84) bytes of data.
>From 54.38.38.159 icmp_seq=1 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=2 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=3 Destination Port Unreachable
>From 54.38.38.159 icmp_seq=4 Destination Port Unreachable

tcpdump sur le port 80 avec enregistrement.
>

Côté serveur dédié OVH ou côté sonde Uptime Kuma ? Au moment du blocage
j'ai déjà tenté de reproduire des pings & curl vers l'IP de mon dédié sur
lequel tournait tcpdump, aucune requête vu de mon IP à la maison.

Le mer. 6 sept. 2023 à 09:00, NoSpam  a écrit :

> Bonjour
>
> Le 06/09/2023 à 08:39, Romain 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.
>
> J'en déduis que le blocage est sur le port 80 ? Pour débloquer je
> suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80
>
> ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
> ping et traceroute ...
>
> >
> > 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...
> tcpdump sur le port 80 avec enregistrement.
>
>

Re: Debian 12 - Blocage IPv4 sans fail2ban & co

[NoSpam]

Bonjour

Le 06/09/2023 à 08:39, Romain 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.


J'en déduis que le blocage est sur le port 80 ? Pour débloquer je 
suppose une connexion ssh ? Lorsque c'est bloqué, testé un nc -v  80


ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise 
ping et traceroute ...




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...

tcpdump sur le port 80 avec enregistrement.

Debian 12 - Blocage IPv4 sans fail2ban & co

[Romain]

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