@Aunet:
Bonjour et merci pour votre aide,
Voici le résultat des tests demandés :
B n'éprouve bien des timeouts qu'envers A, le reste du web est accessible.
A est joignable depuis n'importe quel endroit lorsque nous n'arrivons plus à y accéder (pas de problème en 3G/4G et depuis d'autres bureaux à l'étranger).
B peut joindre plusieurs serveurs en SSH sur A lors du problème, et même le reverse proxy (SSH) ! Ca ne semble donc toucher que le port 80 et 443.
A est relié à Internet par OVH, le câble réseau d'OVH est relié à notre Pfsense de prod et derrière celui-ci Nginx (reverse proxy), Apaches, …
Les graphiques WAN restent stables, il n'y a pas de pointe de traffic.
L'hors du problème, les sites de développement hébergés en DMZ chez B restent accessibles depuis l'hébergement distant A. Le problème n'est donc que dans un sens.
La connexion Internet de B (bureaux) synchronise à 48,50 Mbps en download et 8,19 Mbps en upload.
Schéma :
LAN employés --- Pfsense --- connexion Internet 1 --- Internet --- OVH --- Pfsense de prod --- Nginx --- Apaches, IIS, ...
\ ---/
-- connexion Internet 2 /
Je ne vois d'autres infos à vous communiquer,
Encore merci
corrigez moi si je me trompe
COTE B /////////////////////////////////////////////////////////////////////////// COTE A
LAN employés –- Pfsense --- connexion Internet 1 --- Internet --- OVH --- Pfsense de prod --- Nginx --- Apaches, IIS, ...
\ ---/
-- connexion Internet 2 /
Faites les tests suivants:
Ajoutez un serveur témoin du coté de A écoutant sur le port 80
1/ vous le mettez dans le pool nginx
2/ vous le nattez par ailleurs sur pfsense A par un autre port libre hors du pool exemple 8080 sur 80
depuis B
lorsque le probleme se produit:
1/ vous verifiez l'état en connexion 80 a travers le pool nginx sur le serveur témoin
2/ vous verifiez l'état en connexion 8080 natée sur le temoin 80 (hors du pool)
il sera interessant d'avoir ce résultat.
Coté B:
C'est quoi cette connexion internet 2 ?
les services de A demeurent ils joignables a travers cette deuxieme interface WAN coté B ?
Si non: Y aurait il une possibilité que pfsense B distribue d'une manière non souhaitée les requêtes sur ses ports WAN ? A verifier
lorsque le probleme se produit, faites l'essai avec cette connexion activée
puis faites un contre test après avoir éteint cette deuxieme interface et rebooté pfsense coté B.
autre test a effectuer: passez le gui de pfsense coté A sur 80 puis sur 443, et essayez aussi pendant les timeouts de contacter ca depuis B.
--
de prim'abord je dirais que c'est le reverse.
ces tests et contre tests vous permettront de mettre en lumiere cela
CDLT
ps: je me permet d'insister sur cette composante fondamentale du "serveur témoin" (une débian de base avec apache),
qui m'apparait évident afin de tester sur une bonne base.
en effet, un serveur derriere le pool pourrait tres bien aussi etre fautif, aussi nous ne pouvons faire confiance qu'en ce serveur frais, propre témoin
(a mon avis)
faites en sorte qu'il soit joignable sur les mêmes ports que vos serveurs applicatifs de production
faites en sorte qu'il soit joignable a travers le pool du reverse
faites en sorte qu'il soit joignable par NATage
testez les connectivités depuis B :
derriere en temps que LAN
derriere pfsense en temps que switch LAN
derriere le CPE opérateur (box) en temps que pfsense (si double nat)
ou testez avec un pc, directement au cul du CPE en bridge avec ip publique.
tous ces petits tests, vous feront mener l'enquete