Ikki tarmoqli konteyner notoʻgʻri shlyuzni tanlaydi

Ikki ulanish, bitta standart marshrut va notoʻgʻri tarmoq har safar gʻalaba qozonadi. Compose gw_priority bilan chiqishni mahkamlang va buni konteyner ichidan tasdiqlang.

Konteyneringiz hali ham oʻz boshqaruv koʻprigida javob beradi, lekin har bir chiqayotgan paket ofis macvlan orqali chiqadi. Hech narsa buzilmadi. Ikki ulanish har biri oʻz shlyuzini beradi, va yagona standart marshrut siz moʻljallamagan tarmoqqa ketdi, shuning uchun xizmat ishlashda davom etadi, lekin uning trafigi uzoqroq yoʻl oladi. Kimdir buni payqaganda, dalil xato xabari emas, marshrutlash jadvali boʻladi.

Odatiy izoh — Docker tarmoqni tasodifan tanlagan. Amalda eski qaror ulangan tarmoq nomlarining alifbo tartibiga amal qilgan, bu marshrutlashni yorliqning yon taʼsiriga aylantirgan. gw_priority uni siz ataylab tanlaydigan raqam bilan almashtiradi va joylashuv yozilgandan keyin uni qabul qilish taxminan bir daqiqa oladi.

Nega standart marshrut notoʻgʻri tarmoqqa tushadi

Xizmat qoʻshiladigan har bir tarmoq oʻz shlyuzini taklif qilishi mumkin, lekin konteyner baribir aynan bitta standart marshrut bilan qoladi. Compose 2.33.1 dan oldin tenglik tarmoq nomlarini saralash bilan hal qilinardi, shuning uchun control kabi yorliq office dan oldin kelsa, trafik qayerga ketishini oʻsha belgilardi. Konteyner ichida qaror oʻzboshimchalik bilan qabul qilinganini hech narsa qayd etmaydi, shuning uchun u kod koʻrigidan oʻtib, keyin gʻalati yoʻl sifatida namoyon boʻladi. compose faylida siyosat yozish — tanlovni tekshirish mumkin qilishning yagona yoʻli.

Qaysi tarmoq gʻalaba qozonishini haqiqatan ikki narsa oʻzgartiradi: siz tayinlaydigan gw_priority qiymatlari va qaysi tarmoqlar umuman ulanganligi. Uchinchi tarmoq qoʻshsangiz, nomzodlar toʻplami oʻsadi; macvlan ni olib tashlasangiz, koʻprik bilan raqobatlashadigan hech narsa qolmaydi. Ikkala qadam ham ilova jurnallarida koʻrinmaydi, chunki notoʻgʻri standart marshrut aloqani toʻliq uzishi kamdan-kam uchraydi. U faqat javoblarning qarshi tomon kutmagandir manzildan kelishiga olib keladi.

Shlyuzni gw_priority bilan mahkamlang

Compose 2.33.1 versiyasidan boshlab har bir xizmat-tarmoq ulanishida gw_priority ni ochib beradi va eng katta raqam gʻalaba qozonadi. Har bir xizmat uchun alohida shlyuz kaliti yoʻq, shuning uchun qiymat xizmatning networks blokida boʻladi. Quyidagi misol standart marshrutni control ga beradi, office esa toʻgʻridan-toʻgʻri ulangan LAN i uchun ochiq qoladi.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

Blokni ikki alohida boshqaruv deb oʻqing: gw_priority standart marshrutni, ipam qismi esa manzillashni hal qiladi. Faqat subnet ni oʻzgartirish chiqish tanlovini tegmasdan qoldiradi, va bu tuzatishning yarim qoʻllanishining eng keng tarqalgan yoʻli. Ustuvorliklarni ular boshqaradigan tarmoq yonida saqlang, keyingi oʻquvchi qarorni qidirishga majbur boʻlmasin.

gw_priority ni yonidagi oddiy priority xossasi bilan aralashtirmang. U ulanishlarning yaratilish tartibini belgilaydi va marshrutlash haqida hech narsa demaydi, shuning uchun standart shlyuzni tanlay olmaydi va interfeys nomlarini tuzatmaydi. Agar kimdir trafikni yoʻnaltirish uchun priority ni oshirishni tavsiya qilsa, natijadagi tartib tasodifan toʻgʻri koʻrinsa ham tavsiya notoʻgʻri.

