Docker-ի պորտերի հրապարակումն ընդդեմ VPN-ի. ուր է գնում պատասխանը

Հրապարակված կոնտեյները պատասխանում է իր իսկ հասցեից մինչև հակադարձ NAT-ը։ Երկու ձևավորում կարող են այդ պատասխանը պահել հանրային ուղու վրա՝ տարբեր ծախսերով։

Հոսթը շարունակում է պատասխանել SSH-ին ամբողջական թունելով VPN-ի բարձրանալուց հետո, մինչդեռ նույն մեքենայի վրա Docker-ով հրապարակված ծառայությունը լռում է։ Լսողի հետ ամեն ինչ կարգին է. կոնտեյները աշխատում է, պորտի քարտեզագրումը գոյություն ունի, և փաթեթը հասնում է։ Կոնտեյները առողջ է, և հարցումն իսկապես հասնում է նրան։ Տարբերությունն այն է, թե որտեղից է սկսվում պատասխանը, երբ Linux-ն ընտրում է իր ուղին, և այդ տարբերությունն է որոշում, թե ստորև բերված երկու ձևավորումներից որն է ձեզ պետք։

Հետևեք tuple-ին նպատակակետ NAT-ի միջով

Վերցրեք հոսթ 192.0.2.10 հասցեով, որը TCP 2222-ը հրապարակում է 172.30.240.5:22 հասցեի կոնտեյների համար։ 198.51.100.25 հասցեից եկած հարցումը թարգմանվում է մինչև կոնտեյներին հասնելը, և կոնտեյները պատասխանում է որպես ինքը։

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Հոսթի երթուղու որոշման պահին պատասխանը դեռ կրում է կոնտեյների աղբյուրի հասցեն։ Հակադարձ թարգմանությունը վերականգնում է հրապարակված tuple-ը ավելի ուշ, և դրա համար է, որ փաթեթը սխալ է թվում հենց այն պահին, երբ ընտրվում է ուղին։

Ինչու միայն հոսթի համար կանոնը բաց է թողնում այն

Կանոնը, որը WAN աղյուսակը ընտրում է միայն 192.0.2.10 հասցեից եկած փաթեթների համար, ծածկում է հոսթի սեփական դեմոնները և ամբողջությամբ բաց է թողնում այս փոխանցված պատասխանը։ Պատասխանի աղբյուրի հասցեն 172.30.240.5 է, ոչ թե հոսթը։

Չափից ավելի ուղղումը կոնտեյների ամեն ինչ WAN-ով երթուղավորելն է, ինչը նաև ազատում է կոնտեյների անկապ ելքային կապերը VPN-ից։ Դա այլ քաղաքականություն է, քան պահանջվածը, և սովորաբար ավելի ուշ ինչ-որ մեկին զարմացնում է։

DNAT-ից հետո համընկնումը այլ hook է

Docker-ի firewall-ների փաստաթղթերը նշում են, որ սովորական օգտվողական զտումը տեսնում է DNAT-ից հետո նպատակակետը, ուստի հրապարակված 2222 պորտը սովորական կանոնում համընկնելը նույնը չէ, ինչ կոնտեյների 22 պորտը համընկնելը։ Եթե սկզբնական tuple-ը կարևոր է, օգտագործեք աջակցվող սկզբնական նպատակակետի մեխանիզմը՝ փոխարենը գուշակելու, թե որ պորտն է տեսանելի։

Hook-ների այս շփոթությունը ստեղծում է կանոններ, որոնք ճիշտ են թվում և երբեք չեն համընկնում։ Քաղաքականությունը վերաշարադրելուց առաջ ստուգեք հաշվիչները հենց կանոնի վրա։ Զրո հարվածով կանոնը ձեզ ասում է, որ այն գնահատվում է մի տեղում, ուր փաթեթը երբեք չի հասնում։

Ձևավորում A. որոշումը կրել որպես կապի վիճակ

Կապի նշումը կարող է մուտքի որոշումը կրել թարգմանության միջով, բայց այն պետք է վերականգնվի փաթեթի վրա կարևոր երթուղու որոնումից առաջ։ Փուլերն են.

  1. Վերապահեք նշման դաշտ և կանոնի առաջնահերթություն, որոնք չեն բախվում Docker-ի, VPN-ի կամ այլ քաղաքականության սեփականատիրոջ հետ։
  2. Նույնականացրեք միայն նախատեսված նոր WAN կապը DNAT-ից առաջ ընկած կետում, որտեղ հասանելի է կապերի հետևումը։
  3. Գրանցեք որոշումը կապի նշման վրա՝ առանց բուն սկզբնական հարցումը WAN աղյուսակին պարտադրելու։
  4. Պատասխանի ուղղությամբ երթուղավորումից առաջ վերականգնեք փաթեթի վրա միայն ձեր սեփական նշման բիթերը։
  5. Ընտրեք ամբողջական WAN աղյուսակ բավական վաղ, որպեսզի VPN կանոնը չկարողանա առաջինը հաղթել։

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

Ձևավորում B. ավարտել հոսթի վրա

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

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

Ստուգեք փոփոխությունը, ոչ մտադրությունը

Բացեք նոր լիազորված կապ հանրային կողմից և հաստատեք, որ պատասխանը դուրս է գալիս նախատեսված ինտերֆեյսով։ Այնուհետև ստուգեք, որ կոնտեյների սկսած անկապ հարցումը դեռ հետևում է VPN-ին։

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

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