Android VPN решава пуно име домаћина, али не кратко

Укуцате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, и није алтернативни начин да се пренесе адреса сервера.

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

Овде многи увози desktop профила изгубе то поље. Извозник уписује домен у свој модел, Android frontend мапира само опције које познаје, а резултујући интерфејс изгледа исправно у сваком другом погледу. Профил који ради на лаптопу и пада на телефону обично је празнина у мапирању, а не проблем протокола.

Ако само користите VPN, ово није ваше да постављате

Нема измене на страни клијента која додаје суфикс, ни глобалног својства које можете променити да га лажирате. Вредност доставља онај који поседује тунел: у профилу управљаног клијента, у његовом мапирању по платформи или кроз оно што сервер пошаље. Реците на којој сте платформи и које име пада, јер се desktop и мобилни frontend разилазе управо на том пољу.

Поновни увоз desktop профила опет не доказује ништа о мобилном мапирању.

Три услова одлучују имате ли дефект или очекивано ограничење. Прво, третира ли организација кратку ознаку уопште као подржано име, или је то погодност која је икада радила само на канцеларијском Wi-Fi-ју? Друго, долази ли неуспела претрага из прегледача, који може потпуно заобићи системски разрешивач? Треће, треба ли кратко име бити доступно кроз тунел, или само са LAN-а? Ако је последњи одговор само LAN, додавање суфикса створило би име које се разрешава изван канцеларије и затим се не рутира.

Када је суфикс присутан, а кратка имена и даље падају

Ако списак претраге домена већ приказујеcorp.example, престаните да кривите суфикс. Проверите да ли разрешивач икакав одговор враћа за проширено име, јер суфикс мења само питање које постављате. Он никада не чини сервер меродавним за зону коју не хостује.

Затим проверите руту. Адреса која се разрешава али је тунел не преноси пада при спајању, што изгледа исто као неуспела претрага у прегледачу који тихо одустане.

Сертификати заслужују посебан спомен. HTTPS валидација користи име домаћина које сте стварно укуцали, па кратко име које се исправно прошири и даље представљаfilesу руковању. Сертификат издат заfiles.corp.exampleнеће се валидирати за њега, а та грешка је исправно понашање, а не симптом DNS проблема с којим сте почели.

Шта даље

Потврдите поделу пре него што било шта дирате: пуно име се разрешава, кратко не, иста апликација, иста сесија. Затим пронађите изабрану мрежу и прочитајте њен списак претраге домена уз списак разрешивача. Који год од два буде празан, каже вам ко мора да делује — ви, ако поседујете апликацију; оператер тунела, ако не.

На крају, дајте предност пуном имену услуге у обележивачима и клијентској конфигурацији где је преносивост важна. Оно преживљава промену мреже, не зависи од мапирања које мобилни frontend можда не имплементира и поклапа се с именом за које је сертификат издат.