Git 403 coa VPN conectada: atope quen responde
Un 403 é unha resposta, non un veredicto sobre a VPN. Identifique que compoñente rexeitou a solicitude, despois compare unha variable á vez entre redes e anote que cambiou.
Funciona no Wi-Fi da oficina e falla no punto de acceso do móbil, coa VPN conectada nos dous casos. Git devolve 403 e o erro ocupa tres liñas. A tentación é culpar o punto de acceso e cambiar a configuración de rede ata que algo se mova. HTTP 403 significa que un servidor entendeu a solicitude e rexeitouna, así que a pregunta útil é que servidor, e o seguinte paso útil é unha comparación que cambie unha cousa á vez.
Lea o estado antes que a rede
Un 403 non é unha busca fallida, nin un tempo de espera TCP, nin un handshake TLS que nunca se completou. É unha decisión, tomada por algo que analizou a súa solicitude.
Ata que saiba que tomou esa decisión, cada cambio de rede que probe é unha conxectura cunha historia plausible.
Quen pode responder con 403?
A aplicación do repositorio só é un candidato. Un proxy, unha pasarela ou un servizo de filtrado poden situarse diante e responder primeiro, e o cliente ve o mesmo estado nos dous casos. Garde o estado, as cabeceiras relevantes e un corpo de erro depurado, e despois correlación eos cos rexistros do servizo autorizado. O URL remoto e o extremo realmente acadado tamén poden diferir por DNS ou pola configuración do proxy, así que comprobe o enderezo configurado e o proceso que fai a solicitude.
Se o rexeitamento nunca chegou ao repositorio, os seus rexistros estarán en silencio, e ese silencio é unha proba.
Compare unha variable á vez
A comparación co punto de acceso é útil porque reduce o problema, non porque demostre unha causa. Dúas redes poden diferir ao mesmo tempo en enderezamento, familia de IP, proxy, negociación TLS e política de saída.
Cambie unha cousa por intento e anote o resto. A táboa de abaixo é o mínimo que gardo nunha nota mentres o fago:
| 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 |
Unha soa fila que difira entre a execución que funciona e a que falla é onde vai a seguinte hora.
Unha solución alternativa é unha proba, non unha explicación
Forzar outra familia de enderezos pode cambiar o destino, a ruta ou o intermediario que se escolle, así que pode cambiar o resultado sen demostrar que IPv6 sexa incompatible co repositorio. Unha versión de TLS negociada distinta é unha observación da mesma categoría. Ningunha das dúas xustifica desactivar as comprobacións de certificados nin debilitar a conexión. Siga a política e os rexistros do compoñente que rexeita ata a decisión real, en lugar de deterse no primeiro cambio que funcione.
Unha solución alternativa que non pode explicar volverá fallar noutro sitio.
Escriba un informe que se corrixa
Dea ao propietario do compoñente que respondeu a mesma operación, dúas rutas e o compoñente que dixo que non. Elimine as cabeceiras de autorización, as credenciais incrustadas e os detalles privados do repositorio antes de compartir nada.
O informe útil é breve, reproducible e nomea a capa en lugar do síntoma.
A comprobación que fago, en orde
Confirme o URL remoto e o extremo resolto e logo capture o estado e as cabeceiras dunha execución que falla. Repita a mesma operación nunha segunda rede e compare os dous rexistros.
Despois leve esa diferenza ao compoñente que respondeu:
- Configuración do proxy no cliente e na rede.
- Política de saída ou filtrado diante do repositorio.
- Âmbito do token ou da conta, incluída a caducidade e as condicións de SSO.
- Permiso do repositorio para a identidade que representa o token.
A propia semántica do estado está en RFC 9110, e paga a pena citala cando escriba o informe.