Контејнер со две мрежи избира погрешна порта

Две поврзувања, една стандардна рута и погрешната мрежа секогаш победува. Закачете го излезот со Compose gw_priority и потврдете го од внатрешноста на контејнерот.

Вашиот контејнер сè уште одговара на својот контролен мост, но секој излезен пакет излегува преку канцеларискиот macvlan. Ништо не откажа. Две поврзувања даваат по една порта, а единствената стандардна рута отиде кон мрежата што не ја имавте на ум, па услугата продолжува да работи додека нејзиниот сообраќај оди по подолг пат. Кога некој ќе го забележи, доказот е табела за рутирање, а не порака за грешка.

Вообичаеното објаснување е дека Docker ја избрал мрежата случајно. Во практика старата одлука го следеше азбучниот ред на имињата на поврзаните мрежи, што рутирањето го претвори во несакан ефект на етикета. gw_priority го заменува тоа со број што самите го избирате намерно, а усвојувањето трае околу една минута откако распоредот е запишан.

Зошто стандардната рута слетува на погрешната мрежа

Секоја мрежа кон која се приклучува услуга може да понуди своја порта, а контејнерот сепак завршува со точно една стандардна рута. Пред Compose 2.33.1 нерешеното се решаваше со подредување на имињата на мрежите, па етикета како control што доаѓа пред office одлучуваше каде оди сообраќајот. Ништо во контејнерот не забележува дека одлуката била произволна, и затоа таа ја поминува проверката на код и подоцна се појавува како чуден пат. Ставањето политика во compose-датотеката е единствениот начин изборот да биде проверлив.

Две работи навистина менуваат која мрежа победува: вредностите на gw_priority што ги доделувате и кои мрежи воопшто се поврзани. Додајте трета мрежа и множеството кандидати расте; отстранете го macvlan и нема што да се натпреварува со мостот. Ниту еден од двата потези не се гледа во евиденцијата на апликацијата, бидејќи погрешната стандардна рута ретко целосно ја прекинува врската. Таа само прави одговорите да стигнуваат од адреса што другата страна можеби не ја очекува.

Закачете ја портата со gw_priority

Compose го изложува gw_priority на секое поврзување услуга-кон-мрежа од верзијата 2.33.1, а победува најголемиот број. Нема посебен клуч за порта по услуга, па вредноста припаѓа во блокот 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 конфигурацијата да поседува само своја политика.

Поврзани статии