Эки тармагы бар контейнер туура эмес шлюзди тандайт

Эки туташуу, бир демейки маршрут жана туура эмес тармак ар дайым жеңет. Compose gw_priority менен чыгууну бекитип, аны контейнердин ичинен текшериңиз.

Контейнериңиз дагы эле өзүнүн башкаруу көпүрөсүндө жооп берип турат, бирок ар бир чыгуучу пакет кеңсе 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 конфигурациясы өз саясатына гана ээ болсун.

Тектеш макалалар