SSH લોકલ ફોરવર્ડ થી હાલનું HTTP પ્રોક્સી: બે loopback સરનામાં

તમારું મંજૂર પ્રોક્સી એક જમ્પ હોસ્ટ પર ચાલે છે જ્યાં તે ફક્ત loopback પર સાંભળે છે, તેથી તે મશીનની બહારનું કંઈપણ તેને પહોંચી શકતું નથી. તમારે VPN કે નવું પ્રોક્સી ની જરૂર નથી; તમારે તે મશીનનો એક પોર્ટ તમારા એક પોર્ટ પર લઈ જવાની જરૂર છે. લોકલ ફોરવર્ડ બરાબર એ જ કરે છે, અને તેમાં એક કમાન્ડ અને એપ્લિકેશનનું એક સેટિંગ જોઈએ. ગૂંચવણ સામાન્ય રીતે એમાંથી ઊભી થાય છે કે કયું loopback સરનામું કઈ મશીનનું છે તે મિશ્ર થઈ જાય છે.

નક્કી કરો કે નિશ્ચિત પ્રોક્સી પહેલેથી છે કે નહીં

આ તકનીક એવી સેવાને ફોરવર્ડ કરે છે જે પહેલેથી ચાલી રહી છે. જો રિમોટ હોસ્ટ પર ફક્ત SSH ડેમન હોય અને પ્રોક્સી ન હોય, તો કેટલુંય ફોરવર્ડ કરો તે એક બનાવશે નહીં, અને રિમોટ બાજુથી જોડાણ નકારવામાં આવશે. ખાતરી કરો કે પ્રોક્સી બંધાયેલું છે, તેનો પોર્ટ કયો છે, અને તે 127.0.0.1 પર સાંભળે છે કે ચોક્કસ ઇન્ટરફેસ સરનામા પર, કારણ કે તે સરનામું જ ફોરવર્ડનું લક્ષ્ય હોવું જોઈએ.

આ પહેલા ખાતરી કરવાથી તમે એવી ટનલ ડિબગ કરવાથી બચો છો જે ક્યારેય કોઈ વસ્તુ સાથે જોડાઈ જ ન હતી.

ફોરવર્ડ બનાવો અને કમાન્ડ વાંચો

તમને જોઈતું સ્વરૂપ તમારા લેપટોપ પર એક loopback પોર્ટ બાંધે છે અને સર્વરની બાજુથી તેને પ્રોક્સીના સરનામા સાથે જોડે છે, જેમ સર્વર તેને જુએ છે.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N રિમોટ કમાન્ડ દબાવે છે અને -T termios ફાળવણી દબાવે છે, કારણ કે તમારે ટનલ જોઈએ છે, શેલ નહીં. પહેલું loopback સરનામું તે છે જ્યાં લેપટોપ સાંભળે છે; બીજું SSH સર્વર દ્વારા ઉકેલાય છે, તેથી ત્યાં 127.0.0.1 એટલે તે મશીન પરનું પ્રોક્સી. ExitOnForwardFailure સ્થાનિક પોર્ટ પહેલેથી ભરાયેલો હોય તો કમાન્ડને મોટેથી નિષ્ફળ કરે છે, કંઈ ફોરવર્ડ ન કરતું સત્ર શરૂ કરવાને બદલે. લક્ષ્ય સરનામું સર્વર જેમ ઉકેલે તેમ લખો, કારણ કે ફક્ત તમારું લેપટોપ ઉકેલી શકે એવું નામ સામેની બાજુએ નિષ્ફળ જશે.

આમાંથી કંઈ કામ કરે તે પહેલાં સર્વરની પોતાની નીતિ લાગુ પડે છે. AllowTcpForwarding એને મંજૂરી આપવી જોઈએ, અને PermitOpen મર્યાદિત કરી શકે છે કે સત્ર કઈ ગંતવ્યો અને પોર્ટ સુધી પહોંચી શકે, તેથી ક્લાયન્ટ સ્વીકારે તેવું ફોરવર્ડ પણ સર્વર દ્વારા નકારી શકાય છે. નકાર ક્લાયન્ટ પર ફોરવર્ડ કે ચેનલ ભૂલ તરીકે દેખાય છે, અને તે સંદેશ વાંચવો કમાન્ડ સંપાદિત કરવા કરતાં વધુ ઝડપી છે.

