Android-VPN los die volle gasheernaam op, maar nie die kort naam nie

Jy tikfilesin ’n terminaal-emulator in en niks kom terug nie; jy tikfiles.corp.exampleen dieselfde bediener antwoord dadelik. Niks aan die VPN-geloofsbriewe het verander nie, en die private DNS-bediener was nooit stukkend nie. Op Android volg die kort etiket en die volle naam verskillende paaie deur die oplosser, en een van daardie paaie hang af van ’n instelling wat die eienaar van die tonnel moet verskaf. Die besluit voor jou is nie watter DNS-bediener om te verander nie, maar wie beheer die netwerk wat die app werklik gebruik.

’n Soekdomein is nie ’n adres nie. Dit is ’n lys agtervoegsels wat die oplosser by ’n kaal etiket voeg voordat hy opgee.

’n Soekagtervoegsel en ’n DNS-bediener is aparte velde

Die oplosseradres sê vir Android waar om te vra. Die soekagtervoegsel sê vir hom waarvoor om te vra wanneer jy net die linkerkantste etiket gee. Albei woon op dieselfde netwerkobjek, en enigeen kan op sy eie ontbreek.

Daardie onafhanklikheid is juis hoekom die volle gasheernaam werk. ’n Volledig gekwalifiseerde naam het geen agtervoegsel nodig nie, want dit is reeds die string wat na die bediener gaan.

Android stel die skeiding bloot deurLinkProperties. Die DNS-bedienerlys en die domeinsoeklys sit op dieselfde objek, en die tweede een is gereeld leeg selfs wanneer die eerste vol is. ’n Netwerk met ’n oplosser maar geen domein is ’n netwerk waar die agtervoegsel nooit toegepas is nie — nie ’n bediener wat die kort naam geweier het nie.

Lees die effektiewe netwerk voordat jy iets verander

Wi-Fi, sellulêr en ’n VPN-koppelvlak is drie aparte netwerke, en die tonnel word die verstek sodra dit opkom. Die agtervoegsel wat op kantoor-Wi-Fi gewerk het, is dus nie outomaties die agtervoegsel wat geld terwyl die tonnel aktief is nie. Ondersoek die netwerk waarop die app werklik gekies is, nie die een wat jy verlede week opgestel het nie.

’n Terminaalskulp op die toestel is ’n swak getuie hier, want syresolv.confweerspieël een siening van die oplosser eerder as dié van elke app.

Blaaier-adresbalke voeg nog ’n laag bo-op: ’n kaal woord kan as ’n soektog behandel word, of opgelos word deurdie blaaier se eie geënkripteerde-DNS-beleid, so ’n bladsy wat in Chrome laai bewys niks oor stelselopsoeke nie. Toets met iets wat die platform-oplosser gebruik en wys wat teruggekom het. Hardloop dan die kort vorm en die volle vorm in dieselfde sessie, op dieselfde netwerk, en let op watter een ’n antwoord opgelewer het.

As jy die VPN-app bou, koppel die agtervoegsel in die bouer

Wanneer jou app die koppelvlak vestig deurVpnService,addSearchDomainis die ondersteunde invoer hiervoor. Dit neem ’n domeinstring sooscorp.example, en dit is nie ’n alternatiewe manier om ’n bedieneradres deur te gee nie.

Die oproep bind die agtervoegsel aan die netwerk wat jy bou, so daar is geen globale instelling om daarna om te draai nie. As die app die koppelvlak afbreek en dit by herverbinding herbou, moet die agtervoegsel weer by die nuwe bouer gevoeg word, anders kom die vervangende netwerk sonder dit op.

Dit is waar baie lessenaarprofiel-invoere die veld verloor. Die uitvoerder skryf die domein in sy eie model, die Android-voorkant karteer net die opsies wat hy ken, en die resulterende koppelvlak lyk in elke ander opsig korrek. ’n Profiel wat op ’n skootrekenaar werk en op ’n selfoon faal, is gewoonlik ’n karteringsgaping, nie ’n protokolprobleem nie.

As jy net die VPN verbruik, is dit nie joune om te stel nie

Daar is geen kliëntkant-wysiging wat ’n agtervoegsel byvoeg nie, en geen globale eienskap wat jy kan verander om een na te maak nie. Die waarde word gelewer deur wie ook al die tonnel besit: in die bestuurde kliënt se profiel, in sy kartering per platform, of deur wat die bediener ook al stoot. Sê op watter platform jy is en watter naam faal, want die lessenaar- en mobiele voorkante verskil juis op hierdie veld.

Om weer ’n lessenaarprofiel in te voer bewys niks oor die mobiele kartering nie.

Drie voorwaardes bepaal of jy ’n gebrek of ’n verwagte beperking het. Eerstens, behandel die organisasie die kort etiket hoegenaamd as ’n ondersteunde naam, of is dit ’n gerief wat net ooit op kantoor-Wi-Fi gewerk het? Tweedens, kom die falende opsoek van ’n blaaier, wat die stelseloplosser heeltemal kan omseil? Derdens, is die kort naam bedoel om oor die tonnel bereikbaar te wees, of net vanaf die LAN? As die laaste antwoord net-LAN is, sal die byvoeg van ’n agtervoegsel ’n naam skep wat buite die kantoor oplos en dan nie kan roeteer nie.

Wanneer die agtervoegsel teenwoordig is en kort name steeds faal

As die domeinsoeklys reedscorp.examplewys, moenie die agtervoegsel blameer nie. Kyk of die oplosser hoegenaamd ’n antwoord vir die uitgebreide naam gee, want ’n agtervoegsel verander net die vraag wat jy vra. Dit maak nooit die bediener gesaghebbend vir ’n sone wat hy nie huisves nie.

Kyk dan na die roete. ’n Adres wat oplos maar nie deur die tonnel gedra word nie, faal by verbindingstyd, wat identies lyk aan ’n opsoekfout in ’n blaaier wat stilweg opgee.

Sertifikate verdien ’n eie vermelding. HTTPS-validering gebruik die gasheernaam wat jy werklik getik het, so ’n kort naam wat korrek uitbrei, bied steedsfilesin die handshake aan. ’n Sertifikaat wat virfiles.corp.exampleuitgereik is, sal nie daarvoor valideer nie, en daardie fout is korrekte gedrag eerder as ’n simptoom van die DNS-probleem waarmee jy begin het.

Wat om volgende te doen

Bevestig die skeiding voordat jy enigiets aanraak: volle naam los op, kort naam nie, dieselfde app, dieselfde sessie. Vind dan die gekose netwerk en lees sy domeinsoeklys saam met sy oplosserlys. Watter van die twee ook al leeg is, sê vir jou wie moet optree — jy, as jy die app besit; die tonneloperateur, as jy dit nie doen nie.

Ten slotte, verkies die volle diensgasheernaam in boekmerke en kliëntkonfigurasie waar draagbaarheid saak maak. Dit oorleef ’n netwerkskakeling, dit hang nie af van ’n kartering wat die mobiele voorkant dalk nie implementeer nie, en dit stem ooreen met die naam waarvoor ’n sertifikaat uitgereik is.