Լիարժեք թունել Access Server-ում EC2-ում. ինչու մեկ վանդակը բավարար չէ

EC2 ինստանսում աղբյուրի և նշանակման ստուգումն անջատելը Access Server-ի ինտերնետ ելքի մասին հարցերի ամենակրկնվող պատասխանն է, և ինքնին այն ոչինչ չի անում ձեր հաճախորդների համար։ Ստուգումը AWS-ի փոխանցման սահմանափակում է. այն ինստանսին թույլ է տալիս ընդունել փաթեթներ, որոնց աղբյուրը կամ նշանակումը իր սեփական հասցեն չէ։ Այն չի ասում Access Server-ի հաճախորդին ինտերնետ երթևեկն ուղարկել թունելով, չի ստեղծում վերև տանող երթուղի և չի ավելացնում NAT։ Առասպելն այն է, որ վանդակը հենց գործառույթն է։

Ինչ է իրականում կառավարում ստուգումը

EC2-ի յուրաքանչյուր ցանցային ինտերֆեյս դեն է նետում իրեն չուղղված երթևեկը, բացի այն դեպքից, երբ ինստանսը հանդես է գալիս որպես երթուղիչ, NAT սարք կամ VPN դարպաս, և դուք անջատում եք այդ ստուգումը։ Անջատելը տալիս է փոխանցման թույլտվություն։ Թույլտվությունը կարգավորում չէ. ինստանսին դեռ պետք է երթուղի դեպի ինտերնետ դարպաս կամ NAT սարք, VPC-ի երթուղիների աղյուսակին դեռ պետք է համապատասխան գրառում, անվտանգության խմբերը դեռ պետք է թույլատրեն հոսքը, և սերվերը դեռ պետք է թարգմանի կամ երթուղավորի վերադարձի երթևեկը։

Ստուգեք ընթացիկ արժեքը aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck-ով նախքան որևէ բան փոխելը։ Եթե փոխեք այն կոնսոլում, փոխեք այն պատճառով, որ ինստանսը փոխանցում է ուրիշների համար, ոչ թե որևէ հաճախորդ ինտերնետ չի հասնում։

Հաճախորդի երթուղավորման քաղաքականությունը պատկանում է Access Server-ին

Access Server 3-ում բացեք Access Controls-ը և գտեք Internet Access and DNS բաժինը։ Internet Gateway ընտրությունը առաջարկում է լիարժեք կամ բաժանված թունել. լիարժեք թունելը հաճախորդին ասում է իր լռելյայն երթևեկն ուղղել VPN-ի ներս, բաժանված թունելը ինտերնետ երթևեկը թողնում է հաճախորդի տեղական ուղու վրա։ Պահեք և կիրառեք ապրանքի աշխատահոսքի միջոցով, ապա նորից միացրեք փորձնական հաճախորդ, քանի որ քաղաքականությունը հանձնվում է միացման պահին։

Ավելի հին թողարկումները օգտագործում են այլ ընտրացանկեր, և Community OpenVPN-ի որոշ կառուցվածքներ համարժեք կառավարում չունեն։ Ստուգեք տեղադրված հիմնական տարբերակը նախքան գոյություն չունեցող էկրան փնտրելը։ Ապա հաստատեք, թե ինչ ստացավ հաճախորդը. լիարժեք թունելի պրոֆիլը պետք է տեղադրի լռելյայն երթուղի թունելով, իսկ բաժանված թունելի պրոֆիլը չպետք է դա անի։

Հետևեք փաթեթին թունելից հետո

Երբ հաճախորդը ինտերնետ երթևեկն ուղարկում է թունել, սերվերը պետք է այն փոխանցի և սովորաբար թարգմանի։ Access Server-ը կառավարում է իր սեփական NAT և երթուղավորման կանոնները, ուստի կարդացեք գործող կարգավորումը՝ ստեղծված ֆայլերին Community OpenVPN կանոններ ավելացնելու փոխարեն. չկառավարվող կանոնները վերագրվում կամ հակասության մեջ են մտնում ապրանքի հաջորդ թարմացման ժամանակ։ sudo iptables -t nat -L -n -v կամ nftables-ի համարժեքը ցույց է տալիս, թե ինչ է իրականում թարգմանվում։

