VPN v Androidu razreši polno ime gostitelja, ne pa kratkega

Vtipkatefilesv emulator terminala in nič se ne vrne; vtipkatefiles.corp.examplein isti strežnik se takoj odzove. V poverilnicah VPN se ni nič spremenilo in zasebni strežnik DNS se ni nikoli pokvaril. V Androidu gresta kratka oznaka in polno ime po različnih poteh skozi razreševalnik, ena od teh poti pa je odvisna od nastavitve, ki jo mora zagotoviti lastnik tunela. Odločitev pred vami ni, kateri strežnik DNS zamenjati, ampak kdo nadzoruje omrežje, ki ga aplikacija dejansko uporablja.

Iskalna domena ni naslov. Je seznam pripon, ki jih razreševalnik doda goli oznaki, preden obupa.

Iskalna pripona in strežnik DNS sta ločeni polji

Naslov razreševalnika pove Androidu, kje naj vpraša. Iskalna pripona pove, po čem naj vpraša, ko navedete le skrajno levo oznako. Oba živita na istem omrežnem objektu in vsak lahko manjka sam.

Prav ta neodvisnost pojasnjuje, zakaj polno ime gostitelja deluje. Popolnoma kvalificirano ime ne potrebuje pripone, ker je že niz, ki gre na strežnik.

Android to ločitev razkrije prekLinkProperties. Seznam strežnikov DNS in seznam iskanja domen ležita na istem objektu, drugi pa je pogosto prazen, tudi ko je prvi poln. Omrežje z razreševalnikom, a brez domene, je omrežje, v katerem pripona ni bila nikoli uporabljena — ne strežnik, ki bi zavrnil kratko ime.

Preberite dejansko omrežje, preden karkoli spremenite

Wi-Fi, mobilno omrežje in vmesnik VPN so tri ločena omrežja, tunel pa postane privzet, ko se dvigne. Pripona, ki je delovala v pisarniškem Wi-Fi, torej ni samodejno pripona, ki velja, dokler je tunel aktiven. Preverite omrežje, na katerem je aplikacija dejansko izbrana, ne tistega, ki ste ga nastavili prejšnji teden.

Terminalska lupina na napravi je tu slab priča, ker njenresolv.confodraža en pogled na razreševalnik in ne pogleda vsake aplikacije.

Naslovne vrstice brskalnikov dodajo še eno plast: gola beseda je lahko obravnavana kot iskalna poizvedba ali razrešena preklastne politike brskalnika za šifrirani DNS, zato stran, ki se naloži v Chromu, ne dokazuje ničesar o sistemskih poizvedbah. Preizkusite z nečim, kar uporablja razreševalnik platforme in izpiše, kaj se je vrnilo. Nato zaženite kratko in polno obliko v isti seji, v istem omrežju, in zabeležite, katera je dala odgovor.

Če razvijate aplikacijo VPN, pripono pritrdite v graditelju

Ko vaša aplikacija vzpostavi vmesnik prekVpnService,addSearchDomainje to podprt vnos za to. Sprejme niz domene, na primercorp.example, in ni alternativni način za posredovanje naslova strežnika.

Klic veže pripono na omrežje, ki ga gradite, zato ni globalne nastavitve, ki bi jo pozneje obrnili. Če aplikacija vmesnik razstavi in ga ob ponovni povezavi znova zgradi, mora novi graditelj pripono znova dodati, sicer se nadomestno omrežje dvigne brez nje.

Tu veliko uvozov namiznih profilov izgubi to polje. Izvoznik zapiše domeno v svoj model, čelni del Androida preslika le možnosti, ki jih pozna, in nastali vmesnik je videti pravilen v vseh drugih pogledih. Profil, ki deluje na prenosniku in odpove na telefonu, je običajno vrzel v preslikavi, ne težava s protokolom.

Če VPN samo uporabljate, to ni vaša nastavitev

Ni urejanja na strani odjemalca, ki bi dodalo pripono, in ni globalne lastnosti, ki bi jo spremenili, da bi jo ponaredili. Vrednost zagotovi tisti, ki ima tunel: v profilu upravljanega odjemalca, v njegovi preslikavi po platformah ali prek tistega, kar pošlje strežnik. Povejte, na kateri platformi ste in katero ime odpove, ker se namizni in mobilni čelni del razlikujeta prav na tem polju.

Ponovni uvoz namiznega profila spet ne dokaže ničesar o mobilni preslikavi.

Trije pogoji odločijo, ali imate napako ali pričakovano omejitev. Prvič, ali organizacija kratko oznako sploh obravnava kot podprto ime, ali je to udobje, ki je kdaj delovalo le v pisarniškem Wi-Fi? Drugič, ali prihaja neuspešna poizvedba iz brskalnika, ki lahko popolnoma obide sistemski razreševalnik? Tretjič, ali naj bo kratko ime dosegljivo prek tunela ali le iz LAN? Če je zadnji odgovor le-LAN, bi dodajanje pripone ustvarilo ime, ki se razreši zunaj pisarne in se nato ne usmeri.

Ko je pripona prisotna in kratka imena še vedno odpovedo

Če seznam iskanja domen že prikazujecorp.example, nehajte kriviti pripono. Preverite, ali razreševalnik sploh vrne odgovor za razširjeno ime, ker pripona spremeni le vprašanje, ki ga postavljate. Nikoli ne naredi strežnika pristojnega za območje, ki ga ne gosti.

Nato preverite pot. Naslov, ki se razreši, a ga tunel ne prenaša, odpove ob povezavi, kar je videti enako kot neuspešna poizvedba v brskalniku, ki tiho obupa.

Potrdila si zaslužijo svojo omembo. Preverjanje HTTPS uporablja ime gostitelja, ki ste ga dejansko vtipkali, zato kratko ime, ki se pravilno razširi, v rokovanju vseeno predstavifiles. Potrdilo, izdano zafiles.corp.examplezanjo ne bo veljavno, in ta napaka je pravilno vedenje, ne simptom težave z DNS, s katero ste začeli.

Kaj storiti naprej

Potrdite ločitev, preden se česar koli dotaknete: polno ime se razreši, kratko ne, ista aplikacija, ista seja. Nato poiščite izbrano omrežje in preberite njegov seznam iskanja domen ob seznamu razreševalnikov. Kateri od dveh je prazen, vam pove, kdo mora ukrepati — vi, če je aplikacija vaša; operater tunela, če ni.

Na koncu dajte prednost polnemu imenu storitve v zaznamkih in konfiguraciji odjemalca, kjer je pomembna prenosljivost. Preživi menjavo omrežja, ni odvisno od preslikave, ki je mobilni čelni del morda ne izvaja, in se ujema z imenom, za katero je bilo izdano potrdilo.