VPN-д Docker контейнер хүрэхгүй байна уу? Дэд сүлжээг харьцуулна уу

Контейнерууд оффисын LAN-д хариулдаг боловч компанийн VPN холбогдох тэр мөчид хариулахаа болино. Контейнерт юу ч өөрчлөгдөөгүй: дахин эхлүүлэлт байхгүй, образ шинэчлэлт байхгүй, тохиргооны өөрчлөлт байхгүй. Өөрчлөгдсөн зүйл бол хост машины маршрутын хүснэгт бөгөөд туннелийн нэмсэн маршрут одоо Docker-ын олгосон хаягийг хамарч байна. Дэд сүлжээг засах эсвэл VPN-ээс үл хамаарах хүсэлт гаргахаас өмнө хоёр хаягийн төлөвлөгөөг зэрэгцүүлээрэй, учир нь засварууд нь маш өөр хугацаа шаарддаг.

Тохиргоог өөрчлөхөөс өмнө маршрутыг уншина уу

Docker-ын бодитоор бүтээсэн сүлжээнээс эхэл. IPAM блок нь хаягийн төлөвлөгөө, дэд сүлжээ нь чухал мөр:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose нь шинэ төсөл бүрт анхдагчаар /16 хуваарилдаг тул хоёр сервис 65,536 хаягийн хүрээнд багтах боломжтой. Энэ өргөн нь давхцал ихэвчлэн тохиолдох шалтгаан юм: санамсаргүй сонгосон /16 нь туннелээр хүрдэг сайтыг залгихад хангалттай том бөгөөд туннел асах хүртэл хэн ч анзаардаггүй.

Дараа нь нэг контейнерын хаягийн маршрутын сонголтыг харьцуул: нэг удаа туннел унтарсан үед, нэг удаа асаалттай үед:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

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

Яагаад /16 мөргөлдөөн амархан тохиолддог вэ

Docker нь гүүрний сүлжээг хувийн нөөцөөс авдаг бөгөөд анхдагч нөөц нь 172.16.0.0/12 блокоос /16 зүсмээр гардаг. Корпорацийн сүлжээг ихэвчлэн ижил хувийн орон зайг ашигладаг бөгөөд алсын хандалтын VPN тэдгээр угтварыг холбогдсон клиент бүрт түлхдэг. Хоёр тал 172.18.0.0/16-ыг өөрийн гэж үзэх үед нэг маршрутын хүснэгтэд хоёр зөрчилтэй мэдэгдэл оршдог.

Ялагчийг угтварын урт шийддэг, маршрутуудын дараалал биш. 10.0.0.0/8 түлхдэг туннел нь 172.18.0.0/16 гүүрний маршрутыг дийлэхгүй, учир нь /8 нь бага тодорхой. 172.18.0.0/16 эсвэл түүний доторх 172.18.5.0/24-ыг түлхдэг туннел дийлнэ. Тиймээс нэг зөөврийн компьютер оффисын сүлжээнд ажиллаж, ижил VPN-тэй зочид буудлын Wi-Fi-д бүтэлгүйтдэг: клиент өөр өөр угтвар хүлээн авдаг.

Мөн адил хүснэгт нөгөө чиглэлийг удирддаг. 10.8.4.20 дээр дотоод хост хэрэгтэй контейнер пакетыг гүүрний гарц руугаа илгээдэг, дараа нь хост үүнийг туннел рүү чиглүүлдэг. Хост NAT-ыг гүйцэтгэдэг тул энэ зам ихэвчлэн ажилладаг, гэхдээ корпорацийн тал зөвхөн зөөврийн компьютерын VPN хаягийг хүлээн авах үед, эсвэл урвуу замын шүүлт нь тэгш бус хариултыг хаях үед бүтэлгүйтдэг.

Гурван засварыг харьцуулна уу

Гарах гурван л зам байгаа бөгөөд тэдгээр нь хэнийг зөвшөөрөх шаардлагатай, нэгийг хэрэглэх үед юу эвдрэхээрээ ялгаатай.

