સાઇટ્સ અથડાય તે પહેલાં ખાનગી VPN સરનામા શ્રેણીઓનું આયોજન કરો
એકબીજા પર ચઢતી ખાનગી શ્રેણીઓ કોઈપણ ટનલ પહેલાં રાઉટિંગ તોડી નાખે છે. પ્રીફિક્સની યાદી બનાવો, ક્લાયન્ટ પૂલને સાઇટ LANથી અલગ માપો અને દૂરની બાજુથી પરીક્ષણ કરો.
બે સાઇટ્સ જે બંને 192.168.1.0/24 વાપરે છે, તે દરેક ઇન્ટરનેટ સુધી પહોંચી શકે છે અને તો પણ એકબીજા સુધી પહોંચી શકતા નથી. ગેટવે કોઈ ભૂલ ઉઠાવતું નથી; તે તે પ્રીફિક્સ માટે એક રૂટ સ્થાપિત કરે છે અને દરેક પેકેટને તે પીઅરને મોકલે છે જેણે તેને પહેલાં દાવો કર્યો હતો. હેન્ડશેક, સાઇફર સૂચિ કે ઇન્ટરફેસ મેટ્રિકમાં કંઈ જ કહેતું નથી કે કયો પીઅર ખોટો છે. સરનામા આયોજન એ ડિઝાઇનનો ભાગ છે જે કોઈ જોડાય તે પહેલાં આ નક્કી કરે છે.
પહોંચી શકાય તેવી દરેક જગ્યાની યાદી બનાવો
જે શ્રેણીઓ રૂટ કરવી પડે તે લખો, ફક્ત જે તમે ગોઠવી રહ્યા છો તે નહીં. એટલે સાઇટ LAN, VPN ક્લાયન્ટ પૂલ, ક્લાઉડ સબનેટ, મેનેજમેન્ટ અને આઉટ-ઓફ-બેન્ડ નેટવર્ક, લેબ સેગમેન્ટ અને જે નેટવર્કમાંથી વપરાશકર્તાઓ ઘરેથી નિયમિત જોડાય છે. 192.168.1.0/24 તરીકે મોકલાતું ગ્રાહક રાઉટર કાલ્પનિક નથી, અને એ જ પ્રીફિક્સ હોટેલ અને પરિષદ સ્થળોએ દેખાય છે. યાદી એ પ્રીફિક્સ, માલિક અને હેતુનું કોષ્ટક છે, અને તે એકમાત્ર દસ્તાવેજ છે જે એક જ શ્રેણી બે વાર આપવાથી રોકે છે.
| Prefix | Purpose | Owner |
|---|---|---|
| 10.20.0.0/16 | site LANs | network team |
| 10.20.100.0/22 | VPN client pool | remote access |
| 10.20.200.0/24 | management | operations |
આવતા વર્ષમાં જે પ્રીફિક્સની અપેક્ષા છે તે ઉમેરો, કારણ કે ફક્ત આજને આવરી લેતી યોજના પહેલી નવી સાઇટ પર નિષ્ફળ જાય છે. દરેક હરોળમાં કોણ તેને બદલી શકે તે ચિહ્નિત કરો, ફક્ત કોણ તેનો માલિક છે તે નહીં.
પુનર્વપરનો ઉપયોગ જ આને મુશ્કેલ બનાવે છે: ખાનગી જગ્યા મર્યાદિત છે અને દરેક સંસ્થા 10.0.0.0/8 ને પોતાની ગણે છે. યોજના વચન આપી શકતી નથી કે ભવિષ્યનું કોઈ મહેમાન LAN તમારા પ્રીફિક્સમાંથી એક પર નહીં આવે, તેથી ડિઝાઇનને કહેવું પડે કે એવું થાય ત્યારે શું થાય. બે નિયમો મોટાભાગનું કામ કરે છે. ક્લાયન્ટ પૂલને એક સતત બ્લોકમાં મૂકો જેનો તમે સારાંશ આપી શકો, અને બીજી ટીમ પહેલેથી રૂટ કરતી હોય તેવી શ્રેણી કદી ફાળવો નહીં. બાકીનું બધું એવું રેકોર્ડ છે જે કોઈ વ્યક્તિ અદ્યતન રાખે છે.
કેમ એક ઓવરલેપ રાઉટિંગ કોષ્ટકને હરાવે છે
રૂટ એ પ્રીફિક્સ વત્તા આગળનો હોપ છે, અને ફોર્વર્ડિંગ સૌથી લાંબું મેળ ખાતું પ્રીફિક્સ પસંદ કરે છે. જ્યારે બે પીઅર બંને 192.168.1.0/24 નો દાવો કરે છે, ત્યારે કોષ્ટક તેના માટે એક જ એન્ટ્રી રાખે છે, તેથી બંને સાઇટનો ટ્રાફિક એક જ ટનલમાંથી નીકળે છે. બીજી સાઇટ ખોટી ગોઠવાયેલી નથી; તે પહોંચની બહાર છે કારણ કે પહેલી એ જ સરનામાંઓ માટે જવાબ આપે છે. કોઈ મેટ્રિક તેમને અલગ કરી શકતું નથી, કારણ કે મેળ મેટ્રિકની સલાહ લેવાય તે પહેલાં થાય છે.
નિષ્ફળતા અસમપ્રમાણ છે અને ખોટી રીતે વાંચવી સરળ છે. સાઇટ A ના હોસ્ટ ગેટવે અને કેટલીક સેવાઓ સુધી પહોંચે છે, જ્યારે સાઇટ B ના હોસ્ટ કંઈ જ જવાબ આપતા નથી, અને લોગ બંને દિશામાં સ્વસ્થ ટનલ બતાવે છે. એ પેટર્ન સરનામા અથડામણ છે, પ્રમાણીકરણ કે ફાયરવોલની ખામી નહીં, અને તેની પુષ્ટિ માટે યાદી સાથે સરખાવેલું એક કોષ્ટક ડમ્પ જોઈએ.
ક્લાયન્ટ પૂલ અને સાઇટ શ્રેણીઓ જાણી જોઈને માપો
VPN ક્લાયન્ટ પૂલ એ શ્રેણી છે જે ગેટવે એક સમયે એક સરનામું આપે છે, તેથી તેનું કદ એક સાથેની સંખ્યા મર્યાદિત કરે છે. /24 માં 254 વાપરી શકાય તેવા સરનામાં સમાય છે, જે નાની ટીમ માટે ઉદાર અને કન્ટેનર ચલાવતી શાખા માટે તંગ છે; /22 ખાનગી જગ્યામાં વધારાનો ખર્ચ કરતું નથી અને વિવાદ દૂર કરે છે. પૂલને સતત રાખો અને દરેક સાઇટ LANથી દૂર રાખો, જેથી ક્લાયન્ટ તરફનો સારાંશ રૂટ કદી સાઇટને ગળી ન જાય. પૂલ ખાલી હોય ત્યારે પણ શ્રેણી અનામત રાખો, કારણ કે ન લખાયેલી શ્રેણી એ છે જે આગલો ઇજનેર ફાળવશે.
સાઇટને અપેક્ષિત હોસ્ટ વત્તા વૃદ્ધિ માટે માપેલી શ્રેણીઓ મળે છે, જે સ્વચ્છ રીતે સારાંશ આપી શકાય તેવી સીમા પર ગોઠવાય છે. ફાળવણી વચ્ચેના જાણી જોઈને રાખેલા અંતરનો કોઈ ખર્ચ નથી અને પછીથી એકત્રિત કરવા માટે જગ્યા ખરીદે છે.
પછી જે દિશા લોકો ભૂલી જાય છે તે તપાસો: પરત માર્ગ. દરેક સાઇટ રાઉટરને ક્લાયન્ટ પૂલ સુધીનો રૂટ જોઈએ, અને કોન્સન્ટ્રેટરને તે જે સેવા આપે છે તે દરેક સાઇટ પ્રીફિક્સ સુધીનો રૂટ જોઈએ. પૂલ તરફ પરત માર્ગ વગરનું સુઘડ પ્રીફિક્સ કોષ્ટક હજી પણ તૂટેલી ડિઝાઇન છે, અને લક્ષણ એકમુખી જોડાણ છે જે કંઈ જ જવાબ આપતું નથી. બંને દિશા એક જ કોષ્ટકમાં રાખો અને સાઇટ ઉમેરાય ત્યારે તેની સમીક્ષા કરો.
અનુવાદ અને પુનઃક્રમાંકન જુદી જુદી સમસ્યાઓ ઉકેલે છે
જ્યારે ઓવરલેપ પહેલેથી હાજર હોય, ત્યારે બે પ્રામાણિક વિકલ્પો અને એક અપ્રામાણિક વિકલ્પ હોય છે. પુનઃક્રમાંકન અથડામણ કાયમ માટે દૂર કરે છે અને જાળવણી વિન્ડો વત્તા તમે ભૂલી ગયેલા દરેક હાર્ડકોડ કરેલા સરનામાનો ખર્ચ કરે છે. સરનામા અનુવાદ એક બાજુની ખાનગી શ્રેણીને ટનલની ધાર પર બીજી શ્રેણીમાં મેપ કરે છે, જે બંને સાઇટને અસ્પૃષ્ટ રાખે છે પણ સ્થિતિ ઉમેરે છે, સરનામાં સમાવતા પ્રોટોકોલ તોડે છે અને લોગ વાંચવા મુશ્કેલ બનાવે છે. અપ્રામાણિક વિકલ્પ એ એક સર્વર તરફનો હોસ્ટ રૂટ છે, જે એક પરીક્ષણ પાસ કરે છે અને બાકીના બધામાં નિષ્ફળ જાય છે.
નિયંત્રણ અને આયુષ્ય પ્રમાણે પસંદ કરો. તમારી માલિકીની અને સમયપત્રક આપી શકાય તેવી સાઇટ પુનઃક્રમાંકન માર્ગ પર આવે છે; જે ભાગીદાર નેટવર્કને તમે સ્પર્શી શકતા નથી અને એક એપ્લિકેશન માટે વપરાય છે તે દસ્તાવેજીકૃત મેપિંગ સાથે અનુવાદ માટે ઉમેદવાર છે. એ મેપિંગ લખી રાખો, કારણ કે ફક્ત કન્ફિગરેશન ફાઇલની અંદર રહેલો અનુવાદ ફાઇલ બદલાય તે ક્ષણે અદૃશ્ય થઈ જાય છે.
તૈનાત કરતાં પહેલાં દૂરની બાજુથી પરીક્ષણ કરો
એવા નેટવર્કથી પરીક્ષણ કરો જે ગેટવેનું યજમાન ન હોય, કારણ કે ગેટવેનું પોતાનું LAN મોટાભાગની રાઉટિંગ ભૂલો છુપાવે છે. સામાન્ય ઘરના રાઉટર પાછળ ક્લાયન્ટ જોડો, પછી દરેક સાઇટ પરની સેવા અને ક્લાયન્ટ પૂલની અંદરની એક સેવા સુધી પહોંચો. વિરુદ્ધ દિશા પણ ચકાસો, સાઇટ હોસ્ટથી ક્લાયન્ટ સુધી, કારણ કે પરત માર્ગ સ્વતંત્ર રીતે નિષ્ફળ જાય છે. ફક્ત ગેટવેને પિંગ કરતું પરીક્ષણ સાબિત કરે છે કે ટનલ ચાલુ છે અને તેનાથી વધુ કંઈ નહીં.
શ્રેણીઓ, માલિકો અને અનુવાદ મેપિંગને એક વહેંચાયેલા રેકોર્ડમાં રાખો જે આગલી સાઇટ કંઈપણ ફાળવતાં પહેલાં વાંચે. સાઇટ ઉમેરાય ત્યારે તેની સમીક્ષા કરો, અને દસ્તાવેજ ન હોય તેવી શ્રેણીને આશ્ચર્ય નહીં પણ ખામી ગણો.
રેકોર્ડ જ સોંપણી છે. ત્રણ લોકોની યાદમાં જીવતી યોજના તેમાંથી એક રજા પર હોય તે પહેલી વારે નિષ્ફળ જાય છે, અને ઉત્પાદનમાં મળેલો ઓવરલેપ કોષ્ટક કરતાં વધુ ખર્ચ કરે છે.