Մասնավոր DNS-ը աշխատում է VPC-ում, բայց ոչ VPN-ով
Ծածուկ անուն, որը լուծվում է EC2-ի ներսում, բայց ոչ VPN-ով, resolver-ի ուղու խնդիր է։ Կարդացե՛ք խափանման ձևը, նախքան գոտու գրառումը խմբագրելը։
Մասնավոր անունը լուծվում է EC2 ինստանսից, բայց ոչ VPN-ով միացված նոթբուքից, և գոտին վահանակում ճիշտ տեսք ունի։ Առաջին ազդակը գրառումը խմբագրելն է, ինչը գրեթե երբեք խնդիրը չէ։ Գրառումը ինչ-որ մեկին պատասխանում է. պարզապես ձեր նոթբուքին չի պատասխանում։ Երկու կանչողների տարբերությունն այն է, թե որ resolver-ին են հարցնում և արդյոք այդ resolver-ն ունի աջակցվող ուղի դեպի VPC-ի DNS տեսքը։
Սկսում եմ ապացուցելով, որ գրառումը գոյություն ունի, իսկ մնացած ժամանակը տրամադրում եմ հարցման ուղուն։ Դրանք առանձին համակարգեր են և ձախողվում են տարբեր ձևերով։
Կարդացե՛ք խափանման ձևը, նախքան ինչ-որ բան փոխելը
Երեք արդյունք նշանակում են երեք տարբեր բան, և մեկ հարցում դրանք տարբերում է. գործարկե՛ք dig անվան համար այն resolver-ի դեմ, որը հաճախորդն իսկապես օգտագործում է։
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Ժամանակի սպառումը ցանցի մասին պնդում է։ NXDOMAIN-ը DNS տեսքի մասին պնդում է։ Հանրային պատասխանը քաղաքականության մասին պնդում է։ Ժամանակի սպառման ընթացքում գոտու գրառումը խմբագրելը դեն է նետում գործի միակ օգտակար ապացույցը։
Ինչու VPC-ի պլյուս երկու հասցեն հեռավոր resolver չէ
CIDR պլյուս երկու հասցեն տեղական ծառայություն է VPC-ի ներսում գտնվող ռեսուրսների համար։ AWS-ը փաստագրում է, որ տեղական ցանցերից կամ մեկ այլ VPC-ի DNS սերվերներից հարցումները ուղղակիորեն այդ հասցեին փոխանցելը չի աջակցվում և կարող է տալ անկայուն արդյունքներ։
Դա չի նշանակում, որ փորձը երբեք չի թվում աշխատող։ Դա նշանակում է, որ վարքը պայմանագիր չէ, որը կարելի է դնել աջակցության սկրիպտի մեջ։ Աջակցվող ուղղությունը մուտքային Resolver endpoint-ն է. ձեր VPC-ի ներսում գտնվող հասցեների զույգ, հասանելի ձեր վերահսկած ցանցից, որն ընդունում է AWS-ից դուրս եկող հարցումներ։
Կառուցե՛ք ուղին այն հերթականությամբ, որով այն մաքուր ձախողվում է
Պետք է գոյություն ունենան երեք թռիչք, և յուրաքանչյուրն ունի ձախողման իր ձևը։
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesՓոխանցիչին անհրաժեշտ է երթուղի դեպի endpoint-ի հասցեները VPN-ով, և վերադարձի ուղին նույնպես պետք է աշխատի։ 53 պորտի սովորական DNS-ի համար endpoint-ը պատասխանում է UDP-ով և TCP-ով, ուստի երկու արձանագրություններն էլ պետք է թույլատրվեն, և երկուսն էլ պետք է դիմանան մեջտեղի ցանկացած վիճակային ստուգման։
Այնուհետև ստուգե՛ք DNS տեսքը առանձին։ Մասնավոր հոսթինգային գոտին տեսանելի է միայն այն VPC-ներին, որոնց հետ կապված է, կամ դիտավորյալ փոխանակման պայմանավորվածության միջոցով։ Հասանելի endpoint-ը ինքնին չի դարձնում ամեն մասնավոր գոտի լուծելի իր լուծման համատեքստում։
Ելքային endpoint-ը ծառայում է հակառակ ուղղությանը և չի պատասխանի ձեր նոթբուքից եկող հարցմանը։
Ստուգե՛ք երկու ծայրերից
Հարցրե՛ք հաճախորդից դեպի փոխանցիչ, այնուհետև փոխանցիչից դեպի endpoint։ Եթե հաճախորդը ձախողվում է, մինչ փոխանցիչը հաջողում է, բացը այդ երկուսի միջև է։
Եթե երկուսն էլ ձախողվում են, նայե՛ք endpoint-ի անվտանգության քաղաքականությանը և այն աղբյուրի հասցեին, որը նա իսկապես տեսնում է։ NAT-ի հետևում գտնվող փոխանցիչը ներկայացնում է NAT-ի հասցեն՝ նոթբուքի VPN հասցեի փոխարեն, և միայն այդ տարբերությունը բավական է հարցումը գցելու համար։ Եթե երկուսն էլ հաջողում են, բայց հավելվածը դեռ ձախողվում է, հավելվածը կարող է օգտագործել այլ resolver, քան ձեր փորձարկածը։
Հանրային և մասնավոր անվանատարածքները դիտավորյալ առանձին պահե՛ք։ Split DNS-ը քաղաքականություն է, որը դուք կարգավորում եք, ոչ թե մեկ որոնման պատահական տվյալ վերադարձնելու կողմնակի ազդեցություն։
Ինչ չէի անի
Չէի ավելացնի NAT կանոն, որը մեկ որոնում աշխատացրեց, և դա չէի անվանի դիզայն։
Չէի ուղղի ամեն հեռավոր հաճախորդին դեպի պլյուս երկու հասցեն միայն այն պատճառով, որ մի թեստ մեկ անգամ գրառում վերադարձրեց։ Եվ չէի ընդլայնի endpoint-ի անվտանգության քաղաքականությունը ամբողջ VPN լողավազանի վրա, երբ մեկ փոխանցիչի է պետք մուտք։ Եթե կազմակերպությունն արդեն վարում է հաստատված փոխանցիչ VPC-ի ներսում, նախ կարդացե՛ք այդ դիզայնը, որովհետև ձեր ավելացրած երկրորդ endpoint-ը հենց այն է, որը ոչ ոք չի փաստագրում։