Docker: podczas sesji VPN nie zostają żadne predefiniowane pule adresów

Awaria jest konkretna: Docker nie znajduje akceptowalnej automatycznej podsieci dla nowej sieci mostu. Nie oznacza to, że maszynie skończyły się adresy, ani że VPN jest zepsuty. Diagnozę rozstrzygają dwa pytania: jakie bloki kandydujące demon widzi i które z nich jego alokator wyklucza w tym środowisku. Przejdź przez nie w tej kolejności, bo drugie pytanie nie ma sensu, dopóki nie ma odpowiedzi na pierwsze.

Potwierdź, co zawiodło, zanim cokolwiek zmienisz

Wykonaj poniższe kroki na hoście, który uruchamia demona. Powłoka rozmawiająca ze zdalnym kontekstem opisuje inną maszynę, a sam ten błąd może kosztować godzinę.

Zapisz jednocześnie wersję Engine w zgłoszeniu. Każda heurystyka w dalszej części tego podręcznika jest związana z wersją, a twierdzenie bez wersji to plotka.

Policz przydziały, które już masz

Wypisz sieci, a następnie sprawdź te istotne: docker network ls, a potem docker network inspect NETWORK_NAME. Odczytaj ich podsieci IPAM i kontenery podłączone do każdej. Kilka projektów Compose zużywa więcej bloków, niż sugeruje liczba ich kontenerów, bo każdy projekt ma skłonność do tworzenia własnej domyślnej sieci. Zatrzymany kontener nie zwalnia przydziału swojej sieci.

Sprawdź też konfigurację puli, bo domyślna pula ma zakres bazowy i rozmiar prefiksu na sieć. Duże przydziały na sieć szybciej wyczerpują dostępne bloki, a to fakt dotyczący pojemności, nie problem routingu.

Zapisz liczbę. To linia bazowa, która mówi, czy następna zmiana pomogła.

Porównaj widok tras z perspektywy demona

VPN może wpływać na wybór kandydatów, ale konkretna implementacja decyduje jak. W Moby 28.2.2 na Linuksie InferReservedNetworks zbiera adresy serwerów nazw i pewne trasy IPv4 on-link i nie rezerwuje po prostu każdej trasy z każdej tabeli. Zebrane trasy łącza wykluczają też nieokreślony adres docelowy, więc sama trasa 0.0.0.0/1 nie rezerwuje wszystkich adresów. Inny szeroki prefiks on-link, na przykład 128.0.0.0/1, może przeciąć znane zakresy kandydatów 172 i 192.

Porównaj ip -4 route show table all przed połączeniem VPN i po nim, na hoście demona. Różnica jest dowodem, a wersja zakresem twierdzenia.

Nie uogólniaj heurystyki jednego wydania na wszystkie wydania. Tak odpowiedź z forum staje się zmianą polityki.

Wybierz najmniejszą poprawkę, która działa

Jeśli potwierdzona nieużywana sieć trzyma potrzebny blok, zaplanuj jej celowe wycofanie z właścicielem, zamiast szeroko przycinać. Dla nowej sieci jawnie sprawdzona nieużywana podsieć całkowicie unika zależności od automatycznego wyboru. Ta podsieć nadal musi omijać rzeczywiste cele Docker, LAN i wymagane VPN, bo prywatny nie znaczy bezpieczny. Routing rzeczywistego zdalnego prefiksu zamieniłby błąd przydziału na zerwany dostęp.

Zmiana default-address-pools to szersza polityka dotycząca przyszłych przydziałów. Wybierz niekolidującą bazę i odpowiedni przydzielony rozmiar, scal ją z istniejącymi ustawieniami demona i zaplanuj udokumentowany wpływ restartu. Istniejące sieci nie są po cichu przenumerowywane.

Nie wyłączaj wypychania tras firmowych, żeby przydział się udał. Jawny plan adresacji zwykle rozwiązuje lokalny problem bez osłabiania obowiązkowej polityki.

Zaakceptuj przydział i routing osobno

Po zmianie sprawdź podsieć, którą Docker faktycznie utworzył, i przetestuj zależności aplikacji od VPN i lokalne. Udany przydział i poprawny routing w czasie działania to dwie różne kontrole odbiorcze, a przejście pierwszej nie jest dowodem drugiej. Jeśli aplikacja nie dociera do zasobu za tunelem, masz problem routingu, który ukrywał błąd puli. Zapisz oba wyniki w zgłoszeniu.

Zachowaj różnicę tras i liczbę puli razem z zapisem zmiany, bo następna aktualizacja klienta VPN może zmienić pierwszą bez dotykania Dockera.

Podręcznik jest kompletny, gdy ktoś inny potrafi powtórzyć te dwie kontrole i uzyskać tę samą odpowiedź.