તમારા VPN પર SOCKS પ્રોક્સી તરીકે SSH ગતિશીલ ફોર્વર્ડિંગ
ફક્ત SOCKS બોલતી એપ્લિકેશન પાસે સામાન્ય VPN પર કોઈ પ્રોક્સી એન્ડપોઈન્ટ નથી. બે હોપ, એક લૂપબેક શ્રોતા અને એક નામ શોધ જે SSH સર્વરે જાતે કરવી પડે.
ફક્ત SOCKS બોલતી એપ્લિકેશન પાસે સામાન્ય VPN પર વાત કરવા માટે કંઈ નથી, કારણ કે ટનલ પેકેટ વહન કરે છે અને એપ્લિકેશનને પ્રોક્સી એન્ડપોઈન્ટ જોઈએ છે. OpenSSH તે એન્ડપોઈન્ટ પૂરું પાડી શકે જ્યારે ઍક્સેસનો માલિક પરવાનગી આપે, કારણ કે ગતિશીલ ફોર્વર્ડિંગ એક SSH સત્રને સ્થાનિક પ્રોક્સીમાં ફેરવે છે. પછી બે હોપ અલગ રાખવા પડે: જે ટનલ SSH હોસ્ટ સુધી પહોંચે છે, અને તે હોસ્ટ પછીથી જે જોડાણ ખોલે છે. તેમને અલગ કરવાથી સમજાય છે કે આ ગોઠવણ કેમ કામ કરે છે અને તે ક્યારેય શું નહીં કરે.
SSH શ્રોતા શું બને છે અને શું નહીં
ગતિશીલ ફોર્વર્ડિંગ SSH ક્લાયન્ટને સ્થાનિક રીતે સાંભળવા અને જે પણ જોડાય તેની સાથે SOCKS4 અથવા SOCKS5 બોલવા મજબૂર કરે છે. દરેક વિનંતી એક ગંતવ્યનું નામ આપે છે અને SSH સર્વર આગળનું જોડાણ ખોલે છે, તેથી ગંતવ્યની શોધ દૂરના છેડે થઈ શકે છે. આ એપ્લિકેશન સ્તરનું TCP ફોર્વર્ડિંગ છે, આખા ઉપકરણ માટે VPN નથી. તે કોઈ UDP સંગઠન, કોઈ ICMP, અને પ્રોક્સી સેટિંગ્સ સંપૂર્ણ અવગણતી એપ્લિકેશનો માટે કંઈ પણ વહન કરતું નથી. SSH સર્વરથી એપ્લિકેશન સુધીનો હોપ પણ તમારી ટનલની અંદર નથી, જે ત્યારે મહત્વનું છે જ્યારે ગંતવ્ય ફક્ત જાણીતા નેટવર્કમાંથી ટ્રાફિક સ્વીકારે છે.
પૂર્વશરતો વાસ્તવિક છે: SSH હોસ્ટ સુધીનો રૂટ, અધિકૃત ખાતું, ચકાસાયેલ સર્વર હોસ્ટ કી અને ફોર્વર્ડ કરવાની પરવાનગી. તેમાંથી કંઈ પણ પ્રોક્સી બનાવતું નથી, અને છેલ્લી સામાન્ય રીતે પ્રથમ ખૂટે છે. બીજું કંઈ ડિબગ કરતા પહેલાં ચારેયની પુષ્ટિ કરો, કારણ કે ક્લાયન્ટ તરફથી નિષ્ફળતા એકસરખી દેખાય છે, ગમે તે ખૂટે.
તેને સ્પષ્ટ પોર્ટ સાથે લૂપબેક પર શરૂ કરો
વણવપરાયેલ સ્થાનિક પોર્ટ પસંદ કરો અને સરનામું બાકી રાખવાને બદલે તેને સ્પષ્ટ રીતે લૂપબેક સાથે બાંધો. નીચેના ત્રણ વિકલ્પો દરેક એક કારણસર અસ્તિત્વમાં છે.
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N દૂરના આદેશને છોડે છે અને -T સ્યુડો-ટર્મિનલ છોડે છે, તેથી સત્ર ફક્ત ફોર્વર્ડ કરવા માટે છે. ExitOnForwardFailure શ્રોતા બની ન શકે ત્યારે ક્લાયન્ટને બહાર નીકળવા દે છે, તમે માંગેલા ફોર્વર્ડિંગ વગર ચાલવાને બદલે. ControlPath=none સત્રને હાલના મલ્ટિપ્લેક્સ જોડાણની બહાર રાખે છે જે પોતાના ફોર્વર્ડિંગ ઉમેરી શકે. લૂપબેક શ્રોતાને LAN ની બહાર રાખે છે, પરંતુ વહેંચાયેલ મશીન પર તે અધિકૃતિની સીમા નથી, કારણ કે અન્ય સ્થાનિક પ્રક્રિયાઓ પણ તેને પહોંચી શકે છે. OpenSSH ક્લાયન્ટ સંદર્ભ આ બધા ફ્લેગનું દસ્તાવેજીકરણ કરે છે, અને લૂપબેક ચેતવણી સાંભળતું સોકેટ શું છે તેના પરથી આવે છે.
નામોને પ્રોક્સીમાંથી મોકલો, તેની આસપાસથી નહીં
SOCKS5 ક્લાયન્ટ ગંતવ્ય જાતે ઉકેલી શકે અથવા પ્રોક્સીને એ કરવા કહી શકે, અને આ પસંદગી નક્કી કરે છે કે કયો રિઝોલ્વર જવાબ આપશે. socks5h સાથે curl હોસ્ટનામ પ્રોક્સીમાંથી મોકલે છે, તેથી શોધ SSH સર્વર પર થાય છે. સાદા socks5 સાથે લેપટોપ પહેલા ઉકેલે છે અને ફક્ત જોડાણ જાય છે, જે નામ આંતરિક હોય ત્યારે હેતુ ચૂપચાપ નિષ્ફળ કરે છે. નીચેની વિનંતી નો-પ્રોક્સી યાદી પણ સાફ કરે છે, તેથી વારસાગત NO_PROXY મૂલ્ય તેને પ્રોક્સીની આસપાસ લઈ જઈ શકતું નથી.
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthપ્રમાણપત્ર ચકાસણી અને એપ્લિકેશનનું પોતાનું લૉગિન હજી લાગુ પડે છે, કારણ કે પ્રોક્સી બંનેમાંથી એકને પણ બદલતું નથી. બે શોધ બાકી રહે છે: લેપટોપે અનુમતિપ્રાપ્ત VPN અને DNS માર્ગ દ્વારા SSH હોસ્ટ સુધી પહોંચવું પડે, અને SSH સર્વરે એપ્લિકેશનનું નામ જાતે ઉકેલવું પડે. બીજાને કોઈ ટ્રાફિક પ્રોક્સીમાંથી પસાર થાય તે પહેલાં અલગથી ચકાસી શકાય છે.
ssh [email protected] getent hosts app.corp.exampleએક મંજૂર ગંતવ્ય સાબિત કરો, પછી સત્ર બંધ કરો
નીતિ જે ગંતવ્યને મંજૂરી આપે છે અને જેને નકારવું જોઈએ તે બંને ચકાસો, કારણ કે કામ કરતું ફોર્વર્ડિંગ ફક્ત એ સાબિત કરે છે કે શ્રોતા કામ કરે છે, વધુ કંઈ નહીં. એપ્લિકેશન SSH સર્વર જે સ્રોત સરનામું પસંદ કરે છે તે જુએ છે, અને તે તમારા લેપટોપનું ટનલ સરનામું નથી. જ્યાં દૂરનો છેડો સ્રોત પ્રમાણે જોડાણો લોગ કરે છે, ત્યાં વિનંતી નકારાય ત્યારે તે ફરક પ્રથમ તપાસવાની વસ્તુ છે.
સત્રને તેની માલિકી ધરાવતી પ્રક્રિયા દ્વારા રોકો, અસંબંધિત શેલ મારીને નહીં. પછી ખાતરી કરો કે શ્રોતા ગયો છે, કારણ કે હજી જવાબ આપતો પોર્ટ એ એવું સત્ર છે જે તમે ખરેખર બંધ નથી કર્યું. ફક્ત આ કવાયતે દાખલ કરેલી પ્રોક્સી સેટિંગ દૂર કરો, અને એપ્લિકેશન કન્ફિગરેશનનો બાકીનો ભાગ અકબંધ રાખો. ફોર્વર્ડિંગ નિયમ ધરાવતું બિનદેખરેખ ટર્મિનલ સેવા નથી, અને કાયમી પ્રોક્સીને મંજૂર જીવનચક્રની જરૂર છે, ભૂલાયેલી વિન્ડોની નહીં.
ss -ltn | grep 1080એ નિષ્ફળતાઓ જે આ ગોઠવણ સુધારી શકતી નથી
કેટલાક લક્ષણો ઉપરની મર્યાદાઓ તરફ સીધા ઈશારો કરે છે, અને તેમને વહેલા ઓળખવાથી પ્રોક્સી ડિબગિંગની એક બપોર બચે છે. કોષ્ટક તમે જે જુઓ છો તેને તે સામાન્ય રીતે શું અર્થ ધરાવે છે તેની સાથે જોડે છે. છેલ્લા કૉલમમાંનું કંઈ પણ કન્ફિગરેશન ભૂલ નથી, ડિઝાઇનનો પ્રશ્ન છે.
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
પ્રથમ ત્રણ પંક્તિઓ એ છે જે લોકો ખોટી રીતે નિદાન કરે છે, કારણ કે દરેક પ્રોક્સી વિશેની ભૂલને બદલે જોડાણનો પ્રયાસ ઉત્પન્ન કરે છે. લેપટોપ પર ઉકેલાતું નામ સર્વરના રિઝોલ્વર વિશે કંઈ કહેતું નથી, અને નિષ્ફળતા તેના બદલે પ્રમાણપત્ર કે ટાઇમઆઉટ સમસ્યા તરીકે વંચાય છે. ફક્ત UDP વાળી એપ્લિકેશનો ડિઝાઇનની બહાર ઊભી રહે છે, તેની અંદર તૂટેલી નહીં, અને કોઈ વધારાનો ssh વિકલ્પ તેને બદલતો નથી. બ્રાઉઝર પંક્તિ એ સામાન્ય યાદ છે કે પ્રોક્સી સેટિંગ્સ દરેક એપ્લિકેશન માટે અલગ હોય છે. છેલ્લી પંક્તિ એ કારણ છે કે બંધ કરવાની ચકાસણી કેમ છે: હજી સાંભળતો પોર્ટ એટલે કે હવે બીજું કંઈ તેનું માલિક છે.