Azure-ի մասնավոր DNS-ը VPN-ի վրայով՝ resolver-ի վերջնակետ թե forwarder
Երկու ձևավորումներն էլ պատասխանում են մասնավոր գոտիներին թունելով։ Համեմատեք կառավարվող ներգնա վերջնակետը forwarder VM-ի հետ, ապա ստուգեք այն ուղին, որը պետք է գոյություն ունենա ամեն դեպքում։
Տեղական ցանցի սերվերը հասնում է Azure VM-ին մասնավոր հասցեով և այնուամենայնիվ չի կարողանում լուծել նրա մասնավոր հոսթի անունը, ինչը մարդկանց ստիպում է կոտրված թունել փնտրել։ Թունելը կարգին է։ Բացակայում է DNS սահմանը. տեղական կողմում ոչ ոք չգիտի, որ որոշակի Azure մասնավոր գոտուն պետք է պատասխանի VNet-ի ներսում գտնվող resolver-ը։ Երկու ձևավորում փակում են այդ բացը, և դրանք տարբերվում են նրանով, թե ինչ եք ի վերջո շահագործում, ոչ թե նրանով, թե արդյոք հարցումները աշխատում են։
Թունելը տեղափոխում է հարցումներ, ոչ թե գոտիների գիտելիք
Site-to-site կապը փաթեթներին երթուղի է տալիս երկու ցանցերի միջև։ Այն չի ասում տեղական DNS սերվերին, թե որ անվանատարածքն է պատկանում Azure-ին կամ որ հասցեն պետք է պատասխանի, ուստի հարցումը կամ գնում է ինտերնետ և վերադառնում դատարկ, կամ երբեք չի լքում տեղական resolver-ը։
Ուղղումը երկու կես ունի, որոնք հեշտ է առանձնացնել։ Մի կեսը VNet-ի ներսում գտնվող resolver-ն է, որն ընդունում է թունելով եկող հարցումները։ Մյուս կեսը տեղական կողմի պայմանական forwarder-ն է, որն ուղարկում է ուղիղ մեկ անվանատարածք այդ resolver-ին։ Ոչ մի կես առանձին չի աշխատում։
Ենթադրենք, որ գոտին cloud.corp.example է այս նկարագրության մնացած մասի համար, և բոլոր հասցեները դիտարկեք որպես օրինակ։
Տարբերակ A՝ կառավարվող ներգնա վերջնակետ
Azure DNS Private Resolver-ը տրամադրում է ներգնա վերջնակետ, որն ընդունում է DNS հարցումներ VNet-ից դուրս։ Դուք տեղադրում եք այն հատուկ պատվիրակված ենթացանցում, կապում մասնավոր գոտին այդ VNet-ին և գրանցում այն ներգնա հասցեն, որը ծառայությունը հատկացնում է։
Այնուհետև տեղական DNS սերվերի վրա ստեղծում եք պայմանական forwarder ճշգրիտ անվանատարածքի համար դեպի այդ հասցեն.
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-ի հիբրիդ DNS ընթացակարգը փաստագրում է և՛ գոտու կապը, և՛ forwarder-ի քայլը։ Կառավարվող ուղին ձեզ չի թողնում կարկատելու DNS ծրագրակազմ, իսկ վերջնակետի հասցեն մնում է կայուն ռեսուրսի ողջ կյանքի ընթացքում։
Գինը այն է, որ դուք այժմ ունեք resolver ռեսուրս, նրա ենթացանցի պատվիրակումը և դրա ծախսը, ինչը իրական է նույնիսկ շատ փոքր հարցումների ծավալի դեպքում։
Տարբերակ B՝ forwarder VM VNet-ի ներսում
Ավելի հին ձևավորումը DNS ծրագրակազմ է աշխատեցնում VNet-ի սովորական VM-ի վրա՝ Windows DNS, BIND կամ dnsmasq, ընդ որում մասնավոր գոտին կամ տեղական է հոսթավորվում, կամ փոխանցվում է 168.63.129.16 հասցեով Azure resolver-ին։ Տեղական պայմանական forwarder-ը ուղղված է այդ VM-ի մասնավոր հասցեին։
Այս տարբերակը ծանոթ է այն թիմերին, որոնք արդեն շահագործում են DNS սերվերներ, և այն կարող է կրել լրացուցիչ տրամաբանություն, օրինակ՝ մատյանագրում կամ split-horizon պատասխաններ։ Այն նաև ժառանգում է DNS սերվերի բոլոր գործառնական պարտականությունները՝ կարկատում, երկրորդ օրինակ՝ հասանելիության համար, մոնիտորինգ և վերակառուցման ուղի, երբ VM-ը փոխարինվում է և նրա հասցեն փոխվում։
Սովորական VNet հոսթը DNS փրոքսի չէ, քանի դեռ ծառայությունը տեղադրված չէ և թույլտվություն չի ստացել պատասխանել այդ հաճախորդներին, և հենց այդ քայլն են մարդիկ բաց թողնում VM կլոնավորելիս։
Որն է համապատասխանում ձեր շահագործմանը
Համեմատությունը չի վերաբերում նրան, թե որ ձևավորումն է ավելի արագ։ Այն վերաբերում է նրան, թե արդյոք դուք ընդհանրապես ուզում եք շահագործել DNS ծրագրակազմ, և արդյոք հարցումների ծավալը արդարացնում է կառավարվող ռեսուրս, որը հաշվարկվում է ըստ վերջնակետի և ըստ հարցման։
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Որ տողն էլ որոշի, տեղական forwarder-ի կանոնը նույնն է թվում։ Հենց այս մասն է, որ պետք է գոյություն ունենա երկու ձևավորումներում էլ, և հենց այս մասն է ամենից հաճախ բացակայում, երբ ինչ-որ մեկը հայտնում է, որ լուծումը աշխատում է Azure-ի ներսից, բայց ոչ գրասենյակից։
Ստուգեք ուղին հերթականությամբ
Հաստատեք, որ գոտին կապված է այն VNet-ին, որտեղ գտնվում է resolver-ը, և որ տեղական forwarder-ը նշում է անվանատարածքը, այլ ոչ ծնող տիրույթ։ corp.example-ի forwarder-ը չի համընկնի cloud.corp.example-ի հետ, եթե resolver-ն ինքը չպատվիրակի, և այդ անհամապատասխանությունը տալիս է մաքուր բացասական պատասխան, որը նման է բացակայող գրառման։
Այնուհետև ստուգեք, որ հարցումը հասնում է վերջնակետին. տեղական աղբյուրին անհրաժեշտ է երթուղի դեպի resolver-ի հասցեն և վերադարձի ուղի, և 53 պորտը պետք է թույլատրվի և՛ UDP-ով, և՛ TCP-ով այնտեղ, որտեղ քաղաքականությունը թույլ է տալիս։ NSG-ն չի կարող տրամադրել բացակայող գոտու գրառում, և ճիշտ գոտին չի կարող պատասխանել այն հարցմանը, որը երբեք չի հասնում։
Ախտորոշելիս պահեք պահանջված FQDN-ը ընտրված resolver-ի կողքին, և տարանջատեք ժամանակի սպառումը բացասական պատասխանից։ Ժամանակի սպառումը ուղու կամ քաղաքականության խնդիր է։ Բացասական պատասխանը նշանակում է, որ հարցումը հասավ, և անվանատարածքը չհամընկավ։ Աշխատանքի կարգը՝ կապեք գոտին, ավելացրեք պայմանական forwarder-ը, բացեք 53 պորտը երկու ուղղությամբ, փորձեք մեկ անուն տեղականից, և միայն դրանից հետո նայեք հավելվածի սեփական լիազորությանը։