Docker-ის pool-ის გადაფარვის შეცდომა VPN მარშრუტის პრობლემა არ არის

Docker უარყოფს ქსელის შექმნას შეტყობინებით, რომ pool ემთხვევა სხვას ამ მისამართთა სივრცეში, და ვიღაც წყვეტს, რომ VPN მარშრუტი უნდა იყოს მიზეზი. ასე არ შეიძლება იყოს. ეს შეცდომა წარმოიქმნება pool-ის გამოყოფის დროს, სანამ ერთი პაკეტიც არსებობს, და ხელით შექმნილ ბირთვის მარშრუტს მასზე არავითარი გავლენა არ აქვს. VPN მნიშვნელოვანია ერთი ნაბიჯით გვიან, როცა უკვე მისამართის მქონე კონტეინერი მარშრუტის გამოჩენის შემდეგ მიუწვდომელი ხდება. ორი პრობლემა, მტკიცებულებათა ორი ნაკრები, და მათი შერევა იძლევა ცვლილებას, რომელიც არც ერთს არ ასწორებს.

ორი მსგავსი შეცდომა

გამოყოფის შეცდომა არითმეტიკულია. Docker ადარებს თქვენ მოთხოვნილ ქვექსელს იმ ქვექსელებს, რომლებსაც უკვე მართავს, პოულობს გადაკვეთას და უარყოფს. ჯერ არაფერი მუშაობს, ამიტომ არც მარშრუტია, არც კონტეინერი და არც შესამოწმებელი ტრაფიკი.

მუშაობის დროის სიმპტომი ხელმისაწვდომობის საკითხია. გუშინ პასუხისმგებელი კონტეინერი ახლა არ პასუხობს, და რაღაც შეიცვალა ჰოსტის მარშრუტიზაციის ცხრილში. კონტეინერი კვლავ ინახავს თავის მისამართს; საკითხია, რომელ გზას ირჩევს ეს მისამართი.

ორივე მისამართთა გეგმის პრობლემაა. მხოლოდ ერთი მათგანია Docker-ის პრობლემა.

ჯერ წაიკითხეთ გამოყოფილი pool-ები

ჩამოთვალეთ ქსელები და შეამოწმეთ ისინი, რომლებიც შეიძლება გადაიკვეთოს. ქვექსელი IPAM კონფიგურაციაშია, ხოლო მიერთებული კონტეინერები ცალკეა ჩამოთვლილი:

docker network ls
docker network inspect EXISTING_NETWORK

შეადარეთ ეს ქვექსელი იმ pool-ს, რომელსაც ახალი ქსელი ითხოვს, და დაიმახსოვრეთ, რომ Compose თითოეული პროექტისთვის საკუთარ ნაგულისხმევ ქსელს ქმნის. დავიწყებულ პროექტთან კონფლიქტი ზუსტად ისე გამოიყურება, როგორც დემონთან კონფლიქტი.

სერვისზე სტატიკური ipv4_address ერთი კონტეინერის მისამართია და არა pool-ის განსაზღვრება. მისი შეცვლა არ აშორებს გადაფარვას, რადგან გადაფარვა ქსელის ქვექსელებს შორისაა და არა კონტეინერებს შორის. Docker-ის network-create ცნობარი ჩვეულებრივი ხიდური გამოყოფისთვის მოითხოვს არაგადაფარვად ქვექსელებს და აღწერს, როგორ აირჩიოს ერთი ცხადად.

აირჩიეთ პრეფიქსი, რომელიც VPN-ს გადაურჩება

მყისიერი კონფლიქტი და მომავალი მარშრუტი ერთი არჩევანით წყდება, ამიტომ ერთხელ გააკეთეთ. შეადარეთ კანდიდატი დიაპაზონი LAN-ს, ყოველ VPN დანიშნულებას, რომელსაც ჰოსტი აღწევს, და ნებისმიერ სხვა გამოყენებულ overlay-ს.

