Sdílení sítě VPN kontejneru: co se stane s DNS

Sdílení síťového jmenného prostoru VPN kontejneru dá vaší aplikaci rozhraní a trasy tunelu. Ono jí nedá resolver tunelu, ani sloučenou kopii čehokoli jiného na hostiteli. Tato mezera vytváří velmi konkrétní poruchu: veřejná jména se překládají, interní ne, a aplikace, která selže, vypadá, jako by používala špatný DNS server, protože ho opravdu používá. Oprava je obvykle menší, než diagnóza naznačuje.

Krok 1: Testujte z aplikace, ne z hostitele

Spusťte vyhledávání uvnitř kontejneru, který má problém, ne na hostiteli a ne v prohlížeči. docker exec app-container getent hosts db.internal odpovídá na jedinou důležitou otázku: co vrací resolver tohoto procesu.

Pokud hostitel jméno přeloží a kontejner ne, našli jste závadu. Všechno další je volba podporovaného způsobu opravy.

Krok 2: Přečtěte si podporovaný model runtime

Dokumentace sítí Dockeru zaznamenává omezení pro přepínače DNS u kontejnerů, které sdílejí síťový režim jiného kontejneru. V Compose network_mode: service:vpn váže aplikaci na jmenný prostor VPN kontejneru a u jednotlivých služeb dns se nastavení nechovají tak jako u běžné služby. Řešení, které dostanete, je to, které má sdílený jmenný prostor.

Uživatelem definované mostní sítě také používají vestavěný DNS Dockeru jinak než výchozí most. Proto dns klauzule zkopírovaná z funkčního příkladu mostu nemusí ve sdíleném zásobníku udělat vůbec nic. Před zkopírováním klauzule zkontrolujte uspořádání.

Adresa zpětné smyčky vždy odkazuje na příslušný síťový kontext. Uvnitř sdíleného jmenného prostoru 127.0.0.1 není resolverem hostitele.

Krok 3: Sledujte dotaz k jeho příjemci

Přečtěte si konfiguraci resolveru aplikace a poté jakýkoli šifrovaný DNS specifický pro aplikaci, který aplikace přináší, protože aplikace s vlastním resolverem ignoruje soubor, který jste upravili. Poté zkontrolujte, zda je zvolený resolver dostupný v rámci tras VPN a politiky firewallu. Adresa resolveru na vzdálené straně tunelu je k ničemu, pokud k ní jmenný prostor nemá trasu. Před úpravou jakéhokoli souboru příjemce potvrďte.

Stránka pro kontrolu IP v prohlížeči vám neřekne, kam dotazy na jména odešly. Řekne vám, kam odešlo jedno HTTP spojení.

Krok 4: Opravte dvě třídy selhání různě

Pokud selhávají jména služeb, zatímco veřejná jména fungují, problém je v objevování služeb uvnitř sítě kontejnerů, ne v seznamu veřejných resolverů. Změna každé veřejné adresy DNS nevytvoří záznamy, které mechanismus objevování sítě nikdy nedostal za úkol vytvořit.

Pokud selhávají obě třídy, začněte dostupností resolveru. Pokud selhává jen jedna, začněte mechanismem objevování. Obě mají různé vlastníky, a proto jedna oprava nikdy nepokryje obě.

Krok 5: Po novém vytvoření otestujte znovu

Změňte konfiguraci podporovaným mechanismem runtime a poté znovu vytvořte kontejnery, místo abyste upravovali soubory uvnitř běžícího. Otestujte nové soukromé jméno, nové veřejné jméno a požadavek aplikace, který po vyhledávání následuje. Úprava /etc/resolv.conf uvnitř kontejneru zmizí při novém vytvoření a přesvědčí vás, že oprava fungovala, když nefungovala.

Poznamenejte si vlastníka resolveru a očekávaný jmenný prostor vedle definice sdílené sítě. Další člověk bude potřebovat obojí.