Git 403 avec le VPN connecté : trouver qui répond

Cela fonctionne sur le Wi-Fi du bureau et échoue sur le partage de connexion du téléphone, avec le VPN connecté dans les deux cas. Git renvoie 403 et l'erreur fait trois lignes. La tentation est de tenir le partage de connexion pour la cause et de changer les réglages réseau jusqu'à ce que quelque chose bouge. HTTP 403 signifie qu'un serveur a compris la requête et l'a refusée, donc la question utile est quel serveur, et la prochaine étape utile est une comparaison qui ne change qu'une chose à la fois.

Lisez le statut avant le réseau

Un 403 n'est pas une résolution échouée, ni un délai TCP, ni une poignée de main TLS jamais terminée. C'est une décision, prise par quelque chose qui a analysé votre requête.

Tant que vous ne savez pas ce qui a pris cette décision, chaque changement réseau que vous essayez est une supposition assortie d'une histoire plausible.

Qui peut répondre avec 403 ?

L'application du dépôt n'est qu'un candidat. Un proxy, une passerelle ou un service de filtrage peut se trouver devant elle et répondre en premier, et le client voit le même statut dans les deux cas. Conservez le statut, les en-têtes pertinents et un corps d'erreur expurgé, puis corrélez-les avec les journaux du service autorisé. L'URL distante et le point de terminaison réellement atteint peuvent aussi différer à cause du DNS ou de la configuration du proxy, alors vérifiez l'adresse configurée et le processus qui fait la requête.

Si le refus n'a jamais atteint le dépôt, ses journaux resteront muets, et ce silence est une preuve.

Comparez une variable à la fois

La comparaison avec le partage de connexion est utile parce qu'elle réduit le problème, pas parce qu'elle prouve une cause. Deux réseaux peuvent différer au même moment par l'adressage, la famille d'IP, le proxy, la négociation TLS et la politique de sortie.

Changez une chose par essai et notez le reste. Le tableau ci-dessous est le minimum que je garde dans une note pendant l'exercice :

Une seule ligne qui diffère entre l'exécution qui fonctionne et celle qui échoue, c'est là que passe l'heure suivante.

Un contournement est une preuve, pas une explication

Forcer une autre famille d'adresses peut changer la destination, la route ou l'intermédiaire qui est choisi, donc cela peut changer le résultat sans prouver qu'IPv6 est incompatible avec le dépôt. Une autre version de TLS négociée est une observation de la même catégorie. Ni l'une ni l'autre ne justifie de désactiver les vérifications de certificats ou d'affaiblir la connexion. Suivez la politique et les journaux du composant qui refuse jusqu'à la décision réelle au lieu de vous arrêter au premier changement qui marche.

Un contournement que vous ne pouvez pas expliquer échouera de nouveau ailleurs.

Rédigez un rapport qui sera corrigé

Donnez au propriétaire du composant qui a répondu la même opération, deux chemins et le composant qui a dit non. Retirez les en-têtes d'autorisation, les identifiants intégrés et les détails privés du dépôt avant de partager quoi que ce soit.

Le rapport utile est court, reproductible et nomme la couche plutôt que le symptôme.

La vérification que je fais, dans l'ordre

Confirmez l'URL distante et le point de terminaison résolu, puis capturez le statut et les en-têtes d'une exécution qui échoue. Répétez la même opération sur un second réseau et comparez les deux relevés.

Portez ensuite cet écart au composant qui a répondu :

• Configuration du proxy sur le client et sur le réseau.
• Politique de sortie ou filtrage devant le dépôt.
• Portée du jeton ou du compte, y compris l'expiration et les conditions SSO.
• Autorisation du dépôt pour l'identité que représente le jeton.

La sémantique du statut elle-même se trouve dans RFC 9110, et elle vaut la peine d'être citée quand vous rédigez le rapport.