Navegador da filial para o proxy: duas conexões, duas rotas

Um navegador de filial atrás de um proxy explícito abre duas conexões, e elas falham por motivos diferentes. A primeira é do navegador para o ouvinte do proxy, transportada pela VPN da filial. A segunda é do proxy para o site, usando o resolvedor, a rota e a política de saída do próprio proxy. Chamados de suporte que as tratam como um único fluxo mandam as pessoas para o dispositivo errado por horas. Configure cada uma deliberadamente e teste-as nessa ordem.

Passo 1: anote os dois fluxos

O destino imediato do navegador é o ouvinte do proxy, e não todos os sites que o utilizador acaba por visitar. Essa única frase resolve a maior parte da confusão neste desenho.

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

Origens diferentes, rotas diferentes, permissões diferentes. Guarde o esboço no registo de alterações, porque cada verificação posterior se refere a uma das suas duas metades.

Passo 2: dê ao navegador um caminho até ao ouvinte

Registe o nome do anfitrião do proxy, a porta do ouvinte, os requisitos de autenticação e as origens de filial permitidas. Essa lista é o critério de aceitação do primeiro fluxo e deve incluir a resolução de nomes privada, bem como a rota do túnel.

Aplique uma regra de rede estreita para o serviço pretendido em vez de publicar um proxy sem restrições na Internet. O proxy pode ficar numa rede interna quando os seus clientes pretendidos têm um caminho suportado até ele.

Passo 3: configure o navegador, não apenas a tabela de rotas

Use a definição de proxy do navegador, um ficheiro PAC ou o mecanismo de descoberta gerido da organização. Enviar pacotes normais de sites para o endereço do proxy com uma rota não faz o navegador falar o protocolo do proxy; isso é interceção transparente e pertence a outro desenho de gateway.

Anote que aplicações respeitam a definição. Os clientes de correio, os atualizadores e os jogos muitas vezes não o fazem, e continuarão a usar o caminho simples.

Passo 4: prove a ligação de saída do proxy

O proxy precisa do seu próprio resolvedor e de uma rota permitida até ao site, além da política de firewall ou de tradução exigida pela sua fronteira de Internet. Um navegador que chega ao ouvinte não prova nada disso. Teste o segundo fluxo a partir do próprio proxy, com o mesmo destino e porta que o utilizador relatou.

Para HTTPS, o CONNECT abre um túnel até ao destino pedido. O encaminhamento normal não entrega ao proxy a página decifrada, e desativar a validação de certificados para improvisar uma inspeção não é solução.

Passo 5: distinga quatro falhas

Um desafio de autenticação do proxy é um 407 do ouvinte. Um CONNECT negado é uma decisão de política no proxy, normalmente com o seu próprio estado e linha de registo. Uma ligação de saída falhada parece um tempo limite ou um reinício que o proxy registe em relação ao destino. Uma resposta do site significa que as duas ligações funcionaram e que o problema está na origem.

Relate a fronteira que observou, não o resumo de que a VPN falhou.

Passo 6: delimite o âmbito e planeie o recurso

Decida o que acontece quando o proxy ou o túnel não estão disponíveis, e diga claramente que tráfego este desenho cobre. Transporta acesso web de clientes que respeitam a definição de proxy; não transporta correio, protocolos arbitrários de dispositivos ou software que ignora a configuração.

Valide a operação de navegador exigida e uma negação exigida ao abrigo de um plano aprovado antes de alargar o desenho a mais clientes.