Azure P2S DNS-ը ձախողվում է, երբ resolver-ը զուգակցված VNet-ում է

Հաճախորդը կարող է հասնել իր վիրտուալ ցանցին և այնուամենայնիվ չկարողանալ լուծել անունները զուգակցված ցանցում: Peering-ը gateway-ի տրանզիտ չէ, քանի դեռ երկու կողմերը չեն ասում դա:

Ping արեք VM-ին և այն պատասխանում է. հարցրեք նրա անունը և հաճախորդն ասում է, որ host-ը անհայտ է: Երբ resolver-ը գտնվում է զուգակցված վիրտուալ ցանցում, այլ ոչ այն ցանցում, որը պարունակում է VPN gateway-ը, արդյունքների այս զույգը սպասելի է, և 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-ին, քանի դեռ դիզայնը դա չի թույլատրում: Թույլտվությունը peering-ի վրա գտնվող անջատիչ է, որը պատկանում է gateway-ը պարունակող ցանցին:

Սահմանեք Allow gateway transit VNet2-ից VNet1 ուղղված peering-ի վրա: Հատկությունը պատկանում է peering օբյեկտին, ոչ gateway ռեսուրսին, ուստի այն կարդում և փոխում եք 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

Զույգը կողք-կողքի տեսնելը շրջված կարգավորումը բռնելու ամենաարագ ճանապարհն է: Peering-ը, որը gateway-ի կողմում հաղորդում է AllowGatewayTransit false, բացատրում է ամբողջ ձախողումը առանց փաթեթի որսման:

Ինչ դեռ պետք է ստանա հաճախորդը

Երթուղավորումը անհրաժեշտ է և ոչ բավարար, քանի որ point-to-site պրոֆիլը պետք է հաճախորդին տա նաև DNS հասցե, որը պատասխանում է տրանզիտի աշխատելուց հետո: Հարթակի resolver-ը այդ հասցեն չէ. այն պատասխանում է վիրտուալ ցանցին կապված Azure Private DNS գոտիներին, բայց ոչինչ ձեր սեփական գրացուցակի սերվերներում հոսթինգ արված գոտու համար, և հենց դա է օգտագործում այս տեղադրումը: Ուղղեք հաճախորդին դրան, և հանրային անունները ուրախությամբ լուծվում են, մինչ ներքին host-ը մնում է անհայտ:

Հարցրեք resolver-ին միացված նոութբուքից նախքան որևէ այլ բան փոխելը:

nslookup dc01.corp.example 10.1.0.4

Ժամանակի սպառումը ասում է, որ ուղին դեռ բացակայում է: Հեղինակավոր պատասխանը խնդիրը հետ է մղում հաճախորդին, սովորաբար վերջածանց, որը երբեք չի ավելացվում, ուստի կարճ անունները գնում են հանրային resolver, որը ուրախությամբ ձախողում է դրանք:

Համեմատեք նույն պայմանագիրը site-to-site կողմում

Սրանից ոչինչ հատուկ չէ նոութբուքերին: Փոխարինեք հաճախորդին site-to-site մասնաճյուղով, և երկկողմ պահանջը վերադառնում է. մասնաճյուղը ուղղակիորեն գալիս է gateway ցանց, և երկու ցանց հեռավորության վրա գտնվող ծառայությունը դեռ peering-ի հետևում է:

Տրանզիտը պետք է տրվի երկու peering-ներում, և այն տվող անջատիչը ապրում է peering-ի վրա, ոչ թե հաճախորդի տիպի:

Նախքան gateway-ին մեղադրելը

Windows-ը յուրաքանչյուր ադապտերի համար պահում է resolver-ների ցանկ, ուստի հաստատեք, թե ինչ իրականում ստացավ թունելի ինտերֆեյսը, նախքան gateway-ին մեղադրելը:

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

Բացասական պատասխանը քեշում ապրում է երթուղային ուղղումից ավելի երկար, և հնացած վերջածանցների ցանկը շարունակում է հարցումներ ուղարկել մի տեղ, որտեղ գոտին երբեք չի հոսթինգ արվել: Մաքրեք, նորից հարցրեք և նշեք, թե որ սերվերն է պատասխանում:

Երկու ավելի փոքր պայման է որոշում՝ ուղին կմնա՞: հասցեների տարածքները չպետք է համընկնեն, և resolver-ի ենթացանցի ցանցային անվտանգության խումբը պետք է ընդունի հաճախորդների լողավազանը, որը ընդամենը ևս մեկ աղբյուրի տիրույթ է: Ապացուցեք դա VM-ի կողմից արդյունավետ երթուղու ստուգմամբ գումարած մեկ ուղղակի հարցում հաճախորդից, որպեսզի գոտու խնդիրը, վերջածանցի խնդիրը կամ ֆիլտրը երբեք չշփոթվեն բացակայող տրանզիտի հետ:

Առնչվող հոդվածներ