EC2-ը հասանելիության գոտիներում. ստուգեք երթուղավորումը VPN-ից առաջ

Նախքան երկու EC2 օրինակների միջև VPN ծրագրակազմ տեղադրելը, պատասխանեք մեկ հարցի. արդյո՞ք նրանք նույն VPC-ում են: Եթե այո, մասնավոր ուղին արդեն գոյություն ունի, և գոտիների միջև տեղաբաշխումը դա չի փոխում: Այս իրավիճակում աշխատանքի մեծ մասը հաստատելն է, թե յուրաքանչյուր ենթացանց իրականում որ երթուղային աղյուսակն է օգտագործում, և ապա պարզելը, թե արդյոք խափանումը ընդհանրապես երթուղավորման խնդիր էր: Թունելը սովորաբար սխալ պատասխան է այս կոնկրետ հարցին:

Ստուգում 1. նույն VPC, թե տարբեր VPC-ներ

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

Տարբեր VPC-ները երբեք մասնավոր երթուղի չեն ստանում միայն այն պատճառով, որ կիսում են տարածաշրջան կամ գոտու պիտակ: Այդ դեպքը պահանջում է աջակցվող կապ և սեփական աշխատանք երթուղիների ու թույլտվությունների վրա, ինչը առանձին որոշում է:

Ստուգում 2. ինչ են ասում ենթացանցերի երթուղային աղյուսակները

Գրառեք դասավորությունը իրական արժեքներով: VPC-ն 10.60.0.0/16 հասցեում, 10.60.1.0/24 և 10.60.2.0/24 ենթացանցերով, 10.60.1.10 և 10.60.2.20 օրինակներին ուղի է տալիս VPC-ի տեղական երթուղով:

Այնուհետև ստուգեք երկու ենթացանցերին կապված աղյուսակները, ոչ միայն այն, որն առաջինը գտաք: Ավելի կոնկրետ ստուգման կամ սարքի երթուղին կարող է փոխարինել հիմնականին, և տեղական երթուղու նպատակակետն ինքը կարող է փոխարինվել նոր կազմաձևերում: Կոնսոլում ինչ-որ տեղ երևացող տեղական երթուղին չի ապացուցում, որ երկու աշխատանքային բեռներն էլ օգտագործում են այն:

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

Ստուգում 3. երթուղավորում, թե լիազորում

Երթուղավորումը փաթեթը հասցնում է միայն նպատակակետի ցանցային միջերեսին: Նպատակակետի անվտանգության խումբը դեռ պետք է թույլ տա աղբյուրն ու ծառայությունը, աղբյուրի ելքային կանոնները պետք է թույլ տան հարցումը, և ցանկացած ցանցային ACL պետք է թույլ տա երկու ուղղությունները, քանի որ ACL-ները վիճակ չեն պահում:

Դրանցից այն կողմ են հյուրի ֆայրվոլը, լսողի կապակցումը և հավելվածի սեփական ինքնությունը: Դրանցից յուրաքանչյուրը կարող է մերժել հարցում, որը երթուղավորումը կատարյալ հասցրել էր:

Ընդունումը պետք է լինի հավելվածի իրական գործողությունը: Հաջող ping-ը հավելվածի հասանելիություն չի տալիս և չի ապացուցում, որ TLS անունն ու հավատարմագրերը ճիշտ են, իսկ արգելափակված ping-ը չի հաստատում, որ բոլոր մասնավոր ծառայություններն անջատված են:

Ստուգում 4. արդյո՞ք իսկապես առանձին կապ է պետք

VPN-ը դեռ կարող է լինել նախագծում, բայց նշված պատճառով. այս VPC-ն գրասենյակին միացնելը, նոթբուքերին թույլ տալը կամ ծածկույթի պահանջը բավարարելը։ Այդ պատճառը տարբերվում է նույն VPC-ի ներսում սովորական հաղորդակցությունից:

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

Ստուգում 5. գաղտնագրման հարցը

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

Նախագծի նշումում ցանցային և հավելվածային շերտերի պնդումները առանձին պահեք, քանի որ դրանց միավորումն է այն ձևը, որով վերանայումը վերջում պնդում է պաշտպանություն, որը ոչ ոք չի իրականացրել:

Ինչ գրանցել

Գրանցեք ենթացանցերի երկու նույնացուցիչները, յուրաքանչյուրին կապված երթուղային աղյուսակը, անվտանգության խմբերի հղումները և ձեր փորձարկած հավելվածի գործողությունը: Դրանք չորս փաստ են, և դրանք լուծում են այս ուղու մասին ապագա վեճերի մեծ մասը:

Միայն գոտում տեղաբաշխումը երբեք չի ասում ձեզ ավելացնել VPN, և երբեք չի բացատրում, թե ինչու մասնավոր հարցումը ձախողվեց: