SSL VPN કે TLS આવરણ? જે સીમા નિષ્ફળ ગઈ તેની સરખામણી કરો

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

તમે ખરેખર ગોઠવેલા જોડાણથી શરૂ કરો

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

નેટવર્ક ડિઝાઇનનો કરાર અલગ છે, અને તે માર્ગો અને નીતિમાં વ્યક્ત થાય છે, પોર્ટ જોડીમાં નહીં.

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

આવરણ શેનાથી જોડાય છે તે ચકાસો

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

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

openssl s_client -connect wrapper.lab.example:443 -servername wrapper.lab.example -verify_return_error
sudo ss -ltnp | grep 443

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

ડિઝાઇન કયો ટ્રાફિક વહન કરે છે તે ચકાસો

નેટવર્ક-ઍક્સેસ ડિઝાઇન પસંદ કરેલો ટ્રાફિક વહન કરે છે અને ક્લાયન્ટના રૂટિંગ અને ઍક્સેસ નીતિ સાથે જોડાય છે. પ્રવેશ એ અધિકૃતિ નથી, તેથી પ્રમાણીત જોડાણને હજી પણ કઈ સંસાધનો સુધી પહોંચી શકે તે અંગે નિર્ણય જોઈએ. ક્લાયન્ટ વગરનું પોર્ટલ ત્રીજું મોડેલ છે જે સમર્થિત ક્રિયાઓને પ્રોક્સી કરે છે પણ ક્યારેય tun ઇન્ટરફેસ તરીકે દેખાતું નથી.

ઉત્પાદનનું લેબલ કહેતું નથી કે તમે આમાંથી કયું મોડેલ ખરીદ્યું, અને પોર્ટ નંબર તો વધુ ઓછું કહે છે.

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

નિષ્ફળ સીમા ચકાસો, લેબલ નહીં

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

પોર્ટ 443 એક પરંપરા છે જે TLS ને વચ્ચેના બૉક્સમાંથી પસાર થવા દે છે. તે મનસ્વી ટ્રાફિકને નીતિ ઉપકરણ માટે વેબ વિનંતી જેવો બનાવતું નથી.

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