Standart marshrutni haqiqatan qaysi tarmoq olib yurishini tekshiring

Ishlayotgan konteyner ichida tekshiring, chunki xostning marshrutlash jadvali xostni tasvirlaydi, xizmat ishlatadigan nom maydonini emas. Avval konfiguratsiya tekshiruvini ishga tushiring, shunda terish xatosi qayta ishga tushishdan oldin ushlanadi, keyin konteyner haqiqatan oʻrnatgan marshrutni oʻqing.

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

Toʻgʻri natija koʻprik qurilmasini va 172.30.50.1 ni nomlaydi; notoʻgʻri natija 192.168.120.1 va macvlan qurilmasini nomlaydi. Agar tasvir ichida iproute2 paketi boʻlmasa, /proc fayli baribir standart marshrutni xabar qiladi, manzil 00000000 va shlyuz baytlari teskari. Qurilma nomlari noaniq boʻlsa, interfeys ustunini docker inspect bilan solishtiring.

Macvlan — jismoniy port, koʻprik nusxasi emas

Macvlan konteynerga simda ikkinchi shaxsiyat beradi va mahalliy qurilmalarga kirishni ishlaydigan qiladigan narsa aynan shu. Bu shuningdek kommutator porti va gipervizor qoʻshimcha MAC manzilini qabul qilishi kerakligini bildiradi, va koʻplab bulut tarmoqlari buni jimgina rad etadi. Flotni rejalashtirishdan oldin bitta konteynerni sinab koʻring, chunki rad etilgan MAC odatda yuqorida turgan, ammo hech narsa oʻtkazmaydigan bogʻlanish sifatida koʻrinadi.

macvlan_mode: bridge sozlamasi macvlan drayverining rejimi, Docker ning dasturiy koʻprigi emas, passthru esa standart emas, alohida maxsus rejim. Linux shuningdek macvlan konteynerining oʻz xostiga yetib borishiga toʻsqinlik qiladi oʻsha ota-interfeys orqali, shuning uchun bitta ulanish ikkala ishni bajaradi deb kutish oʻrniga boshqaruv koʻprigi saqlanadi.

VLAN ota-interfeysini Compose koʻrishidan oldin nomlang

Docker eno1.120 kabi nuqtali ota-interfeysni 802.1Q subinterfeysi deb qabul qiladi va VLAN qurilmasini oʻzi yaratadi. Bu qulaylikning chegaralari bor: hosil boʻlgan nom jismoniy interfeys nomiga bogʻliq, uzun nomlar esa natijani atrofdagi vositalar kutganidan tashqariga surib yuborishi mumkin. Xostning tarmoq konfiguratsiyasida nomlangan VLAN interfeysi yaratish va parent ni unga yoʻnaltirish ikkala uchni ham oldindan aytib boʻladigan qiladi.

networks ostidagi kalit Compose nomi, Linux qurilmasi emasligini unutmang. Xostda office nomli interfeysni izlash muvaffaqiyatsiz boʻladi, chunki yadro faqat ota-interfeysni va konteyner orqasidagi veth juftini koʻradi.

Yuqorida VPN uchun joy ajrating

VPN mijozi bu tarmoqlar mavjud boʻlgandan keyin ulanadi, shuning uchun gw_priority dan qatʼi nazar aniqroq marshrutlar, siyosat qoidalari va filtrlarni qoʻshishi mumkin. Uzoq prefikslarni ikkala mahalliy subnet ga nisbatan rejalashtiring, boshqaruv yoʻliga kerak boʻladigan javoblarni ham qoʻshib. Uzoq prefiks ofis LAN i bilan kesishsa, tunnel dan butun xususiy diapazonni yulib olmang, manzil rejasini tuzating.

VPN ishga tushgandan keyin va yana qayta ulangandan keyin manzillar, marshrutlar va xizmat yoʻlini qayta tekshiring, chunki qoʻlda qoʻshilgan marshrut aynan qayta ulanishda yoʻqoladi. Birinchi sinovdan oldin kutilayotgan jadvalni yozib qoʻying, keyingi taqqoslash xotira mashqi emas, diff boʻlsin. Tarmoqning doimiy egaligini Compose da saqlang va VPN konfiguratsiyasi faqat oʻz siyosatiga ega boʻlsin.

O'xshash maqolalar