SSH ફોરવર્ડ ખરેખર કયો એપ ટ્રાફિક વહન કરે છે?

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

કંઈપણ તુલના કરતાં પહેલાં ઇન્ટરફેસનું નામ આપો

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

• શેલ: પ્રોગ્રામ દૂરસ્થ મશીન પર ચાલે છે, સ્થાનિક રીતે કંઈ સાંભળતું નથી.
• સ્થાનિક ફોરવર્ડ: તમારા લેપટોપમાં પોર્ટ છે, દૂરસ્થ હોસ્ટ બહાર જતું જોડાણ કરે છે.
• દૂરસ્થ ફોરવર્ડ: દૂરસ્થ બાજુમાં પોર્ટ છે, ટ્રાફિક તમારી તરફ પાછો આવે છે.
• ગતિશીલ: ક્લાયન્ટ પર SOCKS પ્રોક્સી, ફક્ત પ્રોક્સી-જાગૃત એપ્લિકેશન દ્વારા વપરાય છે.

આમાંથી કોઈ રૂટ સ્થાપિત કરતું નથી. એવો પ્રોગ્રામ જે પ્રોક્સી સેટિંગ્સને અવગણે છે, અથવા UDP બોલે છે, અથવા નામો જાતે ઉકેલે છે, તેના પર સક્રિય SSH સેશનની અસર થતી નથી. આ SSH માં ખામી નથી; આ તમે પસંદ કરેલા ઇન્ટરફેસનો વ્યાપ છે.

સ્થાનિક, દૂરસ્થ અને ગતિશીલ ફોરવર્ડ કોણ સાંભળે છે તેમાં અલગ પડે છે

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

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

પ્રથમ આદેશ લેપટોપ પર પોર્ટ 5432 બાંધે છે અને બાસ્ટિયનથી દેખાય તે રીતે તેને ડેટાબેઝ તરફ ફોરવર્ડ કરે છે. બીજો પોર્ટ 1080 પર SOCKS પ્રોક્સી બનાવે છે. ત્રીજો આદેશ પુષ્ટિ કરે છે કે કઈ પ્રક્રિયાઓ ખરેખર સાંભળે છે, અને તે જ એકમાત્ર પુરાવો છે કે ફોરવર્ડ અસ્તિત્વમાં છે, પોર્ટ અથડામણને કારણે શાંતિથી નિષ્ફળ ગયો નથી.

ગતિશીલ ફોરવર્ડિંગ પોતાની ચેતવણીને લાયક છે: તે ફક્ત એવી એપ્લિકેશનોને આવરી લે છે જે SOCKS નું સન્માન કરે છે. બ્રાઉઝરને તેની તરફ નિર્દેશિત કરી શકાય, કમાન્ડ-લાઇન સાધનને તેનો ઉપયોગ કરવા કહી શકાય, પરંતુ પોતાનું જોડાણ સ્ટેક ધરાવતું ડેટાબેઝ ડ્રાઇવર સામાન્ય રીતે કરી શકતું નથી. મશીન પરનો દરેક પ્રોગ્રામ હવે ટનલ વાપરે છે એવું માનવું એ આ આખા ક્ષેત્રની સૌથી સામાન્ય ભૂલ છે.

ટનલ-ઉપકરણ મોડ એ એકમાત્ર વાસ્તવિક નેટવર્ક અપવાદ છે

OpenSSH -w ટનલ-ઉપકરણ ફોરવર્ડિંગ પણ સમર્થન આપે છે, જે TCP શ્રોતાને બદલે પોઇન્ટ-ટુ-પોઇન્ટ ઇન્ટરફેસ પસાર કરે છે. તે ખરેખરું નેટવર્ક ટનલ છે, અને તે જાણી જોઈને ગોઠવાય છે, શેલ ખોલવાની આડઅસર નથી.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

તેને બંને છેડે ઉપલબ્ધ સંબંધિત ઇન્ટરફેસ નંબર, સર્વર પર યોગ્ય રૂપરેખાંકન અને ઉપકરણ બનાવવા માટે ક્લાયન્ટ પર પૂરતો અધિકાર જોઈએ. તેને સરનામાંકન અને રૂટિંગ યોજના પણ જોઈએ, કારણ કે નરી ઇન્ટરફેસ કયા લક્ષ્યોએ તેનો ઉપયોગ કરવો તે અંગે કોઈ નીતિ ધરાવતું નથી.

તો પણ ટનલ દૂરસ્થ હોસ્ટ પર સમાપ્ત થાય છે. SSH પરિવહને જે રક્ષણ આપ્યું તે ત્યાં સમાપ્ત થાય છે, અને આગળનું જોડાણ અલગ કૂદકો છે. VPN ગેટવેની સીમાનો પણ એ જ આકાર છે, તેથી તુલના વ્યાપ અને સમાપ્તિ વિશે હોવી જોઈએ, કયું સાધન વધુ મજબૂત છે તે વિશે નહીં. એ સીમાને મોટેથી નામ આપવાથી એ બહસ પણ પૂરી થાય છે કે ટનલ «બધું એન્ક્રિપ્ટ કરે છે» કે નહીં, કારણ કે તે સ્પષ્ટ રીતે કરતું નથી.

ચકાસો કે તમારી એપ તમે બનાવેલું ઇન્ટરફેસ વાપરે છે

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

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

પ્રથમ આદેશ હોસ્ટનામ દૂરથી ઉકેલાયેલું રહીને SOCKS અંતિમ બિંદુ દ્વારા વિનંતી મોકલે છે, અને બીજો TLS હજી જરૂરી રહેતાં ફોરવર્ડ કરેલા ડેટાબેઝ પોર્ટનો ઉપયોગ કરે છે. ફોરવર્ડ બંધ રાખીને એ જ પરીક્ષણો ચલાવો જેથી ખાતરી થાય કે તેઓ નિષ્ફળ જાય છે, કારણ કે બંને રીતે પાસ થતું પરીક્ષણ ક્યારેય ટનલ વાપરતું ન હતું.

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