VPN en Mac y proxy PAC: dos decisiones, no una sola configuración

Su Mac descarga un script de política y luego pregunta a ese script qué intermediario debe usar una petición, mientras que el túnel solo decide cómo se alcanza el salto elegido. Ambas respuestas acaban en el mismo socket, así que una petición que falla después de que ambas hayan funcionado parece una sola avería cuando son dos. Separar la descarga de la selección, y la selección de la ruta, es la mayor parte del trabajo en estos tíquetes. El orden siguiente sigue lo que macOS hace realmente, con las comprobaciones que hacen visible cada etapa.

Dónde divergen la dirección PAC y el proxy

Una dirección como https://config.corp.example/proxy.pac nombra un documento que hay que descargar, y ese documento nombra un servidor por el que enviar el tráfico. Pegar la URL en un campo de host del proxy pide al cliente que abra una conexión de proxy hacia un servidor de archivos que nunca escucha una. Dentro del archivo hay una función que el cliente llama en cada petición, y su valor de retorno es el siguiente salto para ese único destino. Esa indirección explica por qué dos máquinas en el mismo servicio de red pueden comportarse de forma distinta aunque ambas tengan la URL correcta. También explica por qué un cambio de política surte efecto sin que nadie toque el proxy en sí.

Lea el script antes de interpretar nada aguas abajo, porque las reglas que contiene llevan las excepciones de la organización y el orden en que se aplican. Un rango amplio temprano puede eclipsar un sufijo interno posterior, y un host que obviamente debería saltarse el proxy sigue usándolo. Cuando alguien insiste en que la política está mal, el script es el único lugar donde esa afirmación se resuelve.

El script debe obtenerse antes de que decida nada

Descargar la política requiere un nombre resuelto y una ruta hacia lo que sirva el archivo, y un túnel conectado no implica ninguna de las dos cosas. Si el host solo se resuelve mediante DNS privado, el resolutor en uso en ese momento decide si la descarga puede empezar. Si el host está en un rango privado, la ruta debe existir desde esta máquina y no desde el portátil de un compañero. Una copia en caché de una sesión anterior oculta todo esto hasta que la caché caduque o la máquina se reinicie.

Ejecute las tres comprobaciones siguientes en orden y deténgase en el primer fallo, porque las etapas no comparten causa. Juntas muestran si la política está configurada, si es alcanzable y qué devuelve.

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

El primer comando imprime el diccionario de proxy del servicio activo, incluida cualquier URL de configuración automática que el sistema tenga. El segundo informa de la URL asociada a un servicio con nombre, lo que importa en un portátil que pasa de Wi-Fi a Ethernet. El tercero obtiene el archivo sin representarlo, de modo que un 404, un tiempo de espera y un fallo del resolutor sigan siendo distinguibles. Si ese último comando devuelve el script mientras las aplicaciones siguen fallando, el problema ya ha superado la obtención.

Qué omite realmente una respuesta DIRECT

La especificación PAC da al cliente un vocabulario pequeño, y DIRECT es una de sus palabras. La palabra indica al cliente que omita el proxy para esa petición y no dice nada sobre qué interfaz usará después el socket. Un socket directo en un túnel completo sigue saliendo por la VPN y sigue mostrando al destino la dirección de salida del túnel.

Leer DIRECT como algo fuera de la VPN es el error que lleva a la gente al panel de configuración equivocado. La imagen especular es igual de común, porque se puede llegar a un proxy privado por una ruta dividida mientras el resto de la máquina queda fuera del túnel. Lo que el destino informa entonces pertenece a la salida del propio proxy, que puede estar en otro país. Escribir la expectativa para un host interno y un host público lo expone enseguida, ya que el script suele responder de forma distinta a los dos. Una vez que sabe qué salto produjo la dirección, el informe deja de ser misterioso.

Tres fallos que aparecen como una sola página de error

La política puede fallar al descargarse, el proxy elegido puede ser inalcanzable, y una petición que llega al servicio puede seguir siendo rechazada allí. Los tres llegan como un tiempo de espera o una página de error genérica, y ninguno nombra la etapa que se rompió. Capturar la decisión junto al error es lo que los separa. Las dos sondas siguientes prueban el salto que eligió el script, una por cada rama que puede devolver.

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

Una conexión completada al proxy traslada la pregunta a la autenticación o a la política propia del proxy, que tiene otro propietario. Una conexión completada al host interno sin proxy en el camino descarta la ruta y apunta a la política. Ambos comandos ignoran el diccionario de proxy de macOS a menos que el shell exporte variables de proxy, así que bórrelas primero. Ninguna de las dos sondas demuestra la otra, y por eso una página de error engaña durante tanto tiempo.

Qué entregar con el tíquet

Envíe el servicio de red activo, la URL del PAC, el resultado de la evaluación para el host que falla y la etapa en la que apareció el error. Esos cuatro permiten a la siguiente persona reproducir la decisión en lugar de adivinar qué capa estaba implicada. Añada el estado del túnel en el momento de la prueba, porque un resultado capturado antes de una reconexión está obsoleto. Conserve también la revisión del script, ya que el archivo de política cambia sin aviso y la respuesta de ayer puede que ya no esté vigente.

Registre cómo se comporta el cliente cuando no se puede obtener el script, porque las implementaciones difieren y la decisión del proxy no es un interruptor general del dispositivo. Algunos recurren a una conexión directa y otros fallan cerrados, y esa diferencia cambia si una caída parece un proxy roto o una política que funciona. Confirme el comportamiento para el cliente y la versión exactos antes de confiar en él durante un incidente.