AWS Client VPN-ը միացված է, բայց ինտերնետ չկա՝ երթուղիների ստուգում

AWS Client VPN-ը միացված է, բայց ինտերնետ հասանելիություն չկա՞։ Ստուգեք հաճախորդի երթուղիները, վերջնակետի լիազորումը, ենթացանցի ելքը և DNS-ը հենց այդ հերթականությամբ։

Դուք միացված եք AWS Client VPN վերջնակետին, մասնավոր ենթացանցը պատասխանում է, և այնուամենայնիվ յուրաքանչյուր հանրային էջ ավարտվում է ժամկետի սպառմամբ։ Այս համակցությունը խնդիրը նեղացնում է կառավարվող կողմի երեք օբյեկտներից մեկին՝ հաճախորդի տեղադրած երթուղին, վերջնակետի երթուղին իր լիազորման կանոնի հետ միասին, կամ կապակցված ենթացանցի հաջորդ թռիչքը։ Ես դրանք ստուգում եմ հենց այդ հերթականությամբ, որովհետև յուրաքանչյուր խափանում հաճախորդի կողմից այլ տեսք ունի։ Այս ուղեցույցը վերաբերում է VPC-ի հետ կապակցված կառավարվող վերջնակետին, ոչ EC2 ինստանսի վրա OpenVPN սերվերին և ոչ Cloud WAN կամ Transit Gateway միացմանը։

Սկսեք նրանից, թե հաճախորդն ինչ է իրականում երթուղավորում

Միացված վիճակը ապացուցում է TLS սեսիան և հաճախորդին տրված CIDR-ը, ոչ ավելին. Հարցրեք օպերացիոն համակարգին, թե ուր կգնա հանրային հասցեն, քանի դեռ թունելը միացված է։ Linux-ում ip route get 1.1.1.1 պետք է նշի թունելի ինտերֆեյսը, macOS-ում netstat -rn -f inet | head -5 ցույց է տալիս լռելյայն գրառումը, Windows-ում Find-NetRoute -RemoteIPAddress 1.1.1.1 տպում է ընտրված ինտերֆեյսը և հաջորդ թռիչքը։

Այնուհետև կարդացեք split-tunnel դրոշը, որովհետև այն որոշում է՝ վերջնակետի հրապարակած երթուղիներն են միակ նպատակակետերը, որոնք հաճախորդն ուղարկում է թունել.

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Երբ SplitTunnel true է, հանրային նպատակակետը թունելն օգտագործում է միայն այն դեպքում, երբ վերջնակետը հրապարակում է այն ծածկող երթուղի, ուստի բացակայող 0.0.0.0/0 այդ երթևեկությունը թողնում է տեղական ինտերֆեյսի վրա։ Երբ այն false է, հաճախորդը որսում է երթևեկությունը, բայց վերջնակետը դեռ պետք է այն երթուղավորի և լիազորի, հակառակ դեպքում փաթեթները մտնում են թունել և կանգ են առնում այնտեղ։ Փոխելուց հետո նորից միացրեք հաճախորդին, քանի որ երթուղիներն ու DNS սերվերները տրամադրվում են միացման պահին, և աշխատող հաճախորդը կարող է պահել հին հավաքածուն։

Կարդացեք վերջնակետի երթուղին և լիազորման կանոնն առանձին

Դրանք երկու օբյեկտ են, և մեկի ստեղծումը չի ստեղծում մյուսը։ Թվարկեք վերջնակետի երթուղիները և փնտրեք լռելյայն երթուղի, որի թիրախը կապակցված ենթացանց է.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Յուրաքանչյուր երթուղի ունի ճիշտ մեկ թիրախ ենթացանց, ուստի երեք կապակցումներին պետք է համապատասխան լռելյայն երթուղի յուրաքանչյուրի համար։ AWS-ը փաստագրում է այս ծածկույթի պահանջը, և բացի գործնական ախտանիշն այն օգտատերն է, որը աշխատում է մի ենթացանցից և խրվում մյուսից, ինչը կարդացվում է որպես ընդհատվող խափանում՝ բացակայող երթուղու փոխարեն։ Client VPN սցենարի պաշտոնական փաստաթղթերը նկարագրում են այն հանրային ենթացանցի դասավորությունը, որին պատկանում են այս երթուղիները։

Լիազորումը երկրորդ օբյեկտն է։ Երբ ոչ մի կանոն չի ծածկում հանրային նպատակակետը, թունելը տանում է փաթեթը, և ծառայությունը դեն է նետում այն, ուստի մասնավոր ռեսուրսները շարունակում են աշխատել, իսկ ինտերնետը՝ ոչ.

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

VPC-ի CIDR-ի կանոնը ոչինչ չի ասում 0.0.0.0/0-ի մասին։ Ամբողջական թունելի համար բացակայող մասերը ավելացնելը նշանակում է մեկ երթուղի յուրաքանչյուր կապակցված ենթացանցի համար՝ գումարած լիազորման կանոն, որը հետագայում կարող եք աուդիտ անել.

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

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

Հետևեք փաթեթին կապակցված ենթացանցից դուրս

