Яагаад macvlan контейнер VPN клиентэд хариу өгч чадахгүй вэ

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

VPN-ийг дуусгаж, зэрэг macvlan сүлжээнд контейнер ажиллуулдаг Linux хостийг төсөөлөөрэй. LAN нь 192.168.60.0/24, контейнерт 192.168.60.210 байна, VPN клиентүүд 10.95.0.0/24-өөс ирдэг. Клиент үйлчилгээнд хүрдэг, хариу хэзээ ч буцаж ирдэггүй, хост дээрх галт ханын дүрэм бүр зөв харагдана. Энэ шинж тэмдгийг хоёр тусдаа хязгаарлалт үүсгэдэг бөгөөд нэгийг засахад нөгөө нь байрандаа үлддэг.

Хоёр хязгаарлалт, нэг шинж тэмдэг

Эхний хязгаарлалт бол тусгаарлалт: Docker-ийн macvlan драйвер контейнерт эх интерфэйсээр дамжуулан өөрийн хосттой харилцахыг зөвшөөрдөггүй. Хост стек болон контейнер хоорондын урсгалд зам байхгүй, хост дээрх маршрутуудыг хэрхэн бичсэнээс үл хамааран.

Хоёр дахь хязгаарлалт бол буцах зам. Контейнерын өгөгдмөл гарц нь ихэвчлэн LAN чиглүүлэгч байдаг тул VPN клиентэд хаягласан хариу тэр чиглүүлэгчээр гардаг. Хэрэв чиглүүлэгч VPN сан руу буцах маршрутгүй бол хариу голд хаа нэгтээ хаягдана.

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

Хост талын shim-ийг нарийн байгуул

Хост дээрх ижил эх рүү гүүрэн горимд холбогдсон хоёр дахь macvlan интерфэйс нь хост стегт тухайн LAN сегмент дээр өөрийн таних тэмдгийг өгдөг. Түүнд зориулж DHCP сангаас гадна, контейнерын хүрээнээс гадна хаяг нөөцөлж, зөвхөн контейнерийг түүгээр дамжуулаарай.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Эхний команд интерфэйсийг гүүрэн горимд үүсгэдэг бөгөөд энэ нь энэ драйверын баримтжуулсан өгөгдмөл бөгөөд хост-контейнер урсгалд хүсэж буй горим юм. Хоёр дахь нь /32 оноож, хаяг LAN угтвартай мөргөлдөхгүй байхыг хангана, дөрөв дэх нь shim-ээр зөвхөн контейнерын хаягийг илгээдэг.

Бүх LAN-ыг шинэ интерфэйсээр дамжуулж болохгүй. Энгийн холбогдсон маршрут хэвээрээ үлдэж, хост маршрут зориуд нарийн байгаа тул нэг контейнер зам олж, сегментийн бусад хэсэг зан төлөвөө өөрчлөхгүй. shim рүү чиглэсэн өгөгдмөл маршрут өөр үр дагавартай өөр загвар болох байсан. Үүнийг тодорхой байлгаж, хохирлын радиус бага хэвээр үлдэнэ.

Эдгээр команд ажиллаж буй хост дээрх сүлжээний тохиргоог өөрчилдөг. Төхөөрөмж эсвэл удирдлагатай платформ дээр тухайн платформын дэмждэг тохиргооны механизмыг ашиглана уу, учир нь root-shell дэх интерактив өөрчлөлт шинэчлэлтийн дараа үлдэхгүй байж болно.

Эх сурвалж хэрхэн хадгалагдахыг шийдээрэй

shim байгаа үед контейнер хост руу хүрч чадна, харин асуулт нь хариу ямар эх сурвалжийн хаяг агуулж байна вэ гэдэг болно. Анхны VPN эх сурвалжийг хадгалах нь илүү цэвэр загвар: контейнер клиентийн жинхэнэ хаягийг хардаг, үйлчилгээний логийн болон хандалтын дүрмүүд үүнийг ашиглаж болно.

Үүнийг ажиллуулахын тулд контейнерын сүлжээний тохиргоо энэ замд 10.95.0.0/24-ийн урсгалыг 192.168.60.250 рүү өөрийн гарц болгон илгээх ёстой. Энэ нь контейнерын өөрийн тохиргооны доторх дэмжигдсэн маршрут эсвэл гарцын тохиргоо бөгөөд хост талын заль биш. Тохиргоо хүчин төгөлдөр болсон гэж таамаглахын оронд контейнерын дотроос баталгаажуулна уу. Одоо ч LAN чиглүүлэгч рүү зааж буй өгөгдмөл гарц хариултуудыг ижил нүх рүү үргэлжлүүлэн илгээнэ.

Хэрэв батлагдсан загвар оронд нь VPN эх сурвалжуудыг нуух бол орчуулгыг нарийн хязгаарлана уу: жинхэнэ VPN сан, гарах интерфэйс болох shim, мөн тодорхой контейнер болон үйлчилгээ.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

shim-ийг гарах интерфэйс гэж тааруулна уу, туннелийг биш. Туннелийг гарах интерфэйс гэж нэрлэсэн дүрэм контейнер руу явж буй пакеттай таарахгүй бөгөөд ийм тохиргоонд ихэвчлэн энэ алдаа байдаг. Дүрмийг дээрх өгүүлбэр шиг нарийн байлгаж, сан өөрчлөгдөх үед дахин хянана уу.

Клиентээс шалгана уу, хостноос биш

Хост өөрөөс нь shim-ийн хаяг руу холбосон хүсэлт shim контейнерт хүрч чадахыг нотолно. Гэхдээ контейнер хадгалагдсан 10.95.0.x эх сурвалж руу урсгалыг буцааж чадахыг нотлохгүй, учир нь тэр шалгалтын эх сурвалжийн хаяг shim-ийн өөрийнх нь юм.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

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

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

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