બે ઓન-પ્રેમ VPN સરનામાં: બે Azure પીઅર, એક નહીં

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

દંતકથા: એક ગેટવે, બે સરનામાં

સ્થાનિક નેટવર્ક ગેટવે એ દૂરના પીઅરનું વર્ણન છે: એક જાહેર એન્ડપોઇન્ટ અને તેની પાછળના ખાનગી પ્રીફિક્સ. તે સંસાધનને «આ બેમાંથી કોઈ પણ ઉપકરણ» અર્થ આપવાની કોઈ સમર્થિત રીત નથી.

એ જ ગૂંચવણ બીજી દિશામાં પણ છે, જ્યાં Azure ના બે જાહેર IP ને બે Azure ગેટવે અસ્તિત્વમાં હોવાના પુરાવા તરીકે વાંચવામાં આવે છે.

પહેલા ઑબ્જેક્ટ ગણો, પછી ટનલ

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

ગણતરી ડિઝાઇન દસ્તાવેજમાં પેસ્ટ કરવા જેટલી ટૂંકી છે:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

એક કનેક્શન સંસાધન એક કરતાં વધુ અંતર્ગત ટનલ વહન કરી શકે છે, તેથી ચાર ટનલનો અર્થ ચાર વર્ચ્યુઅલ નેટવર્ક ગેટવે નથી. Azure ના બે જાહેર IP પણ દૂરના સાઇટનું વર્ણન કરતા બે સ્થાનિક નેટવર્ક ગેટવે જેવા સમાન ઑબ્જેક્ટ નથી.

Azure બાજુએ સક્રિય-સક્રિય શું ઉમેરે છે

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

નિષ્ક્રિય-સ્ટેન્ડબાય ગેટવે સંપૂર્ણ માન્ય ડિઝાઇન છે; તે ફક્ત અલગ ટનલ સંખ્યા આપે છે.

BGP બંને માર્ગને ઉપયોગપાત્ર બનાવે છે

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

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

ફ્લો-આધારિત પસંદગી બેન્ડવિડ્થ પૂલિંગ નથી

Azure ફ્લોના સરનામાં અને પોર્ટ પર હેશનો ઉપયોગ કરીને પ્રતિ ફ્લો એક માર્ગ પસંદ કરે છે. સ્થિર સ્થિતિમાં, આપેલ TCP અથવા UDP ફ્લોના પેકેટ સામાન્ય રીતે સમાન ટનલ લે છે, અને ઓન-પ્રેમ બાજુ પરત દિશા માટે અલગ ટનલ પસંદ કરી શકે છે. તેથી બે ઉપકરણો અને ચાર ટનલ ઉપલબ્ધતા સુધારે છે, એક ટ્રાન્સફરની ઝડપ નહીં. જ્યારે વિક્રેતાની સ્લાઇડ એગ્રિગેશનનું વચન આપે છે, ત્યારે તે બીજી સુવિધા અથવા ગેરસમજનું વર્ણન કરે છે.

માર્ગ કેવી રીતે ફેલાય છે તે જોવા માંગો તો સમાંતર ફ્લો સાથે પરીક્ષણ કરો, અને મર્યાદા જોવા માંગો તો એક ફ્લો સાથે.

તમે ખરેખર કઈ રીડન્ડન્સી દૂર કરી

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

શોધ અને કન્વર્જન્સ વિલંબની અપેક્ષા રાખો, અને કેટલાક હાલના સત્રો સમાપ્ત થવાની અપેક્ષા રાખો.