Git 403 med VPN tilkopla: Finn den som svarar
403 er eit svar, ikkje ein dom over VPN. Identifiser kva komponent som nekta, og samanlikn så éin variabel om gongen på tvers av nettverk og noter kva som endra seg.
Det verkar på kontorets Wi-Fi og feilar på hotspoten til telefonen, med VPN tilkopla i begge tilfelle. Git returnerer 403 og feilen er tre linjer lang. Freistinga er å handsame hotspoten som årsaka og endre nettverksinnstillingar til noko flyttar seg. HTTP 403 tyder at ein server forstod førespurnaden og avviste han, så det nyttige spørsmålet er kva server, og det nyttige neste steget er ei samanlikning som endrar éin ting om gongen.
Les statusen før nettverket
403 er ikkje eit mislukka oppslag, ein TCP-timeout eller eit TLS-handtrykk som aldri vart fullført. Det er ei avgjerd, teken av noko som tolka førespurnaden din.
Inntil du veit kva som tok den avgjerda, er kvar nettverksendring du prøver eit gjetning med ei truverdig historie fest til seg.
Kven kan svare med 403?
Repository-applikasjonen er berre ein kandidat. Ein proxy, ein gateway eller ein filtreringsteneste kan stå framfor han og svare først, og klienten ser same status uansett. Bevar statusen, dei relevante hovuda og ein reinska feiltekst, og korreler dei deretter med loggane til den autoriserte tenesta. Den eksterne URL-en og endepunktet som faktisk blir nådd kan også avvike gjennom DNS eller proxykonfigurasjon, så kontroller den konfigurerte adressa og prosessen som sender førespurnaden.
Viss avvisinga aldri nådde repositoryet, vil loggane vere stille, og den stilla er bevis.
Samanlikn éin variabel om gongen
Hotspot-samanlikninga er nyttig fordi ho snevrar inn problemet, ikkje fordi ho beviser ei årsak. To nettverk kan avvike i adressering, IP-familie, proxy, TLS-forhandling og utgangspolicy på same tid.
Endre éin ting per forsøk og noter resten. Tabellen nedanfor er minimumet eg held i eit notat medan eg gjer 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 |
Éi rad som avvik mellom den fungerande og den feilande køyringa er der den neste timen går.
Ein omveg er bevis, ikkje ei forklaring
Å tvinge ein annan adressefamilie kan endre destinasjonen, ruta eller mellomleddet som blir valt, så det kan endre resultatet utan å bevisa at IPv6 er inkompatibelt med repositoryet. Ein annan forhandla TLS-versjon er ei observasjon i same kategori. Ingen av dei rettferdiggjer å slå av sertifikatkontrollar eller svekke tilkoplinga. Følg policyen og loggane til komponenten som nekta til den faktiske avgjerda i staden for å stoppe ved den første endringa som verkar.
Ein omveg du ikkje kan forklare vil feile igjen ein annan stad.
Skriv ein rapport som blir fiksa
Gi eigaren av komponenten som svara same operasjon, to stiar og komponenten som sa nei. Fjern autorisasjonshovud, innebygde legitimasjonar og private repository-detaljar før du deler noko.
Den nyttige rapporten er kort, reproduserbar og namngjev laget i staden for symptomet.
Sjekken eg køyrer, i rekkefølgje
Stadfest den eksterne URL-en og det oppslåtte endepunktet, og ta deretter opp statusen og hovuda frå ei feilande køyring. Gjenta den identiske operasjonen på eit andre nettverk og diff dei to oppføringane.
Ta så den diffen til komponenten som svara:
- Proxykonfigurasjon på klienten og på nettverket.
- Utgangspolicy eller filtrering framfor repositoryet.
- Token- eller kontoomfang, inkludert utløp og SSO-vilkår.
- Repository-løyve for identiteten tokenet representerer.
Sjølve statussemantikken står i RFC 9110, og han er verdt å sitere når du skriv rapporten.