ორი ქსელის მქონე კონტეინერი არასწორ კარიბჭეს ირჩევს

თქვენი კონტეინერი კვლავ პასუხობს თავის საკონტროლო ხიდზე, მაგრამ ყოველი გამავალი პაკეტი ოფისის 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 კონფიგურაციას მხოლოდ საკუთარი პოლიტიკა დაუტოვეთ.