Azure UDR થી VPN ગેટવે: એક ગંતવ્ય, બધા નિકાસ નહીં

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

આગલો હોપ ગેટવે છે, ઉપકરણનું IP નહીં

UDR મેળ ખાતું પ્રીફિક્સ આગલા-હોપ પ્રકારને મોકલે છે, અને VirtualNetworkGateway એ પ્રકાર છે, સરનામું નહીં. લોકો ગેટવેનું ખાનગી IP VirtualAppliance રૂટમાં પેસ્ટ કરે છે અને પછી વિચારે છે કે કેમ કંઈ મેળ ખાતું નથી, કારણ કે તે પ્રકાર તેના બદલે NIC અથવા આંતરિક લોડ બેલેન્સરની અપેક્ષા રાખે છે. Microsoft નું રૂટિંગ દસ્તાવેજીકરણ પણ ગેટવેના આગલા હોપને એવા વર્ચ્યુઅલ નેટવર્ક સુધી મર્યાદિત કરે છે જેનું ગેટવે VPN ગેટવે હોય. ExpressRoute, Route Server અને Virtual WAN હબ તે વિકલ્પ દ્વારા સંબોધાતા નથી.

રૂટ લખતા પહેલાં વર્ચ્યુઅલ નેટવર્કમાં ખરેખર શું છે તે તપાસો. જો ડિઝાઇન હબ દ્વારા રૂટ કરે છે, તો રૂટ હબના રૂટિંગ માલિકનો છે, તમે જે સ્પોક સંપાદિત કરી રહ્યા છો તેનો નહીં.

કંઈપણ બદલતા પહેલાં અસરકારક રૂટ વાંચો

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

પહેલા અસરકારક કોષ્ટક જુઓ, પછી નક્કી કરો કે તમે રૂટ ઉમેરી રહ્યા છો કે એકને બદલી રહ્યા છો:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

પ્રીફિક્સ સાથે સ્રોત કૉલમ પણ વાંચો. સાચા પ્રીફિક્સ અને ખોટા સ્રોતવાળો રૂટ તમને કહે છે કે કઈ વસ્તુ સંપાદિત કરવી, અને પહેલા સામે હારી જતો બીજો રૂટ ઉમેરવાથી બચાવે છે.

વાસ્તવિક પ્રીફિક્સ અને સબનેટ સામે રૂટ લખો

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

રૂટ બનાવો, પછી કોષ્ટકને વર્કલોડ ધરાવતા સબનેટ સાથે બાંધો:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

પ્રસાર પણ મહત્વપૂર્ણ છે. તે કોષ્ટક પર BGP પ્રસાર સક્ષમ હોય ત્યારે શીખેલા પ્રીફિક્સ તમે લખેલા પ્રીફિક્સની બાજુમાં દેખાય છે, અને વધુ ચોક્કસ શીખેલું પ્રીફિક્સ વિશાળ UDR ને હરાવી શકે છે. પ્રસાર ફક્ત ત્યારે અક્ષમ કરો જ્યારે તમે ઇચ્છો કે UDR સમૂહ તે સબનેટ માટે સત્તાવાર હોય.

ઓન-પ્રેમિસ અડધો ભાગ પૂરો કરો, નહીંતર પ્રવાહ ત્યાં જ મરી જાય છે

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

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

સિલેક્ટર અને મંજૂરી સૂચિઓ આ બધાથી અલગ છે. Azure આગલા હોપને પસંદ કરવાથી VPN ટ્રાફિક સિલેક્ટર પહોળા થતા નથી, અને તે બાહ્ય સેવાની સ્રોત મંજૂરી સૂચિ બદલતું નથી.

ગંતવ્ય જુએ છે તે સ્રોત સાથે ચકાસો

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

પસંદ કરેલા પ્રીફિક્સ દ્વારા ટ્રાન્ઝિટ ફોર્સ્ડ ટનલિંગ કરતાં ઘણો સાંકડો ફેરફાર છે. તેને સાંકડો રાખો અને પાછું ફેરવવું એટલે એક રૂટ કાઢી નાખવો.