WireGuard DNS на iPhone: домейнът е само суфикс за търсене

Пишете един ред с адрес на резолвер и домейн на компанията, очаквайки само имената в този домейн да използват резолвера на тунела. При клиента за Apple всички имена сега отиват там и кратките имена в домейна също се разрешават. Редът прави две отделни неща и само едното от тях е за това кои заявки обработва тунелът. Другото е удобство при писане, повишено до политика от желателно тълкуване.

В какво се превръща DNS редът

Клиентът чете записа като списък и класифицира всеки елемент по форма. Всичко, което изглежда като адрес, става DNS сървър; всичко, което изглежда като домейн, става суфикс за търсене. И двете попадат в настройките на тунела, но в различни полета. Илюстративен ред за тунел, който носи частен резолвер и един вътрешен домейн, изглежда така.

DNS = 10.24.8.53, lab.internal.example

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

Две полета на Apple, две различни задачи

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

Списъкът с домейни за съвпадение е различно свойство. Той решава кои пространства от имена използват този набор DNS настройки, а празният запис означава домейна по подразбиране, а не конкретен суфикс. генератор на настройки за пакетен тунел в клиента за Apple следва този модел. Той поставя анализираните суфикси за търсене в списъка за търсене и когато има сървъри, задава списъка за съвпадение на празния низ. Резултатът е резолвер на тунела, който отговаря на всичко, което системата му изпраща, плюс суфикс, който помага с кратките имена.

Така че домейн в този ред не е селектор на пространство от имена. Добавянето на още един не стеснява заявките, които тунелът използва, а премахването му също не ги разширява. Единственото, което се променя, е колко кратки имена се довършват.

Защо всяко име все още стига до резолвера на тунела

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

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

Какво всъщност би изисквал разделеният DNS

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

На управлявани устройства на Apple това обикновено се доставя чрез конфигурационен профил, който носи DNS настройките за конкретния домейн. Това е различен механизъм от конфигурационния файл на WireGuard и двете могат да съществуват заедно само ако клиентът зачита профила. Проверете как клиентът ви всъщност нарича полето, преди да приемете, че двата продукта се държат еднакво. Скрипт wg-quick на Mac и приложението WireGuard на iPhone четат подобни редове и ги инсталират през различни слоеве.

Четете инсталираните настройки, а не конфигурацията

На Mac можете да проверите до какво е стигнала системата и това е по-информативно от препрочитането на файла, който сте написали. Списъкът с резолвери показва кои сървъри са конфигурирани за кои домейни, а ограничените заявки показват кой е победил. Клиент, който разваля реда, го показва тук, а не във файла, който сте написали. На iOS няма еквивалентен команден ред, затова доказателството там е резултат: частно име, което се разрешава през тунела, и публично име, чийто отговор издава кой резолвер е отговорил.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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