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, з якой вы пачалі.

Што рабіць далей

Пацвердзіце раздзяленне, перш чым нешта чапаць: поўнае імя развязваецца, кароткае — не, тое ж прыкладанне, тая ж сесія. Затым знайдзіце выбраную сетку і прачытайце яе спіс пошуку даменаў разам са спісам рэзалвераў. Той з двух, які пусты, пакажа, хто павінен дзейнічаць — вы, калі валодаеце прыкладаннем; аператар тунеля, калі не.

Нарэшце, аддавайце перавагу поўнаму імі службы ў закладках і канфігурацыі кліента там, дзе важная пераноснасць. Яно перажывае змену сеткі, не залежыць ад адлюстравання, якое мабільны франтэнд можа не рэалізаваць, і супадае з імем, для якога выдадзены сертыфікат.