Միացնել IP փոխանցումը գոյություն ունեցող GCE VPN դարպասում

VM-ը ստեղծվել է առանց IP փոխանցման, այն արդեն աշխատեցնում է VPN ծրագրաշարը, և բնազդը հուշում է վերակառուցել այն ձևանմուշից՝ դրոշակը միացված։ Այդ վերակառուցումն ավելորդ է։ Compute Engine-ը canIpForward-ը ներկայացնում է որպես թարմացվող հատկություն, և փաստաթղթավորված թարմացման ուղին այն կիրառում է refresh-ով, ոչ թե վերագործարկմամբ։ Այն, ինչ դրոշակն իրականում կառավարում է, նեղ է. առանց դրա հարթակը գցում է փաթեթները, որոնք հասնում են օրինակին, բայց հասցեագրված չեն օրինակի սեփական հասցեին։ Դարպասը, որը փոխանցում է այլ մեքենաների երթևեկությունը, անում է հենց դա, ուստի դրոշակը պետք է միացված լինի։ Դրանից հետո ամեն ինչ հյուրի կարգավորումն ու երթուղավորումն է, որոնց դրոշակը չի դիպչում։

Ինչ է թույլատրում դրոշակը, և ինչ ոչ

Փոխանցումն անջատված վիճակում հարթակը օրինակին վերաբերվում է որպես վերջնակետ։ Այն փաթեթները, որոնց նպատակակետը օրինակի սեփական հասցեն է, առաքվում են. այն փաթեթները, որոնք օրինակը պետք է փոխանցի ուրիշի փոխարեն, չեն առաքվում։

Փոխանցումը միացված վիճակում օրինակը կարող է հանդես գալ որպես VPC երթուղու հաջորդ ցատկ, և դա այն դերն է, որն անհրաժեշտ է VPN սարքին։ Դրոշակը ոչինչ չի ասում ֆայրվոլների, հյուրի երթուղավորման, թունելի կարգավորման կամ վերադարձի ուղիների մասին, և true արժեքը կոտրված դարպասի վրա դեռ կոտրված դարպաս է։

Կարդացեք ընթացիկ հատկությունը

Ստուգեք կարգավորումը նախքան որևէ բան փոխելը՝ օգտագործելով միայն կարդալու describe նախատեսված օրինակի, նախագծի և գոտու նկատմամբ։

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

false արժեքը նշանակություն ունի միայն այն դեպքում, եթե այս VM-ը պետք է լինի հաջորդ ցատկ։ Եթե այո, ուղու մնացած մասը դեռ պետք է ստուգվի առանձին, քանի որ հատկությունը մեկ տող է ավելի երկար շղթայում։

Թարմացրեք գոյություն ունեցող օրինակը

Google-ի օրինակի հատկությունների թարմացման ընթացակարգը արտահանում է ընթացիկ ռեսուրսը, փոփոխում հատկությունը և ներկայացնում արդյունքը։ Սա այլ աշխատահոսք է, քան ստեղծման պահի --can-ip-forward դրոշակը, և հենց այն է աշխատում աշխատող VM-ի վրա։

Նախ արտահանեք սահմանումը տեղական ֆայլ, և պահեք անփոփոխ պատճեն՝ համեմատելու համար։

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

Այդ արտահանված ֆայլում սահմանեք հատկությունը և ուրիշ ոչինչ չփոխեք։

canIpForward: true

Պահեք ամբողջ ռեսուրսը՝ ներառյալ նրա մատնահետքը։ Ֆայլը մեկ տողանոց YAML փաստաթղթով փոխարինելը, կամ մեքենայի տեսակի, սկավառակի կամ ինտերֆեյսի անկապ խմբագրումները նույն ներկայացման մեջ միավորելը հենց այն ճանապարհն է, որով հատկության փոփոխությունը դառնում է ընդհատում։

Խնդրեք թարմացման մեխանիզմին վավերացնել ֆայլը և հաղորդել, թե ինչ կպահանջվի, նախքան որևէ արդյունավետ փոփոխություն թույլատրվի։

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

Այդ վավերացման գործարկումը չի միացնում փոխանցումը։ Կարդացեք պատասխանը անվավեր հատկությունների և այն գործողության մասին, որն ասվում է՝ անհրաժեշտ է։ Այս մեկուսացված փոփոխության համար փաստաթղթավորված գործողությունը REFRESH-ն է։ Եթե արդյունքը պահանջում է վերագործարկում, ֆայլը պարունակում է ավելին, քան փոփոխելիք հատկությունը, ուստի ստուգեք այն՝ փոխարենը թույլ չտալով վերագործարկումը։

Կիրառեք վերանայված ֆայլը refresh-ի սահմանափակումով։

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Ստուգեք, որ գործողությունն ավարտվել է, և նորից գործարկեք describe հրամանը։ Եթե մատնահետքն այլևս չի համընկնում, ուրիշ մեկը փոխել է օրինակը ձեր խմբագրման ընթացքում, ուստի արտահանեք նոր պատճեն և նորից վերանայեք փոփոխությունը՝ փոխարենը ձեր հնացած ֆայլը ուժով անցկացնելու։

Հյուրը դեռ պետք է երթուղավորի փաթեթը

Ամպային թույլտվությունը սարքը երթուղիչ չի դարձնում։ Հաստատեք, որ VPC երթուղին ընտրում է այս VM-ը որպես հաջորդ ցատկ նպատակակետ նախածանցի համար, և որ հյուրը երթուղավորում է թունելի ու ճիշտ ինտերֆեյսի միջև՝ իր սեփական փոխանցման քաղաքականությունը միացված։

Ֆայրվոլի քաղաքականությունը պետք է թույլատրի ինչպես ներքին հոսքը, այնպես էլ արտաքին լսողը։ Միայն VPN պորտը բացելը նկարագրում է գաղտնագրված տրանսպորտը և ոչինչ չի ասում դրա ներսում եղած հավելվածային փոխանակման մասին։

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

Linux դարպասում միջուկի փոխանցումը հյուրի կարգավորման մասն է։ pfSense սարքն ունի իր սեփական համարժեքը, և Linux-ի sysctl հրամանը դրա մեջ պատճենելը համապատասխան քայլը չէ։

Ստուգեք այն հաճախորդից, որին մուտք է պետք

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

Գրանցեք հատկությունը այն ամենում, ինչ կառավարում է սարքը։ Ձեռքով ուղղված VM-ը աշխատում է այնքան ժամանակ, քանի դեռ դրա հաջորդ փոխարինումը լուռ չի վերադարձնում սկզբնական կարգավորումը, և այդ ձախողումը կթվա որպես VPN ծրագրաշարի ռեգրեսիա։

Աշխատանքի կարգը. կարդացեք հատկությունը, արտահանեք և խմբագրեք մեկ տող, վավերացրեք NO_EFFECT-ով, կիրառեք REFRESH-ով, հաստատեք, որ հյուրը փոխանցում է, ապա փորձարկեք հաճախորդից։