Նոթբուքը միանում է AWS Client VPN վերջնակետին, հասնում մասնավոր ենթացանցին, և ամեն ինչ առողջ է թվում։ Նույն LAN-ի սեղանադիր համակարգիչը ոչ մի տեղ չի հասնում, թեև Linux հոսթն էլ ունի կամուրջային ինտերֆեյս, և երկու մեքենաներն էլ նույն մալուխի վրա են։ Թունելում ոչինչ սխալ կարգավորված չէ. բացակայող մասը երթուղավորումն է, իսկ կամուրջը կեղծ հետք է։

Client VPN նստաշրջանը LAN տարածելը դարպասի դեր է։ Դա կառավարվող ծառայության մեջ ձգված Ethernet հատված չէ։

Հոսթն աշխատում է, իսկ LAN-ը՝ ոչ

Linux մեքենայի թունելի ինտերֆեյսն ունի հասցե Client VPN հաճախորդի CIDR-ի ներսում, և վերջնակետը VPC միջակայքերի համար երթուղիներ է ուղարկել։ Այդ մեքենայի վրա արված հարցումը տեղում ստեղծված տրաֆիկ է. այն ընտրում է երթուղի, դուրս գալիս թունելով և ստանում պատասխան։ Այդ ուղին երբեք չի դիպչում փոխանցման կոդին, LAN ինտերֆեյսին կամ տրանզիտը կարգավորող որևէ հրակայուն պատի կանոնի։

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

Ոչ ամեն հաճախորդ կարող է դարպաս լինել

AWS-ը նշում է, որ իր Client VPN աշխատասեղանի հավելվածը չի աջակցում IP փոխանցմանը, իսկ այլ հաճախորդներ կարող են։ Այդ սահմանափակումը որոշում է ճարտարապետությունը ցանկացած հրաման մուտքագրելուց առաջ։ Եթե միակ հասանելի հաճախորդը պաշտոնական աշխատասեղանի հավելվածն է, LAN-ի համար փոխանցող Linux դարպասը այն կարգավորումը չէ, որը կարող եք ավարտել, և ոչ մի masquerading դա չի փոխի։

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

Հաճախորդի ընտրությունը դիտարկեք որպես դիզայնի վերանայման մաս։ Այն որոշում է՝ արդյոք LAN փոխանցման ձևանմուշն ընդհանրապես հասանելի է, և որոշում է, թե ինչ ինքնություն է տեսնում վերջնակետը դարպասի հետևի յուրաքանչյուր սարքի համար։ Գրանցեք հաճախորդը և վերջնակետի կարգավորումը, որի դեմ այն փորձարկվել է։ Կես տարի անց հաճախորդի փոխարինումը կարող է լուռ հեռացնել այն հնարավորությունը, որը դիզայնը ենթադրել էր։

Ուղղեք LAN-ը թունել և թարգմանեք այն

Աջակցվող հաճախորդի առկայությամբ մնացածը սովորական դարպասի աշխատանք է։ LAN սարքերին պետք է VPC միջակայքի երթուղի, որն ուղղված է Linux հոսթին, իսկ հոսթին՝ միացված փոխանցում։ Եթե ցանկանում եք, որ VPC-ն տրաֆիկը տեսնի որպես միացված հաճախորդ, այլ ոչ որպես կամայական LAN հասցե, թարգմանեք աղբյուրը ելքի վրա։

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Սահմանափակեք կանոնը թունելի ինտերֆեյսով և VPC միջակայքով, ինչպես վերևում, փոխարենը masquerade անելու ամեն ինչ, ինչ փոխանցում է հոսթը։ Նեղ կանոնն ավելի հեշտ է դատողության համար, և այն լուռ չի փոխում այն տրաֆիկը, որը պետք է պահպաներ իր սկզբնական աղբյուրի հասցեն։

Թույլ տվեք LAN երթուղին ինքնուրույն գալ, եթե կարող եք. DHCP տարբերակ, երթուղիչի հայտարարություն կամ ստատիկ երթուղի, որն ուղարկվում է LAN-ը կառավարողի կողմից։ Միայն մեկ փորձնական մեքենայի վրա գոյություն ունեցող երթուղին դիզայնը կթողնի կոտրված այն պահին, երբ մեկ ուրիշը փորձի այն։

Պատասխանին նույնպես ուղի է պետք

Երբ հարցումը հասնում է VPC, պատասխանը պետք է վերադառնա նույն թարգմանության վիճակներով և գտնի LAN երթուղին դարպասի վրա։ Այդ մասը սովորաբար աշխատում է, երբ masquerade կանոնը տեղում է, որովհետև քարտեզագրումն ապրում է այն հոսթի վրա, որը կատարել է այն։ Այն կոտրվում է, երբ VPC կողմում կա երթուղի, որը պատասխանն ուղարկում է այլ տեղ, և դրա համար էլ կարևոր են և՛ հաճախորդի CIDR երթուղին, և՛ վերջնակետի ենթացանցի կապակցումը։

Նայեք հաշվիչներին, ոչ միայն ping-ին։ Զրո փաթեթով masquerade կանոնը ձեզ ասում է, որ հարցումը երբեք չի հասել թունելի ինտերֆեյսին, ինչը վերադարձնում է LAN երթուղուն կամ հաճախորդի սեփական երթուղային աղյուսակին։ Փաթեթներ ունեցող, բայց պատասխան չունեցող կանոնը ցույց է տալիս VPC կողմը, լիազորման կանոնները կամ անվտանգության խումբ, որը չի ընդունում թարգմանված աղբյուրը։ Կարդացեք երկու ուղղություններն էլ նախքան որևէ բան փոխելը, որովհետև միայն մի կողմից աճող թիվը միակողմանի ուղի է, ոչ դանդաղ։

Հիշեք, որ վերջնակետը կառավարվող ծառայություն է։ Չկա սերվերի կարգավորման ֆայլ խմբագրելու և չկա client-config հրահանգ ավելացնելու համար, ուստի ինքնակառավարվող OpenVPN սերվերի համար հատուկ հաճախորդի ենթացանցային երթուղիներով գրված հրահանգները չեն փոխանցվում։ AWS-ում լծակներն են ենթացանցի կապակցումը, լիազորման կանոնները և VPC-ի երթուղային աղյուսակները։

Ընդհանուր ինքնությունը այն մասն է, որին քաղաքականությունը պետք է պատասխանի

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

Դա կարող է ընդունելի լինել, կամ հենց դա լինի դիզայնի մերժման պատճառը։ Դա կախված է նրանից, թե VPC ռեսուրսներն ինչ են ենթադրում, թե ով է զանգահարում։ Ընդհանուր ինքնությունը, որը տեղավորվում է լիազորման մոդելի մեջ, լավ է. այն, որը լուռ մեկ նույնականացված նստաշրջանը վերածում է ամբողջ LAN-ի հասանելիության, գրառման սպասող բացահայտում է։

Եթե պահանջն իսկապես ամբողջ տեղամասը VPC-ին միացնելն է, համեմատեք աջակցվող տեղամաս-տեղամաս դիզայնը նախքան հեռահար մուտքի հաճախորդը տարածելը։ Իմաստաբանությունը տարբեր է, և NAT-ված հաճախորդի նստաշրջանը վատ փոխարինում է տեղամասի կապի համար, երբ VPC-ն պետք է կապեր սկսի դեպի LAN։

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

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