SSL VPN અને સાઇટ-થી-સાઇટ VPN એકબીજાના વિરોધી કેમ નથી
SSL VPN અને સાઇટ-થી-સાઇટ VPN જુદા જુદા અક્ષો વર્ણવે છે: કોણ નેટવર્કમાં જોડાય છે અને ટનલ કેવી રીતે બને છે. બંનેને એકસાથે નામ આપવું એ શ્રેણીની ભૂલ છે.
બે એડમિનિસ્ટ્રેટરને એક જ VPN વર્ણવવાનું કહો; એક કદાચ “SSL VPN” કહેશે જ્યારે બીજો “સાઇટ-થી-સાઇટ” કહેશે, જાણે બંને મેનુમાં સ્પર્ધાત્મક વિકલ્પો હોય. આ જુદા જુદા પ્રશ્નોના જવાબો છે, અને તેમને વિકલ્પો તરીકે ગણવાથી એવી સરખામણીઓ ઊભી થાય છે જે ઉકેલી શકાતી નથી. એક લેબલ કહે છે કે કયા અંતિમ બિંદુઓ જોડાય છે; બીજું કહે છે કે તેમની વચ્ચે ટ્રાફિક શું લઈ જાય છે. અક્ષોને અલગ રાખો અને દલીલનો મોટો ભાગ અદૃશ્ય થઈ જશે.
બે લેબલ, બે અલગ પ્રશ્નો
ટોપોલોજી જવાબ આપે છે કે કોણ કોની સાથે જોડાય છે. રિમોટ-એક્સેસ ડિઝાઇન વ્યક્તિગત વપરાશકર્તાઓ કે ઉપકરણોને ગેટવે સાથે જોડે છે, સામાન્ય રીતે પ્રતિ-વપરાશકર્તા ઓળખ અને સરનામાંઓના પૂલ સાથે. સાઇટ-થી-સાઇટ ડિઝાઇન બે નેટવર્કને ગેટવે દ્વારા જોડે છે, તેથી રસપ્રદ ઓળખ સાથી ગેટવે છે, કીબોર્ડ પાસેની વ્યક્તિ નહીં. આ જુદી જુદી ઓપરેશનલ સમસ્યાઓ છે, સરનામાં આયોજનથી લઈને રાત્રે 2 વાગ્યે કોણ ઍક્સેસ રદ કરી શકે છે તે સુધી.
મેકેનિઝમ જવાબ આપે છે કે ટનલ કેવી રીતે બને છે અને પ્રમાણિત થાય છે. IKEv2 સાથે IPsec, અંદર IP વહન કરતું TLS-આધારિત ઉત્પાદન, અને બ્રાઉઝર તરફનું એપ્લિકેશન પોર્ટલ એ મેકેનિઝમની પસંદગીઓ છે, અને દરેકની પોતાની વાટાઘાટ, સાઇફર સ્યુટ અને નિષ્ફળતાના પ્રકારો છે. તેમાંથી કોઈ ટોપોલોજી સૂચવતું નથી, અને ટોપોલોજી મેકેનિઝમ પસંદ કરતી નથી.
બે અક્ષોને એક કોષ્ટકમાં મૂકો અને ગૂંચવણ દેખાય છે, કારણ કે ગ્રીડનો દરેક કોષ ભરી શકાય છે. ગ્રીડ જે કરી શકતું નથી તે તમને કહેવું કે તમારા વિક્રેતાએ કયું સંયોજન આપ્યું, કારણ કે ઉત્પાદનના નામ બંને અક્ષોને એક માર્કેટિંગ શબ્દસમૂહમાં સંકોચી નાખે છે.
શ્રેણીની ભૂલ ક્યાંથી આવે છે
વિક્રેતાઓએ વર્ષો સુધી “SSL VPN” ને “IPsec VPN” ના વિરોધી તરીકે વેચ્યું, જેનાથી મેકેનિઝમની સરખામણી ટોપોલોજીની પસંદગી જેવી લાગી. આ શબ્દસમૂહ પોતાની શરતો પર પણ ખરાબ રીતે જૂનો થઈ ગયો છે, કારણ કે હાલની ડિઝાઇન સમર્થિત TLS આવૃત્તિઓ વાપરે છે અને SSL નામ મુખ્યત્વે ઉત્પાદન-શ્રેણી તરીકે ટકી રહ્યું છે.
| Axis | Question it settles | What it cannot tell you |
|---|---|---|
| Topology | Whether users join a gateway or two networks join each other | Which protocol carries the traffic, or how peers prove identity |
| Mechanism | Which protocol suite builds the tunnel and negotiates keys | Whether the endpoints are people, devices or routers |
| Access surface | Whether the client sees a routed network or a set of published applications | Which topology or mechanism is underneath the portal |
| Authentication | What proof each side presents, and to whom | Whether the traffic is later authorized per resource |
એ જ સંકોચનથી બે સંબંધિત દંતકથાઓ આવે છે. પ્રથમ એ છે કે IPsec એટલે સાઇટ-થી-સાઇટ; IKEv2 ક્લાયન્ટ-થી-ગેટવે સંબંધો માટે પણ રચાયું હતું, તેથી એકલ લેપટોપ IPsec સાથે જોડાઈ શકે છે. બીજી એ છે કે TLS-આધારિત ઉત્પાદન એટલે ફક્ત રિમોટ એક્સેસ; OpenVPN નિયમિતપણે બે સાઇટ વચ્ચે ટ્રાફિક લઈ જવા માટે વપરાય છે, અને તેનો TLS ઉપયોગ બ્રાઉઝર સેશનમાં નહીં, પરંતુ નિયંત્રણ અને પ્રમાણીકરણની આપલેમાં કેન્દ્રિત છે.
કોઈપણ વર્ણન માટે ઉપયોગી કસોટી: એક શબ્દ બદલવાથી જો અંતિમ બિંદુઓ અને પ્રોટોકોલ બંને બદલાય, તો વાક્ય અક્ષોને મિશ્ર કરે છે. “SSL VPN વિરુદ્ધ સાઇટ-થી-સાઇટ” આ કસોટીમાં નિષ્ફળ જાય છે, કારણ કે પ્રથમ પદ મેકેનિઝમ-કુટુંબનું નામ આપે છે અને બીજું ટોપોલોજીનું.
અમલીકરણનું વર્ણન એ રીતે કરો કે તેની સરખામણી થઈ શકે
ચાર ખાનાં લખો અને ભરો: અંતિમ બિંદુઓ, મેકેનિઝમ, પ્રમાણીકરણ અને ઍક્સેસ-સપાટી. શાખા-લિંકને બે નામાંકિત પ્રીફિક્સ વચ્ચે પ્રમાણપત્ર-પ્રમાણીકરણ સાથે અને વપરાશકર્તા-સ્તરીય પોર્ટલ વિના IKEv2 ગેટવે-જોડી તરીકે વાંચી શકાય. રિમોટ-એક્સેસ સેવાને પ્રતિ-વપરાશકર્તા સરનામાં ફાળવતી, લૉગિન વખતે બીજું પરિબળ માગતી અને ફક્ત આંતરિક DNS ઝોન પ્રકાશિત કરતી TLS-આધારિત ક્લાયન્ટ તરીકે વાંચી શકાય.
આ વાક્યો એ રીતે સરખાવી શકાય છે જે રીતે ઉત્પાદનનાં નામ નથી. બે રિમોટ-એક્સેસ ડિઝાઇન સમાન વપરાશકર્તા-કાર્યપ્રવાહ અને સમાન રદ-માર્ગ સામે માપી શકાય, અને બે આંતર-સાઇટ ડિઝાઇન સમાન પ્રીફિક્સ-યાદી, ટ્રાફિક નીતિ અને નિષ્ફળતાની આવશ્યકતાઓ સામે. લેબલ સરખામણીને ગોઠવે છે; તેનું સ્થાન લેતાં નથી.
શબ્દાવલીનો પ્રકાશિત આધાર પણ છે. IETF નું VPN શબ્દાવલી દસ્તાવેજ અનેક સેવા-નમૂનાઓ, જેમાં રિમોટ એક્સેસ અને સાઇટ-થી-સાઇટનો સમાવેશ થાય છે, તેમને બનાવવા માટે વપરાતા મેકેનિઝમથી અલગ પાડે છે, અને તે જ એ ભેદ છે જે વારંવાર ખોવાઈ જાય છે.
વાટાઘાટ થયેલો પ્રોટોકોલ વાંચો, ઉત્પાદનનું નામ નહીં
બોક્સ પરનું લેબલ નક્કી કરતું નથી કે ચાલતી ટનલ શેના પર સંમત થઈ છે. TLS બાજુએ સીધા સાથીને પૂછો અને બ્રોશરની આવૃત્તિને બદલે હેન્ડશેએ ઉત્પન્ન કરેલ પ્રોટોકોલ આવૃત્તિ અને સાઇફર વાંચો.
openssl s_client -connect vpn.example.net:443 -tls1_3 -briefIPsec ગેટવે માટે સમકક્ષ નિરીક્ષણ અમલીકરણના પોતાના સ્થિતિ-આઉટપુટમાંથી આવે છે, જે વપરાતા IKE અને ESP પ્રસ્તાવોની જાણ કરે છે. કોઈપણ રીતે, મુદ્દો એ જ છે: મેકેનિઝમ-અક્ષ જીવંત સેશનમાંથી વાંચવો પડે, કારણ કે ક્લાયન્ટ અને ગેટવે બંને એડમિનિસ્ટ્રેટર ધારે તેના કરતાં જૂની કોઈ વસ્તુ સુધી નીચે વાટાઘાટ કરી શકે છે.
ipsec statusall | grep -E "IKE|ESP"ત્યાર પછી બાકી રહેતા પ્રશ્નો એ છે જેનો કોઈ લેબલ જવાબ આપતું નથી. કઈ પ્રોટોકોલ આવૃત્તિઓ હજી સ્વીકારાય છે, ગેટવેની ઓળખ કેવી રીતે ચકાસાય છે, કયો અલ્ગોરિધમ-સેટ માન્ય છે, કોણ આપેલા વપરાશકર્તાને આપેલા સંસાધન માટે અધિકૃત કરે છે, અને ઉપકરણ ખોવાઈ જાય ત્યારે શું ઍક્સેસ રદ કરે છે. ટોપોલોજી-આકૃતિ અને મેકેનિઝમ-નામ એ યાદીની શરૂઆત છે, તેનો વિકલ્પ નહીં.
તો બે લેબલ રાખો, પણ તેમને જે છે તે માટે વાપરો: કયા અંતિમ બિંદુઓ જોડાય છે અને ટનલ કેવી રીતે બને છે તે કહેવાની ટૂંકી રીત. જે ક્ષણે એકને બીજાને બાકાત રાખવા વાપરવામાં આવે, વર્ણન કંઈપણ વર્ણવવાનું બંધ કરી દે છે.