Git 403 met die VPN aan: vind wie antwoord
403 is 'n antwoord, nie 'n uitspraak oor die VPN nie. Bepaal watter komponent geweier het, vergelyk dan een veranderlike op 'n slag oor netwerke en skryf neer wat verander het.
Dit werk op kantoor se Wi-Fi en misluk op die selfoon se hotspot, met die VPN in albei gevalle aan. Git gee 403 terug en die fout strek oor drie reëls. Die versoeking is om die hotspot as die oorsaak te sien en netwerkinstellings te verander totdat iets beweeg. HTTP 403 beteken 'n bediener het die versoek verstaan en dit geweier, so die nuttige vraag is watter bediener, en die nuttige volgende stap is 'n vergelyking wat een ding op 'n slag verander.
Lees eers die status, dan die netwerk
'n 403 is nie 'n mislukte opsoek, 'n TCP-tydsverloop of 'n TLS-handdruk wat nooit voltooi het nie. Dit is 'n besluit, geneem deur iets wat jou versoek ontleed het.
Totdat jy weet wat daardie besluit geneem het, is elke netwerkverandering wat jy probeer 'n raaiskoot met 'n geloofwaardige storie daarby.
Wie kan met 403 antwoord?
Die repository-toepassing is net een kandidaat. 'n Proxy, 'n gateway of 'n filterdiens kan voor dit sit en eerste antwoord, en die kliënt sien in albei gevalle dieselfde status. Bewaar die status, die relevante koptekste en 'n skoongemaakte foutliggaam, en korreleer dit dan met die gemagtigde diens se logboeke. Die remote-URL en die eindpunt wat werklik bereik word, kan ook deur DNS of proxy-konfigurasie verskil, so kontroleer die gekonfigureerde adres en die proses wat die versoek maak.
As die weiering nooit die repository bereik het nie, sal sy logboeke stil wees, en daardie stilte is bewyse.
Vergelyk een veranderlike op 'n slag
Die hotspot-vergelyking is nuttig omdat dit die probleem vernou, nie omdat dit 'n oorsaak bewys nie. Twee netwerke kan op dieselfde oomblik verskil in adressering, IP-familie, proxy, TLS-onderhandeling en uitgangsbeleid.
Verander een ding per poging en teken die res aan. Die tabel hieronder is die minimum wat ek in 'n nota hou terwyl ek dit doen:
| 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 |
Een ry wat verskil tussen die werkende en die mislukkende lopie is waar die volgende uur gaan.
'n Oplossing is bewyse, nie 'n verklaring nie
Om 'n ander adresfamilie te forseer kan die bestemming, die roete of die tussenganger wat gekies word verander, so dit kan die resultaat verander sonder om te bewys dat IPv6 onversoenbaar met die repository is. 'n Ander onderhandelde TLS-weergawe is 'n waarneming in dieselfde kategorie. Nie een regverdig die uitskakel van sertifikaatkontroles of die verswakking van die verbinding nie. Volg die weierde komponent se beleid en logboeke tot by die werklike besluit eerder as om by die eerste verandering wat werk te stop.
'n Oplossing wat jy nie kan verduidelik nie, sal weer elders misluk.
Skryf 'n verslag wat reggemaak word
Gee die eienaar van die antwoordende komponent dieselfde handeling, twee paaie en die komponent wat nee gesê het. Verwyder magtigingskoppe, ingebedde geloofsbriewe en private repository-besonderhede voordat jy iets deel.
Die nuttige verslag is kort, herhaalbaar en noem die laag eerder as die simptoom.
Die kontrole wat ek in volgorde uitvoer
Bevestig die remote-URL en die opgeloste eindpunt, en vang dan die status en koptekste van 'n mislukkende lopie vas. Herhaal dieselfde handeling op 'n tweede netwerk en vergelyk die twee rekords.
Neem dan daardie verskil na die komponent wat geantwoord het:
- Proxy-konfigurasie op die kliënt en op die netwerk.
- Uitgangsbeleid of filtering voor die repository.
- Token- of rekeningomvang, insluitend verval en SSO-voorwaardes.
- Repository-toestemming vir die identiteit wat die token verteenwoordig.
Die status-semantiek self staan in RFC 9110, en dit is die moeite werd om dit aan te haal wanneer jy die verslag skryf.