Problème réseau

Kev · 29 août 2018, 09:25

Bonjour à tous,

Je viens m'en remettre à vous car je rencontre un problème étrange sur lequel je sèche.

Je possède un serveur dans un des datacenter d'OVH, sur ce serveur j'ai 7 VMs dont 1 sur laquelle je fais tourner Apache.
Afin de debuger un problème de lenteur sur l'upload (qui bloquait à ~2Mo/s au lieu de 12) j'ai installé une application HTML5/PHP de test de vitesse.
Lorsque j'utilise cette application, en général aucun problème, sauf quand je fais un test de vitesse depuis une source qui a plus de débit que le serveur (le serveur est limité a 100Mb/s par OVH et j'effectue mon test depuis un réseau 4G+ sur lequel j'ai environ 150Mb/s), dans ce cas, le DOM0 perd complètement le réseau (comme si le câble ethernet était débranché) jusqu'à ce que je redémarre la machine.

En analysant les syslog du DOM0 je vois que iptables drop les paquets entrants sur le port 80 au lieu de les router vers la VM comme habituellement.

Voici le script me permettant de définir les règles iptables du DOM0 :

Code : Tout sélectionner

#!/bin/bash

IPT="/sbin/iptables"

###########################################################################################
# Filter

## Remise par defaut des regles
$IPT -t filter -P INPUT   ACCEPT
$IPT -t filter -P FORWARD ACCEPT
$IPT -t filter -P OUTPUT  ACCEPT

## On purge les tables
$IPT -t filter -F

## On autorise lo
$IPT -t filter -A INPUT -i lo -j ACCEPT

## On ouvre les ports nécéssaires au DOM0
$IPT -t filter -A INPUT -m tcp -p tcp --dport 22      -j ACCEPT                                         ## SSH
$IPT -t filter -A INPUT -m udp -p udp --dport 53      -j ACCEPT                                         ## DNS
$IPT -t filter -A INPUT -m icmp -p icmp --icmp-type 8 -j ACCEPT                                         ## Ping
$IPT -t filter -A INPUT -s 10.0.0.0/24 -j ACCEPT

## On accepte si la connexion est déjà établie
$IPT -t filter -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

## On log ce qui n'a pas été matché par les règles précédente
$IPT -A INPUT -p tcp -j LOG --log-prefix "DROPED packets "

## On bloque tout le reste
$IPT -t filter -P INPUT DROP

############################################################################################
# Nat

## Remise par defaut des regles
$IPT -t nat -P PREROUTING  ACCEPT
$IPT -t nat -P POSTROUTING ACCEPT
$IPT -t nat -P INPUT       ACCEPT
$IPT -t nat -P OUTPUT      ACCEPT

## On purge
$IPT -t nat -F

### Routage des ports entrants pour la VM "mails"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22030 -j DNAT --to 10.0.0.30:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 25    -j DNAT --to 10.0.0.30:25                       ## SMTP
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 587   -j DNAT --to 10.0.0.30:587                      ## SMTP SUBMISSION
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 465   -j DNAT --to 10.0.0.30:465                      ## SMTP SSL
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 143   -j DNAT --to 10.0.0.30:143                      ## IMAP
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 993   -j DNAT --to 10.0.0.30:993                      ## IMAP SSL
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 9930  -j DNAT --to 10.0.0.30:9930                     ## IMAP SSL

### Routage des ports entrants pour la VM "sql"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22020 -j DNAT --to 10.0.0.20:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 3306  -j DNAT --to 10.0.0.20:3306                     ## MariaDB

### Routage des ports entrants pour la VM "files"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22010 -j DNAT --to 10.0.0.10:22                       ## SSH

### Routage des ports entrant pour la VM "web"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22040 -j DNAT --to 10.0.0.40:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 80    -j DNAT --to 10.0.0.40:80                       ## HTTP
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 443   -j DNAT --to 10.0.0.40:443                      ## HTTPS

### Routage des ports entrants pour la VM "monitor"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22050 -j DNAT --to 10.0.0.50:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 850 -j DNAT --to 10.0.0.50:80                 ## HTTP
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 855 -j DNAT --to 10.0.0.50:443                        ## HTTPS

### Routage des ports entrants pour la VM "comm"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22060 -j DNAT --to 10.0.0.60:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 5222  -j DNAT --to 10.0.0.60:5222                     ## Jabber
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 5269  -j DNAT --to 10.0.0.60:5269                     ## Jabber
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 5280  -j DNAT --to 10.0.0.60:5280                     ## Jabber
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 5281  -j DNAT --to 10.0.0.60:5281                     ## Jabber

### Routage des ports entrants pour la VM "secure"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22070 -j DNAT --to 10.0.0.70:22                       ## SSH

### Routage des ports entrants pour la VM "net"
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 22080 -j DNAT --to 10.0.0.80:22                       ## SSH
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 8388  -j DNAT --to 10.0.0.80:8388                     ## shadowsocks
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p udp --dport 8388  -j DNAT --to 10.0.0.80:8388                     ## shadowsocks
$IPT -t nat -A PREROUTING -d XX.XX.XX.XX -p tcp --dport 11094 -j DNAT --to 10.0.0.80:1194                     ## OpenVPN

### Autorise les VMs a accéder a internet
$IPT -t nat -A POSTROUTING -s 10.0.0.0/24 -j  MASQUERADE

Voici ce que je trouve dans les syslogs :

