બે /24ને બદલે એક /23: વાટાઘાટમાં શું બદલાય છે
સારાંશનું ગણિત સહેલું છે અને કરાર નથી. સરનામાં-સમૂહ, દરેક પક્ષ સ્વીકારે તે જૂથીકરણ અને આદાનપ્રદાન જે પરિણામ આપે તેની તુલના કરો.
બે અડીને આવેલા /24 સુઘડ રીતે એક /23માં ભળી જાય છે, અને આ સુઘડ ગણિત લોકોને ખાતરી આપે છે કે ફેરફાર ફક્ત દેખાવનો છે. આ સરનામાંઓ વિશેનું ગણિત છે, અને ટનલને સિલેક્ટરની પરવા છે, જે નેટવર્કનું વર્ણન નહીં પણ વાટાઘાટની દરખાસ્ત છે. નાની લાઇન એ જ ટ્રાફિક સુરક્ષિત રાખી શકે, ઇચ્છા કરતાં વધુ સુરક્ષિત કરી શકે, અથવા તેનો અડધો ભાગ આવરી ન શકે — બંને પક્ષો શું સ્વીકારવા તૈયાર છે તેના પર આધાર રાખીને. સ્થાપિત પરિણામ વાંચવું એ જ જાણવાનો એકમાત્ર રસ્તો છે કે ત્રણમાંથી કયું બન્યું.
ત્રણ હકીકતો જે લોકો એકમાં ભેગી કરે છે
સરનામાં-સમૂહ કહે છે કે કયા હોસ્ટ સુરક્ષિત થવા જોઈએ. જૂથીકરણ કહે છે કે તે સરનામાંઓ કેવી રીતે રજૂ થાય છે: એક સિલેક્ટર કે ઘણા, એક સંકલનમાં કે વધુમાં. વાટાઘાટ કરેલું પરિણામ કહે છે કે બંને પક્ષોએ ખરેખર શું સ્થાપિત કર્યું, અને તે પહેલા બેમાંથી કોઈપણ કરતાં સાંકડું હોઈ શકે.
તેમને ફેરફારના રેકોર્ડમાં અલગ લખો. એક જ લાઇનનું રૂપરેખાંકન ઘણી વાર ત્રણ અલગ જવાબો છુપાવે છે. જે સમીક્ષક તેમને અલગ કરી શકતો નથી તે ફેરફારને મંજૂર પણ કરી શકતો નથી.
તમારા એકત્રીકરણ સાથે જવાબદાતા શું કરી શકે
IKEv2 જવાબદાતા રજૂ કરેલી સિલેક્ટર જોડીને પોતે સ્વીકારવા તૈયાર હોય તેવા ઉપસમૂહ સુધી સાંકડી કરી શકે છે, અને સ્વીકાર્ય કંઈ ન હોય તો દરખાસ્ત સીધી નકારી શકે છે. તે એ પણ જણાવી શકે છે કે વધારાના ટ્રાફિકને આ સંકલનમાં સમાવવાને બદલે બીજું સંકલન જોઈએ.
જે જવાબદાતા કંઈ સ્વીકારતો નથી તેના બદલે ભૂલ પરત કરે છે, જે ઓછામાં ઓછું એ કહે છે કે દરખાસ્ત નકારવામાં આવી, ચૂપચાપ સાંકડી કરવામાં નહીં.
એનો અર્થ એ છે કે સફળ આદાનપ્રદાન સાબિત કરે છે કે પક્ષો કોઈ વાત પર સહમત થયા, એ નહીં કે તમે સૂચિબદ્ધ કરેલી દરેક વાત પર સહમત થયા. પ્રારંભિક સફળતાનો સંદેશ પરિણામ વાંચવાનું પ્રારંભિક બિંદુ છે, ક્યારેય નિષ્કર્ષ નહીં. સ્વીકૃત ઉપસમૂહ એક /24 કરતાં પણ નાનો હોઈ શકે, જે સ્થાપિત સમૂહને દરખાસ્ત સાથે બિલકુલ મેળ ખાતો નથી બનાવે.
જ્યાં સારાંશ ચૂપચાપ એક સીમા ભૂંસી નાખે છે
બે /24 જુદા જુદા સેવા-નિયમો ધરાવી શકે: એક ફક્ત સંચાલન પ્રોટોકોલની પરવાનગી આપે, બીજું સામાન્ય એપ્લિકેશનની. IP સ્તરે બંને સરનામાંઓને આવરી લેતું સિલેક્ટર તે નિયમો જાળવતું નથી, અને સારાંશ સીમાને ટનલની પાછળ રહેલા ગમે તે ફિલ્ટરિંગમાં ખસેડે છે. એકત્ર કરતાં પહેલાં દરેક સબનેટ માટે સેવા-નિયમોની સૂચિ બનાવો, નહીં તો તે સરખામણી ક્યારેય થતી નથી.
પ્રોટોકોલ અને પોર્ટનાં મૂલ્યો સિલેક્ટરનો ભાગ છે, વૈકલ્પિક વધારો નથી. જો મૂળ નીતિ તેમને મર્યાદિત કરતી હોય, તો એકત્રીકરણે એ જ મર્યાદા ધરાવવી પડે, નહીં તો ફેરફાર એ રૂટિંગના વેશમાં પરવાનગીનો ફેરફાર છે. જો મર્યાદા એ મૂળ નીતિનો હેતુ હોય, તો સારાંશ પછી પણ તેને સ્પષ્ટ રાખો અને રેકોર્ડમાં જણાવો.
દરેક પ્રીફિક્સ પ્રમાણે પરિણામ વાંચવું
ફેરફાર પછી રૂપરેખાંકિત થયું તે નહીં, સ્થાપિત થયું તે જુઓ. પછી દરેક પ્રીફિક્સમાંથી દરેક દિશામાં પ્રવાહ બનાવો, અને જે સંકલન તેને સંભાળે છે તેના કાઉન્ટર તપાસો. એક સંકલન પર ટ્રાફિક પેદા કરતા બે પ્રીફિક્સ ઠીક છે; બે પ્રીફિક્સ જેમાંથી એક કંઈ પેદા કરતું નથી તે જ શોધ છે.
વપરાશકર્તાઓ જે એપ્લિકેશન ચલાવે છે તે જ વાપરીને આ કરો. ગેટવે પર ઉદ્ભવતી પ્રોબ તેની પાછળના ક્લાયન્ટ કરતાં અલગ માર્ગ ચકાસે છે, અને તફાવત બરાબર ત્યાં જ છે જ્યાં સિલેક્ટરની ભૂલો સંતાયેલી હોય છે. જે પ્રીફિક્સ વ્યસ્ત હોવું જોઈએ ત્યાં સ્થિર કાઉન્ટર કોઈપણ લોગ લાઇન કરતાં વધુ મજબૂત પુરાવો છે, કારણ કે તે ગેરહાજરી માપે છે.
ફેરફારને ઉલટાવી શકાય તેવો બનાવવો
મૂળ નીતિને રૂપરેખાંકનમાં રાખો જ્યાં સુધી નવી દરેક પ્રીફિક્સ સંયોજનમાંથી પરખાય ન જાય, અને દરેક પ્રવાહ કયા સંકલનમાં ઉતર્યો તે નોંધો. જો દરખાસ્ત બદલાય ત્યારે પક્ષ સંકલન બદલે, તો રોલબેકે જૂની દરખાસ્ત પુનઃસ્થાપિત કરવી પડે, ફક્ત જૂનાં સરનામાંઓ નહીં.
વિન્ડો ખૂલે તે પહેલાં બીજા છેડાના માલિક સાથે સંકલન કરો. એક પક્ષ જેને સ્પષ્ટ ગણે છે તે બીજા પક્ષ માટે અસ્વીકાર્ય જૂથીકરણ હોઈ શકે, અને ફેરફાર દરમિયાન તે શોધવું ખર્ચાળ છે. રજૂ કરેલા જૂથીકરણ પર લેખિતમાં સંમત થાઓ, પછી આદાનપ્રદાન જે સ્થાપિત કરે તેની સાથે તેની તુલના કરો. તે કરારને ફેરફારની ટિકિટમાં રાખો, આવતા અઠવાડિયે અદૃશ્ય થતી ચેટ થ્રેડમાં નહીં.