Una VPN pot transportar el trànsit d'un navegador a un servidor intermediari i deixar que el navegador no pugui utilitzar aquest servidor intermediari, perquè una ruta i una credencial són coses diferents. L'automatització sense cap fa que la bretxa sigui més difícil de veure, ja que no hi ha cap finestra i no hi ha cap indicació per notar-ho. La fallada sol aparèixer com un bloqueig o un error de navegació genèric, i el primer instint és culpar al túnel. La llista de verificació següent separa les quatre coses que han de ser certes perquè una sol·licitud sense cap a través d'un servidor intermediari autenticat pugui tenir èxit.

Dues converses, dues credencials

Es produeixen dues converses i pertanyen a parts diferents. El navegador es connecta primer a l'escolta del servidor intermediari, que pot desafiar-lo per obtenir les credencials; aleshores el proxy fa o permet la connexió posterior amb la destinació. Una VPN pot portar el primer tram sense ser el punt final que desafia el navegador i no té res a dir sobre el segon.

HTTP 407 és el senyal que el client ha d'autenticar per a la sol·licitud de proxy, portada a Proxy-Authenticate amb la resposta esperada a Proxy-Authorization. Aquest no és l'inici de sessió del lloc web de destinació i barrejar els dos és la font de confusió més comuna aquí.

Per tant, les quatre comprovacions són: quin servidor intermediari ha seleccionat realment el navegador, qui respon al 407, a quina xarxa es troba el procés del navegador i com s'entrega la credencial sense cap humà. Cadascun pot fallar de manera independent, i cada fallada sembla semblant des de fora. Treballeu-los en ordre, perquè una comprovació posterior no pot compensar una d'anterior. Un servidor intermediari que no s'ha seleccionat mai no es pot autenticar i una credencial que només existeix al vostre ordinador portàtil no pot arribar a un contenidor.

Comproveu 1: quin proxy està realment seleccionat

Comenceu amb la selecció, perquè un navegador que ignora la configuració del servidor intermediari mai no arriba al repte. A Chrome la bandera és --proxy-server=proxy.example:3128 , amb --proxy-bypass-list per a les exclusions, i Selenium exposa el mateix a través de les opcions del seu navegador. Un fitxer PAC és un mecanisme diferent amb els seus propis modes de fallada.

A continuació, confirmeu des de l'entorn del navegador en execució i no des del vostre shell. Una sonda independent amb el mateix servidor intermediari és curl -x http://proxy.example:3128 -v https://example.com , i la seva sortida detallada mostra si la CONNECT ha tingut èxit, què ha tornat Proxy-Authenticate i si s'ha retornat un 407. Si curl obté un 407 i el navegador es bloqueja, el problema és el camí de la credencial en lloc de la xarxa. Si curl té èxit i el navegador no, el navegador no està utilitzant el servidor intermediari que creieu que és.

Comproveu 2: qui respon el 407

Un 407 té un propietari i el seu nom decideix on va la solució. Si el repte prové del servidor intermediari corporatiu, la solució és una credencial que el navegador pot presentar sense vigilància. Si prové d'un servidor intermediari amunt al qual el primer reenvia, la credencial pertany a aquest segon salt i el primer servidor intermediari pot estar transmetent el desafiament sense canvis. Llegiu l'àmbit d'autenticació i l'amfitrió a la capçalera Proxy-Authenticate, perquè anomenen el quadre que demana.

Preserveu aquesta distinció en qualsevol cosa que registreu. Un repte de proxy, una connexió posterior rebutjada, un inici de sessió al lloc web i un temps d'espera de transport VPN són quatre errors diferents amb quatre propietaris diferents i un missatge d'error genèric destrueix la informació que necessiteu.

Comproveu 3: el camí de la credencial

La pròpia credencial és on es trenquen la majoria de les configuracions desateses. Selenium pot establir un amfitrió i un port de proxy, però l'autenticació de proxy HTTP no és una part portàtil d'aquesta configuració, i les credencials de l'URL del servidor intermediari no són un mecanisme en què es pugui confiar en tots els navegadors i versions del controlador. Les opcions admeses són les que documenteu la pila real: una extensió del navegador que respon al repte, un servidor intermediari de reenviament local que afegeix la capçalera i només es pot accedir des de la feina o un servidor intermediari que autentica la càrrega de treball per altres mitjans. Trieu-ne un deliberadament i comproveu-lo amb el navegador exacte, el controlador i les versions de Selenium que executareu.

Mantingueu la credencial fora dels llocs que la filtran. Les línies d'ordres són visibles a les llistes de processos, les captures de pantalla acaben als informes de prova, les traces del navegador i les capçaleres de captura de fitxers HAR i la configuració de prova compromesa és per sempre. Utilitzeu el mecanisme de lliurament secret de la feina i les seves regles de redacció, i abasteu el compte intermediari a les destinacions o la funció que necessiti.

Si l'organització ofereix una ruta VPN directa permesa en lloc d'un servidor intermediari obligatori, compareu els dos dissenys de manera explícita. No desactiveu el proxy en silenci ni imiteu l'autenticació d'un altre client per evitar la política.

Comproveu 4: el context de xarxa del procés del navegador

Aquest és el control que la gent salta. Un navegador llançat per un treballador, un contenidor o un node remot de Selenium Grid utilitza la xarxa d'aquest entorn, de manera que la connexió VPN de l'ordinador portàtil i les variables de proxy de l'intèrpret d'ordres descriuen un camí que el navegador mai podria tocar.

Enregistreu cinc fets per a la feina que falla: l'amfitrió del navegador, el servidor intermediari configurat, la ruta de resolució inicial, la ruta seleccionada i el propietari de l'autenticació. A continuació, feu una sol·licitud autoritzada inofensiva des d'aquest context exacte, amb la verificació TLS de destinació normal i l'autorització de l'aplicació activada. Un navegador sense cap que s'inicia amb èxit no demostra ni l'admissió de proxy ni la cobertura de VPN, i una captura de pantalla d'una pàgina en blanc no demostra res. La sol·licitud que retorna 200 a través de tota la cadena és l'única evidència que compta.

El flux de treball acabat té tres propietats que val la pena comprovar com a conjunt. Hi ha una ruta admesa des de l'amfitrió del navegador fins al servidor intermediari, una política d'intermediari explícita que anomena el servidor intermediari i les destinacions, i un cicle de vida de credencials que no depèn que un operador respongui una sol·licitud invisible. Si algun dels tres depèn d'una persona, la feina encara no està desatesa, sigui el que digui el codi de sortida. Escriviu els cinc fets abans que la següent persona hereti la canalització.

Articles relacionats