Վերջնակետի երթուղին որոշում է, որ AWS-ը փաթեթը հանձնում է այդ ենթացանցին։ Այն չի որոշում դրանից հետո հաջորդ թռիչքը, որը գտնվում է ենթացանցի սեփական VPC երթուղիների աղյուսակում.

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Օգտագործելի լռելյայն երթուղին մատնանշում է ինտերնետ դարպասին հանրային ենթացանցի համար, կամ NAT դարպասին՝ մասնավորի, և blackhole վիճակը նշանակում է, որ թիրախը ջնջվել է, և ուղին այժմ լուռ մահանում է։ Սրանք տարբեր աղյուսակներ են վերջնակետի երթուղիների ցանկից, և մեկի վերանորոգումը չի վերանորոգում մյուսը։

Այս թռիչքի վրա նստած են երկու զտիչ։ Թիրախ ցանցային կապակցման վրա կիրառված անվտանգության խումբը պետք է թույլ տա ելքային երթևեկությունը դեպի հանրային նպատակակետ, և ցանկացած կիրառելի ցանցային ACL պետք է թույլ տա հարցումը և վերադարձի երթևեկությունը էֆեմեր պորտերում։ Սահմանափակող կապակցման անվտանգության խումբը սովորական պատճառ է, որ մասնավոր հասանելիությունը աշխատում է, իսկ հանրայինը՝ ոչ։

Ընտրեք առաջին շերտը ըստ ախտանիշի, փոխանակ բոլոր երեքը միաժամանակ փոխելու.

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Անջատեք DNS խափանումը մեռած երթուղուց

Անվան լուծումը ձախողվում է այլ կերպ, քան փոխանցումը, և ամբողջական թունելը կարևոր է դարձնում այս տարբերությունը, որովհետև մղված լուծիչին այժմ հասնում են թունելի միջով։ Եթե վերջնակետը նշում է VPC-ի DNS սերվերներ, նրանց հասցեներին պետք է երթուղու ծածկույթ և լիազորում, ինչպես ցանկացած այլ նպատակակետի։ Հարցրեք լուծիչին ուղղակիորեն՝ տեսնելու, թե որ խափանումն ունեք. dig +short example.com @10.0.0.2, կամ nslookup example.com 10.0.0.2 Windows-ում։

Երբ թվային URL-ը պատասխանում է, իսկ անվանվածը՝ ոչ, դադարեցրեք լռելյայն երթուղու խմբագրումը և աշխատեք DNS-ի վրա։ IP հասցեին ուղղված հարցումը ոչինչ չի ապացուցում անվանված վիրտուալ հոսթի և դրա վկայագրի մասին, ուստի վերջնական ստուգման մեջ պահեք մեկ անվանված թեստ։

Ժամանակը օգնում է։ TCP կապը, որը մի քանի վայրկյանում պատասխան չի ստանում, մատնանշում է երթուղավորումը կամ զտիչը, մինչդեռ անվան որոնման մեջ կախված հարցումը մատնանշում է լուծիչը։ Լռելյայն երթուղին փոխելը, քանի դեռ լուծիչը հասանելի չէ, սովորաբար մեկ խափանումը դարձնում է երկու։

Վերադարձեք մաքուր, ապա ստուգեք ելքի ուղին

Երկու օբյեկտներն էլ հավելող էին, ուստի վերադարձը ջնջում է, ոչ վերանորոգում.

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Նորից միացեք և հաստատեք, թե որ ուղով է երթևեկությունը դուրս գալիս։ Համեմատեք դիտարկված հանրային հասցեն NAT դարպասի առաձգական IP հասցեի հետ, կամ այն ինտերնետ դարպասի հետ, որը մտադիր էիք օգտագործել, և ստուգեք, որ մասնավոր ռեսուրսը դեռ պատասխանում է նույն սեսիայում։

Ավարտեք կարճ ցանկով և վերջին կետը դիտարկեք որպես փոփոխության մաս, ոչ որպես փաստաթղթավորում.

  • Մեկ 0.0.0.0/0 վերջնակետի երթուղի յուրաքանչյուր կապակցված ենթացանցի համար։
  • Լիազորման կանոն, որը ծածկում է 0.0.0.0/0-ը այն հաճախորդների համար, որոնց ուզում եք սպասարկել։
  • VPC-ի լռելյայն երթուղի, որը blackhole վիճակում չէ, յուրաքանչյուր կապակցված ենթացանցում։
  • Կապակցման անվտանգության խմբի ելքը, գումարած ACL-ի վերադարձի երթևեկությունը։
  • Լուծիչի հասցեները երթուղավորված և լիազորված, ստուգված անվանված հարցումով։
  • Գրանցված վերադարձ երթուղու և կանոնի համար։

Մեկ ծավալի նշում. սա IPv4 ուղի է։ Երկակի ստեկ հաճախորդը պահում է արդեն իսկ ունեցած IPv6 կապը, ուստի IPv6 լռելյայն երթուղին առանձին որոշում է՝ իր լիազորումով, և ոչ այս մեկի կողմնակի ազդեցությունը։

Առնչվող հոդվածներ