ભાગીદારોને જોડ્યા વિના ભાગીદાર VPN ઍક્સેસને કેન્દ્રિત કરો

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

દરેક ભાગીદારે પહેલેથી સહી કરેલા કરારથી શરૂ કરો

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

તે નોંધ જ પરિણામ છે. જો તમે એક ભાગીદાર માટે તે લખી શકતા નથી, તો તે ભાગીદાર કેન્દ્રિત થવા તૈયાર નથી.

ફક્ત લક્ષ્ય પ્રમાણે નહીં, સંદર્ભ પ્રમાણે રૂટ કરો

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

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

જ્યાં જવાબ હા છે, રૂટિંગ સંદર્ભ તે બની જાય છે જે તમે દસ્તાવેજીકૃત કરો છો અને પરીક્ષણ કરો છો, કારણ કે તે traceroute માં અદૃશ્ય છે.

કર્મચારી શું લખે છે અને ભાગીદાર શું નોંધે છે તે નક્કી કરો

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

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

ભાગીદાર-થી-ભાગીદાર ટ્રાંઝિટ સ્પષ્ટપણે નકારો

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

નકારને પરવાનગીઓની બાજુમાં ભાગીદારના રેકોર્ડમાં લખો, જેથી ઇરાદો કર્મચારી ફેરફારો પછી પણ ટકે.

તેને મોટા લેપટોપ તરીકે નહીં, વહેંચાયેલ સેવા તરીકે ચલાવો

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

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

ભાગીદાર, સંદર્ભ, મંજૂર શ્રેણીઓ અને માલિકનું નાનું કોષ્ટક રાખો. ઘટનાના સમયે કોઈ પણ સૌથી પહેલાં એ જ માંગશે.