VPN контейнер дахь DNAT: INPUT биш, дамжуулалт

DNAT-ын дараа туннелийн хаяг руу чиглэсэн хүсэлт дамжуулагдсан урсгал болно. Дамжуулах дүрмийг нарийсгаж, Docker гинжийг уншиж, буцах замыг зориуд сонгоно уу.

Хүсэлт туннелийн IP хаяг руу ирж, мөн контейнероос хөрш үйлчилгээний хаяг руу гарна. Энэ хоёр мөчийн хооронд DNAT очих газрыг дахин бичсэн тул пакет VPN контейнерийн оролт байхаа болив. Одоо энэ нь өөр дүрмээр үнэлэгдэх дамжуулагдсан урсгал юм. Энэ өөрчлөлт нь туннелийн хаягт зөв мэт санагдах галт ханын дүрэм орчуулагдсан холболтод яагаад нөлөөлөхгүй байгааг тайлбарлана.

Орчуулсны дараа пакетыг дагаарай

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 хост-ын дүрэм биш. Урсгал туннелийн интерфейсээс гүүрэн дээр шилжихэд хост-ын гүүрэн галт хана өөр шийдвэр гаргаж болно. Docker-ын iptables backend-тэй үед баримтжуулсан дамжуулах гинж болон DNAT-ын дараах тохирлын цэгүүд нь тэр шийдвэр илэрдэг газар юм.

Docker галт ханын лавлагаа тэдгээр гинж болон DNAT-ын дараах тохирлыг тайлбарлана. Дутуу зөвшөөрлийг Docker-ын галт ханын менежментийг унтраах эсвэл гинж бүрийг сул болгох замаар засаж болохгүй, учир нь энэ нь таны ашиглахыг хүсч буй хил хязгаарыг арилгана.

Буцах замыг зориудын сонголт болго

Хэрэв эх хаяг хадгалагдвал програм 10.90.0.x-г харж, хариунуудыг VPN контейнерээр буцааж чиглүүлэх ёстой. Үгүй бол түүний ердийн Docker гарц тэдгээрийг туннелийг эзэмшдэггүй хост руу илгээнэ. Өөр сонголт бол VPN контейнер дээрх нарийн хязгаарласан эх орчуулга бөгөөд энэ нь хариуг хялбарчилдаг ч харилцагчийг програмаас нуудаг. Зориуд сонгоод алийг нь сонгосноо бичээрэй.

Энгийн харилцагчаас шинээр зөвшөөрөгдсөн холболтыг туршиж, дараа нь холбоогүй портууд хаалттай хэвээр байгааг баталгаажуулна уу. Пакет алга болоход VPN-ийн нэрийн орон зай, програмын нэрийн орон зай, програмын өөрийн логыг шалгана уу. Гүүрэн гарц руу ping хийх нь үйлчилгээний хүлээн авалтын тест биш.

Дүрмүүдийг контейнерийн дэмжигдсэн эхлүүлэх тохиргоонд хадгална уу, учир нь интерактив засварууд дахин үүсгэх үед алга болно. Хост портыг нийтлэх нь өөр нэг илрэлийн зам бөгөөд үйлчилгээ туннелээр хүрч болох учраас л шаардлагагүй.

Холбоотой нийтлэлүүд