VPN no Mac e proxy PAC: dúas decisións, non unha soa configuración

O seu Mac descarga un script de política e despois pregunta a ese script que intermediario debe usar unha petición, mentres que o túnel só decide como se alcanza o salto elixido. Ambas as respostas acaban no mesmo socket, así que unha petición que falla despois de que ambas funcionasen parece unha soa avaría cando son dúas. Separar a descarga da selección, e a selección da ruta, é a maior parte do traballo nestes tíckets. A orde seguinte segue o que macOS fai realmente, coas comprobacións que fan visible cada etapa.

Onde diverxen o enderezo PAC e o proxy

Un enderezo como https://config.corp.example/proxy.pac nomea un documento que hai que descargar, e ese documento nomea un servidor polo que enviar o tráfico. Pegar o URL nun campo de host do proxy pide ao cliente que abra unha conexión de proxy cara a un servidor de ficheiros que nunca escoita unha. Dentro do ficheiro hai unha función que o cliente chama en cada petición, e o seu valor de retorno é o seguinte salto para ese único destino. Esa indirección explica por que dúas máquinas no mesmo servizo de rede poden comportarse de forma distinta aínda que ambas teñan o URL correcto. Tamén explica por que un cambio de política surte efecto sen que ninguén toque o proxy en si.

Lea o script antes de interpretar nada augas abaixo, porque as regras que contén levan as excepcións da organización e a orde en que se aplican. Un rango amplo temperán pode eclipsar un sufixo interno posterior, e un host que obviamente debería saltar o proxy segue usándoo. Cando alguén insiste en que a política está mal, o script é o único lugar onde esa afirmación se resolve.

O script debe obterse antes de que decida nada

Descargar a política require un nome resolto e unha ruta cara ao que sirva o ficheiro, e un túnel conectado non implica ningunha das dúas cousas. Se o host só se resolve mediante DNS privado, o resolutor en uso nese momento decide se a descarga pode comezar. Se o host está nun rango privado, a ruta debe existir desde esta máquina e non desde o portátil dun compañeiro. Unha copia na caché dunha sesión anterior oculta todo isto ata que a caché caduque ou a máquina se reinicie.

Execute as tres comprobacións seguintes en orde e detéñase no primeiro fallo, porque as etapas non comparten causa. Xuntas mostran se a política está configurada, se é alcanzable e 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 dicionario de proxy do servizo activo, incluída calquera URL de configuración automática que o sistema teña. O segundo informa do URL asociado a un servizo con nome, o que importa nun portátil que pasa de Wi-Fi a Ethernet. O terceiro obtén o ficheiro sen representalo, de xeito que un 404, un tempo de espera e un fallo do resolutor sigan sendo distinguibles. Se ese último comando devolve o script mentres as aplicacións seguen fallando, o problema xa superou a obtención.

Que omite realmente unha resposta DIRECT

A especificación PAC dálle ao cliente un vocabulario pequeno, e DIRECT é unha das súas palabras. A palabra indica ao cliente que omita o proxy para esa petición e non di nada sobre que interface usará despois o socket. Un socket directo nun túnel completo segue saíndo pola VPN e segue mostrando ao destino o enderezo de saída do túnel.

Ler DIRECT como algo fóra da VPN é o erro que leva a xente ao panel de configuración equivocado. A imaxe especular é igual de común, porque se pode chegar a un proxy privado por unha ruta dividida mentres o resto da máquina queda fóra do túnel. O que o destino informa entón pertence á saída do propio proxy, que pode estar noutro país. Escribir a expectativa para un host interno e un host público expono enseguida, xa que o script adoita responder de forma distinta aos dous. Unha vez que sabe que salto produciu o enderezo, o informe deixa de ser misterioso.

Tres fallos que aparecen como unha soa páxina de erro

A política pode fallar ao descargarse, o proxy elixido pode ser inalcanzable, e unha petición que chega ao servizo pode seguir sendo rexeitada alí. Os tres chegan como un tempo de espera ou unha páxina de erro xenérica, e ningún nomea a etapa que se rompeu. Capturar a decisión xunto ao erro é o que os separa. As dúas sondas seguintes proban o salto que elixiu o script, unha por cada rama que pode devolver.

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

Unha conexión completada ao proxy traslada a pregunta á autenticación ou á política propia do proxy, que ten outro propietario. Unha conexión completada ao host interno sen proxy no camiño descarta a ruta e apunta á política. Ambos os comandos ignoran o dicionario de proxy de macOS a menos que a shell exporte variables de proxy, así que bórreas primeiro. Ningunha das dúas sondas demostra a outra, e por iso unha páxina de erro engana durante tanto tempo.

Que entregar co tícket

Envíe o servizo de rede activo, o URL do PAC, o resultado da avaliación para o host que falla e a etapa na que apareceu o erro. Esas catro permiten á seguinte persoa reproducir a decisión en lugar de adiviñar que capa estaba implicada. Engada o estado do túnel no momento da proba, porque un resultado capturado antes dunha reconexión está desactualizado. Conserve tamén a revisión do script, xa que o ficheiro de política cambia sen aviso e a resposta de onte pode que xa non estea vixente.

Rexistre como se comporta o cliente cando non se pode obter o script, porque as implementacións difiren e a decisión do proxy non é un interruptor xeral do dispositivo. Algúns recorre a unha conexión directa e outros fallan pechados, e esa diferenza cambia se unha caída parece un proxy roto ou unha política que funciona. Confirme o comportamento para o cliente e a versión exactos antes de confiar nel durante un incidente.