Երկու ցանց ունեցող կոնտեյները ընտրում է սխալ դարպասը

Ձեր կոնտեյները դեռ պատասխանում է իր կառավարման կամուրջի վրա, բայց յուրաքանչյուր ելքային փաթեթ դուրս է գալիս գրասենյակի 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 կոնֆիգուրացիային տիրել միայն իր սեփական քաղաքականությանը։