> > 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 <mv...@free.fr> 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. > >
