જ્યારે રિઝોલ્વર પિયર્ડ VNetમાં હોય ત્યારે Azure P2S DNS નિષ્ફળ જાય છે

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

એક લેપટોપની કલ્પના કરો જે VNet2માં ગેટવેમાં ટનલ કરે છે, જ્યારે DNS સેવા આપતું ડોમેન કંટ્રોલર VNet1માં બેઠું છે.

બે ટોપોલોજી, એક ફરક

રિઝોલ્વરને ગેટવેના પોતાના વર્ચ્યુઅલ નેટવર્કમાં મૂકો અને ટનલ ઉપર આવે તે ક્ષણે નામ ઉકેલાઈ જાય છે. કોઈ પણ પિયરિંગ સેટિંગ તે શોધમાં ભાગ લેતું નથી.

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

બાજુ A: ગેટવે માલિક પર ગેટવે ટ્રાન્ઝિટની મંજૂરી આપો

પિયરિંગ બે વર્ચ્યુઅલ નેટવર્ક જોડે છે, પણ આ જોડાણ ગેટવે દ્વારા આવતા ટ્રાફિક માટે ટ્રાન્ઝિટિવ નથી, અને પોઈન્ટ-ટુ-સાઇટ વિનંતી બરાબર એ જ રીતે આવે છે. તેથી VNet2માંનું ગેટવે ડિઝાઇન મંજૂરી આપે ત્યાં સુધી શોધને VNet1ને સોંપવાની સત્તા ધરાવતું નથી. મંજૂરી એ ગેટવે ધરાવતા નેટવર્કની માલિકીના પિયરિંગ પરનું સ્વિચ છે.

VNet2થી VNet1 તરફના પિયરિંગ પર Allow gateway transit સેટ કરો. આ ગુણધર્મ ગેટવે સ્રોતનો નહીં, પિયરિંગ ઑબ્જેક્ટનો છે, તેથી તેને પિયરિંગ બ્લેડમાં વાંચો અને બદલો. આખી બાજુ A આટલી જ છે.

બાજુ B: પિયર પર રિમોટ ગેટવે વાપરો

બીજો અડધો ભાગ અરીસાની પ્રતિબિંબ છે: VNet1થી VNet2 તરફ પાછા પિયરિંગ પર Use remote gateways સક્ષમ કરો. એ જ ફ્લેગ બંને છેડે, અથવા ફક્ત એક છેડે ચાલુ કરવાથી અડધું બનેલું માર્ગ અને મૂળ લક્ષણ અસ્પર્શ રહે છે. ફક્ત VPN ગેટવે ધરાવતું નેટવર્ક ટ્રાન્ઝિટની મંજૂરી આપે છે, અને પિયર એ બાજુ છે જે તેનો ઉપયોગ કરે છે.

છેલ્લે ખોલેલા પોર્ટલ બ્લેડ પર ભરોસો કરવાને બદલે બંને નેટવર્ક પર બંને ગુણધર્મ વાંચો.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

જોડીને સાથે સાથે જોવી એ ઉલટાવેલી ગોઠવણ પકડવાનો સૌથી ઝડપી રસ્તો છે. ગેટવે બાજુ AllowGatewayTransit false જણાવતું પિયરિંગ પેકેટ કેપ્ચર વિના આખી નિષ્ફળતા સમજાવે છે.

ક્લાયન્ટને હજી શું મળવું જોઈએ

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

બીજું કંઈ બદલવા પહેલાં જોડાયેલા લેપટોપથી રિઝોલ્વરને પૂછો.

nslookup dc01.corp.example 10.1.0.4

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

સાઇટ-ટુ-સાઇટ બાજુ પર એ જ કરારની તુલના કરો

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

ટ્રાન્ઝિટ બંને પિયરિંગ પર આપવું પડે છે, અને જે સ્વિચ તે આપે છે તે ક્લાયન્ટ પ્રકાર પર નહીં, પિયરિંગ પર રહે છે.

ગેટવેને દોષ આપવા પહેલાં

Windows દરેક એડેપ્ટર માટે રિઝોલ્વરની યાદી રાખે છે, તેથી ગેટવેને દોષ આપવા પહેલાં ટનલ ઇન્ટરફેસને ખરેખર શું મળ્યું તેની ખાતરી કરો.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

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

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