Git 403 med VPN tilsluttet: find den, der svarer
Et 403 er et svar, ikke en dom over VPN. Find ud af, hvilken komponent der afviste anmodningen, og sammenlign derefter én variabel ad gangen på tværs af netværk, og skriv ned, hvad der ændrede sig.
Det virker på kontorets Wi-Fi og fejler på telefonens hotspot, med VPN tilsluttet i begge tilfælde. Git returnerer 403, og fejlen fylder tre linjer. Fristelsen er at gøre hotspot til årsagen og ændre netværksindstillinger, indtil noget flytter sig. HTTP 403 betyder, at en server forstod anmodningen og afviste den, så det nyttige spørgsmål er hvilken server, og det nyttige næste skridt er en sammenligning, der ændrer én ting ad gangen.
Læs status før netværket
Et 403 er ikke et mislykket opslag, en TCP-timeout eller et TLS-håndtryk, der aldrig blev færdigt. Det er en beslutning, truffet af noget, der har parset din anmodning.
Indtil du ved, hvad der traf den beslutning, er enhver netværksændring, du prøver, et gæt med en troværdig historie.
Hvem kan svare med 403?
Repository-applikationen er kun én kandidat. En proxy, en gateway eller en filtreringstjeneste kan sidde foran den og svare først, og klienten ser samme status i begge tilfælde. Gem status, de relevante headers og en renset fejlbody, og korrelér dem derefter med den autoriserede tjenestes logfiler. Den eksterne URL og det endepunkt, der faktisk nås, kan også afvige på grund af DNS eller proxykonfiguration, så kontrollér den konfigurerede adresse og den proces, der laver anmodningen.
Hvis afvisningen aldrig nåede repositoryet, vil dets logfiler være tavse, og den tavshed er bevis.
Sammenlign én variabel ad gangen
Hotspot-sammenligningen er nyttig, fordi den indsnævrer problemet, ikke fordi den beviser en årsag. To netværk kan på samme tid afvige i adressering, IP-familie, proxy, TLS-forhandling og udgangspolitik.
Ændr én ting per forsøg, og notér resten. Tabellen nedenfor er det minimum, jeg holder i en note, mens jeg gør det:
| 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 enkelt række, der afviger mellem det kørende og det fejlende gennemløb, er hvor den næste time går.
En omvej er bevis, ikke en forklaring
At tvinge en anden adressefamilie kan ændre destinationen, ruten eller det mellemled, der vælges, så det kan ændre resultatet uden at bevise, at IPv6 er uforenelig med repositoryet. En anden forhandlet TLS-version er en observation i samme kategori. Ingen af dem retfærdiggør at slå certifikatkontroller fra eller svække forbindelsen. Følg den afvisende komponents politik og logfiler frem til den faktiske beslutning i stedet for at stoppe ved den første ændring, der virker.
En omvej, du ikke kan forklare, vil fejle igen et andet sted.
Skriv en rapport, der bliver rettet
Giv ejeren af den svarande komponent den samme operation, to stier og den komponent, der sagde nej. Fjern autorisationsheaders, indlejrede legitimationsoplysninger og private repository-detaljer, før du deler noget.
Den nyttige rapport er kort, reproducerbar og navngiver laget i stedet for symptomet.
Den kontrol, jeg kører, i rækkefølge
Bekræft den eksterne URL og det opløste endepunkt, og optag derefter status og headers fra et fejlende gennemløb. Gentag den samme operation på et andet netværk, og sammenlign de to optegnelser.
Tag derefter den forskel med til den komponent, der svarede:
- Proxykonfiguration på klienten og på netværket.
- Udgangspolitik eller filtrering foran repositoryet.
- Token- eller kontoomfang, herunder udløb og SSO-betingelser.
- Repository-tilladelse for den identitet, tokenet repræsenterer.
Selve statussemantikken står i RFC 9110, og den er værd at citere, når du skriver rapporten.