Code : Tout sélectionner

Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT= MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2226 DF PROTO=TCP SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT= MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2227 DF PROTO=TCP SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT= MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2228 DF PROTO=TCP SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0
Aug 28 15:50:32 ovh-1 kernel: DROPED packets IN=enp1s0 OUT= MAC=ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ:ZZ SRC=YY.YY.YY.YY DST=XX.XX.XX.XX LEN=40 TOS=0x00 PREC=0x00 TTL=55 ID=2229 DF PROTO=TCP SPT=9610 DPT=80 WINDOW=0 RES=0x00 RST URGP=0

*** J'ai des milliers de lignes de logs similaires ou seul l'ID change, puis : ***

Aug 28 15:50:32 ovh-1 kernel: e1000e: enp1s0 NIC Link is Down
Aug 28 15:50:32 ovh-1 systemd-networkd[20998]: enp1s0: Lost carrier
Aug 28 15:50:34 ovh-1 systemd-networkd[20998]: enp1s0: Gained carrier
Aug 28 15:50:34 ovh-1 kernel: e1000e: enp1s0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Aug 28 15:50:34 ovh-1 kernel: e1000e 0000:01:00.0 enp1s0: 10/100 speed: disabling TSO

Bien que les logs indiquent que la connexion réseau est "restauré", le serveur se retrouve hors ligne.
Dans les logs de la VM je ne vois rien d'anormal.

OVH est intervenu sur la machine, ils ont changé la carte mère et le câble réseau, mais au vu des logs, je songe à un problème software.

Auriez-vous des idées de ce qui peut se passer ou une piste pour m'aider à debuger le problème?

En vous remerciant par avance.

Kevin

29 août 2018, 13:40

Kevin,
tonDOM0, c'est quelle version de debian ? (stable, testing, SID).
As tu fait un ifconfig sur le DOM0 (si tu as encore accès au serveur), afin de vérifier que le pb est avant le tri des paquets ?Si tu n'as plus accès, tu peux lancer un ifconfig toute les minutes par exemple avec stockage de résultat sur disque, le temps de débuguer.

Kev · 29 août 2018, 13:58

Bonjour piratebab,

Merci pour ta réponse.

Le DOM0 (ainsi que le DOMU) utilise debian stable 9.5

Lorsque le problème survient je n'ai plus accès à la machine, je vais planifier un script pour voir le résultat de ifconfig durant le problème.

Depuis mon post, j'ai remarqué que d'autre paquet sont dropés au lieu d'être routés (sur le port 993 qui est censé être routé vers une autre VM).

29 août 2018, 15:36

Ce qui me fait penser à un pb hard , c'est

Code : Tout sélectionner

Aug 28 15:50:32 ovh-1 systemd-networkd[20998]: enp1s0: Lost carrier
Aug 28 15:50:34 ovh-1 systemd-networkd[20998]: enp1s0: Gained carrier

Et les paquets qui sont droped, sont les paquets sortants. je suppose que dans ton stress test, c'est le serveur qui envoi les paquets vers une cible.Et donc si le tuyau de sortie est coupé, le kernel n'a pas d'autre choix que de dropper les paquets.

Si ce n'est pas la CM, c'est peut étre le cable, ou le routeur.

Kev · 29 août 2018, 15:46

C'est bien des paquets entrants qui sont droppés, le SRC= correspond à mon IP en 4G+ et le DST= à celle du serveur.

En effet les logs laissent sous entendre que le câble est débranché puis rebranché, un problème de driver pourrait (peut être) engendrer ce genre de log, mais je pense que j'aurais des infos a ce sujet dans les logs.

Pour l'instant je n'arrive plus a faire en sorte que le serveur perde le réseau, je n'ai que les paquets droppés, je vais continuer mes tests en loguant le résultat d'un ifconfig -a

30 août 2018, 08:06

Si c'est les paquets entrants qui sont droppés, alors c'est un problème différente de celui de la perte de la connexion.
Un problème de driver/firmware ne se voit pas forcément pdans les logs. Vérifie que tu as bien les dernières versions de driver/firmware, et qu'il n'y a aps de configuration particulière à faire pour ton chip (c'est rare, mais ça arrive)

Kev · 30 août 2018, 09:23

On m'a fait remarquer que le "flow control" était inactif (je n'avais pas prêté attention à cette info), à priori, depuis les kernel 2.6 cette option n'est plus active par défaut pour le driver e1000, je l'ai activé pour voir ce que ça donne.

On m'a aussi mis sur la piste de l'anti DDOS d'OVH qui pourrait envoyer de paquets TCP RESET lorsqu'il s'active afin de fermer les connexions (d'où la présence de la mention "RST" dans le log d'iptables).

Le comportement est différent selon si je fait un test de débit via l'application HTML5/PHP qui fait pleins de requêtes ou lors d'un téléchargement d'un gros fichier en 1 seule requête.

Je vais essayer de me rapprocher d'OVH pour savoir si le serveur est isolé du réseau quelques instants lorsque l'anti DDOS s'active.

30 août 2018, 14:42

ça expliquerait effectivement cette coupure du réseau.
Si tu veux avoir une mesure de débit pure, il faut faire passer un flux de données constant. sinon le systéme passe plus de temps à gérer les connexions qu'a faire passer les données!
Dans le transfert d'un gros fichier, il faut aussi vérifier que ce n'est pas la lecture sur le disque qui limite le débit ...

03 oct. 2018, 17:58

Kev a écrit : 30 août 2018, 09:23Je vais essayer de me rapprocher d'OVH pour savoir si le serveur est isolé du réseau quelques instants lorsque l'anti DDOS s'active.

Et ???