VPN в Android розв'язує повне ім'я хоста, але не коротке

Ви вводитеfilesв емуляторі термінала, і нічого не повертається; ви вводитеfiles.corp.exampleі той самий сервер відповідає одразу. В облікових даних VPN нічого не змінилося, і приватний DNS-сервер ніколи не ламався. В Android коротка мітка й повне ім'я йдуть різними шляхами через резолвер, і один із цих шляхів залежить від параметра, який має надати власник тунелю. Рішення перед вами — не який DNS-сервер змінити, а хто контролює мережу, яку застосунок справді використовує.

Домен пошуку — це не адреса. Це список суфіксів, які резолвер додає до голої мітки, перш ніж здатися.

Суфікс пошуку й DNS-сервер — різні поля

Адреса резолвера каже Android, куди звертатися. Суфікс пошуку каже, про що питати, коли ви вказуєте лише найлівішу мітку. Обидва живуть на одному мережевому об'єкті, і кожен може бути відсутній сам по собі.

Саме ця незалежність пояснює, чому повне ім'я хоста працює. Повністю визначеному імені суфікс не потрібен, бо воно вже є рядком, що йде на сервер.

Android показує цей поділ черезLinkProperties. Список DNS-серверів і список пошуку доменів лежать на одному об'єкті, і другий часто порожній навіть тоді, коли перший заповнений повністю. Мережа з резолвером, але без домену — це мережа, у якій суфікс ніколи не застосовувався, а не сервер, що відмовив у короткому імені.

Прочитайте чинну мережу, перш ніж щось змінювати

Wi-Fi, мобільна мережа й інтерфейс VPN — три окремі мережі, і тунель стає типовим, щойно піднімається. Тому суфікс, який працював в офісному Wi-Fi, не обов'язково є суфіксом, чинним під час активного тунелю. Перевіряйте мережу, на якій застосунок справді вибрано, а не ту, яку ви налаштували минулого тижня.

Термінальна оболонка на пристрої тут поганий свідок, бо їїresolv.confвідображає один погляд на резолвер, а не погляд кожного застосунку.

Адресні рядки браузерів додають ще один шар: голе слово може трактуватися як пошуковий запит або розв'язуватися черезвласну політику браузера щодо зашифрованого DNS, тож сторінка, що завантажується в Chrome, нічого не доводить про системні запити. Перевіряйте чимось, що використовує резолвер платформи й друкує, що повернулося. Потім запустіть коротку й повну форму в одній сесії, в одній мережі, і занотуйте, яка дала відповідь.

Якщо ви створюєте застосунок VPN, прикріплюйте суфікс у конструкторі

Коли ваш застосунок піднімає інтерфейс черезVpnService,addSearchDomainце підтримуваний ввід для цього. Він приймає рядок домену, наприкладcorp.example, і це не альтернативний спосіб передати адресу сервера.

Виклик прив'язує суфікс до мережі, яку ви будуєте, тому глобального налаштування, яке можна перемкнути потім, немає. Якщо застосунок зносить інтерфейс і під час повторного підключення будує його заново, новому конструктору треба знову додати суфікс, інакше мережа-заміна піднімається без нього.

Саме тут багато імпортів профілів з комп'ютера втрачають це поле. Експортер записує домен у власну модель, фронтенд Android відображає лише ті опції, які знає, і отриманий інтерфейс виглядає правильним у всіх інших відношеннях. Профіль, який працює на ноутбуці й не працює на телефоні, зазвичай є прогалиною у відображенні, а не проблемою протоколу.

Якщо ви лише користуєтеся VPN, це не вам налаштовувати

Немає клієнтської правки, яка додає суфікс, і немає глобальної властивості, яку можна змінити, щоб його підробити. Значення надає той, кому належить тунель: у профілі керованого клієнта, у його відображенні за платформами або через те, що надсилає сервер. Скажіть, на якій ви платформі й яке ім'я не працює, бо десктопний і мобільний фронтенди розходяться саме в цьому полі.

Повторний імпорт профілю з комп'ютера знову нічого не доводить про мобільне відображення.

Три умови вирішують, у вас дефект чи очікуване обмеження. По-перше, чи вважає організація коротку мітку підтримуваним іменем узагалі, чи це зручність, яка колись працювала лише в офісному Wi-Fi? По-друге, чи приходить невдалий запит із браузера, який може повністю обійти системний резолвер? По-третє, коротке ім'я має бути доступним через тунель чи лише з LAN? Якщо остання відповідь — лише LAN, додавання суфікса створило б ім'я, яке розв'язується поза офісом і потім не маршрутизується.

Коли суфікс є, а короткі імена все одно не працюють

Якщо список пошуку доменів уже показуєcorp.example, перестаньте звинувачувати суфікс. Перевірте, чи резолвер узагалі повертає відповідь для розширеного імені, бо суфікс змінює лише запитання, яке ви ставите. Він ніколи не робить сервер повноважним для зони, яку той не обслуговує.

Потім перевірте маршрут. Адреса, яка розв'язується, але не переноситься тунелем, зазнає невдачі під час підключення, і це виглядає точно так само, як невдалий запит у браузері, який тихо здається.

Сертифікати заслуговують на окрему згадку. Перевірка HTTPS використовує ім'я хоста, яке ви справді ввели, тож коротке ім'я, що правильно розширюється, у рукостисканні все одно подаєfiles. Сертифікат, виданий дляfiles.corp.exampleне буде для нього чинним, і ця помилка — правильна поведінка, а не симптом проблеми DNS, з якої ви почали.

Що робити далі

Підтвердьте поділ, перш ніж щось чіпати: повне ім'я розв'язується, коротке — ні, той самий застосунок, та сама сесія. Потім знайдіть вибрану мережу й прочитайте її список пошуку доменів поряд зі списком резолверів. Котрий із двох порожній, той і каже, кому діяти — вам, якщо застосунок ваш; операторові тунелю, якщо ні.

Насамкінець надавайте перевагу повному імені служби в закладках і клієнтській конфігурації там, де важлива переносність. Воно переживає зміну мережі, не залежить від відображення, яке мобільний фронтенд може не реалізувати, і збігається з ім'ям, для якого видано сертифікат.