proxy_redirect NGINXને તમારા VPN હોસ્ટ સાથે જોડતું નથી
proxy_redirect પહેલેથી આવેલા જવાબમાં હેડર ફરી લખે છે; તે કદી અપસ્ટ્રીમ પસંદ કરતું નથી. proxy_pass, બેકએન્ડ સુધીનો રૂટ, પછી હેડર તપાસો.
નામમાં redirect શબ્દ છે, તેથી VPN પાછળનું બેકએન્ડ પહોંચમાં ન હોય ત્યારે તેને location બ્લોકમાં પેસ્ટ કરવામાં આવે છે. કંઈ બદલાતું નથી, અને સ્પષ્ટ તારણ એ છે કે નિર્દેશ તૂટેલો છે અથવા બીજી સિન્ટેક્સ જોઈએ છે. ખરેખર જે બન્યું તે વધુ સરળ અને ઓછું પ્રશંસનીય છે: proxy_redirect એવા જવાબ પર કામ કરે છે જે પહેલેથી પાછો આવી ગયો છે, અને આ ડિપ્લોયમેન્ટમાં કોઈ પણ વિનંતી ત્યાં સુધી પહોંચી નહોતી.
એક વિનંતીમાં બે નિર્દેશ, બે ક્ષણો
રિવર્સ પ્રોક્સીમાંથી પસાર થતી HTTP વિનંતી ક્રમમાં ઘણા નિર્ણયોમાંથી પસાર થાય છે, અને બંને નિર્દેશ એ ક્રમના વિરોધી છેડે રહે છે. એક નક્કી કરે છે કે વિનંતી ક્યાં જશે. બીજો પાછા આવતા જવાબમાં અમુક હેડરો સંપાદિત કરે છે.
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
એ ક્રમ જ આખો જવાબ છે. જો પહેલી પંક્તિ નિષ્ફળ જવાને કારણે બીજી પંક્તિ કદી ચાલે નહીં, તો બીજો નિર્દેશ ખોટી રીતે ગોઠવાયેલો નથી, તે ફક્ત પહોંચની બહાર છે. બીજી લાઇન કેટલી પણ ફરી લખો, તે જે જવાબ સંપાદિત કરવાનો હતો તે બનશે નહીં. પહેલી પંક્તિથી બહાર તરફ નિદાન કરો, અને ગૂંચવણભર્યું વર્તન ખૂટતા રૂટ અથવા નકારેલા કનેક્શનમાં ઉકેલાય છે.
અપસ્ટ્રીમ પસંદ કરવું proxy_passનું કામ છે
ધારો કે NGINX સાર્વજનિક એન્ટ્રી હોસ્ટ પર ચાલે છે અને તેના VPN દ્વારા 10.40.0.20:8080 પરની એપ્લિકેશન સુધી પહોંચી શકે છે. તે એપ્લિકેશન પસંદ કરતો ટુકડો હાલના server બ્લોકની અંદર આવો દેખાય છે:
location / {
proxy_pass http://10.40.0.20:8080;
}વાસ્તવિક સ્કીમ, સરનામું અને પોર્ટ વાપરો, અને આને ડિપ્લોયમેન્ટ નહીં પણ ટુકડા તરીકે ગણો. એન્ટ્રી હોસ્ટે VPN રૂટ, માન્ય ફોરવર્ડિંગ પાથ અને તે સેવા સુધી કાર્યરત પરત ટ્રાફિક પણ રાખવો પડે, કારણ કે કાગળ પર સરનામે પહોંચતા પ્રોક્સીને હજી કર્નલની સંમતિ જોઈએ.
proxy મોડ્યુલનો સંદર્ભ અપસ્ટ્રીમની પસંદગીને જવાબ-હેડરની પુનર્લેખનથી અલગ રાખે છે અને નોંધે છે કે URI ધરાવતું proxy_pass મૂલ્ય બદલે છે કે મેળ ખાતું location પ્રીફિક્સ કેવી રીતે બદલાય છે. એપ્લિકેશન જે URL ધારે છે તે તપાસ્યા વિના પાથ ઘટકો ઉમેરવા કે દૂર કરવા એ 404 પેદા કરવાનો ભરોસાપાત્ર રસ્તો છે જે રાઉટિંગ નિષ્ફળતા જેવો લાગે.
proxy_redirect ખાનગી સરનામું લીક કરતા જવાબો સુધારે છે
ટ્રાફિક વહેવા લાગે એટલે બેકએન્ડ પોતાનું ખાનગી સરનામું જણાવતા Location હેડર સાથે જવાબ આપી શકે છે. તે હેડર અનુસરતું બ્રાઉઝર સાર્વજનિક પ્રવેશબિંદુ છોડીને એવી વસ્તુ સુધી પહોંચવા પ્રયત્ન કરે છે જે તે ઉકેલી શકતું નથી. જાણી જોઈને ગોઠવાયેલું જવાબ-પુનર્લેખન ખાનગી URLને સાર્વજનિક પર મેપ કરે છે:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;બંને બાજુ વાસ્તવિક મૂલ્યોથી બદલો. સાંકડી પહોંચ પણ સમજો: મેળ ખાતા Location અને Refresh હેડરનું લખાણ ફરી લખાય છે, પણ HTML, JavaScript કે ડાઉનલોડ થયેલી ફાઇલોમાં જડાયેલા URL નહીં.
જો એપ્લિકેશન દરેક જગ્યાએ સંપૂર્ણ લિંક બનાવે, તો ટકાઉ ઉકેલ તેની પોતાની બાહ્ય-URL ગોઠવણી છે, પ્રોક્સી પર વધતી પુનર્લેખન નિયમોની યાદી નહીં. આઉટપુટ સાચું લાગે ત્યાં સુધી નિયમો ઉમેરવાથી એવી ગોઠવણી બને છે જે પહેલા જ એવા પૃષ્ઠ પર નિષ્ફળ જાય જે કોઈએ ચકાસ્યું નથી. એપ્લિકેશનની એક સાચી સેટિંગ આખો સંગ્રહ બદલી નાખે છે.
હેડર પુનર્લેખન શું સુધારી શકતું નથી
કેટલીક નજીકની સમસ્યાઓ રીડાયરેક્ટ સમસ્યા જેવી લાગે છે પણ નથી. અપસ્ટ્રીમને મોકલાતું Host હેડર બેકએન્ડના વર્ચ્યુઅલ હોસ્ટ સાથે મેળ ખાવાની જરૂર પડી શકે છે. TLS અપસ્ટ્રીમને ચોક્કસ સર્વર નામ અને પ્રમાણપત્ર ચકાસણીની જરૂર પડી શકે છે, અને જવાબ-હેડરનું પુનર્લેખન બંનેમાંથી કશાને મદદ કરતું નથી.
કૂકીની પહોંચ અને ડોમેન એટ્રિબ્યુટ એપ્લિકેશન અને તેની ગોઠવણીના છે. પ્રોક્સી આખો દિવસ હેડર ફેંકી શકે છે અથવા ફરી લખી શકે છે અને છતાં એવું સેશન બનાવે છે જે બીજી વિનંતીએ નિષ્ફળ જાય, કારણ કે કૂકી એવા હોસ્ટ માટે આપવામાં આવી હતી જે બ્રાઉઝરે કદી જોયું નહોતું. એ નિષ્ફળતા વચ્ચે વચ્ચે થતી લાગે છે, તેથી ટિકિટ કતારમાં તે આટલું લાંબુ ટકે છે. કૂકીનું ડોમેન વાંચવાથી સામાન્ય રીતે એક મિનિટમાં તપાસ પૂરી થાય છે.
પ્રમાણીકરણ અને બેકએન્ડની પસંદગી પણ ધારેલી એપ્લિકેશન સુધી મર્યાદિત રાખો. સાર્વજનિક રિવર્સ પ્રોક્સીએ સર્વરના VPN દ્વારા એક એપ્લિકેશન ખુલ્લી કરવી જોઈએ, તે હોસ્ટ પહોંચી શકે તેવા દરેક ખાનગી સરનામા સુધીનું સામાન્ય ગેટવે બનવાને બદલે. એક સામાન્ય location જે કૉલર માંગે તે બધું ફોરવર્ડ કરે છે તે એક ખુલ્લી સેવાને તમારા ખાનગી નેટવર્કના નકશામાં ફેરવે છે. અપસ્ટ્રીમને સ્પષ્ટ નામ આપો અને ત્યાં જ રાખો.
વિનંતી જે ક્રમમાં મુસાફરી કરે તે ક્રમમાં પરીક્ષણ કરો
ક્રમમાં ત્રણ વસ્તુ ખાતરી કરો: NGINXએ ધારેલું location પસંદ કર્યું, બેકએન્ડ સુધી વિનંતી પૂરી કરી, અને બ્રાઉઝરે પછીનું કોઈ રીડાયરેક્ટ અનુસરીને ઉપ-સ્રોત લોડ કર્યા. દરેક પગલાની પોતાની લોગ લાઇન છે, અને તેને ક્રમમાં વાંચવાથી અસ્પષ્ટ 502 ચોક્કસ શોધમાં ફેરવાય છે.
તમને જરૂરી ભેદ નિષ્ફળ અપસ્ટ્રીમ કનેક્શન અને પહોંચ ન હોય તેવા ખાનગી નામ પર મોકલાયેલા બ્રાઉઝર વચ્ચેનો છે. પહેલું પ્રોક્સી ભૂલ-લોગમાં દેખાય છે; બીજું એવી વિનંતી તરીકે દેખાય છે જે કદી આવતી નથી, અને બ્રાઉઝર એવા હોસ્ટની ફરિયાદ કરે છે જે તે ઉકેલી શકતું નથી. બે અલગ સમસ્યાઓ, બે અલગ ફાઇલો, અને તેમાંથી ફક્ત એક જ proxy_redirect સાથે સંબંધ ધરાવે છે.