Git 403 con la VPN connessa: trovare chi risponde

Funziona sul Wi-Fi dell'ufficio e fallisce sull'hotspot del telefono, con la VPN connessa in entrambi i casi. Git restituisce 403 e l'errore occupa tre righe. La tentazione è dare la colpa all'hotspot e cambiare le impostazioni di rete finché qualcosa non si muove. HTTP 403 significa che un server ha capito la richiesta e l'ha rifiutata, quindi la domanda utile è quale server, e il passo successivo utile è un confronto che cambi una cosa alla volta.

Leggete lo stato prima della rete

Un 403 non è una risoluzione fallita, né un timeout TCP, né una stretta di mano TLS mai completata. È una decisione, presa da qualcosa che ha analizzato la vostra richiesta.

Finché non sapete cosa ha preso quella decisione, ogni modifica di rete che provate è un'ipotesi con una storia plausibile.

Chi può rispondere con 403?

L'applicazione del repository è solo un candidato. Un proxy, un gateway o un servizio di filtraggio possono stare davanti e rispondere per primi, e il client vede lo stesso stato in entrambi i casi. Conservate lo stato, le intestazioni rilevanti e un corpo dell'errore ripulito, poi correlateli con i log del servizio autorizzato. L'URL remoto e l'endpoint realmente raggiunto possono differire anche a causa del DNS o della configurazione del proxy, quindi controllate l'indirizzo configurato e il processo che fa la richiesta.

Se il rifiuto non ha mai raggiunto il repository, i suoi log resteranno silenziosi, e quel silenzio è una prova.

Confrontate una variabile alla volta

Il confronto con l'hotspot è utile perché restringe il problema, non perché dimostri una causa. Due reti possono differire nello stesso momento per indirizzamento, famiglia di IP, proxy, negoziazione TLS e politica di uscita.

Cambiate una cosa per tentativo e annotate il resto. La tabella qui sotto è il minimo che tengo in una nota mentre lo faccio:

Una sola riga che differisce tra l'esecuzione che funziona e quella che fallisce è dove va l'ora successiva.

Un aggiramento è una prova, non una spiegazione

Forzare un'altra famiglia di indirizzi può cambiare la destinazione, la rotta o l'intermediario che viene scelto, quindi può cambiare il risultato senza dimostrare che IPv6 sia incompatibile con il repository. Una versione TLS negoziata diversa è un'osservazione della stessa categoria. Nessuna delle due giustifica disattivare i controlli dei certificati o indebolire la connessione. Seguite la politica e i log del componente che rifiuta fino alla decisione reale, invece di fermarvi al primo cambiamento che funziona.

Un aggiramento che non sapete spiegare fallirà di nuovo altrove.

Scrivete un rapporto che venga corretto

Date al proprietario del componente che ha risposto la stessa operazione, due percorsi e il componente che ha detto no. Rimuovete intestazioni di autorizzazione, credenziali incorporate e dettagli privati del repository prima di condividere qualcosa.

Il rapporto utile è breve, riproducibile e nomina lo strato invece del sintomo.

Il controllo che eseguo, in ordine

Confermate l'URL remoto e l'endpoint risolto, poi catturate lo stato e le intestazioni di un'esecuzione che fallisce. Ripetete la stessa operazione su una seconda rete e confrontate i due registri.

Poi portate quella differenza al componente che ha risposto:

• Configurazione del proxy sul client e sulla rete.
• Politica di uscita o filtraggio davanti al repository.
• Ambito del token o dell'account, inclusi scadenza e condizioni SSO.
• Autorizzazione del repository per l'identità che il token rappresenta.

La semantica dello stato stessa si trova in RFC 9110, e vale la pena citarla quando scrivete il rapporto.