નાની ઓફિસનું VPN: તેને ડોમેન કંટ્રોલરથી દૂર રાખો

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

ડોમેનનું દરેક મશીન ડોમેન કંટ્રોલર પર ભરોસો કરે છે; VPN ગેટવે સુધી ઇન્ટરનેટ પરનું કોઈપણ પહોંચી શકે છે. એ અસમમિતિ જ આખી દલીલ છે.

બે અલગ એક્સપોઝર પ્રોફાઇલ સાથેના બે કામ

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

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

ડિરેક્ટરી ભૂમિકા વિના પ્રમાણીકરણ

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

પછી દૂરસ્થ ક્લાયંટને ખરેખર જે નેટવર્ક પથની જરૂર છે તે મર્યાદિત કરો. એક આંતરિક ફાઇલ સેવાની ઍક્સેસ, સાથે તે કાર્યપ્રવાહ આધાર રાખે છે તેવી નામ-નિરાકરણ અને ઓળખ સેવાઓ, એ વ્યાખ્યાયિત પથનો સમૂહ છે. VPN પૂલમાંથી દરેક ડોમેન કંટ્રોલર પોર્ટ કે દરેક વ્યવસ્થાપન ઇન્ટરફેસને મંજૂરી આપવાનું આ કારણ નથી.

એક હોસ્ટ હજી પણ એક નિષ્ફળતા ડોમેન છે

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

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

VPN સુધારવા માટે VPN ચાલુ હોવું જરૂરી હોય તેવી જાળવણી વિન્ડો જાળવણી વિન્ડો નથી.

બહાર તાળું માર્યા વિના તેને ખસેડો

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

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

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