Git 403 med VPN tilkoblet: Finn den som svarer
403 er et svar, ikke en dom over VPN. Identifiser hvilken komponent som nektet, og sammenlign så én variabel om gangen på tvers av nettverk og noter hva som endret seg.
Det virker på kontorets Wi-Fi og feiler på telefonens hotspot, med VPN tilkoblet i begge tilfeller. Git returnerer 403 og feilen er tre linjer lang. Fristelsen er å behandle hotspoten som årsaken og endre nettverksinnstillinger til noe beveger seg. HTTP 403 betyr at en server forsto forespørselen og avviste den, så det nyttige spørsmålet er hvilken server, og det nyttige neste steget er en sammenligning som endrer én ting om gangen.
Les statusen før nettverket
403 er ikke en mislykket oppslag, en TCP-timeout eller et TLS-håndtrykk som aldri ble fullført. Det er en beslutning, tatt av noe som tolket forespørselen din.
Inntil du vet hva som tok den beslutningen, er hver nettverksendring du prøver et gjetning med en troverdig historie festet til seg.
Hvem kan svare med 403?
Repository-applikasjonen er bare én kandidat. En proxy, en gateway eller en filtreringstjeneste kan stå foran den og svare først, og klienten ser samme status uansett. Bevar statusen, de relevante hodene og en renset feiltekst, og korreler dem deretter med loggene til den autoriserte tjenesten. Den eksterne URL-en og endepunktet som faktisk nås kan også avvike gjennom DNS eller proxykonfigurasjon, så kontroller den konfigurerte adressen og prosessen som sender forespørselen.
Hvis avvisningen aldri nådde repositoryet, vil loggene være stille, og den stillheten er bevis.
Sammenlign én variabel om gangen
Hotspot-sammenligningen er nyttig fordi den snevrer inn problemet, ikke fordi den beviser en årsak. To nettverk kan avvike i adressering, IP-familie, proxy, TLS-forhandling og utgangspolicy på samme tid.
Endre én ting per forsøk og noter resten. Tabellen nedenfor er minimumet jeg beholder i et notat mens jeg gjør dette:
| 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 |
Én rad som avviker mellom den fungerende og den feilende kjøringen er der den neste timen går.
En omvei er bevis, ikke en forklaring
Å tvinge en annen adressefamilie kan endre destinasjonen, ruten eller mellomleddet som velges, så det kan endre resultatet uten å bevise at IPv6 er inkompatibelt med repositoryet. En annen forhandlet TLS-versjon er en observasjon i samme kategori. Ingen av dem rettferdiggjør å slå av sertifikatkontroller eller svekke tilkoblingen. Følg policyen og loggene til komponenten som nektet til den faktiske beslutningen i stedet for å stoppe ved den første endringen som virker.
En omvei du ikke kan forklare vil feile igjen et annet sted.
Skriv en rapport som blir fikset
Gi eieren av komponenten som svarte samme operasjon, to stier og komponenten som sa nei. Fjern autorisasjonshoder, innebygde legitimasjoner og private repository-detaljer før du deler noe.
Den nyttige rapporten er kort, reproduserbar og navngir laget i stedet for symptomet.
Sjekken jeg kjører, i rekkefølge
Bekreft den eksterne URL-en og det oppslåtte endepunktet, og ta deretter opp statusen og hodene fra en feilende kjøring. Gjenta den identiske operasjonen på et andre nettverk og diff de to oppføringene.
Ta så den diffen til komponenten som svarte:
- Proxykonfigurasjon på klienten og på nettverket.
- Utgangspolicy eller filtrering foran repositoryet.
- Token- eller kontoomfang, inkludert utløp og SSO-betingelser.
- Repository-tillatelse for identiteten tokenet representerer.
Selve statussemantikken står i RFC 9110, og den er verdt å sitere når du skriver rapporten.