Docker: VPN სესიის დროს წინასწარ განსაზღვრული მისამართების აუზები აღარ რჩება

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

დაადასტურეთ, რა ჩავარდა, სანამ რამეს შეცვლით

შეასრულეთ ქვემოთ მოცემული ნაბიჯები იმ ჰოსტიდან, რომელიც დემონს ამუშავებს. ჭურვი, რომელიც დისტანციურ კონტექსტს ესაუბრება, სხვა მანქანას აღწერს და მხოლოდ ეს შეცდომა შეიძლება საათის დაკარგვად იქცეს.

ამავე დროს ჩაწერეთ Engine-ის ვერსია ბილეთში. ამ სახელმძღვანელოს დარჩენილი ნაწილის ყოველი ევრისტიკა ვერსიაზეა მიბმული, ხოლო ვერსიის გარეშე მტკიცება ჭორია.

დათვალეთ განაწილებები, რომლებიც უკვე გაქვთ

ჩამოთვალეთ ქსელები და შემდეგ შეამოწმეთ მნიშვნელოვნები: docker network ls, შემდეგ docker network inspect NETWORK_NAME. წაიკითხეთ მათი IPAM ქვექსელები და თითოეულზე მიმაგრებული კონტეინერები. რამდენიმე Compose პროექტი უფრო მეტ ბლოკს ხარჯავს, ვიდრე მათი კონტეინერების რაოდენობა გვაფიქრებინებს, რადგან ყოველ პროექტს საკუთარი ნაგულისხმევი ქსელის შექმნისკენ აქვს მიდრეკილება. გაჩერებული კონტეინერი არ ათავისუფლებს თავისი ქსელის განაწილებას.

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

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

შეადარეთ დემონის ხედვა მარშრუტებზე

VPN-ს შეუძლია კანდიდატების შერჩევაზე გავლენა მოახდინოს, მაგრამ როგორ — ამას კონკრეტული იმპლემენტაცია წყვეტს. Linux-ზე Moby 28.2.2-ში InferReservedNetworks აგროვებს სახელების სერვერების მისამართებს და გარკვეულ on-link IPv4 მარშრუტებს და ის უბრალოდ არ იტოვებს ყოველი ცხრილის ყოველ მარშრუტს. შეგროვებული კავშირის მარშრუტები ასევე გამორიცხავს გაურკვეველ დანიშნულების მისამართს, ამიტომ მხოლოდ 0.0.0.0/1 მარშრუტი ყველა მისამართს არ იტოვებს. სხვა ფართო on-link პრეფიქსი, მაგალითად 128.0.0.0/1, შეიძლება გადაკვეთოს ნაცნობ 172 და 192 კანდიდატური დიაპაზონები.

შეადარეთ ip -4 route show table all VPN-ის დაკავშირებამდე და შემდეგ, დემონის ჰოსტზე. სხვაობა მტკიცებულებაა, ხოლო ვერსია — მტკიცების ფარგლები.

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

აირჩიეთ ყველაზე მცირე მომუშავე შესწორება

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

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

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

მიიღეთ განაწილება და მარშრუტიზაცია ცალ-ცალკე

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

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

სახელმძღვანელო სრულია მაშინ, როცა სხვას შეუძლია ეს ორი შემოწმება გაიმეოროს და იგივე პასუხი მიიღოს.