OpenVPN-ийн ард Docker ба VM-ийн урсгал: чиглүүлэх үү, дахин дугаарлах уу?

OpenVPN клиент ажиллаж буй хост дахь контейнер, зочид нь буцах замаа алдах эсвэл туннелийн угтвартай мөргөлддөг. Гурван асуулт шийдлийг сонгоно.

Хост туннелээр вэб үзэж байхад хажууд нь байгаа контейнер юунд ч хүрэхгүй байна. Өөрийн VPN клиент ажиллуулдаг контейнероос порт нийтлэх нь бүр дор: хүсэлт ирдэг ч хариу хэзээ ч гардаггүй. Хоёулаа хост дээрх чиглүүлэлтийн шийдвэр бөгөөд Docker бол зөвхөн элч.

Эдгээр хоёр тохиолдлын алийг нь харж байгааг гурван асуулт тодорхойлдог бөгөөд нэг минут орчим үргэлжилнэ.

Ижил харагдах хоёр гэмтэл

Эхнийх нь буцах замын асуудал. Нийтэлсэн порт контейнер руу хөрвүүлэгдэж, хүсэлт ирж, хариу нь хотын өгөгдмөл чиглэлээр явдаг бөгөөд түүнийг OpenVPN клиент tun0 руу чиглүүлсэн байна. Хариу нь алсын тал хүлээгээгүй хаягаас гарч, хаягдана. Хоёр дахь нь угтварын мөргөлдөөн: Docker-ийн өгөгдмөл гүүр 172.17.0.0/16-г эзэмшдэг бөгөөд корпорацийн туннель мөн ижил хүрээг түлхдэг.

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

Гурван асуултаар шийд

Эхний асуулт: VPN-г зогсооход гэмтэл арилдаг уу? Туннель унтарсан үед бүгд ажиллаж байвал буцах замаас сэрдэ. Хоёр дахь асуулт: ip route show table all ижил угтварыг хоёр удаа, нэг удаа гүүрэн дээр, нэг удаа tun0 дээр жагсаадаг уу? Энэ нь мөргөлдөөн. Гурав дахь асуулт: хохирсон хаяг нь контейнер уу, NAT зочин уу, эсвэл гүүрээр холбогдсон зочин уу?

Гурав дахь асуулт чухал, учир нь тус бүрд өөр зөв засвар байдаг бөгөөд контейнерийн засварыг libvirt зочинд хэрэглэх нь нэг оройг үрэгдүүлнэ.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Буцах зам: нэг эх хаягт зориулсан хүснэгт

Контейнерийн урсгал физик интерфейсээр гарах ёстой, харин хост өөрөө туннель ашиглаж байгаа үед эхэд суурилсан чиглүүлэлт нь хамгийн бага өөрчлөлт юм. Контейнерийн хаягтай тохирох дүрэм нэмж, түүнийг тусдаа хүснэгт рүү илгээ. Хост дээр өөр юу ч хөдлөхгүй.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Эх нь тэр хаяг болсон пакет бүр эхлээд хүснэгт 10-ыг шалгаж, хүснэгт 10 түүнийг туннелийн оронд гүүрийн гарц руу илгээдэг.

Үүгээр баталгаажуул: ip route get 1.1.1.1 from 172.22.0.3. Хариултад гүүрийн интерфейс байх ёстой, tun0 биш. Ингэж нэмсэн дүрмүүд дахин ачаалахад арилдаг тул контейнерийг эзэмшдэг unit эсвэл сүлжээний дэгээнд бич.

Мөн адил загвар WireGuard контейнерт ч ажиллана, тэнд хариу замын хувьд ч тодорхой дүрэм хэрэгтэй.

Угтварын мөргөлдөөн: гүүрийг дахин дугаарла

Чиглүүлэлтийн хүснэгт нэг угтварыг нэг газар илгээдэг. Хэрэв VPN 172.17.0.0/16-г түлхэж, Docker-ийн гүүр аль хэдийн тэнд байвал бага метрик ялна: Docker холбогдсон чиглэлээ метрик 0-д суулгаж, түлхэгдсэн чиглэл 50-д ирнэ. Тэгвэл Docker ажилласаар байхад туннель эвдэрсэн мэт харагдана, эсвэл эсрэгээрээ, суулгах дарааллаас хамаарна. Метриктэй тэмцэхийн оронд гүүрийг дахин дугаарла.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

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

VM-үүд дахин өөр хариулт хэрэгтэй

Өгөгдмөл NAT сүлжээн дэх libvirt зочин хостын чиглүүлэлтийг өвлөж, хостын туннель өгөгдмөл чиглэлийг эзэмшихэд гадагш гарахаа болино. Зочныг гүүр эсвэл macvtap төхөөрөмж рүү шилжүүлэх нь түүнд физик сүлжээнд өөрийн зам өгнө. virt-manager дээр техник хангамж нэмж, Network-ыг сонгож, эх сурвалжийг macvtap хост төхөөрөмж болгож, загварыг virtio хэвээр үлдээж, дараа нь хуучин NAT интерфейсийг идэвхгүй болго.

macvtap зочин ихэвчлэн өөрийн хост руу хүрч чаддаггүй. Энэ нь гэмтэл биш, хүлээгдэж буй зан төлөв бөгөөд үлдээх тэмдэглэлдээ багтаах ёстой.

Зөвхөн хостын LAN хэрэгтэй зочинд нийлүүлэгчийн клиентэд дутуу унтраалга байж болно: Mullvad-тай бол mullvad lan set allow libvirt-д хүрэлгүйгээр локал хүртээмжийг сэргээдэг. Контейнер зөвхөн туннелээр хүртээмжтэй байх ёстой бол нийтэлсэн портыг туннелийн хаягт холбо, -p 10.8.0.5:8080:8080, хаяг бүр дээр нийтлэхийн оронд.

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