TLS VPN વિરુદ્ધ IPsec: ચકાસવા લાયક પાંચ ક્ષેત્રો
TLS VPN અને IPsec VPNની સરખામણી રિલીઝ, પ્રોટોકોલ આવૃત્તિ, સ્યૂટ, સહભાગી ઓળખ અને ખુલ્લા અવકાશના આધારે કરો, સાથે તમે ખરેખર રૂપરેખાંકિત કરેલા નિષ્ફળતા-પરિણામના આધારે.
TLS VPNને IPsec VPN સાથે પ્રોટોકોલ પરિવારના આધારે ક્રમબદ્ધ કરવું એ કોઈએ ન પૂછેલા પ્રશ્નનો જવાબ આપે છે, અને સામાન્ય રીતે એવી રચના ટાંકે છે જે બંને પરિવારોએ વર્ષો પહેલાં છોડી દીધી હતી. સમીક્ષક ખરેખર જેનું મૂલ્યાંકન કરી શકે તે છે વાટાઘાટથી નક્કી થયેલું રક્ષણ, સહભાગીની ઓળખ, ક્લાયન્ટ મોડેલ અને ખુલ્લી સેવા. આ ચાર વસ્તુઓ તૈનાતીમાં દેખાય છે, અને તેમાંથી કોઈ પણ ઉત્પાદનના લેબલમાંથી આવતી નથી. પાંચ ક્ષેત્રો માંગો અને વાતચીત ઠોસ બને છે.
પાંચ ક્ષેત્રો, અને લેબલ તેમાંથી એક નથી
પ્રથમ ક્ષેત્ર સમર્થિત સોફ્ટવેર રિલીઝ છે, કારણ કે આવૃત્તિ વગર પ્રોટોકોલનું વર્ણન જાહેરાત પુસ્તિકા છે. બીજું વાટાઘાટથી નક્કી થયેલી પ્રોટોકોલ આવૃત્તિ છે, જે નક્કી કરે છે કે કઈ રચનાઓ ઉપલબ્ધ છે. ત્રીજું રક્ષણ સ્યૂટ છે, ચોથું સહભાગી અને વપરાશકર્તા બંને માટે પ્રમાણીકરણ પદ્ધતિ છે, અને પાંચમું એ પ્રવેશ અવકાશ છે જે ઉત્પાદન પ્રવેશ પછી આપે છે.
SSL VPN લેબલ ઓછામાં ઓછા ત્રણ અલગ ઉત્પાદનોને આવરે છે: સંપૂર્ણ નેટવર્ક ક્લાયન્ટ, એપ્લિકેશન પ્રોક્સી અને બ્રાઉઝર આધારિત જૂનું પોર્ટલ. તેઓ અલગ સેવાઓ ખોલે છે અને અલગ રીતે નિષ્ફળ જાય છે, તેથી લેબલ અવકાશના ક્ષેત્રને બદલી શકતું નથી.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
પ્રમાણિત એન્ક્રિપ્શન ખરેખર શું બદલે છે
TLS 1.3 પ્રમાણિત એન્ક્રિપ્શન ફરજિયાત કરે છે, જે જૂની MAC-then-encrypt રચનાને વૈકલ્પિક રાખવાને બદલે પ્રોટોકોલમાંથી દૂર કરે છે. IPsec ESPમાં પણ તેટલા સમયથી પ્રમાણિત એન્ક્રિપ્શન સ્યૂટ છે, અને AES-GCM તેના પોતાના RFCમાં વ્યાખ્યાયિત છે. બંને પરિવારોમાં ગેરંટી પરિવારના નામથી નહીં પણ વાટાઘાટથી નક્કી થયેલા સ્યૂટથી આવે છે, તેથી ક્ષેત્રોની યાદી આવૃત્તિથી શરૂ થાય છે. જે સમીક્ષક સ્યૂટનું નામ ન કહી શકે તેની પાસે મૂલ્યાંકન માટે કંઈ નથી.
તેથી ઐતિહાસિક સરખામણી ભ્રામક છે. CBC સ્યૂટ સાથે જૂની TLS આવૃત્તિ પર પિન કરેલી તૈનાતી અને AEAD સ્યૂટ સાથે TLS 1.3 ચલાવતી તૈનાતી એકસરખી સુરક્ષા સ્થિતિ નથી, જોકે બંને TLS VPN છે. એ જ વિભાજન IPsec બાજુ પર આધુનિક ESP સ્યૂટ અને જૂના સંયોજન વચ્ચે પણ છે.
તમારા ઇરાદાની રૂપરેખા નહીં, વાટાઘાટથી નક્કી થયેલા મૂલ્યો વાંચો. નીચેના આદેશો દર્શાવે છે કે જીવંત અંતિમ બિંદુ અને જીવંત ટનલ ખરેખર શે પર સંમત થયા.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasજો અંતિમ બિંદુ TLS 1.3 પર વાટાઘાટ કરવા ન ઇચ્છે તો તે એક નિષ્કર્ષ છે, પ્રાધાન્ય નહીં. જો ટનલ એવો સ્યૂટ સૂચિબદ્ધ કરે જેની તમે અપેક્ષા નહોતી રાખી, તો મહત્ત્વની રૂપરેખા તે છે જે સહભાગીઓએ પસંદ કરી, ટેમ્પલેટની નહીં.
સહભાગીની ઓળખ એ અલગ પ્રશ્ન છે
ચકાસાયેલા સહભાગી વગર એન્ક્રિપ્શન ટ્રાફિકને નિરીક્ષકોથી બચાવે છે અને જેણે જોડાણનો જવાબ આપ્યો તેને સોંપે છે. સહભાગી પ્રમાણીકરણ પૂછે છે કે કઈ ઓળખની અપેક્ષા છે, કઈ વિશ્વાસ સામગ્રી તેને પ્રમાણિત કરે છે, અને જવાબ ન મળે ત્યારે ક્લાયન્ટ કેવી રીતે વર્તે છે. પ્રમાણપત્ર શૃંખલા, પિન કરેલી કી અને પહેલેથી વહેંચાયેલું રહસ્ય ત્રણ અલગ જવાબો છે જેની ત્રણ અલગ કાર્યકારી કિંમત છે.
પછી વપરાશકર્તા કે ઉપકરણ વિશે એ જ પ્રશ્નો પૂછો. જે ગેટવે મશીનનું પ્રમાણીકરણ કરી કોઈપણ વપરાશકર્તાને પ્રવેશ આપે, અથવા ઊલટું, તેની એક વિશિષ્ટ સ્થિતિ છે જે લખવી જોઈએ, ધારવી નહીં. પ્રવેશ પછી લાગુ થતી સંસાધન પરવાનગીઓ એ જ ક્ષેત્રનો ભાગ છે, કારણ કે પ્રમાણીકરણ અધિકૃતિ નથી.
હોસ્ટનામ અને પ્રમાણપત્ર તપાસ જાળવવી લોગિન વિંડોની પરિચિતતા કરતાં વધુ મહત્ત્વની છે. ચકાસણી અવગણવા રૂપરેખાંકિત ક્લાયન્ટે એ એકમાત્ર પગલું દૂર કર્યું છે જે તમારા ગેટવેને વિશ્વાસપાત્ર નકલથી અલગ પાડે છે.
ઉત્પાદન જે સીમા ખોલે છે
ક્લાયન્ટવિહીન પોર્ટલ પસંદ કરેલી એપ્લિકેશન ક્રિયાઓને ગેટવે દ્વારા પ્રોક્સી કરે છે, તેથી વપરાશકર્તા નેટવર્કને બદલે ઇન્ટરફેસ સુધી પહોંચે છે. સંપૂર્ણ-ટનલ ક્લાયન્ટ જે તેના રૂટ અને ફિલ્ટરિંગ નીતિ પસંદ કરે તે વહન કરે છે, જે ઘણી મોટી સપાટી છે. બંનેની તુલના પ્રોટોકોલ શક્તિ પર કરવાથી હુમલાખોર તેમના દ્વારા શું પહોંચી શકે તેનો તફાવત ચૂકી જાય છે. એક એપ્લિકેશન ઇન્ટરફેસ ખોલે છે, બીજું રૂટ કરેલું નેટવર્ક, અને બંને અલગ સમીક્ષાઓ માંગે છે.
પૂછો કે કઈ સેવા ખુલ્લી છે, કઈ ક્રિયાઓ અધિકૃત છે અને ગેટવે પોતે શું સાંભળે છે. વપરાશકર્તા પોર્ટલના એ જ સરનામેથી પહોંચી શકાય તેવું વ્યવસ્થાપન ઇન્ટરફેસ તૈનાતીનો નિષ્કર્ષ છે, અને કોઈ પ્રોટોકોલ પસંદગી તેની ભરપાઈ કરતી નથી.
પ્રતિ-એપ્લિકેશન અવકાશ સપાટીને વધુ મર્યાદિત કરે છે, અને ટનલ પડે ત્યારે નિષ્ફળતાનું વર્તન પણ બદલે છે. સંપૂર્ણ-ટનલ પહોંચ ધારી લેતી રચના એવી રીતે તૂટે છે જે પ્રતિ-એપ રચના જાણતી નથી, અને સહાય ભાર તેની પાછળ આવે છે.
નિષ્ફળતાનું પરિણામ અને જીવનચક્ર નક્કી કરો
જ્યારે પ્રમાણીકરણ કે રક્ષણ ઉપલબ્ધ ન હોય ત્યારે શું થાય તે નીતિ નિર્ણય છે જે સમીક્ષામાં આવે છે. અવરોધિત પરિણામ અને ઘોષણા વગરનું સીધું પાછું જવું અલગ પરિણામો ધરાવે છે, અને તફાવત લક્ષણ યાદીમાં અદૃશ્ય છે. ઇચ્છિત વર્તન તે જે સંસાધનનું રક્ષણ કરે છે તેની બાજુમાં લખો.
ગેટવેનું પેચ અને સહાય જીવનચક્ર, તેની સક્રિય બાહ્ય સુવિધાઓ અને ક્લાયન્ટ માટે અદ્યતન માર્ગ સમાવો. સાચી પ્રોટોકોલ પસંદગી ખરાબ તૈનાત સેવાને સુરક્ષિત બનાવતી નથી, અને મોટાભાગની ઘટનાઓ સ્યૂટમાં નહીં પણ તે જ અંતરમાં જીવે છે.
પાંચ ક્ષેત્રો, નિષ્ફળતા નીતિ અને જીવનચક્રનો માલિક એક પૃષ્ઠ પર લખો. તે પૃષ્ઠ એક સમીક્ષા છે; પ્રોટોકોલ પરિવારોની સરખામણી એક અભિપ્રાય છે.