Git 403 met de VPN verbonden: vind wie antwoordt
Een 403 is een antwoord, geen oordeel over de VPN. Stel vast welk onderdeel weigerde, vergelijk daarna één variabele tegelijk tussen netwerken en noteer wat er veranderde.
Het werkt op de Wi-Fi van kantoor en faalt op de hotspot van de telefoon, met de VPN in beide gevallen verbonden. Git geeft 403 terug en de fout is drie regels lang. De verleiding is om de hotspot als oorzaak te zien en netwerkinstellingen te wijzigen tot er iets beweegt. HTTP 403 betekent dat een server het verzoek begreep en weigerde, dus de nuttige vraag is welke server, en de nuttige volgende stap is een vergelijking die één ding tegelijk verandert.
Lees de status vóór het netwerk
Een 403 is geen mislukte opzoeking, geen TCP-time-out en geen TLS-handshake die nooit voltooid raakte. Het is een beslissing, genomen door iets dat je verzoek heeft geparseerd.
Tot je weet wat die beslissing nam, is elke netwerkwijziging die je probeert een gok met een geloofwaardig verhaal eraan vast.
Wie kan met 403 antwoorden?
De repository-applicatie is slechts één kandidaat. Een proxy, een gateway of een filterdienst kan ervoor zitten en als eerste antwoorden, en de client ziet hoe dan ook dezelfde status. Bewaar de status, de relevante headers en een schoner gemaakte foutbody, en correleer ze daarna met de logs van de geautoriseerde dienst. De externe URL en het daadwerkelijk bereikte eindpunt kunnen ook verschillen door DNS of proxyconfiguratie, dus controleer het geconfigureerde adres en het proces dat het verzoek doet.
Als de weigering de repository nooit bereikte, zullen de logs stil blijven, en die stilte is bewijs.
Vergelijk één variabele tegelijk
De hotspotvergelijking is nuttig omdat ze het probleem vernauwt, niet omdat ze een oorzaak bewijst. Twee netwerken kunnen tegelijk verschillen in adressering, IP-familie, proxy, TLS-onderhandeling en uitgaand beleid.
Verander één ding per poging en noteer de rest. De tabel hieronder is het minimum dat ik in een notitie bijhoud terwijl ik dit doe:
| 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 |
Eén rij die verschilt tussen de werkende en de falende run is waar het volgende uur naartoe gaat.
Een omweg is bewijs, geen verklaring
Een andere adresfamilie forceren kan de bestemming, de route of de tussenliggende partij die wordt gekozen veranderen, dus het kan het resultaat veranderen zonder te bewijzen dat IPv6 onverenigbaar is met de repository. Een anders onderhandelde TLS-versie is een waarneming in dezelfde categorie. Geen van beide rechtvaardigt het uitschakelen van certificaatcontroles of het verzwakken van de verbinding. Volg het beleid en de logs van het weigerende onderdeel tot de werkelijke beslissing in plaats van te stoppen bij de eerste wijziging die werkt.
Een omweg die je niet kunt uitleggen, zal ergens anders opnieuw falen.
Schrijf een rapport dat wordt opgelost
Geef de eigenaar van het onderdeel dat antwoordde dezelfde handeling, twee paden en het onderdeel dat nee zei. Verwijder autorisatieheaders, ingebedde inloggegevens en details van privérepositories voordat je iets deelt.
Het nuttige rapport is kort, reproduceerbaar en noemt de laag in plaats van het symptoom.
De controle die ik in volgorde uitvoer
Bevestig de externe URL en het opgeloste eindpunt, en leg dan de status en headers vast uit een falende run. Herhaal de identieke handeling op een tweede netwerk en vergelijk de twee registraties.
Breng dat verschil dan naar het onderdeel dat antwoordde:
- Proxyconfiguratie op de client en op het netwerk.
- Uitgaand beleid of filtering vóór de repository.
- Bereik van token of account, inclusief vervaldatum en SSO-voorwaarden.
- Repositoryrechten voor de identiteit die het token vertegenwoordigt.
De statussemantiek zelf staat in RFC 9110, en die is het citeren waard wanneer je het rapport schrijft.