دوه شبکو لرونکی کانټینر غلط ګېټوې غوره کوي

ستاسو کانټینر لا هم په خپله کنټرول پل کې ځواب ورکوي، خو هره بهر وتونکې بسته د دفتر macvlan له لارې وځي. هیڅ شی ناکام شوی نه دی. دوه نښلونې هر یوه خپله ګېټوې ورکوي، او یوازینې پخوانۍ لار هغه شبکې ته لاړه چې تاسو یې اراده نه لرله، نو خدمت دوام لري خو د هغې ټرافیک اوږده لار نیسي. کله چې چا وپوهېدل، ثبوت د تېروتنې پیغام نه بلکې د لارښوونې جدول وي.

معمول توضیح دا ده چې Docker شبکه ناڅاپه غوره کړه. په عمل کې پخوانۍ پرېکړه د نښلول شوو شبکو د نومونو الفبایي ترتیب تعقیباوه، چې لارښوونه یې د یو لیبل ضمني اغېزې ته واړوله. gw_priority هغه د یوې عدد سره بدلوي چې تاسو یې په قصد غوره کوئ، او د ترتیب له لیکلو وروسته یې منل نږدې یوه دقیقه وخت نیسي.

ولې پخوانۍ لار په غلطه شبکه کې لګېږي

هره شبکه چې خدمت ورته یوځای شي کولای شي خپله ګېټوې وړاندې کړي، خو کانټینر بیا هم دقیقاً یوه پخوانۍ لاره لري. د Compose 2.33.1 دمخه به برابرۍ د شبکو نومونو په ترتیب کولو سره حل کېده، نو د control په څېر لیبل چې د office دمخه راځي هغه به ټاکله چې ټرافیک چېرته ځي. د کانټینر دننه هیڅ شی نه ثبتوي چې پرېکړه دلبخله وه، او همدا لامل دی چې د کوډ بیاکتنې څخه تېرېږي او وروسته د عجیبې لارې په توګه ښکاري. په compose فایل کې د پالیسۍ ایښودل یوازینې لاره ده چې انتخاب د کتنې وړ شي.

کومه شبکه ګټي دا په حقیقت کې دوه شیان بدلوي: هغه gw_priority ارزښتونه چې تاسو ټاکئ، او کومې شبکې چې په اصل کې نښلول شوې دي. درېیمه شبکه ورزیاته کړئ نو د نوماندانو ټولګه لویه شي؛ macvlan لرې کړئ نو له پل سره د سیالۍ لپاره هیڅ نه پاتې کېږي. دواړه ګامونه د اپلیکیشن په لاګونو کې نه ښکاري، ځکه چې غلطه پخوانۍ لاره نښلون په بشپړه توګه کمزوری کوي نه. یوازې دا کوي چې ځوابونه له هغه پتې راشي چې بله خوا یې ممکن تمه نه وي کړې.

ګېټوې د gw_priority سره وتړئ

Compose له 2.33.1 نسخې راهیسې په هر خدمت-شبکې نښلون کې gw_priority ښکاره کوي، او ترټولو لوی عدد ګټي. د هر خدمت لپاره جلا ګېټوې کیلي نشته، نو ارزښت د خدمت د networks بلاک لاندې راځي. لاندې بېلګه پخوانۍ لاره control ته ورکوي پداسې حال کې چې office د خپلې مستقیمې LAN لپاره د لاسرسي وړ پاتې کېږي.

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

بلاک دوه جلا کنټرولونه وګڼئ: gw_priority پخوانۍ لاره ټاکي، او ipam برخه پته ټاکي. یوازې subnet بدلول د وتلو انتخاب نه لمسوي، او دا د دې سمون نیمګړي پلي کېدو ترټولو عامه لاره ده. لومړیتوبونه د هغې شبکې ترڅنګ وساتئ چې دوی پرې واکمني کوي، ترڅو بل لوستونکی پرېکړه ونه لټوي.

gw_priority د څنګ ساده priority ځانګړنې سره مه ګډوئ. هغه د نښلونو جوړېدل ترتیبوي او د لارښوونې په اړه هیڅ نه وایي، نو نه شي کولای پخوانۍ ګېټوې غوره کړي او نه د انټرفیس نومونه سمون کوي. که څوک د ټرافیک د ګرځولو لپاره priority لوړولو مشوره وکړي، مشوره غلطه ده که څه هم پایله ترتیب ناڅاپه سم ښکاره شي.

