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...tcpdump sur le port 80 avec enregistrement.
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.159mtr -n 54.38.38.159
tcpdump sur le port 80 avec enregistrement.Serveur bien sûr
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 <no-spam@tootai.net> 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
<ip> 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.
ping et traceroute ...
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
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 <ip> 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.
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 <no-spam@tootai.net> 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 <ip> 80 >>
ping port unreachable et mtr fonctionnel est un oxymore ! mtr utilise
ping et traceroute ...
tcpdump sur le port 80 avec enregistrement.
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...
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 6 sept. 2023 à  09:31, NoSpam <<a href="mailto:no-spam@tootai.net">no-spam@tootai.net</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
J'insiste, les ports sont ouverts. Depuis une IP source différente (quand
la mienne est bloquée), ça fonctionne.
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.
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
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.
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.
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.
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
<div><br></div><div>Le même quelques minutes après (pas normal) :</div><div>└─# mtr -r 54.38.38.159 -4<br>Start: 2023-09-07T07:24:27+0000<span class="gmail-im" style="color:rgb(80,0,80)"><br>HOST: rpi4             Loss% ÂSnt  Last  Avg  Best  Wrst StDev<br></span> 1.|-- livebox.home        0.0%   10   0.9  1.1  0.7  2.8  0.6<br> 2.|-- 80.10.239.9         0.0%   10   2.8  3.0  2.7  4.4  0.5<br> 3.|--
<div>02h26-03h26 (1 heure)</div><div>03h28-05h28 (2 heures)</div><div>05h55-? (pas encore débloqué)</div><div><br></div><div>Problèmes :</div><div>- sur le template Debian 12 d'OVH pour les serveurs dédiés, il n'y a pas d'outil deblocage pré-installé (pas de fail2ban par exemple)</div><div>- je n'en ai pas ajouté depuis l'installation du serveur, uniquement apache (avec mod_security), PHP et MariaDB</div><div>- depuis l'IP de chez moi, cette nuit, les seules requê
Ç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 <http://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 <http://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 <http://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 <http://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 <http://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
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+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
└─# 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:17, Romain <romain@borezo.info> 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 <no-spam@tootai.net> 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+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
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 ?
└─# mtr -r 54.38.38.159 -4
15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7 7.9 0.4
12.|-- rpi4.home 90.0% 10 7955. 7955. 7955. 7955. 0.0
Le 7 septembre 2023 Romain a écrit :Bein si, on aurait vu de suite une IP privée de rpi4.home, pas besoin de
Oui, rpi4.home est chez moi. J'essaie de reproduire avec le -n, mais maL'option -n évite le dns mais ça n'apporte rien de plus.
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 7 septembre 2023 Romain a écrit :
└─# mtr -r 54.38.38.159 -40.4
15.|-- mail.borezo.info 0.0% 10 6.9 7.2 6.7 7.9
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 ?
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éconneet
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.
<div>A suivre.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 7 sept. 2023 à  12:37, Michel Verdier <<a href="mailto:mv524@free.fr" target="_blank">mv524@free.fr</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 7 septembre 2023 Romain a écrit :<br>
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.
On 07 Sep 2023 12:55, Romain wrote:
Les erreurs étaient bien (et sont encore, même si moins nombreuses) surle
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
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.
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é.
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.
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 <mv524@free.fr> 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.
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.
Bonjour
Le 07/09/2023 à 23:38, Romain a écrit :<html>
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 <mv524@free.fr> 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.
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.
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 <mv524@free.fr> 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 19:24:41 |
| Calls: | 9,665 |
| Files: | 13,713 |
| Messages: | 6,167,961 |