Ինչու EC2-ն չի կարող հասնել ձեր AWS Client VPN նոութբուքին
Client VPN-ը IPv4 հաճախորդի աղբյուրները թարգմանում է վերջնակետի ինտերֆեյսին: Այդ պատճառով պատասխանը աշխատում է, իսկ EC2-ից նոր միացումը՝ ոչ։
AWS Client VPN-ի միջոցով միացված նոութբուքը առանց խնդիրների հասնում է EC2 հավելվածին։ Այնուհետև փորձում եք հակառակը՝ EC2-ից դեպի հաճախորդին տրված հասցեն, և միացումը կախվում է կամ մերժվում։ Այդ անհամաչափությունը հազվադեպ է բացակայող անվտանգության խմբի կանոն։ VPC ենթացանցերին կապված Client VPN վերջնակետում AWS-ը IPv4 հաճախորդի աղբյուրները թարգմանում է վերջնակետի ցանցային ինտերֆեյսին, ուստի չկա ներգնա VPC հասցե, որը ներկայացնի ձեր նոութբուքը։
Սկսեք նրանից, ինչ ցույց է տալիս գրավումը
Գրավում կատարեք EC2 հոսթի վրա, մինչ հաճախորդը միանում է, և կարդացեք աղբյուրի հասցեն, որն իրականում տեսնում է հավելվածը։ Եթե դա VPC-ի կողմի վերջնակետի ինտերֆեյսն է, այլ ոչ հաճախորդների լողավազանից հասցե, ապա թարգմանությունը հաստատված է նախքան որևէ կանոն փոխելը։
Հաճախորդների լողավազանը հատկացման տիրույթ է, ոչ թե վերադարձի երթուղի ունեցող ենթացանց։ Հենց այդ տարբերության վրա է սխալվում նման հետաքննությունների մեծ մասը։
Թարգմանությունը, որը բացատրում է անհամաչափությունը
Երեք հոսք շփոթում են միմյանց հետ, և դրանցից միայն մեկն է, որ մարդիկ փորձարկում են։
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN բաղադրիչների նկարագրությունը հստակ նշում է, որ IPv4 հաճախորդի աղբյուրները թարգմանվում են վերջնակետի ինտերֆեյսին, և դա բավական է հասկանալու, թե ինչու միջին տողը համապատասխանելու բան չունի։
Նոր միացմանը պետք է երթուղի, հասցեի լուծման քայլ և լիազորման որոշում։ Ուրիշի սեանսից եղած թարգմանության վիճակը երեքի ոչ մեկը չի տալիս։
Ինչու պատասխանը նոր միացում չէ
TCP պատասխանը համադրվում է գոյություն ունեցող գրառման հետ, դրա համար վերադարձի ուղին աշխատում է առանց ներգնա կանոնի։ EC2 հոսթից եկող նոր SYN-ը համադրելու գրառում չի գտնում, ուստի դառնում է սովորական ելքային փորձ դեպի նպատակ, որտեղ VPC-ն չգիտի ինչպես հասնել։
Այդ պատճառով էլ սա որպես միակողմանի երթևեկություն նկարագրելը մոլորեցնող է։ Այս սեանսներում վերադարձի երթևեկությունը շարունակ հոսում է։ Ուղի չունեցող մասը սկիզբն է։
Ինչն է դեռ կոտրում սեանսը, որը պետք է աշխատի
Անվտանգության խմբերը, ցանցային ACL-ները և նոութբուքի սեփական firewall-ը բոլորն էլ կարևոր են այն միացումների համար, որոնք պետք է հաջողվեն։ Անհաջող ping-ը ամենաքիչն է ասում, որովհետև ICMP քաղաքականությունը հաճախ առանձին է ձեզ հետաքրքրող TCP քաղաքականությունից։
Այս կանոնները գրեք թարգմանված աղբյուրի հիման վրա, ոչ հաճախորդի հասցեի։ Ցանցում երբեք չհայտնվող հասցեին կապված կանոնները այս ձևավորման մեջ ամենահաճախ հանդիպող ինքնապատճառված ձախողումն են։
Երբ VPC-ն իսկապես պետք է սկսի զրույցը
Եթե ծառայությունը պետք է տեղեկացնի աշխատանքային կայանին, շրջեք ուղղությունը և թույլ տվեք հաճախորդին պահել մշտական ելքային ալիք, որին ծառայությունը պատասխանում է։ Եթե ամբողջ հեռավոր ցանցը պետք է հասանելի լինի VPC-ից, ընտրեք ճարտարապետություն, որը հրապարակում է իր նախածանցներն ու մուտքի քաղաքականությունը՝ փոխարենը ենթադրելու, որ Client VPN-ն արդեն դա անում է։ Հաճախորդից հաճախորդ մուտքը երրորդ, ավելի նեղ դեպքն է՝ իր երթուղու և լիազորման օբյեկտներով։ Դրանցից ոչ մեկը պարզապես վանդակ չէ գոյություն ունեցող վերջնակետում։
IPv4 բացատրության շրջանակը նույնպես ազնիվ պահեք։ AWS-ի ընթացիկ փաստաթղթերը առանձնացնում են IPv6-ը, որտեղ այդ թարգմանությունը չի կիրառվում, և այլ միացման մոդելներ, որոնք այլ կերպ են երթուղավորում։
Փորձարկեք երեք պիտակավորված քայլով՝ հաճախորդը բացում է թույլատրված սեանս, VPC ծառայությունը պատասխանում է այդ սեանսին, և VPC հոսթը նոր սեանս է բացում դեպի հաճախորդ։ Առաջին երկուսի հաջողությունը և երրորդի ձախողումը այս ձևավորման սպասված ձևն է, ոչ թե թերություն, որի հետևից պետք է ընկնել firewall կանոններով։