Navigateur d’agence vers le proxy : deux connexions, deux routes

Un navigateur d’agence derrière un proxy explicite ouvre deux connexions, et elles échouent pour des raisons différentes. La première va du navigateur au listener du proxy, transportée par le VPN du site. La seconde va du proxy au site web, avec le résolveur, la route et la politique de sortie propres au proxy. Les tickets de support qui les traitent comme un seul flux envoient les gens sur le mauvais équipement pendant des heures. Configurez chacune délibérément et testez-les dans cet ordre.

Étape 1 : écrivez les deux flux

La destination immédiate du navigateur est le listener du proxy, et non tous les sites que l’utilisateur finit par visiter. Cette seule phrase résout l’essentiel de la confusion dans cette conception.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

Sources différentes, routes différentes, permissions différentes. Gardez le schéma dans le registre des changements, car chaque vérification ultérieure renvoie à l’une de ses deux moitiés.

Étape 2 : donnez au navigateur un chemin vers le listener

Notez le nom d’hôte du proxy, le port du listener, les exigences d’authentification et les sources d’agence autorisées. Cette liste constitue les critères d’acceptation du premier flux, et elle doit inclure la résolution de noms privée ainsi que la route du tunnel.

Appliquez une règle réseau étroite pour le service prévu au lieu de publier un proxy sans restriction sur Internet. Le proxy peut rester sur un réseau interne lorsque ses clients prévus disposent d’un chemin pris en charge vers lui.

Étape 3 : configurez le navigateur, pas seulement la table de routage

Utilisez le réglage de proxy du navigateur, un fichier PAC ou le mécanisme de découverte géré de l’organisation. Envoyer des paquets de site ordinaires vers l’adresse du proxy avec une route ne fait pas parler au navigateur le protocole du proxy ; c’est de l’interception transparente et cela relève d’une autre conception de passerelle.

Notez quelles applications respectent le réglage. Les clients de messagerie, les programmes de mise à jour et les jeux ne le font souvent pas, et ils continueront d’utiliser le chemin simple.

Étape 4 : prouvez la connexion sortante du proxy

Le proxy a besoin de son propre résolveur et d’une route autorisée vers le site, plus la politique de pare-feu ou de traduction qu’exige sa frontière Internet. Un navigateur qui atteint le listener ne prouve rien de tout cela. Testez le second flux depuis le proxy lui-même, avec la même destination et le même port que ceux signalés par l’utilisateur.

Pour HTTPS, CONNECT ouvre un tunnel vers la destination demandée. Le transfert ordinaire ne remet pas au proxy la page déchiffrée, et désactiver la validation des certificats pour improviser une inspection n’est pas une solution.

Étape 5 : distinguez quatre pannes

Un défi d’authentification du proxy est un 407 émis par le listener. Un CONNECT refusé est une décision de politique sur le proxy, généralement avec son propre statut et sa propre ligne de journal. Une connexion sortante en échec ressemble à un délai d’attente ou à une réinitialisation que le proxy consigne pour la destination. Une réponse du site signifie que les deux connexions ont fonctionné et que le problème vient de l’origine.

Signalez la frontière que vous avez observée, pas le résumé selon lequel le VPN a échoué.

Étape 6 : délimitez la portée et planifiez le repli

Décidez de ce qui se passe lorsque le proxy ou le tunnel est indisponible, et dites clairement quel trafic cette conception couvre. Elle transporte l’accès web depuis les clients qui respectent le réglage de proxy ; elle ne transporte pas le courrier, des protocoles d’appareil arbitraires ou des logiciels qui ignorent la configuration.

Validez l’opération de navigateur requise et un refus requis selon un plan approuvé avant d’étendre la conception à davantage de clients.