تایید کړئ چې په اصل کې کومه شبکه پخوانۍ لاره پورته کوي

د روان کانټینر دننه وګورئ، ځکه چې د کوربه لارښوونې جدول کوربه تشرېح کوي، نه هغه نوم فضا چې خدمت یې کاروي. لومړی د کانفیګ کتنه چلوئ ترڅو ټایپي تېروتنه له بیا پیل دمخه ونیول شي، بیا هغه لاره ولولئ چې کانټینر په حقیقت کې نصب کړې ده.

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

سمه پایله د پل وسیله او 172.30.50.1 نوموي؛ غلطه پایله 192.168.120.1 او د macvlan وسیله نوموي. که په عکس کې د iproute2 بسته نه وي، /proc فایل بیا هم پخوانۍ لاره رپوټ کوي، د مقصد 00000000 او د ګېټوې بایټونه په برعکس. کله چې د وسیلو نومونه روښانه نه وي، د انټرفیس ستنه د docker inspect سره پرتله کړئ.

Macvlan یو فزیکي پورټ دی، د پل کاپي نه

Macvlan کانټینر ته په تار باندې دوهم هویت ورکوي، او همدا د سیمه ییزو وسیلو لاسرسی کاروي. دا هم مانا لري چې د سویچ پورټ او هایپروایزر باید اضافي MAC پته ومني، او ډېرې ورېځې شبکې په چوپتیا دا ردوي. د بیړۍ له پلان دمخه یو کانټینر وازموئ، ځکه چې رد شوې MAC معمولاً د پورته روانې خو هیڅ نه تېرونکې اړیکې په څېر ښکاري.

د macvlan_mode: bridge ترتیب د macvlan ډرایور یو حالت دی، د Docker سافټویر پل نه، او passthru پخوانی نه بلکې جلا ځانګړی حالت دی. Linux هم macvlan کانټینر له خپل کوربه رسېدو منع کوي د همدې والد له لارې، او همدا لامل دی چې کنټرول پل ساتل کېږي، د دې پرځای چې یوه نښلونه دواړه کارونه وکړي.

د VLAN والد مخکې له دې چې Compose یې وویني نوم کړئ

Docker د eno1.120 په څېر د ټکي لرونکي والد د 802.1Q فرعي انټرفیس په توګه ګڼي او پخپله د VLAN وسیله جوړوي. دې اسانتیا حدونه لري: ترلاسه شوی نوم د فزیکي انټرفیس نوم پورې تړلی دی، او اوږد نومونه کولای شي پایله د شاوخوا وسایلو له تمې هاخوا وټېل وهي. د کوربه په شبکه کې نوم لرونکی VLAN انټرفیس جوړول او parent هغه ته نیول دواړه سرونه د وړاندوینې وړ ساتي.

په یاد ولرئ چې networks لاندې کیلي د Compose نوم دی، د Linux وسیله نه. په کوربه کې د office نوم انټرفیس لټول به ناکام شي، ځکه چې کرنل یوازې والد انټرفیس او د کانټینر شاته veth جوړه ویني.

په سر کې د VPN لپاره ځای جوړ کړئ

VPN کلاینټ د دې شبکو له جوړېدو وروسته نښلېږي، نو کولای شي د gw_priority څخه پرته نور ځانګړي لارې، پالیسي قواعد او فلټرونه ورزیات کړي. لرې مخکښې د دواړو سیمه ییزو subnet په وړاندې پلان کړئ، په شمول هغه ځوابونه چې کنټرول لار ته اړین دي. کله چې لرې مخکښه د دفتر LAN سره یوځای شي، د بشپړې خصوصي لړۍ د تونل څخه د ویستلو پرځای د پتو پلان سم کړئ.

د VPN له پیل او بیا نښلېدو وروسته پتې، لارې او د خدمت لاره بیا وګورئ، ځکه چې په لاس اضافه شوې لاره په هماغه بیا نښلېدو کې ورکېږي. لومړي ازمویلو دمخه تمه شوې جدول ولیکئ ترڅو وروسته پرتله کول د حافظې تمرین نه بلکې diff وي. په Compose کې د شبکې دوامداره مالکیت وساتئ او د VPN ترتیب یوازې خپله پالیسي ولري.