Ընդհատվող հասանելիություն AWS Client VPN-ով՝ ստուգեք յուրաքանչյուր միացված ենթացանց
AWS Client VPN-ի որոշ սեսիաներ հասնում են հավելվածի VPC-ին, իսկ մյուսները ժամանակավերջ են ստանում։ Նախ համեմատեք վերջնակետի երթուղիները յուրաքանչյուր միացման VPC երթուղային աղյուսակի հետ։
Օգտատերը միանում է, բացում ներքին հավելվածը և պատասխան ստանում. նույն վերջնակետի գործընկերը ժամանակավերջ է ստանում նույն Wi-Fi-ում գտնվող նույնական նոութբուքից։ Այդ օրինաչափությունը client VPN վերջնակետի ստորագրությունն է, որն ունի մեկից ավելի միացված ենթացանց, որտեղ ուղիները համարժեք չեն։ Ես սա անցնում եմ կոնսոլից դեպի դուրս, որովհետև երկու ներդիր են որոշում՝ արժե՞ արդյոք հետաքննության մնացած մասը։ Կլիենտի կազմաձևում ոչինչ դա չի բացատրում։
Սկսեք վերջնակետից և թվարկեք միացումները
VPC կոնսոլում բացեք Client VPN endpoints-ը, ընտրեք վերջնակետը և կարդացեք Associations ներդիրը։ Յուրաքանչյուր միացում ենթացանց է հասանելիության գոտում, և կլիենտը վայրէջք է կատարում այն ենթացանցում, որը ծառայությունը ընտրում է կապի կառուցման պահին։ Նշեք ենթացանցերի ID-ները և այն երթուղային աղյուսակը, որն իրականում օգտագործում է յուրաքանչյուրը, որովհետև այդ երկու ցանկերն են ձեր անելիք համեմատությունը։
Եթե վերջնակետը ցույց է տալիս միայն մեկ միացում, այս տեսությունը սխալ է, և կլիենտն ավելի լավ կասկածյալ է։
Համեմատեք վերջնակետի երթուղային աղյուսակը յուրաքանչյուր միացման հետ
Բացեք Route table ներդիրը նույն վերջնակետում։ Այնտեղ յուրաքանչյուր նպատակային CIDR ունի թիրախ, և client VPN-ում թիրախը միացումն է, ոչ թե դարպասը։ AWS-ը պահանջում է նպատակակետի գրանցում յուրաքանչյուր միացված ենթացանցի համար, ուստի երթուղին, որը թիրախավորում է դրանցից միայն մեկը, հասանելիությունը կախված է դարձնում նրանից, թե որտեղ է վայրէջք կատարել սեսիան։ Ստուգեք ձեզ իրոք հետաքրքրող նպատակակետը, ապա դրա թույլտվության կանոնը, որովհետև երթուղին տալիս է ուղին, իսկ կանոնը որոշում է՝ ով կարող է օգտագործել այն։
Երբ երկու շերտերն էլ աղյուսակում եք, խափանումը դժվար է բաց թողնել։
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
Երկրորդ տողն է ամբողջ սխալը շատ տոմսերում։ Վերջնակետի երթուղին կա, ուստի ոչ ոք առաջ չի նայում, և փաթեթը մահանում է մեկ ցատկ հետո VPC-ի ներսում։
Հետևեք յուրաքանչյուր ենթացանցի մինչև նրա գործող երթուղային աղյուսակը
Այն ենթացանցը, որը չունի երթուղային աղյուսակի բացահայտ միացում, ժառանգում է VPC-ի հիմնական աղյուսակը։ Կարդացեք այն աղյուսակը, որն իրականում ուժի մեջ է, ոչ թե այն, որի անունը ճիշտ է թվում, և համեմատեք նպատակակետն ու թիրախը, ոչ թե տողի պիտակը։
AWS-ի ընդհատվող հասանելիության ուղեցույցը սա ներկայացնում է որպես երթուղիների ծածկույթ միացումների ընթացքում, ինչը ճիշտ մոդելն է։ Վերջնակետը փաթեթը հասցնում է ենթացանց, և այդ ենթացանցի աղյուսակը դեռ պետք է իմանա, թե որտեղ է գտնվում հավելվածի ցանցը։
Ուղղեք բացակայող տողը այն աղյուսակում, որը տիրապետում է դրան։ Աշխատող ենթացանցից ամբողջ երթուղային աղյուսակը պատճենելը պատճենում է նաև ինտերնետի, սարքի և մեկուսացման ընտրությունները, որոնք երբեք այս մեկի համար չեն նախատեսվել, և այդ փոխանակումը սովորաբար ավելի վատ է, քան ձեր սկսած խափանումը։
Ստուգեք թույլտվության կանոնները, ապա վերադարձի ուղին
Թույլտվության կանոնները նպատակակետի և խմբի համար են և գնահատվում են երթուղիներից առանձին։ Այն նպատակակետը, որն ամենուր երթուղիներ ունի, բայց օգտատիրոջ խմբի համար կանոն չունի, իրեն պահում է սև խոռոչի պես՝ առողջ տեսք ունեցող երթուղային աղյուսակով։
Վերադարձի ուղին նույն ուշադրությանն է արժանի։ Peering կապը հավելվածի VPC-ում պահանջում է երթուղի դեպի կլիենտի CIDR, անվտանգության խմբի կանոններ, որոնք թույլ են տալիս երթևեկությունը երկու ծայրերում, և ցանցային ACL-ներ, որոնք այն չեն գցում։ Միակողմ հասանելիությունը, երբ ping-ը աշխատում է, իսկ TCP ձեռքսեղմումը՝ ոչ, սովորաբար մատնանշում է ACL կամ անվտանգության խումբ, այլ ոչ VPN։
Վերջնակետի սեփական անվտանգության խմբերը գտնվում են միացման առաձգական ցանցային ինտերֆեյսների վրա, ուստի կլիենտի CIDR-ից հավելվածի պորտը թույլատրող կանոնը պետք է կցվի միացմանը, ոչ միայն ինստանսին։
Ստուգեք վերամիացումով, ոչ թե մեկ բախտավոր հարցումով
Split tunnel-ի դեպքում վերջնակետի երթուղիները ուղարկվում են կապի հաստատման պահին, ուստի փոփոխված երթուղիների հավաքածուն երբեք չի հասնում միացած մնացող կլիենտին։ Անջատեք և նորից միացեք աջակցվող կլիենտով, ապա հաստատեք, որ նոր երթուղիները սարքում առկա են։
Վերջապես, կապեք միացումների մատյանը կլիենտի ստացած հասցեի հետ և կրկնեք փորձարկումը բավական անգամ, որպեսզի հանդիպեք մեկից ավելի միացման։ Ուղղումից հետո մեկ հաջող հարցումը ապացուցում է, որ մեկ ուղի աշխատում է, իսկ տոմսը մյուսի մասին էր։