એક એપ્લિકેશનને ફોરવર્ડ તરફ દોરો

એપ્લિકેશનને http://127.0.0.1:13128 પર HTTP પ્રોક્સી વાપરવા માટે ગોઠવો, જો રિમોટ પ્રોક્સી માંગે તો ઓળખપત્રો સાથે. HTTPS ગંતવ્યો માટે એપ્લિકેશનની પોતાની પ્રમાણપત્ર ચકાસણી રાખો, કારણ કે પ્રોક્સી ટનલ તેને બદલતી નથી. આ એક સેવાનું નિશ્ચિત ફોરવર્ડ છે, તેથી એપ્લિકેશનને પ્રોક્સી વિશે કહેવું પડે છે, તેને જાતે શોધવા છોડી દેવાને બદલે.

કંઈ પણ કાયમી ગોઠવતા પહેલાં ઝડપી તપાસ: curl -x http://127.0.0.1:13128 -I https://example.com, જે HTTP CONNECT પદ્ધતિનો અભ્યાસ કરે છે જે પ્રોક્સીએ સમર્થન કરવું જોઈએ.

સત્તા જ્યાં હતી ત્યાં જ રાખો

રિમોટ પ્રોક્સી હજી પણ નક્કી કરે છે કે કઈ ગંતવ્યો અને પદ્ધતિઓને મંજૂરી આપે છે, અને SSH લોગિનએ દરેક ખાતાને ચૂપચાપ સામાન્ય વેબ રિલે આપવો ન જોઈએ. લેપટોપ પર 127.0.0.1 પર બાંધવાથી પોર્ટને તમારા સ્થાનિક નેટવર્ક પર પ્રકાશિત કરવાનું ટાળાય છે, અને તે પોર્ટને એ જ મશીનની બીજી પ્રક્રિયાઓથી ખાનગી બનાવતું નથી. પ્રોક્સી વહેંચવા માટે તે બંધનને wildcard સરનામાથી બદલવું એ જ રીતે અણસંચાલિત ખુલ્લું રિલે બને છે.

SSH પરિવહન સર્વર સુધીની છલાંગને સુરક્ષિત રાખે છે. તે બિંદુ પછી પ્રોક્સી પોતાનું જોડાણ ખોલે છે, તેથી ગંતવ્ય તરફની સાદી HTTP વિનંતી સર્વર પછી પણ સાદી જ રહે છે, જોકે પહેલો ભાગ એન્ક્રિપ્ટ થયેલો હતો.

બંને છેડા ચકાસો, પછી સફાઈ કરો

સ્થાનિક ટનલ ગોઠવણી અને રિમોટ સેવાની સફળતા જુદા જુદા પરિણામો છે, અને કમાન્ડની નિકાસ સ્થિતિ તમને ફક્ત પહેલા વિશે કહે છે. ss -ltn વડે સાંભળનાર અસ્તિત્વમાં છે કે નહીં તે તપાસો, પછી એક મંજૂર એપ્લિકેશન વિનંતી અને એક વિનંતી કરો જે પ્રોક્સીએ નકારવી જોઈએ. બંને અપેક્ષા મુજબ વર્તે તો માર્ગ સાચો છે; ટનલ ચાલુ હોય અને દરેક વિનંતી નિષ્ફળ જાય તો પ્રોક્સી નકારી રહ્યું છે અથવા ગંતવ્ય સુધી પહોંચી શકતું નથી.

પૂરું થાય ત્યારે માલિક SSH પ્રક્રિયા બંધ કરો, એપ્લિકેશનમાંથી પ્રોક્સી સેટિંગ દૂર કરો, અને કાર્ય કરતાં વધુ જીવે એવો સાંભળનાર છોડવાને બદલે સ્થાનિક પોર્ટ ગયો છે તેની ખાતરી કરો.