Udostępnianie sieci kontenera VPN: co dzieje się z DNS

Udostępnianie przestrzeni nazw sieci kontenera VPN daje aplikacji interfejsy i trasy tunelu. To nie daje jej resolvera tunelu, ani scalonej kopii czegokolwiek innego na hoście. Ta luka powoduje bardzo konkretną awarię: nazwy publiczne są rozwiązywane, wewnętrzne nie, a aplikacja, która zawodzi, wygląda, jakby używała złego serwera DNS, bo tak jest. Naprawa jest zwykle mniejsza, niż sugeruje diagnoza.

Krok 1: Testuj z aplikacji, nie z hosta

Uruchom wyszukiwanie wewnątrz kontenera, który ma problem, nie na hoście i nie w przeglądarce. docker exec app-container getent hosts db.internal odpowiada na jedyne ważne pytanie: co zwraca resolver tego procesu.

Jeśli host rozwiązuje nazwę, a kontener nie, znalazłeś awarię. Wszystko dalej to wybór obsługiwanego sposobu jej naprawy.

Krok 2: Przeczytaj obsługiwany model runtime

Dokumentacja sieci Dockera odnotowuje ograniczenia dotyczące flag DNS dla kontenerów, które współdzielą tryb sieci innego kontenera. W Compose network_mode: service:vpn wiąże aplikację z przestrzenią nazw kontenera VPN, a dla każdej usługi dns ustawienia nie zachowują się tak jak w zwykłej usłudze. Rozwiązanie, które otrzymujesz, jest tym, które ma wspólna przestrzeń nazw.

Sieci mostkowe definiowane przez użytkownika również używają wbudowanego DNS Dockera inaczej niż domyślny mostek. Dlatego dns klauzula skopiowana z działającego przykładu mostka może w ogóle nic nie robić we wspólnym stosie. Sprawdź układ przed skopiowaniem klauzuli.

Adres pętli zwrotnej zawsze odnosi się do odpowiedniego kontekstu sieciowego. Wewnątrz wspólnej przestrzeni nazw 127.0.0.1 nie jest resolverem hosta.

Krok 3: Śledź zapytanie aż do jego odbiorcy

Przeczytaj konfigurację resolvera aplikacji, a następnie każdy szyfrowany DNS specyficzny dla aplikacji, który ona ze sobą niesie, ponieważ aplikacja uruchamiająca własny resolver ignoruje plik, który edytowałeś. Następnie sprawdź, czy wybrany resolver jest osiągalny w ramach tras i polityki zapory VPN. Adres resolvera po drugiej stronie tunelu jest bezużyteczny, jeśli przestrzeń nazw nie ma do niego trasy. Potwierdź odbiorcę, zanim edytujesz jakikolwiek plik.

Strona sprawdzania IP w przeglądarce nie może ci powiedzieć, dokąd poszły zapytania o nazwy. Mówi, dokąd poszło jedno połączenie HTTP.

Krok 4: Napraw dwie klasy awarii inaczej

Jeśli nazwy usług zawodzą, a nazwy publiczne działają, problem leży w wykrywaniu usług wewnątrz sieci kontenerów, a nie na liście publicznych resolverów. Zmiana każdego publicznego adresu DNS nie utworzy rekordów, o które mechanizm wykrywania sieci nigdy nie został poproszony.

Jeśli zawiodą obie klasy, zacznij od osiągalności resolvera. Jeśli zawodzi tylko jedna, zacznij od mechanizmu wykrywania. Obie mają różnych właścicieli, dlatego jedna naprawa nigdy nie obejmuje obu.

Krok 5: Przetestuj ponownie po odtworzeniu

Zmień konfigurację przez obsługiwany mechanizm runtime, a następnie odtwórz kontenery zamiast edytować pliki w działającym. Przetestuj nową nazwę prywatną, nową nazwę publiczną i żądanie aplikacji następujące po wyszukiwaniu. Zmiana w /etc/resolv.conf wewnątrz kontenera znika przy odtworzeniu i przekona cię, że naprawa zadziałała, gdy nie zadziałała.

Zapisz właściciela resolvera i oczekiwaną przestrzeń nazw obok definicji wspólnej sieci. Następna osoba będzie potrzebować obu.