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 бодлогыг өөрөөр нэгтгэдэг.