એવી VPN ડિઝાઇન બ્રીફ લખો જે કોઈ ખરેખર સમીક્ષા કરી શકે

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

પ્રથમ, પ્રશ્ન નિર્ણય છે કે ઇચ્છા

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

ઇચ્છા પ્રેક્ષકોને પણ છુપાવવાની વૃત્તિ ધરાવે છે. કહો કે ડિઝાઇન કોણ મંજૂર કરે, કારણ કે એ જ બ્રીફ નેટવર્ક માલિક, સુરક્ષા સમીક્ષક અને નાણાકીય મંજૂરકર્તા માટે અલગ રીતે વંચાય છે.

જો જવાબ કોઈ નથી તો અહીં થંભો, કારણ કે માલિક વગરનો નિર્ણય સૌથી મોટેથી ફરિયાદ કરનાર ફરી બનાવશે. તે ડિઝાઇનની સમસ્યા નહીં પણ શાસનની સમસ્યા છે.

બીજું, પ્રવાહો અને નકારોને નામ આપો

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

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

ક્લાયન્ટો અને તેમની વ્યવસ્થાપન સ્થિતિ પણ નોંધો, કારણ કે એજન્ટ સાથેનું સંચાલિત ઉપકરણ એવું કરી શકે છે જે પોતાનું લેપટોપ લાવેલ વપરાશકર્તા કરી શકતો નથી.

યાદી પરીક્ષણ માટે પૂરતી ટૂંકી રાખો. જે દસ પ્રવાહો તમે ચકાસી શકો તે એ ચાલીસ કરતાં વધુ સારા છે જે તમે ચકાસી શકતા નથી.

તપાસ 3: તથ્યોને ધારણાઓથી અલગ કરો

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

દ્રષ્ટાંતરૂપ નેટવર્ક ત્યાં સુધી ઠીક છે જ્યાં સુધી તે લેબલવાળું હોય. સમસ્યા એ ઊહાપોહ પ્રદેશ છે જે શાંતિથી બીજી ઉપરની લિંક અથવા જાહેર સરનામા બ્લોક મેળવે છે જે તેની પાસે ક્યારેય નહોતો.

સમીક્ષા પહેલાં જે ધારણા તમે ચકાસી શકો તે ચકાસો, કારણ કે એક માપેલું તથ્ય ચર્ચાની આખી શાખા દૂર કરે છે.

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

ચોથું, નિષ્ફળતા કરાર લખો

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

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

પુનઃપ્રાપ્તિનું લક્ષ્ય સરળ ભાષામાં ઉમેરો, જેમ કે સાઇટ કેટલો સમય અધોગતિગ્રસ્ત સ્થિતિમાં ચાલી શકે અને ઘટનાની જાહેરાત કોણ કરે.

તપાસ 5 અને 6: સીમ પસંદ કરો અને ફેરફાર નોંધો

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

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

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

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