resolver peered VNet లో ఉన్నప్పుడు Azure P2S DNS విఫలమవుతుంది

VM కి ping చేయండి, అది సమాధానం ఇస్తుంది; దాని పేరు అడగండి, క్లయింట్ host తెలియదని చెబుతుంది. resolver VPN gateway ఉన్న నెట్‌వర్క్‌లో కాకుండా peered వర్చువల్ నెట్‌వర్క్‌లో ఉన్నప్పుడు, ఈ రెండు ఫలితాల జోడి ఆశించదగినది, మరియు resolver ట్రబుల్‌షూటింగ్ ఎంత చేసినా దాన్ని మార్చదు. లేనిది peering డిఫాల్ట్‌గా ఆపుకునే రూటింగ్ ఒప్పందం. రెండు టోపాలజీలు కాగితంపై దాదాపు ఒకేలా కనిపిస్తాయి, పనిచేసే మరియు పగిలిన దాని మధ్య తేడా సరైన దిశలో పెట్టిన ఒక జత peering స్విచ్‌లు.

ఒక ల్యాప్‌టాప్ VNet2 లోని gateway కి టన్నెల్ చేస్తోంది, DNS సేవ చేసే domain controller VNet1 లో కూర్చుంది అని ఊహించండి.

రెండు టోపాలజీలు, ఒక తేడా

resolver ను gateway యొక్క స్వంత వర్చువల్ నెట్‌వర్క్ లోపల పెట్టండి, టన్నెల్ పైకి వచ్చిన క్షణంలో పేరు పరిష్కరమవుతుంది. ఆ శోధనలో ఏ peering సెట్టింగ్ పాల్గొనదు.

అదే resolver ను peering ఆవలికి తరలించండి, క్లయింట్ ఇప్పటికీ VM నుండి సమాధానం పొందుతుంది, పేరు తెలియనిదే ఉంటుంది. సర్టిఫికెట్, టన్నెల్ మరియు క్లయింట్ మారలేదు. కదిలిన ఏకైక విషయం resolver ఎక్కడ నివసిస్తుందో. peering దానికి ఆ చిరునామాకు మార్గం ఇచ్చింది, gateway కి అక్కడికి ట్రాఫిక్ తీసుకెళ్లే అధికారం కాదు.

వైపు A: gateway యజమాని వద్ద gateway ట్రాన్సిట్ అనుమతించండి

peering రెండు వర్చువల్ నెట్‌వర్క్‌లను కలుపుతుంది, కానీ gateway ద్వారా వచ్చే ట్రాఫిక్‌కు ఈ కలయిక ప్రసారకం కాదు, point-to-site అభ్యర్థన సరిగ్గా అలాగే వస్తుంది. అందువల్ల VNet2 లోని gateway డిజైన్ అనుమతించే వరకు శోధనను VNet1 కి అప్పగించే హక్కు లేదు. అనుమతి gateway ఉన్న నెట్‌వర్క్ సొంతమైన peering పై ఉన్న స్విచ్.

VNet2 నుండి VNet1 వైపు peering పై Allow gateway transit సెట్ చేయండి. ఈ లక్షణం gateway వనరుకు కాదు, peering ఆబ్జెక్టుకు చెందుతుంది, కాబట్టి peering బ్లేడ్‌లో దాన్ని చదివి మారుస్తారు. మొత్తం వైపు A ఇంతే.

వైపు B: భాగస్వామిపై రిమోట్ gateway లను ఉపయోగించండి

మిగిలిన సగం అద్దం ప్రతిబింబం: VNet1 నుండి VNet2 కి తిరిగి వెళ్లే peering పై Use remote gateways ప్రారంభించండి. అదే జెండాను రెండు చివరలలో, లేదా ఒక చివరలో మాత్రమే ఆన్ చేయడం సగం నిర్మించిన మార్గాన్ని మరియు అసలు లక్షణాన్ని తాకకుండా వదిలేస్తుంది. VPN gateway ఉన్న నెట్‌వర్క్ మాత్రమే ట్రాన్సిట్‌ను అనుమతిస్తుంది, భాగస్వామి దాన్ని ఉపయోగించే వైపు.

చివరగా తెరిచిన పోర్టల్ బ్లేడ్‌ను నమ్మడం బదులు రెండు నెట్‌వర్క్‌లపై రెండు లక్షణాలను చదవండి.

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

జోడిని పక్కపక్కన చూడటం తలకిందులైన సెట్టింగ్‌ను పట్టుకునే వేగవంతమైన మార్గం. gateway వైపు AllowGatewayTransit false అని నివేదించే peering ప్యాకెట్ క్యాప్చర్ లేకుండానే మొత్తం వైఫల్యాన్ని వివరిస్తుంది.

