L'authentification proxy du navigateur sans tête n'est pas une route VPN

Un VPN peut acheminer le trafic d'un navigateur vers un serveur proxy tout en empêchant le navigateur d'utiliser ce proxy, car un itinéraire et un identifiant sont des choses différentes. L’automatisation sans tête rend l’écart plus difficile à voir, car il n’y a ni fenêtre ni invite à le remarquer. La panne apparaît généralement comme un blocage ou une erreur de navigation générique, et le premier réflexe est de blâmer le tunnel. La liste de contrôle ci-dessous sépare les quatre éléments qui doivent être vrais avant qu'une requête sans tête via un proxy authentifié puisse aboutir.

Deux conversations, deux informations d'identification

Deux conversations ont lieu et elles appartiennent à des parties différentes. Le navigateur se connecte d'abord à l'écouteur proxy, qui peut lui demander des informations d'identification ; le proxy établit ou autorise ensuite la connexion vers la destination. Un VPN peut assurer la première étape sans être le point final qui défie le navigateur, et il n'a rien à dire sur la seconde.

HTTP 407 est le signal que le client doit s'authentifier pour la demande de proxy, porté dans Proxy-Authenticate avec la réponse attendue dans Proxy-Authorization. Il ne s'agit pas de l'identifiant du site Web de destination, et le mélange des deux est la source de confusion la plus courante ici.

Les quatre vérifications sont donc : quel proxy le navigateur a réellement sélectionné, qui répond au 407, sur quel réseau se trouve le processus du navigateur et comment les informations d'identification sont délivrées sans intervention humaine. Chacun peut échouer indépendamment, et chaque échec se ressemble de l’extérieur. Travaillez-les dans l'ordre, car un contrôle ultérieur ne peut compenser un contrôle antérieur. Un proxy qui n'a jamais été sélectionné ne peut pas être authentifié et un identifiant qui n'existe que sur votre ordinateur portable ne peut pas atteindre un conteneur.

Vérifiez 1 : quel proxy est réellement sélectionné

Commencez par la sélection, car un navigateur qui ignore vos paramètres de proxy ne parvient jamais à relever le défi. Dans Chrome, l'indicateur est --proxy-server=proxy.example:3128 , avec --proxy-bypass-list pour les exclusions, et Selenium expose la même chose via les options de son navigateur. Un fichier PAC est un mécanisme différent avec ses propres modes de défaillance.

Confirmez ensuite depuis l'environnement du navigateur en cours d'exécution plutôt que depuis votre shell. Une sonde indépendante avec le même proxy est curl -x http://proxy.example:3128 -v https://example.com , et sa sortie détaillée indique si la CONNECT a réussi, quel Proxy-Authenticate est revenu et si un 407 a été renvoyé. Si curl obtient un 407 et que le navigateur se bloque, le chemin des informations d'identification est le problème plutôt que le réseau. Si curl réussit et que le navigateur ne le fait pas, le navigateur n'utilise pas le proxy que vous pensez.

Vérifiez 2 : qui répond au 407

Un 407 a un propriétaire et son nom détermine la destination du correctif. Si le défi provient du proxy d'entreprise, le correctif est un identifiant que le navigateur peut présenter sans surveillance. S'il provient d'un proxy en amont vers lequel le premier transmet, les informations d'identification appartiennent à ce deuxième saut et le premier proxy peut relayer le défi sans modification. Lisez la portée d'authentification et l'hôte dans l'en-tête Proxy-Authenticate, car ils nomment la case qui demande.

Préservez cette distinction dans tout ce que vous enregistrez. Un défi de proxy, une connexion refusée, une connexion à un site Web et un délai d'attente de transport VPN sont quatre échecs différents avec quatre propriétaires différents, et un message d'erreur générique détruit les informations dont vous avez besoin.

Vérifiez 3 : le chemin d'accès aux informations d'identification

Les informations d'identification elles-mêmes sont l'endroit où la plupart des configurations sans surveillance échouent. Selenium peut définir un hôte et un port proxy, mais l'authentification proxy HTTP n'est pas une partie portable de cette configuration, et les informations d'identification dans l'URL du proxy ne sont pas un mécanisme sur lequel vous pouvez compter sur tous les navigateurs et versions de pilotes. Les options prises en charge sont celles de vos documents de pile réels : une extension de navigateur qui répond au défi, un proxy de transfert local qui ajoute l'en-tête et est accessible uniquement à partir du travail, ou un proxy qui authentifie la charge de travail par d'autres moyens. Choisissez-en un délibérément et comparez-le aux versions exactes du navigateur, du pilote et de Selenium que vous exécuterez.

Gardez les informations d'identification hors des endroits où elles fuient. Les lignes de commande sont visibles dans les listes de processus, les captures d'écran se retrouvent dans les rapports de test, les traces du navigateur et les en-têtes de capture des fichiers HAR, et la configuration de test validée est éternelle. Utilisez le mécanisme de livraison secret du travail et ses règles de rédaction, et étendez le compte proxy aux destinations ou au rôle dont il a besoin.

Si l’organisation propose une route VPN directe autorisée au lieu d’un proxy obligatoire, comparez explicitement les deux conceptions. Ne désactivez pas discrètement le proxy et n'imitez pas l'authentification d'un autre client pour contourner la politique.

Vérifiez 4 : le contexte réseau du processus du navigateur

C’est le chèque que les gens sautent. Un navigateur lancé par un travailleur, un conteneur ou un nœud Selenium Grid distant utilise le réseau de cet environnement, de sorte que la connexion VPN de votre ordinateur portable et les variables proxy de votre shell décrivent un chemin que le navigateur ne peut jamais toucher.

Enregistrez cinq faits pour la tâche défaillante : l'hôte du navigateur, le proxy configuré, le chemin du résolveur initial, la route sélectionnée et le propriétaire de l'authentification. Ensuite, faites une demande autorisée inoffensive à partir de ce contexte exact, en laissant la vérification TLS de destination normale et l'autorisation d'application activées. Un navigateur sans tête qui démarre avec succès ne prouve ni l'admission du proxy ni la couverture VPN, et une capture d'écran d'une page vierge ne prouve rien du tout. La requête qui renvoie 200 sur toute la chaîne est la seule preuve qui compte.

Le flux de travail terminé possède trois propriétés qui méritent d'être vérifiées dans leur ensemble. Il existe un itinéraire pris en charge depuis l'hôte du navigateur vers le proxy, une politique intermédiaire explicite qui nomme le proxy et les destinations, et un cycle de vie des informations d'identification qui ne dépend pas de la réponse d'un opérateur à une invite invisible. Si l’un des trois dépend d’une personne, le travail n’est pas encore sans surveillance, quoi qu’en dise le code de sortie. Notez les cinq faits avant que la personne suivante n’hérite du pipeline.