હબ અને સ્પોક કે પૂર્ણ મેશ: કઈ VPN ટોપોલોજી તમારી સાઇટ્સ માટે યોગ્ય છે

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

બીજું કંઈ પણ પહેલાં પીઅર સંબંધો ગણો

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

તેમાંનો દરેક સંબંધ એવી સ્થિતિ રાખે છે જેની માલિકી તમારી પાસે હોવી જોઈએ। IPsec માં તેનો અર્થ સિક્યોરિટી એસોસિએશન, ઓળખ, કી કે સર્ટિફિકેટ, ડેડ-પીઅર શોધ અને દરેક દૂરના પ્રિફિક્સ માટે ઓછામાં ઓછો એક રૂટ છે। WireGuard માં તેનો અર્થ જાહેર કી અને AllowedIPs દરેક પીઅર માટે બ્લોક છે, જે પ્રતિ પીઅર સસ્તું છે પણ સંપૂર્ણ શોધ વિના આવે છે: નવી સાઇટ કોઈપણ રીતે દરેક હાલની સાઇટ પર કન્ફિગરેશન ફેરફાર છે।

ટ્રાફિકનું મિશ્રણ નક્કી કરે, ચિત્ર નહીં

જો શાખાઓનો ટ્રાફિક મુખ્યત્વે કેન્દ્રીય ERP કે ફાઇલ ક્લસ્ટરની વિનંતીઓ હોય, તો હબ સમાધાન નથી, તે યોગ્ય આકાર છે: ટ્રાફિક પહેલેથી ત્યાં જવા માંગતો હતો, અને એક નીતિ બિંદુ જોડી-આધારિત નિયમોના મેશ કરતાં ઓડિટ કરવા સરળ છે। શાખાઓ એકબીજા સાથે ડેટા વિનિમય કરે ત્યારે મેશ પોતાની જટિલતા કમાય છે — બે ઓફિસો વચ્ચે પ્રતિકૃતિ, સાઇટ્સ વચ્ચે અવાજ, ડઝનબંધ એન્જિનિયરો આખો દિવસ ખોલે તેવું CAD શેરિંગ।

અઘરા કિસ્સા વચ્ચે હોય છે, અને તેઓ જ બહુમતી છે। સંસ્થા ચાર્ટ પરથી અનુમાન કરવાને બદલે દલીલ કરતાં પહેલાં માપો।

કોષ્ટકને નિયમ નહીં, નિર્ણાયક તરીકે વાંચો। ચારમાંથી ત્રણ પંક્તિઓ એક દિશામાં હોય તો સામાન્ય રીતે ડિઝાઇન નક્કી થાય છે; વિભાજન એટલે હાઇબ્રિડ, જે મોટાભાગના પરિપક્વ નેટવર્ક છેવટે ચલાવે જ છે।

હબને ફોરવર્ડ કરવાનું કહેવું પડે

બે કાર્યરત સ્પોક-થી-હબ ટનલ સ્પોક-થી-સ્પોક ઍક્સેસ બનાવતી નથી। હબને IP ફોરવર્ડિંગ ચાલુ, દરેક સ્પોક નેટવર્ક સુધી રૂટ, ટ્રાન્ઝિટની પરવાનગી આપતો ફાયરવોલ નિયમ અને પરત માર્ગ ગણેલો જોઈએ; દરેક સ્પોકને બીજી સાઇટના પ્રિફિક્સ માટે રૂટ જોઈએ। Linux હબ પર તે net.ipv4.ip_forward=1 વત્તા FORWARD એક ચેઇન છે જે જોડીને શાંતિથી પડતી મૂકતી નથી, અને નીતિ-આધારિત IPsec માં તે ટ્રાફિક સિલેક્ટર છે જે બંને છેડે દૂરના સ્પોક સબનેટની યાદી આપે છે। strongSwan માં ફોરવર્ડિંગ નોંધો કર્નલ અને ફાયરવોલની બાજુ આવરી લે છે, જ્યારે તે જ તમારો ખૂટતો સ્તર હોય। સસ્તી કસોટી એ છે કે એક સ્પોકથી બીજી બાજુની સેવા તરફ ટ્રાફિક મોકલો અને હબના કાઉન્ટર જુઓ; જે નિયમ ક્યારેય વધતો નથી તેનો અર્થ ક્રમ ખોટો છે, રૂટ નહીં।

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

અડધા-બનેલા સંસ્કરણથી સાવધ રહો: સ્પોક A હબ દ્વારા સ્પોક B તરફ રૂટ કરે છે, હબ બંને દિશામાં રૂટ કરે છે, અને હબનો ફાયરવોલ A તરફથી નવા કનેક્શનની પરવાનગી આપે છે પણ B તરફથી નહીં। પહેલી દિશા સારી રીતે પરીક્ષણ પામે છે અને બીજી અટકી જાય છે, જે રૂટિંગ ખામી જેવું લાગે છે અને તેવું નથી।

પહેલાં નિષ્ફળતાની ડિઝાઇન કરો, પછી સામાન્ય માર્ગની

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

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

બંનેમાંથી કોઈ ડિઝાઇન પોતાની જાતે ફેલઓવર દરમિયાન TCP સેશન જીવંત રાખતી નથી। જો ઍપ્લિકેશન ફરી જોડાઈ શકતી ન હોય, તો ટોપોલોજી તમારી સમસ્યા નથી।

બદલાવના ખર્ચ પ્રમાણે પસંદ કરો, પછી રૂટ ચકાસો

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

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

બંને ચિત્રો ઍક્સેસ મેટ્રિક્સ સાથે રાખો, અને સાઇટ ઉમેરાય ત્યારે તેમને ફરી જુઓ; તમે જે ખર્ચ સંભાળો છો તે આગલા બદલાવનો ખર્ચ છે, વર્તમાન ચિત્રની સુંદરતા નહીં।