Git 403 con la VPN conectada: encuentre quién responde
Un 403 es una respuesta, no un veredicto sobre la VPN. Identifique qué componente rechazó la solicitud, luego compare una variable a la vez entre redes y anote qué cambió.
Funciona en el Wi-Fi de la oficina y falla en el punto de acceso del móvil, con la VPN conectada en ambos casos. Git devuelve 403 y el error ocupa tres líneas. La tentación es culpar al punto de acceso y cambiar la configuración de red hasta que algo se mueva. HTTP 403 significa que un servidor entendió la solicitud y la rechazó, así que la pregunta útil es qué servidor, y el siguiente paso útil es una comparación que cambie una cosa a la vez.
Lea el estado antes que la red
Un 403 no es una búsqueda fallida, ni un tiempo de espera TCP, ni un handshake TLS que nunca se completó. Es una decisión, tomada por algo que analizó su solicitud.
Hasta que sepa qué tomó esa decisión, cada cambio de red que pruebe es una conjetura con una historia plausible.
¿Quién puede responder con 403?
La aplicación del repositorio es solo un candidato. Un proxy, una puerta de enlace o un servicio de filtrado pueden situarse delante y responder primero, y el cliente ve el mismo estado en ambos casos. Guarde el estado, las cabeceras relevantes y un cuerpo de error depurado, y luego correlaciónelos con los registros del servicio autorizado. La URL remota y el extremo realmente alcanzado también pueden diferir por DNS o por la configuración del proxy, así que compruebe la dirección configurada y el proceso que hace la solicitud.
Si el rechazo nunca llegó al repositorio, sus registros estarán en silencio, y ese silencio es una prueba.
Compare una variable a la vez
La comparación con el punto de acceso es útil porque acota el problema, no porque demuestre una causa. Dos redes pueden diferir a la vez en direccionamiento, familia de IP, proxy, negociación TLS y política de salida.
Cambie una cosa por intento y anote el resto. La tabla de abajo es el mínimo que guardo en una nota mientras lo hago:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
Una sola fila que difiera entre la ejecución que funciona y la que falla es donde va la siguiente hora.
Un rodeo es una prueba, no una explicación
Forzar otra familia de direcciones puede cambiar el destino, la ruta o el intermediario que se elige, así que puede cambiar el resultado sin demostrar que IPv6 sea incompatible con el repositorio. Una versión de TLS negociada distinta es una observación de la misma categoría. Ninguna de las dos justifica desactivar las comprobaciones de certificados ni debilitar la conexión. Siga la política y los registros del componente que rechaza hasta la decisión real, en lugar de detenerse en el primer cambio que funcione.
Un rodeo que no puede explicar volverá a fallar en otro sitio.
Escriba un informe que se corrija
Dé al propietario del componente que respondió la misma operación, dos rutas y el componente que dijo que no. Elimine las cabeceras de autorización, las credenciales incrustadas y los detalles privados del repositorio antes de compartir nada.
El informe útil es breve, reproducible y nombra la capa en lugar del síntoma.
La comprobación que hago, en orden
Confirme la URL remota y el extremo resuelto y luego capture el estado y las cabeceras de una ejecución que falla. Repita la misma operación en una segunda red y compare los dos registros.
Después lleve esa diferencia al componente que respondió:
- Configuración del proxy en el cliente y en la red.
- Política de salida o filtrado delante del repositorio.
- Ámbito del token o de la cuenta, incluida la caducidad y las condiciones de SSO.
- Permiso del repositorio para la identidad que representa el token.
La propia semántica del estado está en RFC 9110, y merece la pena citarla cuando escriba el informe.