Հոսթը հասնում է IPsec գործընկերոջը, Docker կոնտեյները՝ ոչ

Դուք ping եք ուղարկում հեռավոր հոսթին Linux մեքենայից, և այն պատասխանում է, ուրեմն թունելն աշխատում է։ Ձեր կողքի կոնտեյները դեռ ժամանակը սպառում է, և հաջորդ բնական քայլը Docker-ը վերագործարկելն է։ Կամուրջ ցանցի կոնտեյները սովորաբար սկսվում է այլ աղբյուրի հասցեով և հոսթ ներս է մտնում փոխանցման միջոցով, ոչ թե հոսթի հավելվածի սեփական ելքի ուղով, ուստի հաջող փորձարկումը չափել է այլ փաթեթ։ Քաղաքականության վրա հիմնված strongSwan թունելի համար հեռավոր ենթացանցի սովորական երթուղին բավարար չէ, երբ փոխանցվող փաթեթը չի համապատասխանում տեղադրված IPsec քաղաքականությանը։

Ստորև ներկայացված ուղեցույցը հետևում է մեկ նպատակակետի երկու աղբյուրով և կարդում է վիճակը նախքան որևէ բան փոխելը։

Սկսեք մեկ նպատակակետից և երկու աղբյուրից

Նախ ընտրեք IP-ով հայտնի ծառայություն, որպեսզի միաժամանակ DNS չվրիպազերծեք։ Գրանցեք երեք փաստ՝ կոնտեյների կամրջի նախածանցը, հաջող հոսթի հարցման աղբյուրի հասցեն և թունելի համար պայմանավորված տեղական ու հեռավոր տրաֆիկի սելեկտորները։ Այդ երեք թիվը բացատրում են այս ախտանշի գրեթե բոլոր դեպքերը։

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

Կարդացեք քաղաքականությունները նախքան Docker-ին դիպչելը

Միայն կարդալու հոսթի ստուգումները ընդգրկում են երթուղավորման որոշումները, քաղաքականության տվյալների բազան և նրանց միջև ընտրող կանոնները:

ip rule show
ip route show table all
ip xfrm policy

Քաղաքականությունների ցանկը ցույց է տալիս սելեկտորներն ու ուղղությունը՝ առանց բանալու նյութով լի IPsec վիճակի արտածման, այդ պատճառով ապահով է այն տոմսի մեջ տեղադրել։ Փնտրեք տեղական սելեկտոր, որը ծածկում է հոսթի հասցեն, բայց ոչ կամրջի նախածանցը։ Ստուգեք նաև համընկնումը. կոնտեյների երթուղին, որը հեռավոր նպատակակետը համարում է տեղական, երբեք չի ստեղծի սպասված փոխանցվող փաթեթը, և թունելն է մեղադրվում։ Պահեք այդ ցանկը կոնտեյների աղբյուրի հասցեի կողքին, որովհետև երկուսը միասին ամբողջ համեմատությունն են։

Եթե կոնտեյների նախածանցը բացակայում է, կանգ առեք և որոշեք ճարտարապետությունը նախքան այլ բան խմբագրելը։ Ուղեցույցի մնացած մասը ենթադրում է, որ դուք պայմանավորվել եք, թե որ աղբյուրի հասցեն պետք է երևա ցանցում։

Ստուգեք զտումն ու թարգմանությունը հերթականությամբ

Docker-ի Linux կամրջի հրշեջ պատը կարող է արգելափակել փոխանցումը՝ անկախ IPsec-ից։ iptables backend-ով ստուգեք FORWARD ուղին և DOCKER-USER որոշումները՝ հիշելով, որ ավելի վաղ վճռից հետո ավելացված կանոնը կարող է երբեք չաշխատել։ nftables backend-ը ինտեգրվում է այլ կերպ, ուստի DOCKER-USER շղթա մի ստեղծեք միայն այն պատճառով, որ iptables օրինակն այդպես է անվանել այն. ստուգեք, թե ձեր daemon-ն իրականում որ backend-ն է օգտագործում։

Այնուհետև ստուգեք աղբյուրի թարգմանությունը։ Լայն MASQUERADE կանոնը կարող է նախկինում IPsec սելեկտորին համապատասխանող փաթեթը դարձնել այնպիսին, որ այլևս չհամապատասխանի, և խափանումը ճիշտ երթուղավորման խնդրի տեսք ունի։ strongSwan-ի փոխանցման ուղեցույցը փաստում է NAT բացառությունը, որն անհրաժեշտ է նման թարգմանությունից առաջ արդեն քաղաքականությանը համապատասխանող տրաֆիկի համար։

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

Այնուհետև որոշեք՝ երթուղավորվա՞ծ, թե թարգմանված

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

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

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

Ստուգեք նոր միացումով, ոչ թե վերագործարկումով

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

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