Git 403 med VPN ansluten: hitta den som svarar
403 är ett svar, inte en dom över VPN:en. Identifiera vilken komponent som nekade och jämför sedan en variabel i taget mellan nätverk och notera vad som ändrades.
Det fungerar på kontorets Wi-Fi och misslyckas på telefonens hotspot, med VPN ansluten i båda fallen. Git returnerar 403 och felet är tre rader långt. Frestelsen är att behandla hotspoten som orsaken och ändra nätverksinställningar tills något rör sig. HTTP 403 betyder att en server förstod begäran och nekade den, så den användbara frågan är vilken server, och det användbara nästa steget är en jämförelse som ändrar en sak i taget.
Läs statusen före nätverket
403 är inte en misslyckad sökning, en TCP-timeout eller en TLS-handskakning som aldrig slutfördes. Det är ett beslut, fattat av något som tolkat din begäran.
Tills du vet vad som fattade det beslutet är varje nätverksändring du provar en gissning med en trovärdig historia.
Vem kan svara med 403?
Repository-applikationen är bara en kandidat. En proxy, en gateway eller en filtreringstjänst kan sitta framför den och svara först, och klienten ser samma status oavsett. Bevara statusen, relevanta huvuden och en rensad felkropp och korrelera dem sedan med loggarna för den auktoriserade tjänsten. Fjärr-URL:en och den slutpunkt som faktiskt nås kan också skilja sig genom DNS eller proxykonfiguration, så kontrollera den konfigurerade adressen och processen som gör begäran.
Om nekandet aldrig nådde repositoryt blir dess loggar tysta, och den tystnaden är bevis.
Jämför en variabel i taget
Hotspotjämförelsen är användbar eftersom den snävar in problemet, inte för att den bevisar en orsak. Två nätverk kan skilja sig i adressering, IP-familj, proxy, TLS-förhandling och utgångspolicy samtidigt.
Ändra en sak per försök och notera resten. Tabellen nedan är minimumet jag har i en anteckning medan jag gör detta:
| 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 |
En enda rad som skiljer sig mellan den fungerande och den misslyckade körningen är där nästa timme går.
En kringgång är bevis, inte en förklaring
Att tvinga fram en annan adressfamilj kan ändra destinationen, rutten eller den mellanhand som väljs, så det kan ändra resultatet utan att bevisa att IPv6 är inkompatibelt med repositoryt. En annan förhandlad TLS-version är en observation i samma kategori. Ingen av dem motiverar att stänga av certifikatkontroller eller försvaga anslutningen. Följ den nekande komponentens policy och loggar till det faktiska beslutet i stället för att stanna vid den första ändring som fungerar.
En kringgång du inte kan förklara kommer att misslyckas igen någon annanstans.
Skriv en rapport som blir åtgärdad
Ge ägaren av komponenten som svarade samma operation, två vägar och komponenten som sa nej. Ta bort auktoriseringshuvuden, inbäddade uppgifter och privata repository-detaljer innan du delar något.
Den användbara rapporten är kort, reproducerbar och namnger lagret i stället för symptomet.
Kontrollen jag kör, i ordning
Bekräfta fjärr-URL:en och den uppslagna slutpunkten och fånga sedan statusen och huvudena från en misslyckad körning. Upprepa samma operation i ett andra nätverk och jämför de två posterna.
Ta sedan den skillnaden till komponenten som svarade:
- Proxykonfiguration på klienten och i nätverket.
- Utgångspolicy eller filtrering framför repositoryt.
- Omfång för token eller konto, inklusive utgång och SSO-villkor.
- Repository-behörighet för den identitet som token representerar.
Själva statussemantiken finns i RFC 9110, och den är värd att citera när du skriver rapporten.