HTTP પ્રોક્સી, SSH ટનલ કે VPN: યોગ્ય સ્તર પસંદ કરો

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

બે હકીકતોથી નિર્ણય કરો: કયા પ્રોટોકોલ પસાર થવા જોઈએ અને સંબંધિત નામો કોણ ઉકેલી શકે। બાકી બધું પસંદગી છે।

પ્રોક્સી ફક્ત તે જ ખસેડે છે જે તે સમજે છે

વેબ પ્રોક્સી જે પ્રોટોકોલ માટે બન્યું છે તેનું વિશ્લેષણ કરે છે। ક્લાયન્ટ તેને વિનંતી આપે છે અને તે તે વિનંતી આગળ મોકલે છે, તેથી પ્રોક્સી સેટિંગ વગરની એપ્લિકેશન બિલકુલ ભાગ લેતી નથી। HTTPS માટે ક્લાયન્ટને અપારદર્શક ચેનલ જોઈએ છે, જે પ્રોક્સી CONNECT દ્વારા પૂરી પાડે છે, વિનંતી વાંચીને નહીં।

SSH ડાયનેમિક ફોરવર્ડ સ્થાનિક પોર્ટ ખોલે છે જે SOCKS બોલે છે, અને તે પોર્ટ TCP પ્રવાહને ક્લાયન્ટ નામ આપે તે કોઈપણ લક્ષ્ય પર મોકલે છે। TCP પર બનેલા પ્રોટોકોલ સામાન્ય રીતે તેનાથી કામ કરે છે। UDP નહીં, સિવાય કે કોઈ સાધન સ્પષ્ટ રીતે આધાર ઉમેરે। સ્થાનિક ફોરવર્ડ વધુ સાંકડું છે: એક સ્થાનિક પોર્ટ એક નિશ્ચિત હોસ્ટ અને પોર્ટ પર મેપ, જે એક જાણીતી સેવા પૂરી પાડે છે અને વધુ કંઈ નહીં।

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN પેકેટ ખસેડે છે। ક્લાયન્ટ ટનલમાં જે મોકલે છે તે બધું તેમાંથી પસાર થાય છે, UDP અને ICMP સહિત, તેથી તે એક જ કનેક્શનને બદલે નેટવર્કની જરૂરિયાતને અનુરૂપ છે।

કોઈએ નામ ઉકેલવું પડશે

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

curl વિભાજન સ્પષ્ટ બતાવે છે: એક ફ્લેગ હોસ્ટનામ પ્રોક્સીને આપે છે, બીજો તેને પહેલા સ્થાનિક રીતે ઉકેલે છે। સ્થાનિક ઉકેલ સાથે ફક્ત-આંતરિક નામ કોઈપણ ટનલને સ્પર્શ કરવા પહેલા નિષ્ફળ જાય છે, અને ભૂલ પ્રોક્સીને તે વાતનો દોષ આપે છે જે ખરેખર DNS નિર્ણય હતો।

VPN ત્રીજો માર્ગ લે છે: રૂટની બાજુમાં ખાનગી રિઝોલ્વર અને શોધ ડોમેન સ્થાપિત કરીને। તે અનુકૂળ છે, અને તે પરિચિત ભ્રમ ઉભો કરે છે: જે રૂટ અસ્તિત્વમાં છે પણ રિઝોલ્વર જવાબ આપતું નથી તે મૃત ટનલ જેવો જ દેખાય છે, જોકે પેકેટ બીજી બાજુ પહોંચે છે।

જ્યારે નેટવર્ક ફક્ત એક જ નિકાસની મંજૂરી આપે

ઘણા કોર્પોરેટ નેટવર્ક બહાર જતા કનેક્શન ફક્ત પ્રમાણિત વેબ પ્રોક્સી દ્વારા મંજૂર કરે છે। OpenVPN અને SSH બંનેને ત્યાં ચલાવી શકાય છે, પ્રથમ પોતાનું પરિવહન પ્રોક્સી દ્વારા ટનલ કરીને અને બીજું પ્રોક્સી આદેશ દ્વારા જે નાનું CONNECT સહાયક ચલાવે છે।

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

મધ્યસ્થોને સાંકળવું એ સ્તર પસંદ કરવાથી જુદો પ્રશ્ન છે। બીજું પ્રોક્સી અથવા Tor ઉમેરવાથી બદલાય છે કે કોણ શું નિરીક્ષણ કરે છે, અને સાંકળમાં સ્થાન નક્કી કરે છે કે કયો હોપ સાઇફરટેક્સ્ટ જુએ છે।

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

બનાવટી સરનામું વિકલ્પોમાંનો એક નથી

બીજાના સ્રોત સરનામા સાથે પેકેટ બનાવવાથી કંઈ ઉપયોગી મળતું નથી: જવાબો ખરા માલિક પાસે જાય છે, અને મોટાભાગના નેટવર્ક ટ્રાફિક સીધો કાઢી નાખે છે। મધ્યસ્થ જરૂરી છે કારણ કે સ્રોત શોધી શકાતો નથી, અને તે ત્રણેય રચનાઓનું પ્રામાણિક સમર્થન છે।

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

પ્રોટોકોલ અને નામોથી નિર્ણય કરો

પ્રોક્સી પસંદ કરો જ્યારે એક વેબ ક્લાયન્ટને એક વેબ સેવા જોઈએ અને તેની પાસે પ્રોક્સી સેટિંગ હોય। SSH ટનલ પસંદ કરો જ્યારે થોડી જાણીતી TCP સેવાઓ પૂરતી હોય અને SSH પ્રવેશ પહેલેથી હોય। VPN પસંદ કરો જ્યારે ઘણી એપ્લિકેશન, બિન-TCP ટ્રાફિક, ખાનગી DNS અથવા ફરી વાપરી શકાય તેવો માર્ગ જરૂરિયાતનો ભાગ હોય।

પછી ખરા ક્લાયન્ટ અને ખરા નામ સાથે ચકાસો। પ્રોક્સી દ્વારા પૃષ્ઠ લોડ કરવાથી UDP વિશે કંઈ શીખવા મળતું નથી, અને એક સાધન SOCKS પર ચલાવવાથી સિસ્ટમ રિઝોલ્વર વિશે કંઈ શીખવા મળતું નથી। વાંચો કે પ્રક્રિયાએ કયા સ્થાનિક સરનામે બાંધ્યું અને કયા રિઝોલ્વરે જવાબ આપ્યો। કામ કરતા માર્ગ અને એક વાર સંજોગવશાત કામ કરેલા માર્ગ વચ્ચેનો આ જ ફરક છે।