DNAT-ը VPN կոնտեյներում՝ ուղղորդում, ոչ թե INPUT

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

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

Հետևեք փաթեթին թարգմանությունից հետո

Վերցրեք 10.90.0.0/24 հաճախորդների լողավազան և 10.90.0.1 թունելի հասցե։ Մի կամրջի վրա կան երկու կոնտեյներ՝ 192.0.2.2-ը գործարկում է VPN-ը, իսկ 192.0.2.3-ը՝ հավելվածը։ Հաճախորդը միանում է 10.90.0.1:8080-ին, և VPN կոնտեյների անվանատարածքի DNAT կանոնը վերագրում է այն հավելվածի իրական հասցեին ու պորտին։ Այնուհետև երթուղին փաթեթը ուղարկում է կամրջով։ Այս հասցեները օրինակելի են, ոչ թե տեղակայման բաղադրատոմս։

Այն պորտը, որի վրա հավելվածն իրականում լսում է, կարող է տարբերվել հոսթի վրա հրապարակված ցանկացած պորտից։ Կարդացեք լսողին կոնտեյների ներսում՝ փոխարենը ենթադրելու, որ երկու թվերը համընկնում են։

Թույլտվությունը պատկանում է ուղղորդման ուղուն

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

Պահեք շրջանակը նեղ՝ մեկ աղբյուրի տիրույթ, մեկ նպատակակետ, մեկ ծառայություն։ Թույլատրող ուղղորդման կանոնը ավելի հեշտ է գրել և շատ ավելի դժվար պաշտպանել ավելի ուշ։

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker-ի շղթաները ձեր կոնտեյների շղթաները չեն

Կոնտեյների անվանատարածքի ներսի կանոնները Docker հոսթի կանոնները չեն։ Երբ երթևեկությունը թունելի ինտերֆեյսից անցնում է կամուրջ, հոսթի կամրջի firewall-ը կարող է այլ որոշում կայացնել։ Docker-ի iptables backend-ի դեպքում փաստագրված ուղղորդման շղթաները և DNAT-ից հետո համապատասխանության կետերն այն տեղն են, որտեղ հայտնվում է այս որոշումը։

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

Վերադարձի ուղին դարձրեք գիտակցված ընտրություն

Եթե աղբյուրի հասցեն պահպանվում է, հավելվածը տեսնում է 10.90.0.x և պետք է պատասխանները հետ ուղղորդի VPN կոնտեյնով։ Հակառակ դեպքում նրա սովորական Docker դարպասը դրանք կուղարկի հոսթին, որը թունելի տեր չէ։ Այլընտրանքը նեղ սահմանափակված աղբյուրի թարգմանությունն է VPN կոնտեյնում, որը պարզեցնում է պատասխանը, բայց թաքցնում է հաճախորդին հավելվածից։ Ընտրե՛ք գիտակցաբար և գրե՛ք, թե որն ընտրեցիք։

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

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

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