Si le WSA reçoit un paquet de réinitialisation TCP sur sa connexion en amont au serveur Web, le WSA enverra une erreur 504 Gateway Timeout au client. Causes typiques de ce problème : 1. Cisco Layer 4 Traffic Monitor (L4TM) empêche le proxy WSA de se connecter au serveur Web. 2. Un pare-feu, un système IDS, un système IPS ou un autre dispositif d’inspection de paquets bloque l’appareil de sécurité Web. Étapes de dépannage : Déterminez tout d'abord si le RST TCP provient de L4TM ou d'un autre périphérique. Si L4TM bloque ce trafic, il s'affiche dans les rapports de l'interface utilisateur sous "Monitor -> L4 Traffic Monitor". Sinon, la TVD provient d'un autre périphérique. Blocage L4TM : Il est recommandé que si L4TM bloque, ne bloquez pas les ports sur lesquels le proxy WSA est également en cours d'exécution. Il y a plusieurs raisons à cela : 1. Le proxy WSA fournit un message d’erreur convivial en cas de problème, au lieu de simplement réinitialiser la connexion via TCP. Cela permettra de limiter la confusion des utilisateurs finaux lorsqu'ils sont bloqués. 2. Le proxy WSA peut analyser et bloquer du contenu spécifique, tandis que L4TM bloque tout le trafic correspondant à une adresse IP sur liste noire. Afin de configurer L4TM pour ne pas bloquer sur les ports proxy, allez à "GUI -> Security Services -> L4 Traffic Monitor". Si le site est un site Web inapproprié connu, mais qu'il existe des raisons pour lesquelles le trafic doit être autorisé, le site peut être répertorié en blanc dans : "GUI -> Web Security Manager -> Moniteur de trafic de couche 4 -> Liste d'autorisation" Pare-feu / IDS / Blocage IPS : Si un autre périphérique du réseau empêche le WSA de se connecter au serveur Web, il est recommandé d'analyser les éléments suivants : 1. Journaux de blocage du pare-feu 2. Captures de paquets en entrée/sortie pendant le problème Les journaux de blocage peuvent rapidement confirmer si le périphérique bloque le WSA. Parfois, un pare-feu, IPS ou IDS bloque le trafic et NE le consigne PAS correctement. Si c'est le cas, la seule façon de prouver d'où vient la RST TCP est d'obtenir des captures d'entrée et de sortie du périphérique. Si un RST est envoyé par l'interface d'entrée et qu'aucun paquet n'est passé par le côté de sortie, le périphérique de sécurité est certainement la cause.
|