Navegador da sucursal ao proxy: dúas conexións, dúas rutas

Un navegador de sucursal detrás dun proxy explícito abre dúas conexións, e fallan por motivos distintos. A primeira é do navegador ao oínte do proxy, transportada pola VPN da sucursal. A segunda é do proxy ao sitio web, usando o resolutor, a ruta e a política de saída do propio proxy. Os tickets de soporte que as tratan como un único fluxo envían á xente ao dispositivo equivocado durante horas. Configure cada unha deliberadamente e próbeas nesa orde.

Paso 1: escriba os dous fluxos

O destino inmediato do navegador é o oínte do proxy, non todos os sitios que o usuario acaba visitando. Esa única frase resolve a maior parte da confusión deste deseño.

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

Orixes distintas, rutas distintas, permisos distintos. Garde o esquema no rexistro de cambios, porque cada comprobación posterior refírese a unha das súas dúas metades.

Paso 2: dea ao navegador un camiño ata o oínte

Anote o nome de host do proxy, o porto do oínte, os requisitos de autenticación e as orixes de sucursal permitidas. Esa lista son os criterios de aceptación do primeiro fluxo, e debe incluír a resolución de nomes privada ademais da ruta do túnel.

Aplique unha regra de rede estreita para o servizo previsto en lugar de publicar un proxy sen restricións en Internet. O proxy pode quedar nunha rede interna cando os seus clientes previstos teñen un camiño compatible ata el.

Paso 3: configure o navegador, non só a táboa de rutas

Use o axuste de proxy do navegador, un ficheiro PAC ou o mecanismo de descubrimento xestionado da organización. Enviar paquetes normais de sitio web cara ao enderezo do proxy cunha ruta non fai que o navegador fale o protocolo do proxy; iso é intercepción transparente e pertence a outro deseño de pasarela.

Anote que aplicacións respectan o axuste. Os clientes de correo, os actualizadores e os xogos a miúdo non o fan, e seguirán usando o camiño simple.

Paso 4: demostre a conexión de saída do proxy

O proxy necesita o seu propio resolutor e unha ruta permitida ata o sitio web, ademais de calquera política de cortafuegos ou tradución que exixa a súa fronteira de Internet. Un navegador que chega ao oínte non demostra nada diso. Probe o segundo fluxo desde o propio proxy, co mesmo destino e porto que notificou o usuario.

Para HTTPS, CONNECT abre un túnel ata o destino solicitado. O reenvío normal non entrega ao proxy a páxina descifrada, e desactivar a validación de certificados para improvisar unha inspección non é unha solución.

Paso 5: distinga catro fallos

Un desafío de autenticación do proxy é un 407 do oínte. Un CONNECT denegado é unha decisión de política no proxy, normalmente co seu propio estado e liña de rexistro. Unha conexión de saída fallida parece un tempo de espera ou un reinicio que o proxy rexistra contra o destino. Unha resposta do sitio web significa que ambas as conexións funcionaron e que o problema está na orixe.

Informe da fronteira que observou, non do resumo de que a VPN fallou.

Paso 6: delimite o alcance e planifique o respaldo

Decida que ocorre cando o proxy ou o túnel non están dispoñibles, e diga claramente que tráfico cobre este deseño. Leva acceso web desde clientes que respectan o axuste de proxy; non leva correo, protocolos arbitrarios de dispositivos nin software que ignora a configuración.

Valide a operación de navegador requirida e unha denegación requirida baixo un plan aprobado antes de estender o deseño a máis clientes.