Navegador de sucursal al proxy: dos conexiones, dos rutas

Un navegador de sucursal detrás de un proxy explícito abre dos conexiones, y fallan por motivos distintos. La primera es del navegador al oyente del proxy, transportada por la VPN de la sucursal. La segunda es del proxy al sitio web, usando el resolutor, la ruta y la política de salida del propio proxy. Los tickets de soporte que las tratan como un solo flujo envían a la gente al dispositivo equivocado durante horas. Configure cada una deliberadamente y pruébelas en ese orden.

Paso 1: escriba los dos flujos

El destino inmediato del navegador es el oyente del proxy, no todos los sitios que el usuario acaba visitando. Esa sola frase resuelve la mayor parte de la confusión de este diseño.

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

Orígenes distintos, rutas distintas, permisos distintos. Guarde el esquema en el registro de cambios, porque cada comprobación posterior se refiere a una de sus dos mitades.

Paso 2: dé al navegador un camino hasta el oyente

Anote el nombre de host del proxy, el puerto del oyente, los requisitos de autenticación y los orígenes de sucursal permitidos. Esa lista son los criterios de aceptación del primer flujo, y debe incluir la resolución de nombres privada además de la ruta del túnel.

Aplique una regla de red estrecha para el servicio previsto en lugar de publicar un proxy sin restricciones en Internet. El proxy puede quedarse en una red interna cuando sus clientes previstos tienen un camino compatible hasta él.

Paso 3: configure el navegador, no solo la tabla de rutas

Use el ajuste de proxy del navegador, un archivo PAC o el mecanismo de descubrimiento gestionado de la organización. Enviar paquetes normales de sitio web hacia la dirección del proxy con una ruta no hace que el navegador hable el protocolo del proxy; eso es intercepción transparente y pertenece a otro diseño de puerta de enlace.

Anote qué aplicaciones respetan el ajuste. Los clientes de correo, los actualizadores y los juegos a menudo no lo hacen, y seguirán usando el camino simple.

Paso 4: demuestre la conexión saliente del proxy

El proxy necesita su propio resolutor y una ruta permitida hasta el sitio web, además de cualquier política de cortafuegos o traducción que exija su frontera de Internet. Un navegador que llega al oyente no demuestra nada de eso. Pruebe el segundo flujo desde el propio proxy, con el mismo destino y puerto que notificó el usuario.

Para HTTPS, CONNECT abre un túnel hasta el destino solicitado. El reenvío normal no entrega al proxy la página descifrada, y desactivar la validación de certificados para improvisar una inspección no es una solución.

Paso 5: distinga cuatro fallos

Un desafío de autenticación del proxy es un 407 del oyente. Un CONNECT denegado es una decisión de política en el proxy, normalmente con su propio estado y línea de registro. Una conexión saliente fallida parece un tiempo de espera o un reinicio que el proxy registra contra el destino. Una respuesta del sitio web significa que ambas conexiones funcionaron y que el problema está en el origen.

Informe de la frontera que observó, no del resumen de que la VPN falló.

Paso 6: delimite el alcance y planifique el respaldo

Decida qué ocurre cuando el proxy o el túnel no están disponibles, y diga claramente qué tráfico cubre este diseño. Lleva acceso web desde clientes que respetan el ajuste de proxy; no lleva correo, protocolos arbitrarios de dispositivos ni software que ignora la configuración.

Valide la operación de navegador requerida y una denegación requerida bajo un plan aprobado antes de extender el diseño a más clientes.