Imprimer la page - Comportement étrange, principalement la nuit, vers IP OVH

Bonjour à tous,

Je tente de comprendre un problème assez complexe et inexpliqué à ce jour. Je possède plusieurs serveurs (chez OVH, Scaleway & co), et depuis chez moi (fibre Orange), j'ai un monitoring via Uptime Kuma, toutes les minutes, sur chacun de ces serveurs (ping et curl).

Très récemment, j'ai réinstallé un de ces serveurs, passant de Debian 11 à Debian 12. Pas de fail2ban & co, règles iptables vides.

Depuis, alors que je n'ai rien changé de spécial niveau réseau, j'ai régulièrement des blocages, qui sont de plus en plus long dès que le 1er blocage se déclenche. Exemple d'une nuit :
01h43-02h13 (30 minutes)
02h26-03h26 (1 heure)
03h28-05h28 (2 heures)

Lors de ces blocages, MTR fonctionne dans un sens (Orange vers OVH), mais pas dans l'autre (OVH vers Orange). Le ping d'Orange vers OVH, cependant, retourne des erreurs (étrange).
Quand je parle de blocage, c'est complet (SSH, ICMP, HTTP/HTTPS, ...).

Exemple :

Code: [Sélectionner]

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

Si je coupe un des deux monitorings (ping ou curl), le blocage cesse assez rapidement. Si je redémarre le serveur en mode rescue (où il n'y a pas de http/https ouvert par défaut), ça revient rapidement (mais pas immédiatement). Ca ne se déclenche jamais la journée.

Quand tout va bien, le routage d'Orange vers OVH donnait cela :

Code: [Sélectionner]

└─# mtr -r 54.38.38.159
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

Et OVH vers Orange :

Code: [Sélectionner]

Start: 2023-09-08T15:49:54+0200
HOST: rbx                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 54.38.38.252               0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- 10.162.250.98              0.0%    10    0.7   0.6   0.5   0.7   0.1
  3.|-- 10.72.52.32                0.0%    10    0.7   0.6   0.5   0.8   0.1
  4.|-- 10.73.17.42                0.0%    10    0.2   0.2   0.2   0.3   0.1
  5.|-- 10.95.64.152               0.0%    10    0.9   1.1   0.9   1.5   0.2
  6.|-- 54.36.50.226               0.0%    10    4.6   4.4   4.2   4.6   0.2
  7.|-- 10.200.2.73                0.0%    10    4.0   4.1   4.0   4.3   0.1
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- [MON IP PUBLIQUE]              0.0%    10    6.8   6.5   6.3   6.8   0.2

Quand ça déconne, Orange vers OVH :

Code: [Sélectionner]

idem que ci-dessus
Et OVH vers Orange :

Code: [Sélectionner]

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

Selon moi, si ma livebox est en ligne 9 quand tout va bien, la ligne 8 est un équipement Orange, et le blocage a lieu à ce niveau là.

Suite à ces échanges avec OVH, ils ont changé le routage pour passer par OpenTransit. Même résultat.

Quand ça fonctionne, d'OVH vers Orange :

Code: [Sélectionner]

Start: 2023-09-11T16:31:13+0200
HOST: rbx                                                                     Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg   Best   Wrst  StDev
  1. AS16276  54.38.38.252                                                     0.2   0.1   0.2   0.0%     5     5    0.3   0.5    0.3    0.6    0.1
  2. AS???    10.162.250.98                                                    0.1   0.1   0.2   0.0%     5     5    0.6   0.6    0.5    0.7    0.1
  3. AS???    10.72.52.32                                                      0.1   0.1   0.3   0.0%     5     5    0.6   0.6    0.4    0.7    0.1
  4. AS???    10.73.17.42                                                      0.1   0.1   0.1   0.0%     5     5    0.2   0.2    0.2    0.3    0.1
  5. AS???    10.95.64.152                                                     0.1   0.1   0.3   0.0%     5     5    1.1   1.1    1.1    1.3    0.1
  6. AS16276  par-th2-sbb1-nc5.fr.eu (54.36.50.226)                            0.2   0.1   0.3   0.0%     5     5    4.1   4.3    4.1    4.6    0.2
  7. AS???    10.200.2.69                                                      0.0   0.1   0.2   0.0%     5     5    4.3   4.3    4.3    4.5    0.1
  8. AS???    ???                                                              0.0   0.0   0.0  100.0     5     0    0.0   0.0    0.0    0.0    0.0
  9. AS???    bundle-ether306.pastr4.paris.opentransit.net (193.251.133.140)   0.1   0.1   0.2   0.0%     5     5    4.4   4.4    4.4    4.6    0.1
 10. AS???    ae0-0.niidf101.rbci.orange.net (193.252.137.9)                   0.0   0.0   0.1   0.0%     5     5    4.2   4.2    4.2    4.3    0.0
 11. AS???    ae41-0.ncidf103.rbci.orange.net (193.252.159.42)                 7.6   7.2  11.8   0.0%     5     5   25.7  14.7    4.5   25.7    8.3
 12. AS???    lag-102.nemla--1.rbci.orange.net (193.253.80.137)                0.0   0.0   0.1   0.0%     5     5    4.6   4.6    4.6    4.7    0.1
 13. AS3215   [MON FQDN] ([MON IP PUBLIQUE)       0.4   0.1   0.4   0.0%     5     5    6.6   6.3    6.2    6.6    0.2

Et quand ça déconne :

Code: [Sélectionner]

Start: 2023-09-12T07:33:01+0200
HOST: rbx                                                                     Jttr  Javg  Jmax  Loss%   Snt   Rcv   Last   Avg   Best   Wrst  StDev
  1. AS16276  54.38.38.252                                                     0.1   0.1   0.2   0.0%     5     5    0.4   0.4    0.3    0.5    0.1
  2. AS???    10.162.250.98                                                    0.0   0.3   0.7   0.0%     5     5    0.5   0.6    0.5    1.1    0.3
  3. AS???    10.72.52.32                                                      0.2   0.1   0.3   0.0%     5     5    0.4   0.5    0.4    0.7    0.1
  4. AS???    10.73.17.42                                                      0.0   0.0   0.0   0.0%     5     5    0.2   0.2    0.1    0.2    0.0
  5. AS???    10.95.64.152                                                     0.2   2.6   6.8   0.0%     5     5    1.2   2.6    1.0    7.9    3.0
  6. AS16276  par-th2-sbb1-nc5.fr.eu (54.36.50.226)                            0.4   0.2   0.4   0.0%     5     5    4.1   4.4    4.1    4.6    0.2
  7. AS???    10.200.2.69                                                      0.1   0.1   0.2   0.0%     5     5    4.3   4.3    4.2    4.4    0.1
  8. AS???    ???                                                              0.0   0.0   0.0  100.0     5     0    0.0   0.0    0.0    0.0    0.0
  9. AS???    bundle-ether306.pastr4.paris.opentransit.net (193.251.133.140)   0.2   0.1   0.2   0.0%     5     5    4.4   4.5    4.4    4.6    0.1
 10. AS???    ae0-0.niidf101.rbci.orange.net (193.252.137.9)                   0.0   0.1   0.1   0.0%     5     5    4.3   4.2    4.1    4.3    0.1
 11. AS???    ae41-0.ncidf103.rbci.orange.net (193.252.159.42)                 2.6   4.6  11.6   0.0%     5     5    4.6   8.2    4.5   16.1    4.8
 12. AS???    lag-102.nemla--1.rbci.orange.net (193.253.80.137)                0.0   0.0   0.1   0.0%     5     5    4.7   4.7    4.6    4.7    0.0
 13. AS???    ???

J'ai pensé à un blocage côté Livebox, j'ai tenté de réduire le pare-feu IPv4 à "faible" avec LiveboxMonitor, et j'ai tenté un redémarrage de la Livebox pendant le blocage, sans succès.

Avez-vous une idée de comment faire investiguer ça côté Orange ? Je me vois mal appeler le 3900 et évoquer cela :(

Romain

Ah oui et le ping depuis chez moi quand c'est tombé :

Code: [Sélectionner]

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

Je vois bien un ping request arriver sur le serveur, mais impossible d'y répondre semble-t-il :

Code: [Sélectionner]

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)

Concernant la réponse "Destination Port Unreachable", ICMP n'a pas de notion de port et, à ma connaissance, pas de raison d'envoyer ça en réponse à un ping.

Ce message vient très certainement d'un firewall, sur le serveur ou alors celui d'OVH si il interfère.

C'est, par exemple, la réponse par défaut de iptables quand il matche une de ces règles :

-P INPUT REJECT
ou :
-A -p icmp --icmp-type xxx -j REJECT

https://ipset.netfilter.org/iptables-extensions.man.html
cf REJECT (IPv4-specific)

Il n'y a aucune règle iptable sur le serveur, et on voit bien le paquet quitter le réseau d'OVH sur le MTR. Je pense que le filtrage s'effectue sur un équipement Orange, ou sur ma box mais j'ai pas la main dessus et un reboot n'aide pas.

quote:
Je vois bien un ping request arriver sur le serveur, mais impossible d'y répondre semble-t-il :

Code: [Sélectionner]

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)

Iptables n'était qu'un exemple. Ce paquet 36 est émis et capturé sur le serveur ? Si oui la réponse parvient bien à ton PC chez Orange vu les traces. Et dans ce cas, Orange ou pas, ca ne peut pas marcher.

La capture vient bien du serveur OVH, mais c'est le seul à ne pas pouvoir ping ou faire un MTR complet jusqu'à mon IP Orange.
Un autre serveur OVH, ou un serveur ailleurs, parvient sans problème à le faire.

Là c'est down.

Impossible de ping l'IP d'Orange depuis OVH, et d'OVH depuis Orange.

tshark des deux côtés, tentative de requête http sur le port 80 du serveur OVH depuis Orange

Vu par OVH :

Code: [Sélectionner]

└─# tshark -f 'host [IP ORANGE]'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'enp3s0f0'
 ** (tshark:3959333) 22:29:18.715877 [Main MESSAGE] -- Capture started.
 ** (tshark:3959333) 22:29:18.715930 [Main MESSAGE] -- File: "/tmp/wireshark_enp3s0f0G6HJB2.pcapng"
    1 0.000000000 [IP ORANGE] → 54.38.38.159 TCP 74 41816 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=4011860070 TSecr=0 WS=128
    2 0.000078325 54.38.38.159 → [IP ORANGE] ICMP 102 Destination unreachable (Port unreachable)

Vu côté appareil connecté sur mon réseau qui fait la requête (curl):

Code: [Sélectionner]

└─$ sudo tshark -f 'host 54.38.38.159'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens192'
 ** (tshark:176657) 22:29:13.403143 [Main MESSAGE] -- Capture started.
 ** (tshark:176657) 22:29:13.403513 [Main MESSAGE] -- File: "/tmp/wireshark_ens192A0ZEB2.pcapng"
    1 11.266112910 192.168.0.254 → 54.38.38.159 TCP 74 41816 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=4011860070 TSecr=0 WS=128
    2 11.272746876 54.38.38.159 → 192.168.0.254 ICMP 102 Destination unreachable (Port unreachable)

C'est revenu à la normal après pile 30 minutes, maintenant même opération, on voit le SYN ACK.

Côté OVH :

Code: [Sélectionner]

1 0.000000000 [IP ORANGE] → 54.38.38.159 ICMP 98 Echo (ping) request  id=0x1b73, seq=1/256, ttl=49
    2 0.000089963 54.38.38.159 →[IP ORANGE] ICMP 98 Echo (ping) reply    id=0x1b73, seq=1/256, ttl=64 (request in 1)
    3 1.159941073 [IP ORANGE] → 54.38.38.159 TCP 74 46654 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=4012893090 TSecr=0 WS=128
    4 1.160022397 54.38.38.159 → [IP ORANGE] TCP 74 80 → 46654 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2779244587 TSecr=4012893090 WS=128
    5 1.167813959 [IP ORANGE] → 54.38.38.159 TCP 66 46654 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=4012893098 TSecr=2779244587
    6 1.168538977 [IP ORANGE] → 54.38.38.159 HTTP 146 GET / HTTP/1.1

Côté Orange :

Code: [Sélectionner]

1 0.000000000 192.168.0.254 → 54.38.38.159 ICMP 98 Echo (ping) request  id=0x1b73, seq=1/256, ttl=63
    2 0.007622202 54.38.38.159 → 192.168.0.254 ICMP 98 Echo (ping) reply    id=0x1b73, seq=1/256, ttl=51 (request in 1)
    3 1.160849961 192.168.0.254 → 54.38.38.159 TCP 74 46654 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=4012893090 TSecr=0 WS=128
    4 1.168861901 54.38.38.159 → 192.168.0.254 TCP 74 80 → 46654 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=2779244587 TSecr=4012893090 WS=128
    5 1.168887000 192.168.0.254 → 54.38.38.159 TCP 66 46654 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=4012893098 TSecr=2779244587
    6 1.169000617 192.168.0.254 → 54.38.38.159 HTTP 146 GET / HTTP/1.1

Bonjour,

ça ressemble vraiment à un blocage style anti DDOS ou autre sur l'infra orange.
C'est une connexion Orange GP ou Pro ?
quelle est la fréquence de tes curls/pings ? si tu espaces légèrement tes requêtes, est ce que ça se passe mieux ?

Connexion GP, un ping et un curl par minute via Uptime Kuma.

et si tu passes à 2 min pour le curl observes tu toujours les mêmes blocages ?
Sur une connexion Orange GP, aucune chance que le service client traite ce genre de soucis ...

Je pense qu'en réduisant le délai entre 2 monitoring le problème de se reproduira pas, mais justement j'attend la fin des échanges avec Orange pour voir, car pendant ces échanges j'ai besoin de reproduire :)

Je suis passé de 1 minute à 5 minutes pour le monitoring, ça coince toujours, et toujours la nuit à partir de 23h. Jamais de blocage la journée.

et tu fais toujours le ping et le curl a la même seconde ?

Ca a effectivement lieu à la même seconde, cependant c'était déjà le cas depuis longtemps, et surtout j'ai une dizaine d'autres serveurs qui sont surveillés aussi, dont certains aussi chez OVH, et je n'ai pas ce problème.

Problème réglé 👍

Citation de: ro78 le 02 octobre 2023 à 13:17:54

Problème réglé 👍

Tout seul ou via une action ?

Ce n’était ni OVH ni Orange, mais mon problème a permis de mettre en évidence un problème de MTU sur un équipement Orange pour le trafic sur Paris.

Comme je le disais, pas de fail2ban ou autre sur ce serveur. Sauf dans une stack Docker (mailcow).

J’ai fini par confirmer que redémarrer le serveur réglait immédiatement le problème.
J’ai ensuite fini par trouver que redémarrer Docker permettait de régler le problème.
Enfin, que redémarrer le container netfilter de cette stack réglait le problème.

J’ai d’abord pensé à un bug de ce container sous Debian 12, jusqu’à ce que je fouille les journaux de celui-ci.

Après analyse, voici ce qu’il en ressort :
- un appareil (téléphone de ma femme) de mon réseau avec sa propre IPv6 tente de se connecter en IMAP mais échoue
- après X échecs, blocage de son IPv6 mais puisque chaque appareil du réseau a son IPv6, pas visible sur mon monitoring
- suite à ce blocage, tentative de connexion du téléphone en IPv4
- après X échecs, blocage de l’IPv4 publique qui est partagée à tous les appareils du réseau, donc visible sur mon monitoring

Ca colle avec la progressivité de la durée de blocage observée, et du coup ça colle aussi avec le fait que c’était surtout la nuit, puisque la journée Madame n’est pas là.

J’ai réglé le problème de connexion du téléphone et problème résolu. Le piège d’avoir un filtrage qui n’est pas directement sur l’hôte.

« Tout ça pour ça »

La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => Orange / Sosh => Incidents Orange => Discussion démarrée par: ro78 le 12 septembre 2023 à 10:14:36