AWS կողմը առանձին ուղի է։ Հանրային ենթացանցում գտնվող ինստանսը ուղիղ հասնում է ինտերնետ դարպասին և պահպանում իր հանրային հասցեն կամ առաձգական IP-ն։ Մասնավոր ենթացանցում գտնվող ինստանսին պետք է երթուղի դեպի NAT դարպաս կամ NAT ինստանս, իսկ NAT սարքին պետք է իր սեփական երթուղին դեպի ինտերնետ դարպաս։ Ինտերնետ դարպասը VPC-ին կցելը ինքնին ոչ մի մասնավոր աղբյուրի հանրային վերադարձի հասցե չի տալիս, դրա համար է նույն Access Server կարգավորումը աշխատում է մի ենթացանցում և լուռ ձախողվում մյուսում։

Ստուգեք ինստանսի ենթացանցին կապված երթուղիների աղյուսակը, ոչ միայն VPC-ի հիմնական աղյուսակը։ Ենթացանցերի միացումները գերազանցում են հիմնական աղյուսակին, և հնացած միացումը սովորական պատճառ է, որ աշխատող կարգավորումը կանգ է առնում վերակառուցումից հետո։

Առանձին պահեք IP ելքը և DNS-ը

Նախ փորձեք հասցեի բառացի ձևը, ապա անունը՝ նույն հաճախորդի հավելվածից։ Եթե curl -4 https://checkip.amazonaws.com-ը վերադարձնում է հանրային հասցե, բայց հոսթի անունները ձախողվում են, թունելն ու NAT ուղին աշխատում են, և խնդիրը DNS-ն է. ուղարկված լուծիչը, հաճախորդի լուծիչի վիճակը կամ լուծիչը արգելափակող անվտանգության խումբը։ Access Server-ի DNS կարգավորումները նույն Internet Access տարածքում են, բայց անցնում են այլ կոդային ուղով։

Համեմատեք վերադարձված հասցեն ձեր նախատեսած ելքի հետ։ Եթե դա ինստանսի հանրային հասցեն է, երթևեկը թարգմանում է ինստանսը. եթե դա NAT դարպասի հասցե է, օգտագործվում է մասնավոր ենթացանցի ուղին։ Երկուսն էլ կարող են ճիշտ լինել։ Ինչ չեք կարող եզրակացնել, այն է, որ սերվերի վրա բրաուզերը ապացուցում է հաճախորդի փոխանցումը։

Թույլ մի տվեք, որ մեկ վանդակը փակի հետաքննությունը

IPv6-ը առանձին որոշում է։ IPv4-ի համար լիարժեք թունելի քաղաքականությունը ոչինչ չի ասում այն մասին՝ IPv6-ը տեղափոխվում է, արգելափակվում է թե արտահոսում, և երկկույտ հաճախորդը կարող է շարունակել օգտվել իր տեղական IPv6 ուղուց, մինչ IPv4-ը թունելում է։ Փորձարկեք այն հասցեների ընտանիքը, որն իսկապես կարևոր է ձեզ, և հստակ որոշեք՝ արդյոք մյուսը պետք է անջատվի։

Վերջապես, փորձարկեք անջատված վիճակը։ Լիարժեք թունելի ընտրությունը նկարագրում է երթուղավորման քաղաքականությունը միացված ժամանակ, ոչ թե այն, ինչ տեղի է ունենում թունելի անկման ժամանակ։ Եթե պահանջն այն է, որ ոչ մի երթևեկ չփախչի VPN-ից դուրս, դա kill-switch-ի և հրային պատի հարց է, և պահանջում է իր սեփական փորձարկումը՝ երթուղիների աղյուսակից եզրակացության փոխարեն։