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
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
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
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
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
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,
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
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
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
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.
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
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
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.
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
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
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
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
>
└─# 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.|--
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 ?
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
Ç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
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
>
> 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é
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
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
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
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
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 ...
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
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
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
31 matches
Mail list logo