Дахин дугаарлалт нь тасалбаргүйгээр дуусгах цорын ганц засвар бөгөөд ихэнх бичвэрүүд тэндээ зогсдог нь тиймээс юм. Залуу төсөл дээр хямд, харин шилжүүлэн суулгах хэрэгсэл эсвэл хадгалсан холболтын мөр шууд хаягийг зааж эхэлмэгц үнэтэй болно. Тэдгээр лавлагааг YAML засахаас өмнө тоол, дараа нь биш.

Давхцал нь танай компанид үнэхээр хамаарах хүрээнд байвал туннелээс үл хамаарах нь хамгийн цэвэр хариулт юм. Энэ нь мөн хамгийн удаан бөгөөд клиентийн профайлыг өөрчилж чадахгүй гэрээт ажилтанд хэрэггүй. Нийтэлсэн порт эсвэл жижиг урвуу прокси энэ маргааныг зайлсхийдэг: клиент туннелийн зөв чиглүүлдэг хаягтай ярьж, зөвхөн тэр порт хүртээмжтэй байх шаардлагатай.

Хүрээг санаатайгаар тогтоо

Нэг төслийн хувьд дэд сүлжээг compose файлд зарлаж, төсөл нь хуваалцсан нөөцөөс авахаа болино:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Тэр хүрээг хайх явцад олсон жишээнээс биш, баг тань хөтөлдөг бүртгэлээс ав. VPN-ын түлхдэг угтвар, хүмүүсийн ажилладаг гэрийн LAN, мөн ижил хост дээрх бусад контейнер сүлжээтэй харьцуулж шалга. Дараа нь дахин бүтээхийг төлөвлө, учир нь одоо байгаа сүлжээ хуучин дэд сүлжээгээ хадгалдаг: docker compose down, дараа нь up -d. Төгсгөлийн цэгүүд холбогдсон үед docker network rm татгалздаг бөгөөд файл дахь аливаа ipv4_address бичлэг шинэ хүрээнд багтах ёстой.

Docker-ын өөрөө үүсгэдэг сүлжээнд /etc/docker/daemon.json дотор демоны нөөц тогтоо:

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

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

Linux гүүр болон Docker Desktop өөр өөрөөр бүтэлгүйтдэг

Linux хост дээр контейнерууд хост нэрний орон зай дахь гүүрэн дээр суудаг. Бүхнийг нэг хүснэгт шийддэг тул дээрх харьцуулалт бүх түүх юм: гүүрний маршрутыг унш, туннелийн маршрутыг унш, бодит контейнерын хаягийн хувьд аль нь ялдгийг хар.

Docker Desktop контейнеруудыг өөрийн NAT-тай виртуал машин ард тавьдаг. Хост контейнерын хаяг руу огт маршрутгүй; үйлчилгээнд нийтэлсэн портоор хүрдэг бөгөөд ихэвчлэн 127.0.0.1 руу холбогдсон байдаг. Тиймээс VPN клиент ямар ч дэд сүлжээний давхцалгүйгээр үйлчилгээг эвдэж болно: виртуал машины дотоод хүрээнд маршрут суулгах эсвэл туннел холбогдсон үед loopback урсгалыг хаах замаар. Хост дээрх ip route get контейнерын хаягт маршрут байхгүй гэж мэдээлбэл, энэ нь хүлээгдэж буй зүйл бөгөөд алдаа биш.

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

Туннел асаалттай үед шалга

Засварласан гэж хэлэхээс өмнө VPN-д хоёр удаа дахин холбогд, учир нь холбогдох үед маршрут нэмж, салгах үед буцааж авдаг профайл эхний оролдлогын дараа зөв харагдаж болно. Дараа нь клиентийн бодитоор хийдэг шалгалтуудыг хий:

1. Контейнерын бодит хаягийг ашиглан хост дээрээс ip route get.
2. Үйлчилгээ өөрөө эрүүл гэдгийг батлахын тулд өөр контейнероос ирсэн хүсэлт.
3. Туннел асаалттай үед клиентээс curl -sv http://127.0.0.1:8080/, дараа нь LAN дахь машинаас контейнерын хаяг руу traceroute -n.
4. Хүсэлт хостт хүрсэн боловч хариулт алга болвол sysctl net.ipv4.conf.all.rp_filter.

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