જ્યારે રિમોટ-એક્સેસ ક્લાયન્ટે શાખા ગેટવે તરીકે કામ કરવું પડે

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

પ્રોટોકોલ લેબલ તમને શું નથી કહેતું

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

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

કરારની બે બાજુઓ છે: શાખા અને મુખ્ય કાર્યાલય

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

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

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

રાઉટેડ કે અનુવાદિત: પરત માર્ગ જાણી જોઈને પસંદ કરો

રાઉટેડ પસંદ કરો જ્યારે દરેક ઉપકરણની ઓળખ અને દરેક હોસ્ટની નીતિ મહત્વપૂર્ણ હોય અને તમે દરેક સંબંધિત રાઉટર પર પરત માર્ગ જાળવી શકો.

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

એક ઉપયોગી તપાસ અસમપ્રમાણ છે: શાખા ઉપકરણમાંથી સંસાધન માંગો, પછી ખાતરી કરો કે જવાબ મુખ્ય કાર્યાલય છોડીને શાખા પ્રીફિક્સ તરફ જાય છે. traceroute -n 10.60.4.20 મુખ્ય કાર્યાલયના હોસ્ટમાંથી બતાવે છે કે તે માર્ગ VPN ગેટવેમાંથી પસાર થાય છે કે નહીં.

તેને લોગિનની જેમ નહીં, માળખાગત સુવિધાની જેમ ચલાવો

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

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

મંજૂર યોજના હેઠળ ધારેલી શાખા એપ્લિકેશનો, તેમનો પરત ટ્રાફિક અને એક નકારેલું ગંતવ્ય માન્ય કરો. સફળતા નામવાળી શાખા ઓળખ અને સ્પષ્ટ નીતિ ધરાવતી માલિકીની નેટવર્ક સેવા જેવી દેખાય છે, કનેક્ટેડ લખેલી ક્લાયન્ટ વિન્ડો જેવી નહીં.