Споделяне на мрежата на VPN контейнер: какво се случва с DNS

Споделянето на пространството от имена на мрежата на VPN контейнер дава на приложението интерфейсите и маршрутите на тунела. То не му дава резолвера на тунела, нито обединено копие на нещо друго на хоста. Тази разлика поражда много специфична повреда: публичните имена се разрешават, вътрешните не, а приложението, което се проваля, изглежда сякаш използва грешен DNS сървър, защото е точно така. Поправката обикновено е по-малка, отколкото предполага диагнозата.

Стъпка 1: Тествайте от приложението, не от хоста

Изпълнете търсенето в контейнера, който има проблема, не на хоста и не в браузър. docker exec app-container getent hosts db.internal отговаря на единствения въпрос, който има значение: какво връща резолверът на този процес.

Ако хостът разрешава името, а контейнерът не, открили сте повредата. Всичко след това е избор на поддържан начин да я поправите.

Стъпка 2: Прочетете поддържания модел на средата

Документацията на Docker за мрежи записва ограничения за DNS флагове на контейнери, които споделят мрежовия режим на друг контейнер. В Compose network_mode: service:vpn обвързва приложението с пространството от имена на VPN контейнера, а за всяка услуга dns настройки не се държат така, както при обикновена услуга. Разрешението, което получавате, е това, което има споделеното пространство от имена.

Мрежите тип мост, дефинирани от потребителя, също използват вградения DNS на Docker по различен начин от моста по подразбиране. Ето защо dns блок, копиран от работещ пример за мост, може да не направи нищо в споделен стек. Проверете схемата, преди да копирате блока.

Адресът за обратна връзка винаги се отнася до съответния мрежов контекст. Вътре в споделено пространство от имена 127.0.0.1 не е резолверът на хоста.

Стъпка 3: Проследете заявката до нейния получател

Прочетете конфигурацията на резолвера на приложението, след това всеки специфичен за приложението криптиран DNS, който то носи, защото приложение със собствен резолвер игнорира файла, който сте редактирали. След това проверете дали избраният резолвер е достъпен под маршрутите и политиката на защитната стена на VPN. Адрес на резолвер от другата страна на тунела е безполезен, ако пространството от имена няма маршрут до него. Потвърдете получателя, преди да редактирате какъвто и да е файл.

Страница за проверка на IP в браузър не може да ви каже къде са отишли заявките за имена. Тя казва къде е отишла една HTTP връзка.

Стъпка 4: Поправяйте двата класа повреди по различен начин

Ако имената на услуги се провалят, докато публичните имена работят, проблемът е откриването на услуги в мрежата на контейнера, а не списъкът с публични резолвери. Промяната на всеки публичен DNS адрес няма да създаде записи, които механизмът за откриване на мрежата никога не е бил помолен да създаде.

Ако и двата класа се провалят, започнете с достъпността до резолвера. Ако само един се проваля, започнете с механизма за откриване. Двата имат различни собственици, затова една поправка никога не покрива и двата.

Стъпка 5: Тествайте отново след пресъздаване

Променете конфигурацията чрез поддържания механизъм на средата, след което пресъздайте контейнерите, вместо да редактирате файлове в работещ контейнер. Тествайте свежо частно име, свежо публично име и заявката на приложението, която следва търсенето. Промяна в /etc/resolv.conf в контейнер изчезва при пресъздаване и ще ви убеди, че поправката е проработила, когато не е.

Запишете собственика на резолвера и очакваното пространство от имена до дефиницията на споделената мрежа. Следващият човек ще се нуждае от двете.