GCP Cloud VPN: ստուգեք դարպասը, թունելը և firewall-ը հերթականությամբ

Ձեր կոնսոլը ցույց է տալիս կանաչ թունել, տեղում մոնիտորինգը դեռ չի կարողանում հասնել ոչ մի օրինակի, և թունելի վերակառուցումը թվում է ակնհայտ լուծում։ Դա հազվադեպ է այդպես։ Հաստատված թունելը ապացուցում է միայն, որ երկու դարպասներ ավարտել են IKE փոխանակումը։ Այն ոչինչ չի ասում այն մասին, թե արդյոք փաթեթը երբևէ թույլատրվել է մտնել ձեր VPC։

Այդ կանաչ պատկերակի և պատասխանի միջև կանգնած են չորս որոշումներ, և դրանք ձախողվում են կանխատեսելի հերթականությամբ։ Սկսեք ամենաէժանից։

Երեք օբյեկտ, և դրանցից միայն մեկն է գաղտնագրում

VPN դարպասը տիրապետում է այն արտաքին հասցեին, որին գաղտնագրում է ձեր զույգը. Կոնսոլում դուք երբեք այն ձեռքով չեք ստեղծում: միացման ձևաթղթի ներսում ընտրեք կամ ամրագրեք հասցե, և դարպասը հայտնվում է դրա հետ։ HA դարպասը վերցնում է երկու հասցե երկու ինտերֆեյսի վրա, ինչը կարևոր է ավելի ուշ քվոտայի ստուգման ժամանակ։

Թունելը այդ դարպասի և զույգի միջև զուգավորումն է։ Այն կրում է ընդհանուր գաղտնիքը և այն երթևեկության ընտրիչները, որոնք խոստանում է պաշտպանել։ Հենց այդ ընտրիչներից են սկսվում անաղմուկ խափանումների մեծ մասը։ Թունելը, որի տեղական ընտրիչը ծածկում է 10.0.0.0/24-ը, չի հասցնի 10.0.1.0/24-ը, որքան էլ կարգավիճակը առողջ թվա։

Հեռավոր կողմը պահում է իր սեփական ցանկը, որը սովորաբար կոչվում է գաղտնագրման տիրույթ, և ավարտող սարքավորումը համեմատում է այն ձերինի հետ։ Ոչ մի կողմ չի բանակցում ընտրիչի շուրջ, որը երբեք չի տրվել իրեն։

Երթուղավորման տեսակը որոշում է, թե ինչ է հասնում երթուղիների աղյուսակ

Cloud VPN-ը առաջարկում է երթուղավորման երեք ձևեր, և դրանք մաքուր չեն խառնվում։ Քաղաքականության վրա հիմնված երթուղավորումը պահում է ստատիկ ընտրիչների զույգերը, երթուղիների վրա հիմնված երթուղավորումը սպասում է, որ դուք ինքներդ ավելացնեք ստատիկ երթուղիներ, իսկ դինամիկ երթուղավորումը հայտարարում է նախածանցներ Cloud Router-ի միջոցով BGP-ի վրա։ Ընտրեք մեկը դիտավորյալ։

Դինամիկ թունելը, որի կողքին ձեռքով գրված ստատիկ երթուղիներ կան, ստեղծում է երթուղիների աղյուսակ, որը դատարկվում է ամեն անգամ, երբ BGP նստաշրջանը տատանվում է։

Դինամիկը միակ ձևն է, որը թույլ է տալիս պաշտպանված նախածանցներին փոխվել առանց թունելը վերակառուցելու, և այն քաշում է Cloud Router-ը այն օբյեկտների բազմության մեջ, որոնք պետք է ստուգեք։ Ստատիկ ընտրիչները մնում են աշխատունակ, երբ զույգը սարքավորումային firewall է, որը չի կարողանում BGP խոսել։ Այդ դեպքում երկու ծայրերին էլ անհրաժեշտ են նույն տիրույթները, և ավելի կոնկրետ գրառումը պետք է հաղթի երկուսում։ Զույգը, որը տարբերվում է մեկ ենթացանցով, հաստատվում է և հետո կրում ձեր երթևեկության կեսը։

Ենթադրյալ մերժումը նստած է թունելի հետևում

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

Փոխարենը կարդացեք firewall-ի մերժումների մատյանը, երբ թունելը աշխատում է, իսկ ստուգումը ժամանակավարտվում է, ապա սահմանափակեք կանոնը աղբյուրի տիրույթով և ձեզ անհրաժեշտ պորտերով:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Միայն մեկ ուղղության աշխատելը firewall-ի ակնարկ է

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

Հասցեների ստեղծումը նույնպես քվոտային գործողություն է։ Օգտագործվող արտաքին հասցեների սահմանին մոտ գտնվող նախագիծը մերժում է միացումը սխալով, որը կարդացվում է որպես թույլտվության ձախողում։

Ընտրիչներ, քվոտաներ, ապա չորս ստուգումներ

Կոնսոլում ստեղծված թունելները երբեմն վերադարձնում են դատարկ հեռավոր երթևեկության ընտրիչ gcloud compute vpn-tunnels describe-ից, մինչդեռ գեներացված երթուղիները ճիշտ են տեղափոխում երթևեկությունը։ Համեմատեք, թե ինչ է գրանցում API-ն, այն տիրույթների հետ, որոնք դուք իրականում պաշտպանում եք, նախքան թունելը սխալ համարելը։ API-ի կամ SDK-ի միջոցով ստեղծելը պահում է ընտրիչը բացահայտ։

Քվոտաները մյուս հեշտ բացթողումն են։ Խնդրեք ավելացումը սպասարկման պատուհանից առաջ, ոչ թե ընթացքում, և ստուգեք հասցեների քանակը նույն նախագծում, ինչ դարպասը։

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