Docker-ի պորտերի հրապարակումը և VPN աղբյուրները՝ երկու համընկնում, որոնք բաց եք թողնում

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

Առասպելը՝ թույլատրեք VPN սերվերին, և վերջ

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

Այսպիսով՝ VPN սերվերի IP արտահայտությունը նկարագրում է ենթադրություն, ոչ դիտարկում։ Քանի դեռ չգիտեք, թե երկու ձևավորումներից որն է ձեր առջև, կանոնը գուշակություն է։

Աղբյուրը՝ հաճախորդների լողավազան, թե թարգմանված դարպաս

Ստուգեք չորս բան հերթով։ Առաջին՝ հաճախորդների հասցեների լողավազանը, օրինակ 10.90.0.0/24։ Երկրորդ՝ արդյոք դարպասը թարգմանում է այդ լողավազանը մինչև հոսթ հասնելը։ Երրորդ՝ այն աղբյուրը, որը հոսթն իրականում դիտում է մեկ նոր միացման համար։ Չորրորդ՝ արդյոք հավելվածի նույնականացումը տարբերում է առանձին օգտագործողներին, որովհետև ընդհանուր թարգմանված հասցեն չի կարող դա անել։

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

Պորտ՝ DNAT-ը փոխում է այն թիվը, որը համընկնում եք

Docker iptables-ով սովորական Linux կամուրջ հրապարակման դեպքում հոսթի քարտեզագրումը 8443-ից կոնտեյների 443 պորտին թարգմանվում է նախքան փոխանցման զտիչը կաշխատի։ Փաթեթը զտիչին հասնում է 443 նպատակակետ պորտով։ Այդ պահին 8443-ին համապատասխանող կանոնը երբեք չի գործարկվում, թեև 8443-ն այն է, ինչ մուտքագրել է հաճախորդը։

Հրապարակված պորտը դեռ գոյություն ունի միացումների հետևման մեջ, դրա համար էլ սկզբնական նպատակակետը կարելի է համընկնել այնտեղ, երբ իրոք պետք է։

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

Շղթա՝ DOCKER-USER, ոչ INPUT

Docker-ի iptables ուղեցույցը օգտագործողի փոխանցման քաղաքականությունը դնում է DOCKER-USER շղթայում, որը գնահատվում է Docker-ի սեփական փոխանցման կանոններից առաջ։ Հոսթի ծառայությունից INPUT շղթա պատճենված կանոնը զտում է հոսթին ուղղված երթևեկությունը, ոչ թե կոնտեյներ փոխանցվող երթևեկությունը։ Այդ սխալը ստեղծում է կանոն, որը ճիշտ է թվում և ոչ մի ազդեցություն չունի կոնտեյների ուղու վրա։

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

Ստուգեք թարմ միացումներով

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

Այս ստուգումների հետևում գտնվող շղթաների հերթականությունը և պորտի թարգմանության վարքը փաստաթղթավորում է Docker-ի iptables ուղեցույցը։ Կարդացեք այն բաղադրատոմս պատճենելուց առաջ և հաստատեք, թե տեղադրված Docker-ը որ backend-ն է օգտագործում, որովհետև nftables backend-ը քաղաքականությունը ինտեգրում է այլ կերպ։