Git 403 kun konektita VPN: trovu la respondanton
403 estas respondo, ne verdikto pri la VPN. Identigu, kiu komponanto rifuzis la peton, poste komparu unu variablon samtempe inter retoj kaj notu, kio ŝanĝiĝis.
Ĝi funkcias per la oficeja Wi-Fi kaj malsukcesas per la poŝtelefona hotspots, kun la VPN konektita en ambaŭ kazoj. Git redonas 403 kaj la eraro havas tri liniojn. La tento estas rigardi la hotspotan kiel kaŭzon kaj ŝanĝi retajn agordojn ĝis io moviĝos. HTTP 403 signifas, ke servilo komprenis la peton kaj rifuzis ĝin, do la utila demando estas kiu servilo, kaj la utila sekva paŝo estas komparo, kiu ŝanĝas unu aferon samtempe.
Legu la staton antaŭ la reto
403 ne estas malsukcesa serĉo, nek TCP-tempo elĉerpiĝo, nek TLS-manpremo, kiu neniam finiĝis. Ĝi estas decido, farita de io, kio analizis vian peton.
Ĝis vi scios, kio faris tiun decidon, ĉiu reta ŝanĝo, kiun vi provas, estas konjekto kun kredinda rakonto.
Kiu povas respondi per 403?
La deponeja aplikaĵo estas nur unu kandidato. Prokuro, kluzo aŭ filtrada servo povas stari antaŭ ĝi kaj respondi unue, kaj la kliento vidas la saman staton en ambaŭ kazoj. Konservu la staton, la koncernajn kapliniojn kaj purigitan eraran korpon, poste kunligu ilin kun la protokoloj de la rajtigita servo. La fora URL kaj la efektive atingita finpunkto ankaŭ povas diferenci pro DNS aŭ prokura agordo, do kontrolu la agorditan adreson kaj la procezon, kiu faras la peton.
Se la rifuzo neniam atingis la deponejon, ĝiaj protokoloj silentos, kaj tiu silento estas pruvo.
Komparu unu variablon samtempe
La komparo kun la hotspoto utilas ĉar ĝi mallarĝigas la problemon, ne ĉar ĝi pruvas kaŭzon. Du retoj povas samtempe diferenci en adresado, IP-familio, prokuro, TLS-traktado kaj elira politiko.
Ŝanĝu unu aferon por provo kaj notu la reston. La suba tabelo estas la minimumo, kiun mi tenas en noto dum tio:
| 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 |
Unu sola vico, kiu diferencas inter la funkcianta kaj la malsukcesa rulo, estas kie iras la sekva horo.
Provizora solvo estas pruvo, ne klarigo
Devigi alian adresan familion povas ŝanĝi la celon, la itineron aŭ la peranton, kiu estas elektata, do ĝi povas ŝanĝi la rezulton sen pruvi, ke IPv6 estas neakordigebla kun la deponejo. Alia traktita TLS-versio estas observo en la sama kategorio. Nek unu nek la alia pravigas malŝalti atestilajn kontrolojn aŭ malfortigi la konekton. Sekvu la politikon kaj protokolojn de la rifuzanta komponanto ĝis la efektiva decido, anstataŭ halti ĉe la unua ŝanĝo, kiu funkcias.
Provizora solvo, kiun vi ne povas klarigi, denove malsukcesos aliloke.
Skribu raporton, kiu estos riparita
Donu al la posedanto de la respondinta komponanto la saman operacion, du vojojn kaj la komponanton, kiu diris ne. Forigu rajtigajn kapliniojn, enkorpigitajn akreditaĵojn kaj privatajn deponejajn detalojn antaŭ ol kunhavigi ion ajn.
La utila raporto estas mallonga, ripetebla kaj nomas la tavolon anstataŭ la simptomon.
La kontrolo, kiun mi faras, laŭorde
Konfirmu la foran URL kaj la solvitan finpunkton, poste kaptu la staton kaj kapliniojn el malsukcesa rulo. Ripetu la saman operacion en dua reto kaj komparu la du rikordojn.
Poste portu tiun diferencon al la komponanto, kiu respondis:
- Prokura agordo sur la kliento kaj sur la reto.
- Elira politiko aŭ filtrado antaŭ la deponejo.
- Etendo de ĵetono aŭ konto, inkluzive de limdato kaj SSO-kondiĉoj.
- Deponeja permeso por la identeco, kiun la ĵetono reprezentas.
La semantiko de la stato mem troviĝas en RFC 9110, kaj indas citi ĝin, kiam vi skribos la raporton.