Git 403 amb la VPN connectada: trobeu qui respon
Un 403 és una resposta, no un veredicte sobre la VPN. Identifiqueu quin component ha refusat la petició, i després compareu una variable alhora entre xarxes i anoteu què ha canviat.
Funciona al Wi-Fi de l'oficina i falla al punt d'accés del mòbil, amb la VPN connectada en tots dos casos. Git retorna 403 i l'error té tres línies. La temptació és culpar el punt d'accés i canviar la configuració de xarxa fins que alguna cosa es mogui. HTTP 403 vol dir que un servidor ha entès la petició i l'ha refusada, així que la pregunta útil és quin servidor, i el pas següent útil és una comparació que canvia una cosa alhora.
Llegiu l'estat abans que la xarxa
Un 403 no és una cerca fallida, ni un temps d'espera TCP, ni un handshake TLS que no s'ha completat. És una decisió, presa per algú que ha analitzat la vostra petició.
Fins que no sapigueu què ha pres aquella decisió, cada canvi de xarxa que proveu és una conjectura amb una història versemblant.
Qui pot respondre amb 403?
L'aplicació del repositori només és un candidat. Un proxy, una passarel·la o un servei de filtratge poden situar-se al davant i respondre primer, i el client veu el mateix estat en tots dos casos. Conserveu l'estat, les capçaleres rellevants i un cos d'error depurat, i després correlacioneu-los amb els registres del servei autoritzat. L'URL remot i el punt final realment assolit també poden diferir per DNS o per la configuració del proxy, així que comproveu l'adreça configurada i el procés que fa la petició.
Si el rebuig no ha arribat mai al repositori, els seus registres estaran en silenci, i aquest silenci és una prova.
Compareu una variable alhora
La comparació amb el punt d'accés és útil perquè estreta el problema, no perquè demostri una causa. Dues xarxes poden diferir en adreçament, família d'IP, proxy, negociació TLS i política de sortida al mateix moment.
Canvieu una cosa per intent i anoteu la resta. La taula de sota és el mínim que guardo en una nota mentre ho faig:
| 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 difereixi entre l'execució que funciona i la que falla és on va l'hora següent.
Una solució provisional és una prova, no una explicació
Forçar una altra família d'adreces pot canviar la destinació, la ruta o l'intermediari que es tria, així que pot canviar el resultat sense demostrar que IPv6 sigui incompatible amb el repositori. Una versió de TLS negociada diferent és una observació de la mateixa categoria. Cap de les dues no justifica desactivar les comprovacions de certificats ni debilitar la connexió. Seguiu la política i els registres del component que refusa fins a la decisió real, en lloc d'aturar-vos al primer canvi que funcioni.
Una solució provisional que no podeu explicar fallarà una altra vegada en un altre lloc.
Escriviu un informe que es corregeixi
Doneu al propietari del component que ha respost la mateixa operació, dos camins i el component que ha dit que no. Traieu les capçaleres d'autorització, les credencials incrustades i els detalls privats del repositori abans de compartir res.
L'informe útil és curt, reproduïble i nomena la capa en lloc del símptoma.
La comprovació que faig, en ordre
Confirmeu l'URL remot i el punt final resolt, i després captureu l'estat i les capçaleres d'una execució que falla. Repetiu la mateixa operació en una segona xarxa i compareu els dos registres.
Després porteu aquesta diferència al component que ha respost:
- Configuració del proxy al client i a la xarxa.
- Política de sortida o filtratge davant del repositori.
- Abast del testimoni o del compte, incloent la caducitat i les condicions d'SSO.
- Permís del repositori per a la identitat que representa el testimoni.
La mateixa semàntica de l'estat és a RFC 9110, i val la pena citar-la quan escriviu l'informe.