AWS Client VPN-ը միացված է, բայց EC2-ը դեռ չի պատասխանում
Միացված լինելը միայն նշանակում է, որ վկայականը կամ SAML մուտքը աշխատել է: Թույլատրող կանոնները, endpoint-ի երթուղիները և անվտանգության խմբերը յուրաքանչյուրն հսկում է դեպի մասնավոր հոսթ տանող ուղու մի հատվածը:
Իմ նոթբուքը ցույց էր տալիս միացված: AWS Client VPN հաճախորդը ցույց էր տալիս իր կանաչ վիճակը, endpoint-ը գրանցել էր սեսիա, և այնուամենայնիվ ես չէի կարողանում բացել MongoDB պորտ EC2 ինստանսի վրա մասնավոր ենթացանցում: Թվում էր, թե ոչինչ կոտրված չէ. վկայականը վավեր էր, պրոֆիլը եկել էր կոնսոլից, և թունելը տանում էր տրաֆիկ: Սխալը իմն էր, որովհետև ես միացված բառը կարդում էի որպես լիազորված:
Մուտքը պատասխանում է ուղիղ մեկ հարցի. կարո՞ղ է այս ինքնությանը սեսիա հաստատել: Ամեն ինչ դրանից հետո որոշում են առանձին կանոններ, որոնք երբեք չեն տեսնում ձեր վկայականը: Սեսիան, որը նույնականացվում է, և փաթեթը, որը հասնում է, երկու տարբեր հաջողություններ են, և նրանց միջև ընկած բացը այն տեղն է, որտեղ ապրում են VPN-ը միացած է, բայց հոսթը հասանելի չէ տիպի բողոքների մեծ մասը:
Ստորև բերված ստուգումները այն հերթականությունն են, որ հիմա օգտագործում եմ:
Ինչ է իրականում ապացուցում միացված սեսիան
Handshake-ի ընթացքում endpoint-ը վավերացնում է հաճախորդի վկայականը իր trust store-ի դեմ, կամ երբ SAML-ը կարգավորված է, բրաուզերը վերահղում է ձեր ինքնության մատակարարին: Եթե դա անցնում է, հաճախորդը ստանում է հասցե endpoint-ի հաճախորդ CIDR-ից, և կոնսոլը ցույց է տալիս ակտիվ կապ: Այդ փոխանակման ոչ մի պահի որևէ բան չի հարցնում՝ կարո՞ղ եք հասնել 10.0.4.17-ին 27017 պորտով:
Նպատակակետի թույլտվությունը endpoint-ի վրա առանձին օբյեկտ է: Յուրաքանչյուր հոսք համեմատվում է թույլատրող կանոնների հետ, և յուրաքանչյուրը զուգակցում է նպատակակետ CIDR-ը այն խմբի հետ, որին տրված է կանոնը: Երբ ոչ մի կանոն չի ծածկում նպատակակետը, endpoint-ը ընդունում է սեսիան և գցում տրաֆիկը: Ոչ բաններ կա, ոչ վերամիացման հանգույց, և ոչինչ հաճախորդի ինտերֆեյսում, որ ասի մերժված:
Համեմատեք թույլատրող կանոնը ռեսուրսի հետ, ոչ VPC-ի
Թվարկեք կանոնները և դրեք դրանք այն հասցեի կողքին, որն ինստանսը իրականում ունի:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8Արդյունքը ցույց է տալիս նպատակակետ CIDR և խմբի ID յուրաքանչյուր կանոնի համար: Դրա մեջ թաքնված են երկու խափանում: Կանոնը կարող է թույլատրել 10.0.0.0/16, մինչ ինստանսը գտնվում է 10.1.0.0/16-ի վրա peer արված VPC-ում. peering երթուղին գոյություն ունի, բայց ոչ ոք չի գրել թույլատրող կանոն երկրորդ տիրույթի համար: Կամ կանոնը մատնանշում է գրացուցակի խմբի, որին օգտատերը պատկանում է գրացուցակում, բայց ոչ այն խմբում, որը գնահատում է endpoint-ը:
Գրեք ամենանեղ կանոնը, որը ծածկում է նպատակակետը, և երկրորդը ավելացրեք միայն այն ժամանակ, երբ երկրորդ CIDR-ն իսկապես անհրաժեշտ է: Արագ մեկնարկից եկած լայն 0.0.0.0/0 կանոնը աշխատում է, և հենց դրա համար է այն գոյատևում մինչև արտադրություն և թաքցնում մոդելը:
Երկու երթուղային աղյուսակներ են որոշում՝ փաթեթը կշարժվի՞
Endpoint-ի երթուղին քարտեզագրում է նպատակակետ CIDR-ը endpoint-ի հետ կապված ենթացանցերից մեկին: Դա ուղու կեսն է: Ենթացանցի սեփական երթուղային աղյուսակը դեռ պետք է իմանա, թե ինչպես փոխանցել փաթեթը, և դա կարևոր է այն պահին, երբ նպատակակետը գտնվում է peering կապի, transit gateway-ի կամ site-to-site թունելով հասանելի տեղական տիրույթի հետևում:
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8Փնտրեք երթուղի, որի նպատակակետը համընկնում է ռեսուրսի CIDR-ի հետ, և որի թիրախը կապված ենթացանց է: Եթե երթուղին բացակայում է, ավելացրեք: Եթե այն կա, և հոսթը դեռ լուռ է, բացը VPC-ի կողմում է, ուրեմն համեմատեք միացման ենթացանցի երթուղային աղյուսակի հետ:
Հաճախորդի կողմի մեկ կարգավորում կոտրում է երթուղավորումը՝ չկոտրելով թունելը. route-nopull պարունակող պրոֆիլ: Հրահանգն ասում է OpenVPN-ի վրա հիմնված հաճախորդին անտեսել սերվերի մղած երթուղիները, այնպես որ ինտերֆեյսը բարձրանում է միայն endpoint-ի սեփական հասցեով, և նպատակակետը պարզապես երթուղի չունի: Ստուգեք ip route show-ով Linux-ում կամ netstat -rn-ով macOS-ում, թե արդյոք tun ինտերֆեյսով երթուղի կա: Եթե չկա, հեռացրեք route-nopull-ը արտահանված պրոֆիլից և նորից միացեք, որպեսզի մղված երթուղիները կիրառվեն:
Անվտանգության խմբերը չեն տեսնում ձեր հաճախորդի հասցեն
Սա այն մասն է, որտեղ ես մի ամբողջ կեսօր սխալ էի: Ենթացանցի հետ կապված IPv4 endpoint-ի համար ծառայությունը հաճախորդի աղբյուրի հասցեն թարգմանում է endpoint-ի ցանցային ինտերֆեյսի հասցեին այդ ենթացանցում: Ինստանսին հասնող փաթեթը չի կրում այն հասցեն, որը ցույց էր տալիս ձեր հաճախորդը, ուստի հաճախորդների լողավազանը, ասենք 172.16.0.0/22, թույլատրող անվտանգության խմբի կանոնը ոչնչի հետ չի համընկնում:
Թույլատրեք պորտը endpoint-ի անվտանգության խմբից, որը կցված է միացման ինտերֆեյսին, ոչ թե հաճախորդի CIDR-ից: Խմբին հղումը ավելի դիմացկուն է, քան հասցեի կոշտ կոդավորումը, որովհետև ինտերֆեյսի հասցեն ձեր վերահսկողության տակ չէ: Ցանցային ACL-ները անվիճակ են, ուստի որտեղ կան հատուկ գրառումներ, և՛ մուտքային, և՛ ելքային ուղղությունը պետք է թույլատրի հոսքը:
Միացեք նաև ինստանսի մասնավոր հասցեով: Հանրային IP-ն փաթեթը դուրս է տանում VPC-ից և հետ բերում այլ ուղով՝ այլ կանոններով, ուստի հանրային հասցեով փորձարկումը ոչինչ չի ասում մասնավոր ուղու մասին:
Մեկուսացման կարգ, որը կանգ է առնում առաջին խափանման վրա
Անցեք դրանց հերթականությամբ և կանգ առեք այնտեղ, որտեղ մեկը ձախողվում է: Յուրաքանչյուր քայլ բացառում է մեկ շերտ, ոչ բոլորը:
- Հաստատեք, թե որ ինքնությունն է օգտագործել սեսիան և որ խումբն է գնահատում endpoint-ը: Մեկ trust store-ի վկայականը նույն սուբյեկտը չէ, ինչ գրացուցակից եկած SAML պնդումը:
- Հաստատեք, որ թույլատրող կանոնը ծածկում է ռեսուրսի CIDR-ը այդ խմբի համար:
- Հաստատեք, որ endpoint-ի երթուղին գոյություն ունի և ուղղված է կապված ենթացանցին, ապա որ ենթացանցի երթուղային աղյուսակը կարող է առաջ փոխանցել:
- Հաստատեք, որ անվտանգության խումբը թույլատրում է պորտը endpoint-ի ինտերֆեյսից, ոչ հաճախորդների լողավազանից:
- Փորձարկեք VPC-ի ներսից՝ SSM սեսիայով նույն ենթացանցի մեկ այլ ինստանսի վրա, որպեսզի առանձնացնեք հավելվածի խնդիրը հաճախորդի ուղու խնդրից:
Երբ քայլերը վճռական չեն, ես ապավինում եմ այս աղյուսակին:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
Հաշվի երկու մանրամասնություն առաջացնում են ախտանիշներ, որոնք նման են թույլտվության խափանումների: Յուրաքանչյուր օգտատիրոջ պետք է առանձին հաճախորդի վկայական. մեկը երկու մեքենաների միջև կիսելը ստիպում է սեսիաներին միմյանց դուրս մղել, և արդյունքը վերամիացման հանգույց է, ոչ թե մերժում: Երբ ստեղծվում է նոր endpoint, կոնսոլը ցույց է տալիս DNS անուն, որը հաճախորդի որոշ տարբերակներ ընդունում են միայն endpoint-ի էջում ցուցադրված պատահական նախածանցով, ուստի պատճենեք ամբողջ անունը՝ այն վերակառուցելու փոխարեն:
Եթե հինգերորդ քայլը ձեզ կանգնեցնում է, քաշեք endpoint-ի կապի մատյանը և կարդացեք թույլատրման գրառումները՝ նախքան որևէ բան փոխելը: Մատյանը նշում է ստուգված նպատակակետը և այն կանոնը, որը համընկել է կամ չի համընկել, և դա չորս շերտանի հարցը հանգեցնում է մեկ պատասխանի: