Ներքին ALB հանրային DNS անունով՝ արդյոք այն իրոք բաց է։

Կատարեք հանրային DNS հարցում ներքին բեռնվածքի հավասարակշռիչի նկատմամբ և կարող եք մասնավոր հասցե ստանալ, ինչը սխալ կարգավորում է թվում այնքան ժամանակ, քանի դեռ չեք ստուգել, թե ինչի համար է գրառումը։ AWS-ը փաստում է, որ ներքին հավասարակշռիչների անունները կարող են հանրային լուծելի լինել, մինչդեռ դրանց հանգույցները պահում են միայն մասնավոր հասցեներ։ Resolver-ը պատասխանեց, թե որտեղ է ծառայությունը՝ այն չստեղծեց ուղի, չբացեց անվտանգության խումբ և ոչ մեկին չհաստատեց։ Արդյոք այդ պատասխանը խնդիր է, կախված է փաստերից, որոնք կարող եք ստուգել հերթով։

Առաջին քայլը՝ կարդացեք սխեման, ոչ թե IP-ն

Սխեմայի դաշտը հենց հավասարակշռիչի հայտարարությունն է իր սահմանի մասին։ aws elbv2 describe-load-balancers --names app-internal-ը վերադարձնում է Scheme՝ internal կամ internet-facing արժեքով, գումարած հասցեի տեսակ IPv4-ի կամ կրկնակի ստեկի համար։ Ինտերնետին ուղղված հավասարակշռիչը դեռ կարող է փոխանցել մասնավոր թիրախներին, ուստի մասնավոր backend հասցեներ տեսնելը ոչինչ չի ապացուցում առջևի մասի մասին։

Գրեք սխեման նախքան որևէ այլ բան նայելը, քանի որ յուրաքանչյուր հետագա դատողություն կախված է դրանից։ Այն նաև ասում է, թե ինչ հսկողություններ կան՝ անվտանգության խմբերից և listener-ի կանոններից մինչև այդ տիպի հավասարակշռիչի հատկությունները։ Հին կոնսոլի սքրինշոթից պատճենված սխեման ավելի վատ է, քան ոչ մի նշում։ Կրկին կարդացեք API-ից և տեղադրեք արժեքը տոմսի մեջ։

Երկրորդ քայլը՝ տեսեք, թե անունն ինչի է լուծվում

Հարցրեք VPC-ից դուրս dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com-ով և նշեք՝ արդյոք պատասխանները 10.0.0.0/8, 172.16.0.0/12 կամ 192.168.0.0/16 միջակայքում են։ Հանրային resolver-ից մասնավոր պատասխանը ներքին հավասարակշռիչի անվան համար սպասվող վարքն է՝ դա ապացույց չէ, որ հասցեն ինտերնետից երթուղելի է։

Լուծեք նույն անունը VPC-ի ներսից և համեմատեք։ Եթե երկու պատասխանները տարբերվում են, դուք տեսնում եք split-horizon անվանակոչում, և այդ տարբերությունը դիզայնի մանրամասն է, ոչ արտահոսք։

Երրորդ քայլը՝ թվարկեք ուղիները, որոնք կարող են հասնել այնտեղ

Մասնավոր հասցեն հասանելի է այնտեղ, որտեղ կա ուղի և անվտանգության կանոն։ Թվարկեք դրանք դիտավորյալ՝ site-to-site VPN, client VPN, VPC peering, transit gateway միացումներ, Direct Connect և ցանկացած proxy կամ bastion VPC-ի ներսում։ Դրանցից մեկը նախատեսված ուղին է, իսկ մնացածը՝ նրանք, որոնք հարձակվողը կփնտրեր։

Այնուհետև ստուգեք յուրաքանչյուր ուղու հսկողությունները՝ անվտանգության խմբերը հավասարակշռիչի վրա, ցանցային ACL-ները ենթացանցերում և երթուղավորումը, որն ընդհանրապես ստեղծում է ուղին։ Բաց ներքին ծառայության մասին հայտնված դեպքերի մեծ մասը լուծվում է այստեղ՝ կա՛մ չնախատեսված peering կար, կա՛մ ուղին նախատեսված էր, և հավելվածը չուներ նույնականացում։

Չորրորդ քայլը՝ փորձարկեք listener-ը և հավելվածը առանձին

Փորձեք միանալ ցանցից, որը չպետք է հասնի ծառայությանը, և հաստատեք, որ չեք կարող։ Ապա փորձեք այն ցանցից, որը պետք է, և հաստատեք, որ հասնում եք listener-ի։ Այս երկու արդյունքները բաժանում են ցանցային հասանելիությունը հավելվածի վարքից, և դրանք միակ ապացույցն են, որ նշանակություն ունի բացվածության հարցում։

Հասանելի listener-ը նույնը չէ, ինչ մատչելի հավելվածը։ Ստուգեք TLS վկայականը և արձանագրության քաղաքականությունը, ապա հավելվածի սեփական նույնականացումն ու լիազորումը։ Ներքին գործիքը, որն ընդունում է ցանկացած զանգահարողի կորպորատիվ VPN-ում, բաց է այդ VPN-ի յուրաքանչյուր վտանգված նոութբուքի առաջ, ինչը տարբեր ռիսկ է, քան ինտերնետին ուղղվածը, բայց դեռ ռիսկ է։

Հիշեք, որ հսկողությունները տարբերվում են ըստ տեսակի։ Հավելվածային շերտի firewall-ները կցվում են հավասարակշռիչների մի ընտանիքին, ոչ մյուսին, ուստի հաստատեք, թե ինչ է իրականում հասանելի ձեր առջևի սխեմայի և տեսակի համար՝ փոխարենը ենթադրելու հավասարություն։

Հինգերորդ քայլը՝ որոշեք՝ արդյոք անունն ինքն է կարևոր

Հանրային լուծելիությունը կարող է բացահայտել ծառայության անուն, տարածաշրջան և հասցեների տիրույթ։ Վերաբերվեք դրան որպես տեղեկատվության բացահայտման հարց՝ քաղաքականության պատասխանով, ոչ որպես ինքնաբերական միջադեպ՝ զգայուն բիզնես տերմինները պահեք ռեսուրսների անուններից դուրս, և գրանցեք բացահայտումը ձեր ռիսկերի մատյանում, եթե անվանակոչման կանոնը բացահայտում է ավելին, քան ցանկանում եք։

Եթե կազմակերպությունը ցանկանում է մասնավոր անվանակոչման փորձ, մասնավոր hosted zone-ը կարող է alias մատուցել, որը լուծվում է միայն կապակցված VPC-ների ներսում։ Դա փոխում է այն անունը, որ տեսնում են օգտատերերը՝ չի գաղտնիացնում մատակարարի ստեղծած անունը և չի հեռացնում ոչ մի ցանցային ուղի։

Մի՛ փորձեք ամրացնել հասցեները պատասխանը թաքցնելու համար։ Հավասարակշռիչի հասցեները փոխվում են, ամրացումը փչացնում է TLS ստուգման սովորությունները, և հսկողությունը, որն իրոք պետք է, այն է՝ ով կարող է կապ հաստատել և ինչ է հավելվածը պահանջում նրանցից։ Ստուգեք չորս փաստերը, գրեք դրանք, և հարցը դադարում է երկիմաստ լինելուց։