VPN no Mac e proxy PAC: duas decisões, não uma única configuração

O seu Mac descarrega um script de política e depois pergunta a esse script qual intermediário um pedido deve usar, enquanto o túnel decide apenas como o salto escolhido é alcançado. Ambas as respostas acabam no mesmo socket, por isso um pedido que falha depois de ambos terem funcionado parece uma única avaria quando são duas. Separar a transferência da seleção, e a seleção da rota, é a maior parte do trabalho nestes tickets. A ordem abaixo segue o que o macOS faz realmente, com as verificações que tornam cada etapa visível.

Onde o endereço PAC e o proxy divergem

Um endereço como https://config.corp.example/proxy.pac nomeia um documento a transferir, e esse documento nomeia um servidor por onde enviar o tráfego. Colar o URL num campo de anfitrião do proxy pede ao cliente que abra uma ligação proxy a um servidor de ficheiros que nunca escuta uma. Dentro do ficheiro há uma função que o cliente chama em cada pedido, e o valor devolvido é o próximo salto para esse único destino. Essa indireção explica por que duas máquinas no mesmo serviço de rede podem comportar-se de forma diferente mesmo tendo ambas o URL correto. Também explica por que uma mudança de política entra em vigor sem que ninguém toque no próprio proxy.

Leia o script antes de interpretar qualquer coisa a jusante, porque as regras lá dentro transportam as exceções da organização e a ordem em que se aplicam. Um intervalo amplo inicial pode ofuscar um sufixo interno posterior, e um anfitrião que obviamente deveria contornar o proxy continua a usá-lo. Quando alguém insiste que a política está errada, o script é o único lugar onde essa afirmação se resolve.

O script tem de ser obtido antes de decidir seja o que for

Transferir a política requer um nome resolvido e uma rota até ao que serve o ficheiro, e um túnel ligado não implica nenhuma das duas. Se o anfitrião só se resolve através de DNS privado, o resolvedor em uso nesse momento decide se a transferência pode começar. Se o anfitrião está num intervalo privado, a rota tem de existir a partir desta máquina e não do portátil de um colega. Uma cópia em cache de uma sessão anterior esconde tudo isto até a cache expirar ou a máquina reiniciar.

Execute as três verificações abaixo por ordem e pare na primeira falha, porque as etapas não partilham causa. Juntas mostram se a política está configurada, se é alcançável e o que devolve.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

O primeiro comando imprime o dicionário de proxy do serviço ativo, incluindo qualquer URL de configuração automática que o sistema detenha. O segundo relata o URL associado a um serviço com nome, o que importa num portátil que passa de Wi-Fi para Ethernet. O terceiro obtém o ficheiro sem o renderizar, para que um 404, um tempo limite e uma falha de resolvedor continuem distinguíveis. Se esse último comando devolver o script enquanto as aplicações ainda falham, o problema já passou a obtenção.

O que uma resposta DIRECT realmente salta

A especificação PAC dá ao cliente um vocabulário pequeno, e DIRECT é uma das suas palavras. A palavra diz ao cliente para saltar o proxy nesse pedido e não diz nada sobre que interface o socket usará depois. Um socket direto num túnel completo continua a sair pela VPN e continua a mostrar ao destino o endereço de saída do túnel.

Ler DIRECT como estando fora da VPN é o erro que envia as pessoas para o painel de definições errado. A imagem ao espelho é igualmente comum, porque se pode chegar a um proxy privado por uma rota dividida enquanto o resto da máquina fica fora do túnel. O que o destino relata então pertence à saída do próprio proxy, que pode estar noutro país. Escrever a expectativa para um anfitrião interno e um anfitrião público expõe isto depressa, porque o script responde muitas vezes de forma diferente aos dois. Assim que souber qual salto produziu o endereço, o relatório deixa de ser misterioso.

Três falhas que surgem como uma única página de erro

A política pode falhar a transferência, o proxy escolhido pode estar inacessível, e um pedido que chega ao serviço pode continuar a ser recusado lá. Os três chegam como tempo limite ou página de erro genérica, e nenhum nomeia a etapa que quebrou. Capturar a decisão ao lado do erro é o que os separa. As duas sondas abaixo testam o salto que o script escolheu, uma por cada ramo que pode devolver.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Uma ligação concluída ao proxy desloca a pergunta para a autenticação ou para a política do próprio proxy, que tem outro responsável. Uma ligação concluída ao anfitrião interno sem proxy no caminho exclui a rota e aponta para a política. Ambos os comandos ignoram o dicionário de proxy do macOS a menos que a shell exporte variáveis de proxy, por isso limpe-as primeiro. Nenhuma das sondas prova a outra, e é por isso que uma página de erro engana durante tanto tempo.

O que entregar com o ticket

Envie o serviço de rede ativo, o URL do PAC, o resultado da avaliação para o anfitrião que falha e a etapa onde o erro apareceu. Esses quatro permitem à pessoa seguinte reproduzir a decisão em vez de adivinhar que camada estava envolvida. Acrescente o estado do túnel no momento do teste, porque um resultado capturado antes de uma reconexão está desatualizado. Guarde também a revisão do script, já que o ficheiro de política muda sem aviso e a resposta de ontem pode já não estar atual.

Registe como o cliente se comporta quando o script não pode ser obtido, porque as implementações diferem e a decisão do proxy não é um interruptor geral do dispositivo. Alguns recorrem a uma ligação direta e outros falham fechados, e essa diferença muda se uma falha parece um proxy avariado ou uma política a funcionar. Confirme o comportamento para o cliente e a versão exatos antes de depender dele durante um incidente.