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

Споделувањето на мрежниот простор од имиња на VPN контејнер и дава на вашата апликација интерфејсите и рутите на тунелот. Тоа не и го дава резолверот на тунелот, ниту обединета копија на нешто друго на хостот. Овој јаз создава многу специфичен дефект: јавните имиња се решаваат, внатрешните не, а апликацијата што паѓа изгледа како да користи погрешен DNS сервер, затоа што навистина го користи. Поправката обично е помала отколку што сугерира дијагнозата.

Чекор 1: Тестирајте од апликацијата, не од хостот

Стартувајте го пребарувањето внатре во контејнерот што има проблем, не на хостот и не во прелистувач. docker exec app-container getent hosts db.internal одговара на единственото важно прашање: што враќа резолверот на овој процес.

Ако хостот го решава името, а контејнерот не, го најдовте дефектот. Сѐ понатаму е избор на поддржан начин да се поправи.

Чекор 2: Прочитајте го поддржаниот модел на runtime

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

Кориснички дефинираните мостни мрежи исто така го користат вградениот DNS на Docker поинаку од стандардниот мост. Затоа dns клаузула копирана од работен пример за мост може да не направи ништо во споделен стек. Проверете ја поставеноста пред да ја копирате клаузулата.

Loopback адресата секогаш се однесува на соодветниот мрежен контекст. Внатре во споделен простор од имиња, 127.0.0.1 не е резолверот на хостот.

Чекор 3: Следете го барањето до неговиот примач

Прочитајте ја конфигурацијата на резолверот на апликацијата, потоа секој шифриран DNS специфичен за апликацијата што таа го носи, затоа што апликација што управува со сопствен резолвер ја игнорира датотеката што ја уредивте. Потоа проверете дали избраниот резолвер е достапен под рутите и политиката на огнениот ѕид на VPN. Адреса на резолвер од другата страна на тунелот е бескорисна ако просторот од имиња нема рута до неа. Потврдете го примачот пред да уредите која било датотека.

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

Чекор 4: Поправете ги двете класи на дефекти различно

Ако имињата на услугите паѓаат додека јавните имиња работат, проблемот е откривање на услуги внатре во контејнерската мрежа, не списокот на јавни резолвери. Менувањето на секоја јавна DNS адреса нема да создаде записи што механизмот за откривање на мрежата никогаш не бил замолен да ги создаде.

Ако двете класи паѓаат, започнете со достапноста на резолверот. Ако паѓа само едната, започнете со механизмот за откривање. Двете имаат различни сопственици, затоа една поправка никогаш не ги покрива двете.

Чекор 5: Тестирајте повторно по пресоздавањето

Променете ја конфигурацијата преку поддржаниот механизам на runtime, потоа пресоздајте ги контејнерите наместо да уредувате датотеки во контејнер што работи. Тестирајте ново приватно име, ново јавно име и барањето на апликацијата што следи по пребарувањето. /etc/resolv.conf во контејнерот исчезнува при пресоздавање и ќе ве увери дека поправката работела кога не работела.

Забележете го сопственикот на резолверот и очекуваниот простор од имиња до дефиницијата на споделената мрежа. Следното лице ќе ги има потреба од двете.