Problème connexion MySQL 'des fois' entre 2 serveurs FreeBSD
Bonjour, Ca fait plusieurs jours que je cherche pourquoi j'ai cette erreur et je m'en remet à vos bons conseils ^_^ J'ai 2 serveurs FreeBSD (12.1-RELEASE) avec PF activé sur chacun d'eux. L'un est le serveur web (nginx / php-fpm) et l'autre un serveur MariaDB. Ils sont connectés sur le même switch et aucune erreur réseau sur ce switch. De temps en temps (1 requête sur 10 environ mais des fois plus souvent), j'ai des requêtes de connexion sur la base de données qui n'aboutissent pas. J'ai analysé les trames (du coté du serveur web, donc celui qui initie la connexion MySQL) et je me retrouve avec un RST (cf la capture d'écran). Mon PF a la policy par défaut et donc drop les trame (soit ne renvoi pas de RST), j'ai controlé avec des logs et un tcpdump et les trames dont je parle juste au dessus n'arrivent pas sur PF. Est-ce que quelqu'un aurait une idée de génie? Cordialement, David Durieux
Yo, Pour le dire de manière simple le client reste souvent connecté au serveur SQL sans forcément faire de query et pf fini par faire expirer l'état dans sa table tu peut soit agir au niveau applicatif en rajoutant un anti-idle dans ton pool de connexions (options keepalive) ou alors reconfigurer la règle pf pour gérer la connexion sans état plutôt qu'avec (passer en no keep state) les 2 sont viables selon tes besoins. ;) On 24/10/2020 23:21, David Durieux wrote:
Bonjour,
Ca fait plusieurs jours que je cherche pourquoi j'ai cette erreur et je m'en remet à vos bons conseils ^_^
J'ai 2 serveurs FreeBSD (12.1-RELEASE) avec PF activé sur chacun d'eux.
L'un est le serveur web (nginx / php-fpm) et l'autre un serveur MariaDB.
Ils sont connectés sur le même switch et aucune erreur réseau sur ce switch.
De temps en temps (1 requête sur 10 environ mais des fois plus souvent), j'ai des requêtes de connexion sur la base de données qui n'aboutissent pas.
J'ai analysé les trames (du coté du serveur web, donc celui qui initie la connexion MySQL) et je me retrouve avec un RST (cf la capture d'écran).
Mon PF a la policy par défaut et donc drop les trame (soit ne renvoi pas de RST), j'ai controlé avec des logs et un tcpdump et les trames dont je parle juste au dessus n'arrivent pas sur PF.
Est-ce que quelqu'un aurait une idée de génie?
Cordialement,
David Durieux
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, merci d'abord à ceux qui m'ont envoyé des messages afin de m'aider. J'ai trouvé la source du problème. Le NAT (à cause des jails) dans PF envoyait sur l'interface extérieure mais des fois il envoyait avec une IP qui n'était pas la mienne (allez savoir pourquoi...). J'ai modifié ma configuration PF pour forcer la première IP de l'interface extérieure et ça régle le soucis. Je suis passé de : nat on igb0 from lo1:network to any -> igb0 à nat on igb0 from lo1:network to any -> igb0:0 Si ça peut servir à d'autre et éviter de chercher des jours et des jours :D Cordialement, David On Sat, 24 Oct 2020 23:21:46 +0200 David Durieux <david@durieux.family> wrote:
Bonjour,
Ca fait plusieurs jours que je cherche pourquoi j'ai cette erreur et je m'en remet à vos bons conseils ^_^
J'ai 2 serveurs FreeBSD (12.1-RELEASE) avec PF activé sur chacun d'eux.
L'un est le serveur web (nginx / php-fpm) et l'autre un serveur MariaDB.
Ils sont connectés sur le même switch et aucune erreur réseau sur ce switch.
De temps en temps (1 requête sur 10 environ mais des fois plus souvent), j'ai des requêtes de connexion sur la base de données qui n'aboutissent pas.
J'ai analysé les trames (du coté du serveur web, donc celui qui initie la connexion MySQL) et je me retrouve avec un RST (cf la capture d'écran).
Mon PF a la policy par défaut et donc drop les trame (soit ne renvoi pas de RST), j'ai controlé avec des logs et un tcpdump et les trames dont je parle juste au dessus n'arrivent pas sur PF.
Est-ce que quelqu'un aurait une idée de génie?
Cordialement,
David Durieux
participants (2)
-
David Durieux -
Jean Théry