VPN સાઇટની 403 પ્રોક્સી નિષ્ફળતા કેમ નથી
મૂળ તરફથી 403, નકારાયેલ CONNECT અને 407 પડકાર જુદી જુદી સીમાઓ દર્શાવે છે. પહેલાં પ્રોક્સીનો એગ્રેસ માર્ગ બ્રાઉઝરના VPN સરનામા સાથે સરખાવો.
વપરાશકર્તાઓ VPN કાપી નાખે છે, આંતરિક સાઇટ પર 403 મેળવે છે અને જણાવે છે કે પ્રોક્સી બગડી છે. ત્રણ અલગ વસ્તુઓ એ પૃષ્ઠ બનાવી શકે છે: મૂળે વિનંતી નકારી, ફોરવર્ડ પ્રોક્સીએ ટનલ ખોલવાનો ઇનકાર કર્યો, અથવા પ્રોક્સીએ પોતાના ઓળખપત્રો માંગ્યા. તેમાંથી દરેક જુદા પ્રશ્નનો સાચો જવાબ છે, અને તેમને એક સામાન્ય નિષ્ફળતા પૃષ્ઠમાં સપાટ કરવાથી તમારી પાસેનો એકમાત્ર પુરાવો નષ્ટ થાય છે. નકારને જે ઘટકે કર્યો તેના પ્રમાણે ગોઠવો, પછી દરેક ઘટક ખરેખર વાપરે છે તે નેટવર્ક માર્ગની સરખામણી કરો.
403 ઉત્પન્ન કરનાર ઘટકનું નામ આપો
HTTP સ્થિતિ કોડ તેને મોકલનાર પક્ષનો છે. જ્યારે મૂળ 403 પરત કરે છે, ત્યારે તેણે વિનંતીનું વિશ્લેષણ કર્યું છે અને નક્કી કર્યું છે કે કૉલર પાસે સંસાધન ન પણ હોય, જે અધિકૃતિનો જવાબ છે, પરિવહનની સમસ્યા નથી. જ્યારે ફોરવર્ડ પ્રોક્સી CONNECTને 403 જવાબ આપે છે, ત્યારે તેણે ટનલ બનાવવાનો સંપૂર્ણ ઇનકાર કર્યો છે અને ઉપરના કોઈનો ક્યારેય સંપર્ક થયો નથી. જ્યારે તે 407 જવાબ આપે છે, ત્યારે તે પોતાના ઓળખપત્રો ઈચ્છે છે, જેનો એપ્લિકેશનના લૉગિન સાથે કોઈ સંબંધ નથી.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 આ ભૂમિકાઓ વ્યાખ્યાયિત કરે છે, પ્રોક્સી-વિશિષ્ટ પડકાર સહિત. મુખ્ય ભાગ વાંચતા પહેલાં જવાબની પોતાની સ્થિતિ અને કોઈપણ Proxy-Authenticate હેડર વાંચો, કારણ કે મૈત્રીપૂર્ણ HTML ભૂલ પૃષ્ઠ સામાન્ય રીતે છુપાવે છે કે કયા ઘટકે તે લખ્યું.
CONNECT ટનલ બાઇટ રિલે પાસેથી શું છુપાવે છે
પ્રોક્સી CONNECTને 200 પરત કરે પછી તે બાઇટ્સ રિલે કરે છે અને બ્રાઉઝર મૂળ સાથે પોતાનું TLS સત્ર રાખે છે. તેથી બાઇટ-રિલે કરતી પ્રોક્સી તે સત્રની અંદરની એન્ક્રિપ્ટેડ 403 વાંચી શકતી નથી, અને તે ક્યારેય નકારનું લેખક બનતી નથી. ટનલ ખૂલે તે પહેલાંનો ઇનકાર સંપૂર્ણપણે જુદી ઘટના છે, જે એક સ્તર નીચે ઉત્પન્ન થાય છે.
TLS સમાપ્ત કરતી રિવર્સ પ્રોક્સી અલગ સ્થિતિમાં છે: તે TLS સીમાની માલિક છે, HTTPનું વિશ્લેષણ કરે છે અને કાયદેસર રીતે જવાબો ફરીથી લખી કે અટકાવી શકે છે. એ ક્ષમતા રૂપરેખાંકનની પસંદગી છે, સામાન્ય રીતે પ્રોક્સીની ગુણવત્તા નથી, અને તે એપ્લિકેશનની ઍક્સેસ નીતિને બાયપાસ કરવાની અધિકૃતિ આપતી નથી. જવાબ વાંચવો એ ક્ષમતા છે; કૉલર શું જોઈ શકે તે નક્કી કરવું મૂળનું કામ જ રહે છે.
વ્યવહારુ પરિણામ એ છે કે 403નું અર્થઘટન કરતા પહેલાં તમારે જાણવું જોઈએ કે તમે ત્રણમાંથી કયો આકાર ચલાવો છો. સ્ટ્રીમ પ્રોક્સીમાં HTTP નિરીક્ષણ નિયમો ઉમેરવાથી તેને દૃશ્યતા મળતી નથી, અને બાઇટ રિલે પાસેથી મૂળના નકારને સમજાવવાની અપેક્ષા રાખવાથી તમે ખોટા લૉગમાં જશો.
પ્રોક્સીના એગ્રેસ માર્ગને બ્રાઉઝરના ટનલ સરનામા સાથે સરખાવો
VPN સાથે જોડાયેલું બ્રાઉઝર આપોઆપ અલગ પ્રોક્સી સર્વરને તે ટનલ પર ખસેડતું નથી. મૂળ પ્રોક્સીનું એગ્રેસ સરનામું જુએ છે, અને જો પ્રોક્સી હજી સ્થાનિક ડિફૉલ્ટ માર્ગથી નીકળે છે, તો સુરક્ષિત સાઇટ એવું સરનામું જુએ છે જેને ક્યારેય વિશ્વાસ કરવા માટે ગોઠવવામાં આવ્યું ન હતું. લૅપટૉપ પરનું આંતરિક VPN સરનામું તે મૂળ માટે અદૃશ્ય છે. કાર્યકારી ટનલ હજી પણ એવી સાઇટથી 403 આપે છે જે બીજા બધા માટે યોગ્ય વર્તે છે—આ તેનું સૌથી સામાન્ય કારણ છે.
સરનામાં ભળી ન જાય તે માટે બંને માર્ગ અલગથી ચકાસો.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateપ્રથમ વિનંતી દર્શાવે છે કે મૂળ તમારા પોતાના સરનામા માટે શું જવાબ આપે છે, બીજી દર્શાવે છે કે પ્રોક્સીના સરનામા માટે શું જવાબ આપે છે. મેળ ખાતી 403 જોડી મૂળના અધિકૃતિ નિયમો તરફ ઇશારો કરે છે; 200 પછી 403 આવે તો પ્રોક્સી માર્ગ તરફ ઇશારો કરે છે. VPN પૂલ સમાવેશ થાય છે એમ માનવાને બદલે મૂળના માલિકને પૂછો કે નિયમ સમૂહ ખરેખર કયા સ્રોત સરનામાં સ્વીકારે છે.
જે વિનંતી સીમાને અલગ કરે તેનાથી દરેક સીમા ચકાસો
પ્રોક્સી સ્તરને એવું કંઈક માંગીને અલગ કરો જે તે એપ્લિકેશનના કારણોસર નકારી ન શકે. પ્રોક્સીને પહોંચવાની પરવાનગી હોય તેવા હોસ્ટ પર CONNECT, આઉટપુટ ફેંકી દઈને, તમને જણાવે છે કે ટનલ પ્રવેશ બિલકુલ કામ કરે છે કે નહીં.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
જો તે CONNECT માટે 200 અને પછી TLS હેન્ડશેક છાપે, તો પ્રોક્સી પ્રવેશ ઠીક છે અને પછીની 403 મૂળ તરફથી આવી. જો તે 407 છાપે, તો --proxy-user સાથે પ્રોક્સી ઓળખપત્રો આપો અને સાઇટ વિશે કોઈ નિષ્કર્ષ કાઢતા પહેલાં પુનરાવર્તન કરો. જો તે CONNECT લાઇન પર 403 છાપે, તો પ્રોક્સીની પોતાની પરવાનગી સૂચિ તપાસવાની સીમા છે, અને એપ્લિકેશન તેમાં સામેલ નથી.
ઓળખપત્રોને શેલ ઇતિહાસ અને પેસ્ટ કરેલા ટ્રાન્સક્રિપ્ટ્સથી દૂર રાખો. આદેશ લાઇનમાં ટાઇપ કરેલો પ્રોક્સી પાસવર્ડ અન્ય સ્થાનિક વપરાશકર્તાઓને દેખાય છે, અને ઓળખપત્રો સાથે પકડાયેલો CONNECT ટ્રેસ કોઈ ટ્રેસ ન હોવા કરતાં ખરાબ છે.
પૃષ્ઠ ફરીથી લખવાને બદલે ચુકાદો વાંચનીય રાખો
કયા ઘટકે નકાર કર્યો તે જાણ્યા પછી, તે જવાબ સાચવો. જે રિવર્સ પ્રોક્સી મૂળની 403ને 504 ટાઇમઆઉટ તરીકે ફરીથી લેબલ કરે છે, અથવા તેને સફળતા પૃષ્ઠથી બદલે છે, તે અધિકૃતિના નિર્ણયને ઉપલબ્ધતાની વાર્તા પાછળ છુપાવે છે અને આગલા પ્રતિસાદકર્તાને ખોટી ટીમમાં મોકલે છે. કસ્ટમ ભૂલ પૃષ્ઠો ત્યારે સારા હોય છે જ્યારે તે સ્થિતિ રાખે અને સંદર્ભ ઉમેરે.
કેશિંગ પણ એટલી જ કાળજી લાયક છે. RFC 9111 નિયંત્રિત કરે છે કે શેર કરેલા કેશ જવાબોનો ફરી ઉપયોગ કેવી રીતે કરી શકે, અને એક કૉલર માટે ઉત્પન્ન થયેલો નકાર બીજાને પરવાનગી હોય તેમ આપવો ન જોઈએ. જો નકારના જવાબો બિલકુલ સંગ્રહિત થાય, તો તેમને ખાનગી અને મર્યાદિત રાખો, અને ફક્ત ઉપરના ટ્રાફિકને ઘટાડવા માટે ક્યારેય જાહેર તાજગીનો નિયમ ઉમેરો નહીં.
લેખિત ચુકાદાથી સમાપ્ત કરો જે ઘટક, તેણે ઉત્પન્ન કરેલી સ્થિતિ અને મૂળે જોયેલું સ્રોત સરનામું નામ આપે. ચોક્કસ વિનંતી, અમલમાં રહેલી પ્રોક્સી સેટિંગ્સ અને સમય નોંધો, જેથી આગલો અહેવાલ સ્મૃતિમાંથી ફરી મેળવવાને બદલે એ જ પુરાવા સાથે મેળવી શકાય. એ નોંધ આગલા અહેવાલનો જવાબ સેકંડોમાં આપે છે અને એ જ 403ને ફરી VPN વિક્ષેપ તરીકે નિદાન થતું અટકાવે છે.