Azure NVA નિરીક્ષણ: જવાબ બીજા ફાયરવોલમાંથી કેમ પસાર થાય છે
Route Server બે સમાન માર્ગ વહેંચે છે અને બીજું કંઈ નહીં. જ્યારે જવાબ બીજા ઉપકરણને પસંદ કરે છે, ત્યારે તે સત્રની ત્યાં કોઈ સ્થિતિ હોતી નથી અને પ્રવાહ મરી જાય છે.
શાખાથી Azure સુધીનો પ્રવાહ બંને દિશામાં યોગ્ય રીતે રૂટ થઈ શકે છે અને તોપણ નિષ્ફળ થઈ શકે છે, કારણ કે બંને દિશાઓ અલગ ઉપકરણોમાંથી પસાર થાય છે. વિનંતી VPN દ્વારા શાખા છોડે છે, NVA A પર ઉતરે છે અને વર્કલોડ સુધી પહોંચે છે. જવાબ વર્કલોડ છોડે છે, NVA B તરફ નિર્દેશ કરતા રૂટ સાથે મેળ ખાય છે અને ત્યાં જ મરી જાય છે. તે ચિત્રનો દરેક રૂટ માન્ય છે, અને TCP સત્ર હજી પણ તૂટેલું છે.
Request: branch -> VPN gateway -> NVA A -> workload
Reply: workload -> NVA B -> VPN gateway -> branch
એ જ અંતર અહીં આખો વિષય છે: રૂટિંગ કન્વર્જન્સ અને સત્રની સ્થિતિની માલિકી એવી અલગ સમસ્યાઓ છે જે ડાયાગ્રામમાં એકસમાન દેખાય છે.
Route Server ખરેખર શું પ્રોગ્રામ કરે છે
Azure Route Server સમર્થિત BGP વક્તાઓ સાથે પીઅરિંગ કરે છે, તેમના રૂટ શીખે છે અને તેમને વર્ચ્યુઅલ નેટવર્કના અસરકારક રૂટમાં પ્રોગ્રામ કરે છે. તે કંટ્રોલ-પ્લેન કાર્ય છે. તે કોઈ વેન્ડર ફાયરવોલનું સત્ર કોષ્ટક વાંચતું નથી, અને તેને ખબર નથી કે કયા ઉપકરણે આપેલ કનેક્શનને મંજૂરી આપી. બે સમાન-ખર્ચવાળા આગલા હોપ આ ફેબ્રિક માટે ફક્ત એક જ પ્રીફિક્સ સુધી પહોંચવાના બે રસ્તા છે, અને તે ગમે તે વાપરશે.
તેથી રૂટ શીખવો પહોંચવાની ક્ષમતા સાબિત કરે છે. બીજા છેડેનું ઉપકરણ આ પ્રવાહ પહેલાં જોયો છે કે નહીં તે વિશે તે કંઈ સાબિત કરતું નથી.
ડિઝાઇન કરતાં પહેલાં બંને દિશા વાંચો
દરેક દિશામાં તમારી પાસે ખરેખર જે સ્ટીયરિંગ છે તે લખવાથી શરૂ કરો, તમે જે ઇરાદો રાખ્યો હતો તે નહીં. વધુ ચોક્કસ BGP રૂટ, વપરાશકર્તા-વ્યાખ્યાયિત રૂટ અને ગેટવે વર્તન બધા સ્પર્ધા કરે છે, અને વિજેતા દરેક ગંતવ્ય માટે નક્કી થાય છે, દરેક સત્ર માટે નહીં. NVA પરનો ડિફોલ્ટ રૂટ એનો અર્થ નથી કે દરેક ખાનગી પ્રીફિક્સ તેમાંથી પસાર થાય છે.
એક ઉપયોગી તપાસ એ છે કે એક ચોક્કસ વર્કલોડ IP માટે પૂછો કે દરેક દિશા કયા આગલા હોપમાં ઉકેલાય છે. જવાબ બે અલગ ઉપકરણો હોય, તો તમારી પાસે અસમાનતાની સમસ્યા છે, તે પહેલેથી પ્રગટ થઈ હોય કે ન હોય.
સ્થિતિ ક્યાં રહે છે
સ્ટેટફુલ ફાયરવોલ કનેક્શન સ્વીકારે છે અને પાંચ-ટુપલ પર કી કરેલ કોષ્ટક પ્રવેશ રાખે છે. જવાબ તે પ્રવેશ ધરાવતા ઉપકરણ સુધી પહોંચવો જોઈએ, અથવા તે ઉપકરણે સ્થિતિ બીજી રીતે મેળવવી જોઈએ. Azure ડેટા પ્લેનમાં કંઈ પણ ઉપકરણો વચ્ચે પ્રવેશને ફોરવર્ડ કરતું નથી. કાં તો ટ્રાફિક માલિક તરફ પાછો સ્ટીયર થાય છે, અથવા ઉપકરણો વેન્ડર મિકેનિઝમ દ્વારા સ્થિતિ શેર કરે છે, અથવા ડિઝાઇન કામ કરતી નથી.
તેથી જ બે સ્વસ્થ NVA નિરીક્ષણ માટે આરોગ્ય-તપાસ નથી. આરોગ્ય પહોંચવાની ક્ષમતા વિશે છે; નિરીક્ષણ એ વિશે છે કે કઈ ઇન્સ્ટન્સ સત્ર ધરાવે છે.
સમર્થિત HA મોડેલ અને દરેક શું વચન આપે છે
Microsoft's guidance on Virtual WAN રૂટિંગ ઇરાદા વિશે Microsoftની માર્ગદર્શિકા દ્વિ-ભૂમિકા કનેક્ટિવિટી અને ફાયરવોલ NVA માટે મર્યાદિત વર્તનનું વર્ણન કરે છે, જ્યાં સીધું રૂટિંગ હબના સામાન્ય સમપ્રમાણ અમલને બાયપાસ કરી શકે છે. તે નોંધોને તમે પસંદ કરેલી ટોપોલોજી પરના પ્રતિબંધો તરીકે વાંચો, સક્રિય-સક્રિય ડિઝાઇન પરની મનાઈ તરીકે નહીં. જે વેન્ડર જોડી સ્થિતિ સિંક્રોનાઇઝ કરે છે અથવા પ્રતિ પ્રવાહ સ્ટીયર કરે છે તેને સમર્થન આપી શકાય. જે સમાન-ખર્ચવાળી જોડી બંનેમાંથી કંઈ કરતી નથી તેને નહીં.
પછી વ્યાખ્યાયિત કરો કે નોડ નિષ્ફળ જાય ત્યારે હાલના સત્રોનું શું થાય છે. રૂટ કન્વર્જન્સ સેકંડોમાં નવા પ્રવાહો માટે પહોંચવાની ક્ષમતા પુનઃસ્થાપિત કરે છે, જ્યારે જૂની ફાયરવોલ સ્થિતિ ફક્ત ગાયબ થઈ જાય છે. ક્લાયંટ પુનઃકનેક્શન દસ્તાવેજીકૃત પરિણામ હોઈ શકે છે, અને તે ઘટનાના સમયે નહીં પણ પહેલાં લેવાનો નિર્ણય છે.
તેના પર ભરોસો કરતાં પહેલાં શું પરીક્ષણ કરવું
Test with inspection enabled and વર્કલોડની ઍક્સેસ નીતિ સ્થાને રાખીને પરીક્ષણ કરો, કારણ કે બંનેમાંથી કોઈ પણ અસમાનતાને છુપાવી શકે છે. બંને દિશામાં નવો અધિકૃત પ્રવાહ મોકલો અને ખાતરી કરો કે એ જ ઉપકરણે બંને અર્ધ ભાગ જોયા છે. પછી સતત ટ્રાફિક ચલાવો અને મંજૂર ફેઇલઓવર ટ્રિગર કરો, સ્થાપિત સત્રો ટકી રહે છે કે પુનઃકનેક્ટ થાય છે તે અવલોકન કરો.
દરેક પ્રવાહને તેને સંભાળનારા ઉપકરણ સાથે સહસંબંધિત કરો. એક NVA પર પેકેટ કેપ્ચર લગભગ કંઈ જ કહેતું નથી જો જવાબ ક્યારેય ત્યાં પાછો ન આવે.
અંતમાં, યોજના ત્રણ અલગ લીટીઓ તરીકે લખો: રૂટની માલિકી, ટ્રાફિક સ્ટીયરિંગ અને સત્રની સ્થિતિની માલિકી. પ્રથમ બે ઉકેલાઈ જાય અને ત્રીજું ધારી લેવાય ત્યારે ડિઝાઇન તૂટે છે.