პრეფიქსი, რომელიც Docker-ს აკმაყოფილებს და დაშორებულ ქსელს ეჯახება, გაძლევთ კონტეინერს, რომელიც სუფთად იწყება და გვირაბის აწევის წამსვე მიუწვდომელი ხდება. ეს ამ სტატიის მეორე შეცდომაა, და გაცილებით ძნელია მისი დიაგნოსტიკა მოგვიანებით, ვიდრე ახლა თავის არიდება.

ჩაწერეთ არჩეული დიაპაზონები იქ, საიდანაც შემდეგი პროექტი წაიკითხავს. ერთსტრიქონიანი რეესტრი გამოყოფილი პრეფიქსებიდან უფრო იაფია, ვიდრე გაუხსნელი დროის ამოწურვების ერთი კვირა.

გააუქმეთ ან შეცვალეთ ქსელი განზრახ

ახალი Compose ქსელისთვის დააყენეთ გამოუყენებელი პრეფიქსი ქსელის IPAM კონფიგურაციაში. არსებული პროექტისთვის დაგეგმეთ გადანომრვა: სტატიკური მისამართები, დამოკიდებული სერვისები და ქსელის ხელახლა შექმნის ნაბიჯი ყველა უნდა იქნას გათვალისწინებული, რადგან YAML-ის რედაქტირება მომუშავე ქსელს არ გადანომრავს.

თუ მოძველებულ ქსელს უკავია კონფლიქტური გამოყოფა, სანამ წაშლით, შეამოწმეთ ვინ არის მიერთებული. docker network rm უარყოფს, სანამ აქტიური endpoint-ები არსებობს, ხოლო docker stop იღებს კონტეინერების სახელებს ან ID-ებს და არა ქსელის სახელს. კონტეინერის გაჩერება ასევე არ შლის ქსელის განსაზღვრებას, რომელიც pool-ს ინახავს.

ფართო prune სადიაგნოსტიკო ინსტრუმენტი არ არის. ის აღწევს დაუკავშირებელ პროექტებამდე და ანადგურებს იმ მტკიცებულებებს, რომელთა შეგროვებასაც აპირებდით.

ნაგულისხმევი pool-ები მხოლოდ შემდეგ გამოყოფას ეხმარება

დემონის ნაგულისხმევი მისამართების pool-ის პარამეტრი აუმჯობესებს მომავალ ავტომატურ გამოყოფებს იმით, რომ ინახავს მათ თქვენ მიერ დაცული დიაპაზონებიდან გარეთ. ის უკუძალით არ გადამისამართებს უკვე არსებულ ქსელებს, და არ ხსნის ცხად ქვექსელს, რომელიც ემთხვევა სხვა ცხად ქვექსელს.

მოეპყარით ამ პარამეტრს როგორც ცალკე, დაგეგმილ ცვლილებას საკუთარი გადატვირთვით, და არა ერთი პროექტის შეკეთების ნაწილად. ორივეს შერევა ნიშნავს, რომ დემონის გადატვირთვა უკავშირო გამოძიების შუაში ვარდება. დაგეგმეთ ის საკუთარ ფანჯარაში. შემდეგ დაადასტურეთ, რომ ერთი ახალი ავტომატური გამოყოფა ნამდვილად ვარდება დაცული დიაპაზონების გარეთ.

შექმნის წარმატების შემდეგ, გადაამოწმეთ რეალურად მომუშავე ქვექსელი და შემდეგ გააკეთეთ ერთი რეალური აპლიკაციის მოთხოვნა VPN-ის მიზნობრივ მდგომარეობაში. თუ pool ვალიდურია და წვდომა კვლავ ვერ ხერხდება, დარჩენილი სამუშაოა მარშრუტის შერჩევა, ფილტრაცია და დაბრუნების გზა. ეს გაშვების დროის გამოძიებაა და ის გამოყოფის შეცდომას უკუძალით უაზროს არ ხდის.

სამუშაოს რიგი: წაიკითხეთ გამოყოფილი pool-ები, აირჩიეთ პრეფიქსი, რომელიც გვერდს უვლის Docker-საც და VPN დანიშნულებებსაც, განზრახ ხელახლა შექმენით ქსელი, შემდეგ გამოსცადეთ ერთი მოთხოვნა გვირაბის აწეულ მდგომარეობაში.