Błąd nakładania się pul w Dockerze nie jest problemem trasy VPN

Docker odmawia utworzenia sieci z komunikatem, że pula nakłada się na inną w tej przestrzeni adresowej, a ktoś postanawia, że przyczyną musi być trasa VPN. Nie może nią być. Ten błąd powstaje podczas przydzielania puli, zanim istnieje choćby jeden pakiet, a ręczna trasa jądra nie ma na niego wpływu. VPN liczy się o krok później, gdy kontener, który już ma adres, staje się nieosiągalny po pojawieniu się trasy. Dwa problemy, dwa zestawy dowodów, a ich mieszanie daje zmianę, która nie naprawia żadnego z nich.

Dwa błędy, które wyglądają podobnie

Błąd przydzielania jest arytmetyczny. Docker porównuje żądaną podsieć z podsieciami, którymi już zarządza, znajduje przecięcie i odmawia. Nic jeszcze nie działa, więc nie ma trasy, kontenera ani ruchu do zbadania.

Objaw w czasie działania to pytanie o osiągalność. Kontener, który wczoraj odpowiadał, teraz nie odpowiada, a coś zmieniło się w tabeli routingu hosta. Kontener nadal trzyma swój adres; pytanie brzmi, którą drogę ten adres obiera.

Oba są problemami planu adresów. Tylko jeden z nich jest problemem Dockera.

Najpierw przeczytaj przydzielone pule

Wypisz sieci i sprawdź te, które mogą się przecinać. Podsieć żyje w konfiguracji IPAM, a podłączone kontenery są wymienione osobno:

docker network ls
docker network inspect EXISTING_NETWORK

Porównaj tę podsieć z pulą, o którą prosi nowa sieć, i pamiętaj, że Compose tworzy własną sieć domyślną dla każdego projektu. Konflikt z zapomnianym projektem wygląda dokładnie jak konflikt z demonem.

Statyczny ipv4_address w usłudze to adres jednego kontenera, a nie definicja puli. Zmiana go nie usuwa nakładania się, ponieważ nakładanie zachodzi między podsieciami sieci, a nie między kontenerami. Dokumentacja network-create Dockera wymaga nie nakładających się podsieci do zwykłego przydzielania przez mostek i opisuje, jak wybrać jedną jawnie.

Wybierz prefiks, który przetrwa VPN

Natychmiastowy konflikt i przyszła trasa są rozstrzygane tym samym wyborem, więc dokonaj go raz. Porównaj zakres kandydacki z LAN, z każdym celem VPN, do którego host może dotrzeć, oraz z każdym innym używanym overlayem.

Prefiks, który zadowala Dockera i koliduje ze zdalną siecią, daje kontener, który startuje czysto i staje się nieosiągalny w chwili, gdy tunel się podnosi. To drugi błąd w tym artykule i znacznie trudniej go zdiagnozować później niż uniknąć teraz.

Zapisz wybrane zakresy tam, gdzie następny projekt będzie mógł je przeczytać. Rejestr przydzielonych prefiksów w jednej linii jest tańszy niż tydzień niewyjaśnionych przekroczeń czasu.

Wycofaj lub zmień sieć celowo

Dla nowej sieci Compose ustaw nieużywany prefiks w konfiguracji IPAM sieci. Dla istniejącego projektu zaplanuj przenumerowanie: stałe adresy, usługi zależne i krok odtworzenia sieci muszą być wszystkie uwzględnione, bo edycja YAML nie przenumerowuje działającej sieci.

Jeśli przestarzała sieć posiada kolidujące przydzielenie, sprawdź, kto jest podłączony, zanim ją usuniesz. docker network rm odmawia, dopóki istnieją aktywne endpointy, a docker stop przyjmuje nazwy lub ID kontenerów, a nie nazwę sieci. Zatrzymanie kontenera nie usuwa też definicji sieci, która trzyma pulę.

Szeroki prune nie jest narzędziem diagnostycznym. Sięga do niepowiązanych projektów i niszczy dowody, które właśnie zamierzałeś zebrać.

Pule domyślne pomagają tylko następnemu przydzieleniu

Ustawienie domyślnej puli adresów demona poprawia przyszłe automatyczne przydzielenia, trzymając je poza zakresami, które rezerwujesz. Ono nie zmienia wstecznie adresów sieci, które już istnieją, i nie rozwiązuje jawnej podsieci, która nakłada się na inną jawną podsieć.

Traktuj to ustawienie jako osobną, zaplanowaną zmianę z własnym restartem, a nie jako część naprawy jednego projektu. Mieszanie obu oznacza, że restart demona wypada w środku niepowiązanego dochodzenia. Zaplanuj go w osobnym oknie. Następnie potwierdź, że jedno nowe automatyczne przydzielenie rzeczywiście wypada poza zarezerwowane zakresy.

Gdy utworzenie się powiedzie, zweryfikuj podsieć, która faktycznie działa, a następnie wykonaj jedno prawdziwe żądanie aplikacji z VPN w zamierzonym stanie. Jeśli pula jest poprawna, a dostęp nadal zawodzi, pozostała praca to wybór trasy, filtrowanie i droga powrotna. To dochodzenie w czasie działania i nie czyni błędu przydzielania wstecznie bezsensownym.

Kolejność pracy: przeczytaj przydzielone pule, wybierz prefiks, który omija i Dockera, i cele VPN, odtwórz sieć celowo, a następnie przetestuj jedno żądanie z podniesionym tunelem.