VPN સાથે જોડાયેલા Git 403: જવાબ આપનારને શોધો
403 એ જવાબ છે, VPN વિશેનો ચુકાદો નહીં. કયા ઘટકે વિનંતી નકારી તે ઓળખો, પછી નેટવર્ક વચ્ચે એક સમયે એક ચલ સરખાવો અને શું બદલાયું તે નોંધો.
ઓફિસના Wi-Fi પર કામ કરે છે અને ફોનના હોટસ્પોટ પર નિષ્ફળ જાય છે, બંને કિસ્સામાં VPN જોડાયેલું છે. Git 403 પરત કરે છે અને ભૂલ ત્રણ લાઇનની છે. લલચાવ એ છે કે હોટસ્પોટને કારણ માની લેવું અને કંઈક બદલાય ત્યાં સુધી નેટવર્ક સેટિંગ્સ બદલતા રહેવું. HTTP 403 નો અર્થ છે કે સર્વરે વિનંતી સમજી અને નકારી દીધી, તેથી ઉપયોગી પ્રશ્ન એ છે કે કયો સર્વર, અને ઉપયોગી આગળનું પગલું એ સરખામણી છે જે એક સમયે એક વસ્તુ બદલે છે.
નેટવર્ક પહેલાં સ્થિતિ વાંચો
403 એ નિષ્ફળ શોધ નથી, TCP સમયસીમા નથી, કે અધૂરું રહેલું TLS હેન્ડશેક પણ નથી. તે એક નિર્ણય છે, જે તમારી વિનંતીનું પૃથ્થકરણ કરનાર કોઈકે લીધો છે.
જ્યાં સુધી તમે ન જાણો કે એ નિર્ણય કોણે લીધો, તમે અજમાવો છો તે દરેક નેટવર્ક ફેરફાર વિશ્વસનીય વાર્તા સાથેનું અનુમાન છે.
કોણ 403 સાથે જવાબ આપી શકે?
રિપોઝિટરી એપ્લિકેશન ફક્ત એક ઉમેદવાર છે. પ્રોક્સી, ગેટવે અથવા ફિલ્ટરિંગ સેવા તેની સામે બેસીને પહેલા જવાબ આપી શકે છે, અને ક્લાયન્ટને બંને કિસ્સામાં એ જ સ્થિતિ દેખાય છે. સ્થિતિ, સંબંધિત હેડરો અને સાફ કરેલું ભૂલ શરીર સાચવો, પછી તેમને અધિકૃત સેવાના લોગ સાથે સાંકળો. દૂરનું URL અને ખરેખર પહોંચેલું અંતિમ બિંદુ પણ DNS અથવા પ્રોક્સી રૂપરેખાંકનને કારણે અલગ હોઈ શકે, તેથી ગોઠવેલું સરનામું અને વિનંતી કરતી પ્રક્રિયા તપાસો.
જો નકાર ક્યારેય રિપોઝિટરી સુધી પહોંચ્યો ન હોય, તો તેના લોગ શાંત રહેશે, અને એ શાંતિ એ પુરાવો છે.
એક સમયે એક ચલ સરખાવો
હોટસ્પોટ સરખામણી ઉપયોગી છે કારણ કે તે સમસ્યાને સાંકડી કરે છે, એટલા માટે નહીં કે તે કારણ સાબિત કરે છે. બે નેટવર્ક એક જ સમયે સરનામાંકન, IP કુટુંબ, પ્રોક્સી, TLS વાટાઘાટ અને એગ્રેસ નીતિમાં અલગ હોઈ શકે છે.
દરેક પ્રયાસમાં એક વસ્તુ બદલો અને બાકીનું નોંધો. નીચેનું કોષ્ટક એ લઘુત્તમ છે જે હું આ કરતી વખતે નોંધમાં રાખું છું:
| 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 |
કાર્યરત અને નિષ્ફળ રન વચ્ચે જે એક હરોળ અલગ પડે છે, આગલો કલાક ત્યાં જ જાય છે.
વર્કઅરાઉન્ડ પુરાવો છે, સમજૂતી નહીં
બીજું સરનામું કુટુંબ ફરજિયાત કરવાથી ગંતવ્ય, માર્ગ અથવા પસંદ થતો મધ્યસ્થ બદલાઈ શકે છે, તેથી તે પરિણામ બદલી શકે છે પણ IPv6 રિપોઝિટરી સાથે અસંગત છે તે સાબિત કરતું નથી. વાટાઘાટ થયેલું બીજું TLS સંસ્કરણ એ જ શ્રેણીનું અવલોકન છે. બંનેમાંથી કોઈ પણ પ્રમાણપત્ર તપાસ બંધ કરવાનું કે જોડાણ નબળું કરવાનું વાજબી ઠેરવતું નથી. પ્રથમ કામ કરતા ફેરફાર પર અટકવાને બદલે નકારનારા ઘટકની નીતિ અને લોગને ખરા નિર્ણય સુધી અનુસરો.
તમે સમજાવી ન શકો તેવું વર્કઅરાઉન્ડ બીજે ક્યાંક ફરી નિષ્ફળ જશે.
એવો અહેવાલ લખો જે સુધારાય
જવાબ આપનારા ઘટકના માલિકને એ જ ક્રિયા, બે માર્ગ અને ના પાડનાર ઘટક આપો. કંઈપણ શેર કરતા પહેલાં અધિકૃતિ હેડરો, એમ્બેડ કરેલા ઓળખપત્રો અને ખાનગી રિપોઝિટરી વિગતો દૂર કરો.
ઉપયોગી અહેવાલ ટૂંકો, પુનરાવર્તનીય હોય છે અને લક્ષણને બદલે સ્તરનું નામ આપે છે.
હું ક્રમમાં જે તપાસ કરું છું
દૂરનું URL અને ઉકેલાયેલું અંતિમ બિંદુ ખાતરી કરો, પછી નિષ્ફળ રનમાંથી સ્થિતિ અને હેડરો કેપ્ચર કરો. બીજા નેટવર્ક પર એ જ ક્રિયા પુનરાવર્તિત કરો અને બંને રેકોર્ડ સરખાવો.
પછી એ ફરક જવાબ આપનારા ઘટક પાસે લઈ જાઓ:
- ક્લાયન્ટ પર અને નેટવર્ક પર પ્રોક્સી રૂપરેખાંકન.
- રિપોઝિટરીની સામે એગ્રેસ નીતિ અથવા ફિલ્ટરિંગ.
- ટોકન અથવા ખાતાનો વ્યાપ, સમાપ્તિ અને SSO શરતો સહિત.
- ટોકન જે ઓળખનું પ્રતિનિધિત્વ કરે તેના માટે રિપોઝિટરી પરવાનગી.
સ્થિતિનો અર્થ જ RFC 9110-માં છે, અને અહેવાલ લખતી વખતે તેને ટાંકવા યોગ્ય છે.