క్లయింట్ ఇంకా ఏమి పొందాలి

రూటింగ్ అవసరం, సరిపోదు, ఎందుకంటే point-to-site ప్రొఫైల్ ట్రాన్సిట్ పనిచేసిన తర్వాత సమాధానం ఇచ్చే DNS చిరునామాను కూడా క్లయింట్‌కు ఇవ్వాలి. ప్లాట్‌ఫారమ్ resolver ఆ చిరునామా కాదు: వర్చువల్ నెట్‌వర్క్‌కు లింక్ చేసిన Azure Private DNS జోన్‌లకు సమాధానం ఇస్తుంది, కానీ మీ స్వంత డైరెక్టరీ సర్వర్లపై హోస్ట్ చేసిన జోన్‌కు ఏమీ ఇవ్వదు, ఈ డిప్లాయ్‌మెంట్ అదే ఉపయోగిస్తుంది. క్లయింట్‌ను అక్కడికి సూచించండి, పబ్లిక్ పేర్లు సంతోషంగా పరిష్కరమవుతాయి, అంతర్గత host తెలియనిదే ఉంటుంది.

మరేదైనా మార్చే ముందు కనెక్ట్ చేసిన ల్యాప్‌టాప్ నుండి resolver ను అడగండి.

nslookup dc01.corp.example 10.1.0.4

సమయం ముగియడం మార్గం ఇంకా లేదని చెబుతుంది. అధికారిక సమాధానం సమస్యను క్లయింట్ వైపు నెట్టేస్తుంది, సాధారణంగా ఎప్పుడూ చేర్చని ప్రత్యయం, కాబట్టి చిన్న పేర్లు వాటిని సంతోషంగా విఫలం చేసే పబ్లిక్ resolver కి ప్రయాణిస్తాయి.

సైట్-టు-సైట్ వైపు అదే ఒప్పందాన్ని పోల్చండి

వీటిలో ఏదీ ప్రత్యేకంగా ల్యాప్‌టాప్‌లకు చెందినది కాదు. క్లయింట్ స్థానంలో సైట్-టు-సైట్ శాఖను పెట్టండి, రెండు వైపుల షరతు తిరిగి వస్తుంది: శాఖ నేరుగా gateway నెట్‌వర్క్‌కు వస్తుంది, రెండు నెట్‌వర్క్‌ల దూరంలో ఉన్న సేవ ఇంకా peering వెనుక ఉంది.

ట్రాన్సిట్ రెండు peering లపై ఇవ్వాలి, దాన్ని ఇచ్చే స్విచ్ క్లయింట్ రకం మీద కాదు, peering పై నివసిస్తుంది.

gateway ను నిందించే ముందు

Windows ప్రతి అడాప్టర్‌కు resolver జాబితాను ఉంచుతుంది, కాబట్టి gateway ను నిందించే ముందు టన్నెల్ ఇంటర్‌ఫేస్ నిజంగా ఏమి పొందిందో నిర్ధారించండి.

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

ప్రతికూల సమాధానం క్యాష్‌లో రూటింగ్ సవరణ కంటే ఎక్కువ కాలం జీవిస్తుంది, పాత ప్రత్యయ జాబితా జోన్ ఎప్పుడూ హోస్ట్ చేయని చోటికి ప్రశ్నలు పంపడం కొనసాగిస్తుంది. ఫ్లష్ చేయండి, మళ్లీ అడగండి, ఏ సర్వర్ సమాధానం ఇస్తుందో గుర్తించండి.

మార్గం నిలబడుతుందో లేదో రెండు చిన్న షరతులు నిర్ణయిస్తాయి: చిరునామా స్థలాలు ఒకదానిపై ఒకటి అతివ్యాప్తి కాకూడదు, మరియు resolver యొక్క సబ్‌నెట్‌పై ఉన్న నెట్‌వర్క్ భద్రతా సమూహం క్లయింట్ పూల్‌ను అనుమతించాలి, అది మరో మూల పరిధి మాత్రమే. VM వైపు నుండి ప్రభావవంత మార్గ తనిఖీ మరియు క్లయింట్ నుండి ఒక ప్రత్యక్ష ప్రశ్నతో దాన్ని నిరూపించండి, జోన్ సమస్య, ప్రత్యయ సమస్య లేదా ఫిల్టర్ ఎప్పుడూ లేని ట్రాన్సిట్ గా పొరపాటు పడకుండా.