Docker: VPN sessiyası zamanı əvvəlcədən təyin edilmiş ünvan hovuzları qalmayıb

Uğursuzluq konkretdir: Docker yeni körpü şəbəkəsi üçün məqbul avtomatik subnet tapa bilmir. Bu, maşının ünvanlarının bitdiyi anlamına gəlmir və VPN-in sındığı anlamına da gəlmir. Diaqnozu iki sual həll edir: daemon hansı namizəd blokları görə bilir və onlardan hansını onun ayırıcısı bu mühitdə istisna edir. Onları bu sıra ilə işləyin, çünki birinci sual cavablanmadan ikincinin mənası yoxdur.

Nəyin uğursuz olduğunu dəyişməzdən əvvəl təsdiqləyin

Aşağıdakı addımları daemonu işlədən hostdan yerinə yetirin. Uzaq kontekstlə danışan qabıq başqa maşını təsvir edir və yalnız bu səhv bir saat itirə bilər.

Eyni zamanda biletdə Engine versiyasını qeyd edin. Bu runbookun qalan hissəsindəki hər evristika versiya ilə məhdudlaşır və versiyasız iddia söz-söhbətdir.

Artıq malik olduğunuz ayrılmaları sayın

Şəbəkələri sadalayın, sonra vacib olanları yoxlayın: docker network ls, ardınca docker network inspect NETWORK_NAME. Onların IPAM subnetlərini və hər birinə qoşulmuş konteynerləri oxuyun. Bir neçə Compose layihəsi konteyner sayının göstərdiyindən daha çox blok istehlak edir, çünki hər layihə öz defolt şəbəkəsini yaratmağa meyllidir. Dayandırılmış konteyner öz şəbəkəsinin ayrılmasını buraxmır.

Hovuz konfiqurasiyasına da baxın, çünki defolt hovuzun əsas diapazonu və hər şəbəkə üçün prefiks ölçüsü var. Hər şəbəkə üzrə böyük ayrılmalar mövcud blokları daha tez tükədir və bu, marşrutlaşdırma problemi deyil, tutum faktıdır.

Sayı yazın. Növbəti dəyişikliyin kömək edib-etmədiyini bildirən baza məhz budur.

Daemonun marşrutlara baxışını müqayisə edin

VPN namizəd seçiminə təsir edə bilər, lakin dəqiq tətbiq bunun necə olacağını müəyyən edir. Linux üzərində Moby 28.2.2 versiyasında InferReservedNetworks ad serveri ünvanlarını və bəzi on-link IPv4 marşrutlarını toplayır və hər cədvəldən hər marşrutu sadəcə rezerv etmir. Toplanmış link marşrutları həmçinin qeyri-müəyyən təyinat ünvanını istisna edir, buna görə tək bir 0.0.0.0/1 marşrutu bütün ünvanları rezerv etmir. Başqa geniş on-link prefiksi, məsələn 128.0.0.0/1, tanış 172 və 192 namizəd diapazonları ilə kəsişə bilər.

VPN qoşulmazdan əvvəl və sonra ip -4 route show table all əmrini daemonun hostunda müqayisə edin. Fərq sübutdur, versiya isə iddianın əhatə dairəsidir.

Bir buraxılışın evristikasını hər buraxılışa ümumiləşdirməyin. Forum cavabı beləcə siyasət dəyişikliyinə çevrilir.

İşləyən ən kiçik düzəlişi seçin

Təsdiqlənmiş istifadəsiz şəbəkə sizə lazım olan bloku saxlayırsa, geniş budamaq əvəzinə onun məqsədli ləğvini sahibi ilə planlaşdırın. Yeni şəbəkə üçün açıq şəkildə nəzərdən keçirilmiş istifadəsiz subnet avtomatik seçimdən asılılığı tamamilə aradan qaldırır. Həmin subnet yenə də real Docker, LAN və tələb olunan VPN təyinatlarından yayınmalıdır, çünki özəl demək təhlükəsiz demək deyil. Real uzaq prefiksi marşrutlaşdırmaq ayrılma xətasını qırılmış girişlə dəyişərdi.

default-address-pools dəyişmək gələcək ayrılmalara dair daha geniş siyasətdir. Ziddiyyətsiz baza və uyğun ayrılmış ölçü seçin, onu mövcud daemon parametrləri ilə birləşdirin və sənədləşdirilmiş yenidən başlatma təsirini planlaşdırın. Mövcud şəbəkələr səssizcə yenidən nömrələnmir.

Ayrılmanın uğurlu olması üçün şirkət marşrut ötürmələrini söndürməyin. Açıq ünvan planı adətən məcburi siyasəti zəiflətmədən yerli problemi həll edir.

Ayrılmanı və marşrutlaşdırmanı ayrı-ayrı qəbul edin

Dəyişiklikdən sonra Docker-in həqiqətən yaratdığı subneti yoxlayın və tətbiqin VPN və yerli asılılıqlarını sınayın. Uğurlu ayrılma və düzgün işləmə marşrutlaşdırması iki fərqli qəbul yoxlamasıdır və birincini keçmək ikinci üçün sübut deyil. Tətbiq tunelin arxasındakı resursa çata bilmirsə, hovuz xətasının gizlətdiyi marşrutlaşdırma probleminiz var. Hər iki nəticəni biletdə qeyd edin.

Marşrut fərqini və hovuz sayını dəyişiklik qeydi ilə birlikdə saxlayın, çünki növbəti VPN klient yeniləməsi Docker-ə toxunmadan birincini dəyişə bilər.

Runbook o zaman tamamlanır ki, başqa biri bu iki yoxlamanı təkrarlayıb eyni cavabı ala bilsin.